Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
A named argument containing either singular float, integer and string values, or repeated float, int and string arrays.
Used in:
,Used to hold backend-specific options.
Used in:
Name of the backend that the specified options apply to.
Flexible map for passing in the options.
Blob profiling information. Profile for a blob is created every time a node outputs to the blob.
Used in:
Name of the blob (corresponds to OperatorDef.output).
required
Profiling statistics.
Protobuf format for blobs that are not Tensors. We use a key to store the type of the blob. For example for a serialized DBProto, the type should be "DBReader" and the content should be a serialized DBProto object.
If blob is not Tensor and is divided into chunks, content_num_chunks contains number of chunks, into which blob was divided.
Used in:
Original Caffe1 Datum copy: this is used in image input op to allow us to load caffe1 serialized datum without having to regenerate the database.
the actual image data, in bytes
Optionally, the datum could also hold float data.
If true data contains an encoded image that need to be decoded
Protobuf format to serialize DBReader.
The name for the DB object in the workspace.
The source of the DB
The type of the DB
The current key of the DB if the DB supports seeking.
Device-specific options. We do not distinguish DeviceOption protos for different DeviceTypes, so currently all devices share the same DeviceOption proto. Fields that are specific to a device type is ignored if the type does not match. Note: if you add fields to the DeviceOption, make sure you add the corresponding changes to IsSameDevice() function in utils/proto_utils.{h,cc}.
Used in:
, ,[general] Options that need to be carried out before running the execution. optional DeviceType device_type = 1 [ default = CPU ];
0 is CPU.
[general] Used together with device_type to identify the exact device
[general] The random seed to start the device random number generator with.
[general] What node this op should execute on. Used for net transformation purposes. Must be empty at execution time.
[CPU and Linux specific] NUMA node id
[general] Extra information passed, not used at execution time currently.
DeviceType that Caffe2 currently supports. Note: if you add a device type, make sure you add the corresponding device line in the DeviceTypeName() function in caffe2/utils/proto_utils.cc and update c10/core/DeviceType.h
In default, we will use CPU.
CUDA.
Reserved for explicit MKLDNN
OpenGL
OpenCL
IDEEP.
AMD HIP
FPGA
MSNPU
XLA / TPU
Change the following number if you add more devices in the code.
This device type is only for test.
ExecutionStep is actually a sort-of-hacky way we simulate iteration right now.
Used in:
ExecutionStep should either contain a set of substeps, or a set of network names to run in this execution step. They should NOT both be set at the same time.
An execution step could be recursive, in which it involves a set of substeps.
Alternatively, an execution step could involve one or more networks. Note that you cannot have both substeps and networks. Choose one. Note that an execution step refers networks by their name. The actual network definition of the same name should be included in the network field of the plan. The reason is that a network object might hold internal states (think of a data layer), so we want to have the same network object that multiple steps could ask to run.
Number of iterations to run this step. The substeps or the networks specified will be run sequentially, and one sequential run is considered one iteration. If this is not set, the number of iterations is assumed to be 1.
Criteria network specifies a single output (TensorCPU<bool>) of size (1), is run on every iteration by the executor, and execution terminates when the output[0] is `false`.
DEPRECATED. Use `run_every_ms`.
If provided, execute this step at every time interval (in millisecs) while its sibiling execution steps execute in parallel. This step is guaranteed to run at least once after all non-interval siblings finished.
If false or not set, execute sub-steps serially. If true, execute all substeps concurrently, each one in a separate thread.
Name of a scalar boolean tensor. ES checks this blob AFTER every substeps/subnets. If specified, and the value is true, then ES will skip the rest and return immediately. This means that the report_net and the first step will always be called. Use cases: 1) the first substep stops the rest if data condition not met 2) the first substep decide which of the rest of the steps should be run. 3) external control ** It is the user's responsibility to not to put this blob in race conditions. ** For example when setting this blob in concurrent substeps
if only_once is true, this step will only be executed once. this ONLY takes effect when using should_stop_blob
Whether to create a child workspace for this step. If yes, the workflow and nets are re-created every time this step is run.
How many copies of the children execution steps to run concurrently.
ExternalDataProto stores the pointer to the content of TensorProto the content are stored in the raw format as little endian
Used in:
used together with type
the size of the entire record (in bytes)
the offset of the starting point, the content may be shared between multiple tensors
the strides of the content
type of the external storage type, can be the following:
Used in:
the container defined in torch/csrc/jit/serialization.h is used, and record_id is the tag to help the runtime identify the data this type of storage is set as DEFAULT and recommended for external data storage
use external file to store the data, and record_id is the POSIX relative path to the file. this (simple) file is only for the data, and the data is stored as little endian in the file
Internal Protobuf format which represents the path in the tree hierarchy for each word in the vocabulary.
Do not use old-stype padding strategies.
VALID and SAME are two strategies adopted in Google DistBelief: it forces the input shape as follows. For SAME, the output is: R_out = ceil(float(R) / float(S)) C_out = ceil(float(C) / float(S)) where R and C are row and column, S is the stride, and K is the kernel. The number of padded pixels is then computed as Pr = ((R_out - 1) * S + K - R) Pc = ((C_out - 1) * S + K - C) When Pr and Pc are even numbers, both sides (left and right, or top and bottom) get half each. When Pr and Pc are odd numbers, the right and the bottom gets the one additional padding pixel. For VALID, padding values of 0 are always used.
CAFFE_LEGACY_POOLING is a flag that notifies the code to use the old Caffe padding strategy. Basically, in caffe2, after padding the convolution and pooling use the same computation strategy: half-windows at the right and bottom are discarded. In Caffe, convolution follows this strategy but if there are some pixels in the half-windows, the pooling layer will actually put one additional output. If you set LegacyPadding to this, we will compute the equivalent padding strategy in caffe2 so that the output size is backward compatible with Caffe. THIS IS NOW DEPRECATED. ANY non-conventional use has to be manually converted.
MapFieldEntry follows the pattern for cross-proto-version maps. See https://developers.google.com/protocol-buffers/docs/proto3#maps
Used in:
Text-format serialized NetDefs.
Info about where the model comes from. Possible use cases: 1) sanity check or diagnose 2) provide info for evaluation.
Used in:
Network definition.
Used in:
, , ,the network's name
Operators that the network contains. Note: this is not named "operator" because that is a reserved word in C++.
The type of network that the net should be run with. This routes the network instantiation to different execution modes. The default mode, "simple", runs the operators in a sequential way as the original Caffe implementation does.
the number of workers, if the operators in the network is to be carried out in parallel. Note: This is to be deprecated. Using the arg field with "num_workers" as key. Note 2: The old uses of this were never actually cleaned up
The device option for the network. If a network has a specific device option and one of its operators does not have it set, we will copy over the device option to the operator. This allows us to basically avoid putting device options at every operator.
Two optional fields to declare external input and output of a net. If these two are set, when a net is created, we will sanity check for every op whether its input is declared (either as an external input, or as an intermediate blob created by one of the ops), and sanity check if all blobs in external_output are produced. In cases of memory optimization, declaring external_input and external_output also ensures that storage of these blobs are persistent: for any blob in external_input and external_output, after a network run finishes, their content are actually the right content. Any intermediate blobs' contents may be overwritten.
Partitioning info, indexed by partition names.
Used in:
Each node in the hierarchy contains links to either leaf nodes or more non-terminal nodes
Used in:
Links to non-terminal children nodes
Links to terminal (leaf) nodes
Represents specification of an operation cost.
Used in:
Operator Definition.
Used in:
the name of the input blobs
the name of output top blobs
the operator name. This is optional.
the operator type. This is needed to create the object from the operator registry.
arg is for the argument defined in operator schema
The device option that the operator should run under.
Optionally, one can specify an engine when there are multiple implementations available simultaneously for one device type. If one specifies an engine but that engine does not exist in the compiled Caffe2 binary, Caffe2 will fall back to the default engine of that device type.
Additional 'fake' inputs used for expressing control dependencies in the operator graph. This can be used to ensure that an operator does not run until another operator is ready, for e.g. scheduling control. These are not passed as actual inputs to the Operator implementation, and are only used by the Net class for scheduling purposes.
is_gradient_op argument is only used as a hint in shape inference and has no runtime significance
debug information associated with the construction of the operator. This is an optional string with no assumed characteristics as operators can be constructed in any language.
the domain of the operator to help runtime distinguish which operator library this OperatorDef refers to. For example, both caffe2 and aten has `Add` operator, with domain, we can easily decide which operator to execute. to support multiple operator libs, we use domain to distinguish which operator lib we refer to: - "caffe2" means this uses Caffe2 operator library - "aten" means this uses ATen operator library - "c10" is for the fused library - if the domain is missing or empty, we use "caffe2", this is for legacy models, new serializer should always export an OperatorDef with domain and op_version
each operator is has its own version number. operator version information each time, we change the API or semantics of the operator, we bump the version for the operator. the runtime system should check the op_version of each OperatorDef and decide it should reject or accept the model
Partition definition.
Used in:
Name of the partition.
A list of logic device ID, indicating which devices this partition can be executed on. If empty, it means the partition won't run on device but on host CPU instead.
Extra debug info.
Flexible map for passing options specific to a backend.
Represents a node in the path from the root node all the way down to the word (leaf).
Used in:
Parameter matrix offset for this node
Number of children
Index of the next node in the path
Each PathProto belongs to a word and is an array of nodes in the path from the root to the leaf (which is the word itself) in the tree.
Used in:
Used in:
All the networks that are used in this execution. Note that networks should be ordered in the way they are executed, i.e. for a layer in a network, all its input blobs should already have been initialized by the layers or networks defined before it.
The networks that are going to be used in this plan.
Used in:
Important - to ensure ordered traversal of the DB, these must be set in the given (lexicographic) order in the input DBReader.
Blob types used in MetaNetDef blobs
Net types used in MetaNetDef nets
Shape info blob name
Sequential blob reader name
Protobuf format to serialize profiler data.
Used in:
The name for the operator
The mean execution time
The standard deviation
New field to represent the numbers above, and with count.
Blob profiles that this node outputs.
The extra_info from the operator device option.
Operator profiling information. Note: The indices for elements of 'stats' and the indices of 'output_profile' inside each 'stats' are assumed to match the indices of 'op' elements of a corresponding NetDef and the 'output' indices within each 'op'.
Used in:
,Multi-group quantization params
Multi-group quantization needed, indicates in which dimension we do the "group wise quantization"
It should be true if it is a multi-group quantization proto
Used in:
TensorBoundShape is used to save bound shape inference result for a tensor. TensorBoundShape.shape is inferred shape for this tensor. TensorBoundShape.dimType contains dim_type for every dimension. eg: for dimension i, shape.dims[i] is the inferred shape and dim_type[i] is corresponding dim_type.
Used in:
dim_type.size() == shape.dims.size()
Used in:
unknown
constant
batch, corresponding dimension is batch_size
batch_of_feature_max, corresponding shape is inferred_feature_length * batch_size
batch_of_feature_max_default corresponding shape is default_feature_length * batch_size
feature_max, corresponding shape is inferred_feature_length
feature_max_default, corresponding shape is default_feature_length
Used in:
TensorProto stores serialized Tensor objects.
Used in:
, ,The dimensions in the tensor.
For float
For int32, uint8, int8, uint16, int16, bool, and float16 Note about float16: in storage we will basically convert float16 byte-wise to unsigned short and then store them in the int32_data field.
For bytes
For strings
For double
For int64
store the raw data, contents are serialized as little-endian
store the pointer to the data
Optionally, a name for the tensor.
Optionally, a TensorProto can contain the details about the device that it was serialized from. This is useful in cases like snapshotting a whole workspace in a multi-GPU environment.
Data type
Used in:
, , ,Basic types
float
int
byte, when deserialized, is going to be restored as uint8
string
Less-commonly used data types
bool
uint8_t
int8_t
uint16_t
int16_t
int64_t
at::Half
double
zero-collision hash state
When loading from chunks this is going to indicate where to put data in the full array. When not used full data have to be present
Used in:
data storage
Used in:
the content is stored in typed field, for example, if the data_type is FLOAT, float_data is used to store the content.
the content is serialized in field raw_data as little-endian
the pointer to the content is stored in field external_data the content is serialized as little-endian
When StorageType is NO_CONTENT, we use TensorProto to store only type and shape information. Reuse TensorProto to store type and shape because we can just have one proto, not having another ValueInfoProto
TensorProtos stores multiple TensorProto objects in one single proto. This is useful for small tensors; For anything big, consider using a DB for storage.
Used in:
,Protobuf format to accept hierarchy for hierarchical softmax operator. TreeProto points to the root node.
A two number summary for a value. It also has count for restoring.
Used in:
,