@@ -6,9 +6,10 @@ import "tensorboard/compat/proto/cost_graph.proto";
66import "tensorboard/compat/proto/graph.proto" ;
77import "tensorboard/compat/proto/step_stats.proto" ;
88import "tensorboard/compat/proto/cluster.proto" ;
9- import "tensorboard/compat/proto/coordination_config.proto" ;
109import "tensorboard/compat/proto/debug.proto" ;
1110import "tensorboard/compat/proto/rewriter_config.proto" ;
11+ import "tensorboard/compat/proto/rpc_options.proto" ;
12+ import "tensorboard/compat/proto/coordination_config.proto" ;
1213
1314option cc_enable_arenas = true ;
1415option java_outer_classname = "ConfigProtos" ;
@@ -123,6 +124,12 @@ message GPUOptions {
123124 // created with the default. If this field has values set, then the size
124125 // of this must match with the above memory_limit_mb.
125126 repeated int32 priority = 2 ;
127+
128+ // Virtual Device ordinal number determines the device ID of the device.
129+ // A Virtual device with a lower ordinal number always receives the a
130+ // smaller device id. The phyiscal device id and location in the
131+ // virtual device list is used to break ties.
132+ repeated int32 device_ordinal = 3 ;
126133 }
127134
128135 // The multi virtual device settings. If empty (not set), it will create
@@ -132,15 +139,30 @@ message GPUOptions {
132139 // "visible_device_list" filtering if it is set), and the string represented
133140 // device names (e.g. /device:GPU:<id>) will refer to the virtual
134141 // devices and have the <id> field assigned sequentially starting from 0,
135- // according to the order they appear in this list and the "memory_limit"
136- // list inside each element. For example,
142+ // according to the order of the virtual devices determined by
143+ // device_ordinal and the location in the virtual device list.
144+ //
145+ // For example,
137146 // visible_device_list = "1,0"
138147 // virtual_devices { memory_limit: 1GB memory_limit: 2GB }
139- // virtual_devices {}
140- // will create three virtual devices as:
148+ // virtual_devices { memory_limit: 3GB memory_limit: 4GB }
149+ // will create 4 virtual devices as:
141150 // /device:GPU:0 -> visible GPU 1 with 1GB memory
142151 // /device:GPU:1 -> visible GPU 1 with 2GB memory
143- // /device:GPU:2 -> visible GPU 0 with all available memory
152+ // /device:GPU:2 -> visible GPU 0 with 3GB memory
153+ // /device:GPU:3 -> visible GPU 0 with 4GB memory
154+ //
155+ // but
156+ // visible_device_list = "1,0"
157+ // virtual_devices { memory_limit: 1GB memory_limit: 2GB
158+ // device_ordinal: 10 device_ordinal: 20}
159+ // virtual_devices { memory_limit: 3GB memory_limit: 4GB
160+ // device_ordinal: 10 device_ordinal: 20}
161+ // will create 4 virtual devices as:
162+ // /device:GPU:0 -> visible GPU 1 with 1GB memory (ordinal 10)
163+ // /device:GPU:1 -> visible GPU 0 with 3GB memory (ordinal 10)
164+ // /device:GPU:2 -> visible GPU 1 with 2GB memory (ordinal 20)
165+ // /device:GPU:3 -> visible GPU 0 with 4GB memory (ordinal 20)
144166 //
145167 // NOTE:
146168 // 1. It's invalid to set both this and "per_process_gpu_memory_fraction"
@@ -355,41 +377,6 @@ message ThreadPoolOptionProto {
355377 string global_name = 2 ;
356378}
357379
358- message RPCOptions {
359- // If true, always use RPC to contact the session target.
360- //
361- // If false (the default option), TensorFlow may use an optimized
362- // transport for client-master communication that avoids the RPC
363- // stack. This option is primarily for used testing the RPC stack.
364- bool use_rpc_for_inprocess_master = 1 ;
365-
366- // The compression algorithm to be used. One of "deflate", "gzip".
367- string compression_algorithm = 2 ;
368-
369- // If compression_algorithm is set, the compression level to be used.
370- // From 0 (no compression), up to 3.
371- int32 compression_level = 3 ;
372-
373- // Setting cache_rpc_response to true will enable sender side caching of
374- // response for RecvTensorAsync and RecvBufAsync to allow receiver to retry
375- // requests . This is only necessary when the network fabric is experiencing a
376- // significant error rate. Without it we'll fail a step on an network error,
377- // while with it we'll be able to complete long steps (like complex
378- // initializations) in the face of some network errors during RecvTensor.
379- bool cache_rpc_response = 4 ;
380-
381- // Disables TCP connection sharing when opening a new RPC channel.
382- bool disable_session_connection_sharing = 5 ;
383-
384- // Setting num_channels_per_target > 0 allows uses of multiple channels to
385- // communicate to the same target. This can be used to improve the aggregate
386- // throughput on high speed links (e.g 100G) where single connection is not
387- // sufficient to maximize link utilization. Note that a single RPC only goes
388- // on a single channel, this only helps in situations where there are multiple
389- // transfers to the same target overlapping in time.
390- int32 num_channels_per_target = 6 ;
391- }
392-
393380// Metadata about the session.
394381//
395382// This can be used by the runtime and the Ops for debugging, monitoring, etc.
@@ -606,13 +593,10 @@ message ConfigProto {
606593 // Session::Extend() may not be supported.
607594 bool optimize_for_static_graph = 12 ;
608595
609- // This field will eventually be deprecated and replaced by
610- // mlir_bridge_rollout (b/166038521).
611- //
612- // Whether to enable the MLIR-based TF->XLA bridge.
596+ // Whether to enable the MLIR-based TF->XLA bridge. This is only used if set
597+ // to true. Default value or false is ignored. Use mlir_bridge_rollout for
598+ // finer control.
613599 //
614- // This is a replacement to the existing bridge, and not ready for
615- // production usage yet.
616600 // If this option is set to true when a session is created, MLIR is used to
617601 // perform the set of graph transformations to put the graph in a form that
618602 // can be executed with delegation of some computations to an accelerator.
@@ -644,9 +628,6 @@ message ConfigProto {
644628 // to process the TF graph.
645629 MLIR_BRIDGE_ROLLOUT_SAFE_MODE_FALLBACK_ENABLED = 4 ;
646630 }
647- // This field is underdevelopment, for now use enable_mlir_bridge
648- // (b/166038521).
649- //
650631 // Whether to enable the MLIR-based TF->XLA bridge.
651632 MlirBridgeRollout mlir_bridge_rollout = 17 ;
652633
@@ -798,6 +779,9 @@ message RunMetadata {
798779 // level idea of what the built graph looks like (since the various graph
799780 // optimization passes might change the structure of the graph significantly).
800781 repeated FunctionGraphs function_graphs = 4 ;
782+
783+ // Metadata about the session.
784+ SessionMetadata session_metadata = 5 ;
801785}
802786
803787// Defines a connection between two tensors in a `GraphDef`.
0 commit comments