Visible to Intel only — GUID: GUID-A4CEC1E4-2C32-4E42-9E8E-EC3F25E6B91E
Abs
AbsBackward
Add
AvgPool
AvgPoolBackward
BatchNormForwardTraining
BatchNormInference
BatchNormTrainingBackward
BiasAdd
BiasAddBackward
Clamp
ClampBackward
Concat
Convolution
ConvolutionBackwardData
ConvolutionBackwardWeights
ConvTranspose
ConvTransposeBackwardData
ConvTransposeBackwardWeights
Dequantize
Divide
DynamicDequantize
DynamicQuantize
Elu
EluBackward
End
Exp
GELU
GELUBackward
HardSigmoid
HardSigmoidBackward
HardSwish
HardSwishBackward
Interpolate
InterpolateBackward
LayerNorm
LayerNormBackward
LeakyReLU
Log
LogSoftmax
LogSoftmaxBackward
MatMul
Maximum
MaxPool
MaxPoolBackward
Minimum
Mish
MishBackward
Multiply
Pow
PReLU
PReLUBackward
Quantize
Reciprocal
ReduceL1
ReduceL2
ReduceMax
ReduceMean
ReduceMin
ReduceProd
ReduceSum
ReLU
ReLUBackward
Reorder
Round
Select
Sigmoid
SigmoidBackward
SoftMax
SoftMaxBackward
SoftPlus
SoftPlusBackward
Sqrt
SqrtBackward
Square
SquaredDifference
StaticReshape
StaticTranspose
Subtract
Tanh
TanhBackward
TypeCast
Wildcard
enum dnnl_alg_kind_t
enum dnnl_normalization_flags_t
enum dnnl_primitive_kind_t
enum dnnl_prop_kind_t
enum dnnl_query_t
enum dnnl::normalization_flags
enum dnnl::query
struct dnnl_exec_arg_t
struct dnnl_primitive
struct dnnl_primitive_desc
struct dnnl::primitive
struct dnnl::primitive_desc
struct dnnl::primitive_desc_base
enum dnnl_rnn_direction_t
enum dnnl_rnn_flags_t
enum dnnl::rnn_direction
enum dnnl::rnn_flags
struct dnnl::augru_backward
struct dnnl::augru_forward
struct dnnl::gru_backward
struct dnnl::gru_forward
struct dnnl::lbr_augru_backward
struct dnnl::lbr_augru_forward
struct dnnl::lbr_gru_backward
struct dnnl::lbr_gru_forward
struct dnnl::lstm_backward
struct dnnl::lstm_forward
struct dnnl::rnn_primitive_desc_base
struct dnnl::vanilla_rnn_backward
struct dnnl::vanilla_rnn_forward
Visible to Intel only — GUID: GUID-A4CEC1E4-2C32-4E42-9E8E-EC3F25E6B91E
OpenCL Interoperability
Overview
oneDNN uses the OpenCL runtime for GPU engines to interact with the GPU. Users may need to use oneDNN with other code that uses OpenCL. For that purpose, the library provides API extensions to interoperate with underlying OpenCL objects. This interoperability API is defined in the dnnl_ocl.hpp header.
The interoperability API is provided for two scenarios:
Construction of oneDNN objects based on existing OpenCL objects
Accessing OpenCL objects for existing oneDNN objects
The mapping between oneDNN and OpenCL objects is provided in the following table:
oneDNN object |
OpenCL object(s) |
|---|---|
Engine |
cl_device_id and cl_context |
Stream |
cl_command_queue |
Memory (Buffer-based) |
cl_mem |
Memory (USM-based) |
Unified Shared Memory (USM) pointer |
The table below summarizes how to construct oneDNN objects based on OpenCL objects and how to query underlying OpenCL objects for existing oneDNN objects.
oneDNN object |
API to construct oneDNN object |
API to access OpenCL object(s) |
|---|---|---|
Engine |
dnnl::ocl_interop::get_device(const engine &)dnnl::ocl_interop::get_context(const engine &) |
|
Stream |
dnnl::ocl_interop::make_stream(const engine &, cl_command_queue) |
|
Memory (Buffer-based) |
||
Memory (USM-based) |
OpenCL Buffers and USM Interfaces for Memory Objects
The memory model in OpenCL is based on OpenCL buffers. Intel extension further extends the programming model with a Unified Shared Memory (USM) alternative, which provides the ability to allocate and use memory in a uniform way on host and OpenCL devices.
oneDNN supports both buffer and USM memory models. The buffer model is the default. The USM model requires using the interoperability API.
To construct a oneDNN memory object, use one of the following interfaces:
-
Constructs a USM-based or buffer-based memory object depending on memory allocation kind kind. The handle could be one of special values DNNL_MEMORY_ALLOCATE or DNNL_MEMORY_NONE, or it could be a user-provided USM pointer. The latter works only when kind is dnnl::ocl_interop::memory_kind::usm.
dnnl::memory(const memory::desc &, const engine &, void *)
Constructs a buffer-based memory object. The call is equivalent to calling the function above with with kind equal to dnnl::ocl_interop::memory_kind::buffer.
dnnl::ocl_interop::make_memory(const memory::desc &, const engine &, cl_mem)
Constructs a buffer-based memory object based on a user-provided OpenCL buffer.
To identify whether a memory object is USM-based or buffer-based, dnnl::ocl_interop::get_memory_kind() query can be used.
Handling Dependencies
OpenCL queues could be in-order or out-of-order. For out-of-order queues, the order of execution is defined by the dependencies between OpenCL tasks therefore users must handle the dependencies using OpenCL events.
oneDNN provides two mechanisms to handle dependencies:
dnnl::ocl_interop::execute() interface
This interface enables the user to pass dependencies between primitives using OpenCL events. In this case, the user is responsible for passing proper dependencies for every primitive execution.
In-order oneDNN stream
oneDNN enables the user to create in-order streams when submitted primitives are executed in the order they were submitted. Using in-order streams prevents possible read-before-write or concurrent read/write issues.
NOTE:
oneDNN follows retain/release OpenCL semantics when using OpenCL objects during construction. An OpenCL object is retained on construction and released on destruction. This ensures that the OpenCL object will not be destroyed while the oneDNN object stores a reference to it.
NOTE:
The access interfaces do not retain the OpenCL object. It is the user’s responsibility to retain the returned OpenCL object if necessary.
NOTE:
It’s the user’s responsibility to manage lifetime of the OpenCL event returned by dnnl::ocl_interop::execute().
NOTE:
USM memory doesn’t support retain/release OpenCL semantics. When constructing a oneDNN memory object using a user-provided USM pointer oneDNN doesn’t own the provided memory. It’s user’s responsibility to manage its lifetime.