Full example text: sycl_interop_buffer.cpp
This C++ API example demonstrates programming for Intel(R) Processor Graphics with SYCL extensions API in oneDNN. The workflow includes following steps:
To start using oneDNN, we must first include the dnnl.hpp header file in the application. We also include CL/sycl.hpp from DPC++ for using SYCL APIs and dnnl_debug.h, which contains some debugging facilities such as returning a string representation for common oneDNN C types. All C++ API types and functions reside in the dnnl
namespace, and SYCL API types and functions reside in the cl::sycl
namespace. For simplicity of the example we import both namespaces.
All oneDNN primitives and memory objects are attached to a particular dnnl::engine, which is an abstraction of a computational device (see also Basic Concepts). The primitives are created and optimized for the device to which they are attached, and the memory objects refer to memory residing on the corresponding device. In particular, that means neither memory objects nor primitives that were created for one engine can be used on another.
To create engines, we must specify the dnnl::engine::kind and the index of the device of the given kind. In this example we use the first available GPU or CPU engine, so the index for the engine is 0. This example assumes DPC++ being a runtime. In such case, during engine creation, an SYCL context is also created and attaches to the created engine.
In addition to an engine, all primitives require a dnnl::stream for the execution. The stream encapsulates an execution context and is tied to a particular engine.
In this example, a stream is created. This example assumes DPC++ being a runtime. During stream creation, a SYCL queue is also created and attaches to this stream.
Next, we create a memory object. We need to specify dimensions of our memory by passing a memory::dims object. Then we create a memory descriptor with these dimensions, with the dnnl::memory::data_type::f32 data type, and with the dnnl::memory::format_tag::nchw memory format. Finally, we construct a memory object and pass the memory descriptor. The library allocates memory internally.
The underlying SYCL buffer can be extracted from the memory object using the interoperability interface: dnnl::sycl_interop_buffer::get_buffer<T>(const dnnl::memory)
.
We are going to create an SYCL kernel that should initialize our data. To execute SYCL kernel we need a SYCL queue. For simplicity we can construct a stream and extract the SYCL queue from it. The kernel initializes the data by the 0, -1, 2, -3, ...
sequence: data[i] = (-1)^i * i
.
There are three steps to create an operation primitive in oneDNN:
Let's create the primitive to perform the ReLU (rectified linear unit) operation: x = max(0, x). An operation descriptor has no dependency on a specific engine - it just describes some operation. On the contrary, primitive descriptors are attached to a specific engine and represent some implementation for this engine. A primitive object is a realization of a primitive descriptor, and its construction is usually much "heavier".
Next, execute the primitive.
Before running validation codes, we need to access the SYCL memory on the host. The simplest way to access the SYCL-backed memory on the host is to construct a host accessor. Then we can directly read and write this data on the host. However no any conflicting operations are allowed until the host accessor is destroyed. We can run validation codes on the host accordingly.
We now just call everything we prepared earlier.
Because we are using the oneDNN C++ API, we use exceptions to handle errors (see API). The oneDNN C++ API throws exceptions of type dnnl::error, which contains the error status (of type dnnl_status_t) and a human-readable error message accessible through the regular what()
method.
Upon compiling and running the example, the output should be just: