GPUOptions.Experimental

 If non-empty, defines a good GPU ring order on a single worker based on
 device interconnect.  This assumes that all workers have the same GPU
 topology.  Specify as a comma-separated string, e.g. "3,2,1,0,7,6,5,4".
 This ring order is used by the RingReducer implementation of
 CollectiveReduce, and serves as an override to automatic ring order
 generation in OrderTaskDeviceMap() during CollectiveParam resolution.
 

 If non-empty, defines a good GPU ring order on a single worker based on
 device interconnect.  This assumes that all workers have the same GPU
 topology.  Specify as a comma-separated string, e.g. "3,2,1,0,7,6,5,4".
 This ring order is used by the RingReducer implementation of
 CollectiveReduce, and serves as an override to automatic ring order
 generation in OrderTaskDeviceMap() during CollectiveParam resolution.
 

 If kernel_tracker_max_bytes = n > 0, then a tracking event is
 inserted after every series of kernels allocating a sum of
 memory >= n.  If one kernel allocates b * n bytes, then one
 event will be inserted after it, but it will count as b against
 the pending limit.
 

 Parameters for GPUKernelTracker.  By default no kernel tracking is done.
 Note that timestamped_allocator is only effective if some tracking is
 specified.
 If kernel_tracker_max_interval = n > 0, then a tracking event
 is inserted after every n kernels without an event.
 

 If kernel_tracker_max_pending > 0 then no more than this many
 tracking events can be outstanding at a time.  An attempt to
 launch an additional kernel will stall until an event
 completes.
 

 If > 1, the number of device-to-device copy streams to create
 for each GPUDevice.  Default value is 0, which is automatically
 converted to 1.
 

 If true then extra work is done by GPUDevice and GPUBFCAllocator to
 keep track of when GPU memory is freed and when kernels actually
 complete so that we can know when a nominally free memory chunk
 is really not subject to pending use.
 

 If true, uses CUDA unified memory for memory allocations. If
 per_process_gpu_memory_fraction option is greater than 1.0, then unified
 memory is used regardless of the value for this field. See comments for
 per_process_gpu_memory_fraction field for more details and requirements
 of the unified memory. This option is useful to oversubscribe memory if
 multiple processes are sharing a single GPU while individually using less
 than 1.0 per process memory fraction.
 

 The multi virtual device settings. If empty (not set), it will create
 single virtual device on each visible GPU, according to the settings
 in "visible_device_list" above. Otherwise, the number of elements in the
 list must be the same as the number of visible GPUs (after
 "visible_device_list" filtering if it is set), and the string represented
 device names (e.g. /device:GPU:<id>) will refer to the virtual
 devices and have the <id> field assigned sequentially starting from 0,
 according to the order they appear in this list and the "memory_limit"
 list inside each element. For example,
   visible_device_list = "1,0"
   virtual_devices { memory_limit: 1GB memory_limit: 2GB }
   virtual_devices {}
 will create three virtual devices as:
   /device:GPU:0 -> visible GPU 1 with 1GB memory
   /device:GPU:1 -> visible GPU 1 with 2GB memory
   /device:GPU:2 -> visible GPU 0 with all available memory
 NOTE:
 1. It's invalid to set both this and "per_process_gpu_memory_fraction"
    at the same time.
 2. Currently this setting is per-process, not per-session. Using
    different settings in different sessions within same process will
    result in undefined behavior.
 

 The multi virtual device settings. If empty (not set), it will create
 single virtual device on each visible GPU, according to the settings
 in "visible_device_list" above. Otherwise, the number of elements in the
 list must be the same as the number of visible GPUs (after
 "visible_device_list" filtering if it is set), and the string represented
 device names (e.g. /device:GPU:<id>) will refer to the virtual
 devices and have the <id> field assigned sequentially starting from 0,
 according to the order they appear in this list and the "memory_limit"
 list inside each element. For example,
   visible_device_list = "1,0"
   virtual_devices { memory_limit: 1GB memory_limit: 2GB }
   virtual_devices {}
 will create three virtual devices as:
   /device:GPU:0 -> visible GPU 1 with 1GB memory
   /device:GPU:1 -> visible GPU 1 with 2GB memory
   /device:GPU:2 -> visible GPU 0 with all available memory
 NOTE:
 1. It's invalid to set both this and "per_process_gpu_memory_fraction"
    at the same time.
 2. Currently this setting is per-process, not per-session. Using
    different settings in different sessions within same process will
    result in undefined behavior.
 

 The multi virtual device settings. If empty (not set), it will create
 single virtual device on each visible GPU, according to the settings
 in "visible_device_list" above. Otherwise, the number of elements in the
 list must be the same as the number of visible GPUs (after
 "visible_device_list" filtering if it is set), and the string represented
 device names (e.g. /device:GPU:<id>) will refer to the virtual
 devices and have the <id> field assigned sequentially starting from 0,
 according to the order they appear in this list and the "memory_limit"
 list inside each element. For example,
   visible_device_list = "1,0"
   virtual_devices { memory_limit: 1GB memory_limit: 2GB }
   virtual_devices {}
 will create three virtual devices as:
   /device:GPU:0 -> visible GPU 1 with 1GB memory
   /device:GPU:1 -> visible GPU 1 with 2GB memory
   /device:GPU:2 -> visible GPU 0 with all available memory
 NOTE:
 1. It's invalid to set both this and "per_process_gpu_memory_fraction"
    at the same time.
 2. Currently this setting is per-process, not per-session. Using
    different settings in different sessions within same process will
    result in undefined behavior.
 

 The multi virtual device settings. If empty (not set), it will create
 single virtual device on each visible GPU, according to the settings
 in "visible_device_list" above. Otherwise, the number of elements in the
 list must be the same as the number of visible GPUs (after
 "visible_device_list" filtering if it is set), and the string represented
 device names (e.g. /device:GPU:<id>) will refer to the virtual
 devices and have the <id> field assigned sequentially starting from 0,
 according to the order they appear in this list and the "memory_limit"
 list inside each element. For example,
   visible_device_list = "1,0"
   virtual_devices { memory_limit: 1GB memory_limit: 2GB }
   virtual_devices {}
 will create three virtual devices as:
   /device:GPU:0 -> visible GPU 1 with 1GB memory
   /device:GPU:1 -> visible GPU 1 with 2GB memory
   /device:GPU:2 -> visible GPU 0 with all available memory
 NOTE:
 1. It's invalid to set both this and "per_process_gpu_memory_fraction"
    at the same time.
 2. Currently this setting is per-process, not per-session. Using
    different settings in different sessions within same process will
    result in undefined behavior.
 

 The multi virtual device settings. If empty (not set), it will create
 single virtual device on each visible GPU, according to the settings
 in "visible_device_list" above. Otherwise, the number of elements in the
 list must be the same as the number of visible GPUs (after
 "visible_device_list" filtering if it is set), and the string represented
 device names (e.g. /device:GPU:<id>) will refer to the virtual
 devices and have the <id> field assigned sequentially starting from 0,
 according to the order they appear in this list and the "memory_limit"
 list inside each element. For example,
   visible_device_list = "1,0"
   virtual_devices { memory_limit: 1GB memory_limit: 2GB }
   virtual_devices {}
 will create three virtual devices as:
   /device:GPU:0 -> visible GPU 1 with 1GB memory
   /device:GPU:1 -> visible GPU 1 with 2GB memory
   /device:GPU:2 -> visible GPU 0 with all available memory
 NOTE:
 1. It's invalid to set both this and "per_process_gpu_memory_fraction"
    at the same time.
 2. Currently this setting is per-process, not per-session. Using
    different settings in different sessions within same process will
    result in undefined behavior.