[SYCL][Doc] RFC draft for SYCLBIN format #20276
Conversation
Not to be merged to `sycl` branch. Created for discussion and feedback.
YuriPlyakhin
requested review from
KseniyaTikhomirova,
aelovikov-intel,
bader,
gmlueck,
jbrodman,
maarquitos14,
maksimsab,
sergey-semenov,
steffenlarsen and
vinser52
|
|
||
| ### Enable modular dynamic loading of device binaries at runtime | ||
|
|
||
| Some applications require dynamic loading of device binaries at runtime to achieve modularity and avoid recompiling the entire application when device code changes. The SYCLBIN format provides a standardized interface between compiler-produced SYCLBIN binaries and runtime handling, enabling efficient dynamic loading scenarios. |
There was a problem hiding this comment.
It might be useful to elaborate more here. We see SYCLBIN as SYCL's analog of CUDA's FATBIN format. Therefore, a SYCL compiler could provide compiler options that generate a "*.syclbin" file, just as nvcc provides compiler options to generate a "*.fatbin" file. In addition, we are adding SYCL runtime functions that can load and manipulate "*.syclbin" files just as CUDA provides runtime functions to load and manipulate "*.fatbin" files.
|
|
||
| **Abstract Modules:** collection of device binaries that share properties, including, but not limited to: exported symbols, [aspect requirements](https://github.com/intel/llvm/blob/sycl/sycl/doc/design/OptionalDeviceFeatures.md), and [specialization constants](https://github.khronos.org/SYCL_Reference/iface/specialization-constants.html). The device binaries contained inside an abstract module must either be an IR module or a native device code image. IR modules contain device binaries in some known intermediate representation, such as SPIR-V, while the native device code images can be an architecture-specific binary format. There is no requirement that all device binaries in an abstract module are usable on the same device or are specific to a single vendor. | ||
|
|
||
| **IR modules:** binary data for the corresponding module compiled to a given IR representation, identified by the IR type field. |
There was a problem hiding this comment.
What you say here is true, but I think you intended to describe "IR module header" (which is the next section in the file format diagram above)?
The IR module header does not contain the binary data for a module compiled to IR. It only contains a "header" which contains a reference to the IR representation (which resides in the binary byte table) and a reference to the metadata (which resides in the metadata byte table).
|
|
||
| **IR modules:** binary data for the corresponding module compiled to a given IR representation, identified by the IR type field. | ||
|
|
||
| **Native device code images:** binary data for the corresponding module AOT compiled for a specific device, identified by the architecture |
There was a problem hiding this comment.
Same here. The next section is "native device code image header". This contains a reference to the native module representation (which resides in the binary byte table) and a reference to the metadata (which resides in the metadata byte table).
2 participants
Intention is to post it to discourse as RFC. Not to be merged to
syclbranch. Created for discussion and feedback. Hence, I'll keep it in draft mode, while I'll request reviews.