|
| 1 | +# The SYCL Runtime Plugin Interface. |
| 2 | + |
| 3 | + |
| 4 | +## Overview |
| 5 | +The SYCL Runtime Plugin Interface (PI) is the interface layer between |
| 6 | +device-agnostic part of the SYCL runtime and the device-specific runtime layers |
| 7 | +which control execution on devices. It employs the “plugin” mechanism to bind |
| 8 | +to the device specific runtime layers similarly to what is used by libomptarget |
| 9 | +or OpenCL. |
| 10 | + |
| 11 | +The picture below illustrates the placement of the PI within the overall SYCL |
| 12 | +runtime stack. Dotted lines show components or paths which are not yet available |
| 13 | +in the runtime, but are likely to be developed. |
| 14 | + |
| 15 | + |
| 16 | +The plugin interface and the discovery process behind it allows to dynamically |
| 17 | +plug in implementations based on OpenCL and “native” runtime for a particular |
| 18 | +device – such as OpenCL for |
| 19 | +FPGA devices or native runtimes for GPUs. Implementations of the PI are |
| 20 | +“plugins” - dynamic libraries or shared objects which expose a number of entry |
| 21 | +points implementing the PI interface. The SYCL runtime collects those function |
| 22 | +pointers into a PI interface dispatch table - one per plugin - and uses this |
| 23 | +table to dispatch to the device(s) covered by the corresponding plugin. |
| 24 | + |
| 25 | +PI is based on a subset of OpenCL 1.2 runtime specification, it follows its |
| 26 | +platform, execution and memory models in all aspects except those explicitly |
| 27 | +mentioned in this document. A part of PI API types and functions have exact |
| 28 | +matches in OpenCL. Whenever there is such a match, the semantics also fully |
| 29 | +matches unless the differences are explicitly specified in this document. While |
| 30 | +PI has roots in OpenCL, it does have many differences, and the gap is likely |
| 31 | +to grow, for example in the areas of memory model and management, program |
| 32 | +management. |
| 33 | + |
| 34 | +## Discovery and linkage of PI implementations |
| 35 | + |
| 36 | + |
| 37 | + |
| 38 | +Device discovery phase enumerates all available devices and their features by |
| 39 | +querying underlying plugins found in the system. This process is only performed |
| 40 | +once before any actual offload is attempted. |
| 41 | + |
| 42 | +### Plugin discovery |
| 43 | + |
| 44 | +Plugins are physically dynamic libraries stored somewhere in the system where |
| 45 | +the SYCL runtime runs. TBD - design and describe the process in details. |
| 46 | + |
| 47 | +#### Plugin binary interface |
| 48 | +TBD - list and describe all the symbols plugin must export in order to be picked |
| 49 | +up by the SYCL runtime for offload. |
| 50 | + |
| 51 | +#### OpenCL plugin |
| 52 | + |
| 53 | +OpenCL plugin is a usual plugin from SYCL runtime standpoint, but its loading |
| 54 | +and initialization involves a nested discovery process which finds out available |
| 55 | +OpenCL implementations. They can be installed either in the standard Khronos |
| 56 | +ICD-compatible way (e.g. listed in files under /etc/OpenCL/vendors on |
| 57 | +Linux) or not, and the OpenCL plugin can hook up with both. |
| 58 | + |
| 59 | +TBD describe the nested OpenCL implementation discovery process performed by |
| 60 | +the OpenCL plugin |
| 61 | + |
| 62 | +### Device enumeration by plugins |
| 63 | + |
| 64 | +TBD |
| 65 | + |
| 66 | +## PI API Specification |
| 67 | + |
| 68 | +PI interface is logically divided into few subsets: |
| 69 | +- **Core API** which must be implemented by all plugins for SYCL runtime to be |
| 70 | +able to operate on the corresponding device. The core API further breaks down |
| 71 | +into |
| 72 | + - **OpenCL-based** APIs which have OpenCL origin and semantics |
| 73 | + - **Extension** APIs which don't have counterparts in the OpenCL |
| 74 | +- **Interoperability API** which allows interoperability with underlying APIs |
| 75 | +such as OpenCL. |
| 76 | + |
| 77 | +See [pi.h](../include/CL/sycl/detail/pi.h) header for the full list and |
| 78 | +descriptions of PI APIs. [TBD: link to pi.h doxygen here] |
| 79 | + |
| 80 | +### The Core OpenCL-based PI APIs |
| 81 | + |
| 82 | +This subset defines functions representing core functionality, |
| 83 | +such as device memory management, kernel creation and parameter setting, |
| 84 | +enqueuing kernel for execution, etc. Functions in this subset fully match |
| 85 | +semantics of the corresponding OpenCL functions, for example: |
| 86 | + |
| 87 | + piKernelCreate |
| 88 | + piKernelRelease |
| 89 | + piKernelSetArg |
| 90 | + |
| 91 | +### The Extension PI APIs |
| 92 | + |
| 93 | +Those APIs don't have OpenCL counter parts and require full specification. For |
| 94 | +example, the function below selects the most appropriate device binary based |
| 95 | +on runtime information and the binary's characteristics |
| 96 | +``` |
| 97 | +pi_result piextDeviceSelectBinary( |
| 98 | + pi_device device, |
| 99 | + pi_device_binary * binaries, |
| 100 | + pi_uint32 num_binaries, |
| 101 | + pi_device_binary * selected_binary); |
| 102 | +``` |
| 103 | + |
| 104 | +PI also defines few types and string tags to describe a device binary image. |
| 105 | +Those are used to communicate to plugins information about the images where it |
| 106 | +is needed, currently only in the above function. The main |
| 107 | +type is ```pi_device_binary```, whose detailed description can also be found |
| 108 | +in the header. The layout of this type strictly matches the layout of the |
| 109 | +corresponding device binary descriptor type defined in the |
| 110 | +```clang-offload-wrapper``` tool which wraps device binaries into a host |
| 111 | +object for further linkage. The wrapped binaries reside inside this descriptor |
| 112 | +in a data section. |
| 113 | + |
| 114 | +### The Interoperability PI APIs |
| 115 | + |
| 116 | +These are APIs needed to implement SYCL runtime interoperability with underlying |
| 117 | +"native" device runtimes such as OpenCL. Currently there are only OpenCL |
| 118 | +interoperability APIs, which is to be implemented by the OpenCL PI plugin only. |
| 119 | +These APIs match semantics of the corresponding OpenCL APIs exactly. |
| 120 | +For example: |
| 121 | + |
| 122 | +``` |
| 123 | +pi_program piclProgramCreateWithSource( |
| 124 | + pi_context context, |
| 125 | + pi_uint32 count, |
| 126 | + const char ** strings, |
| 127 | + const size_t * lengths, |
| 128 | + pi_result * errcode); |
| 129 | +``` |
| 130 | + |
| 131 | +### PI Extension mechanism |
| 132 | + |
| 133 | +TBD This section describes a mechanism for SYCL or other runtimes to detect |
| 134 | +availability of and obtain interfaces beyond those defined by the PI dispatch. |
| 135 | + |
| 136 | +TBD Add API to query PI version supported by plugin at runtime. |
0 commit comments