Learn what is SPIR-V is and how it enables SYCL to support C++ virtual functions for heterogeneous computing. Overview of two of those concepts that take SYCL in various directions in this post.
Alexey Sachiko of Intel presented a number of experimental ideas at the 13th IWOCL International Workshop on OpenCL and SYCL to expand the use and scope of SYCL as a common cross-architecture framework for accelerated computing for various use cases and verticals, ranging from edge to cloud and from AI PC to supercomputer.
The start by discussing virtual functions. SYCL is intended to be a seamless, all-inclusive transition from C++ to multiarchitecture computing. Expanding the concept of virtual functions which can be redefined in derived classes to offload kernels is therefore only consistent.
Though not the abstraction of functions within a base class, the second concept is also about abstraction. The goal is to increase the support for SPIR-V backend abstractions so that SYCL’s low-level implementation may more easily interface with the diverse range of hardware architectures and specialized custom accelerators that are now available. The goal is to improve the collaboration between LLVM and SPIR-V in a SYCL setting.
In many ways, SYCL and its broad, universal applicability are expanding. As examine its further development, let’s discuss abstraction using SYCL, ranging from low-level hardware abstraction to C++ virtual function objects.
Virtual Functions in SYCL
Since the language’s creation, virtual functions have been a regular component of contemporary C++ program development. It is essential to popular backend abstractions such as the Kokkos C++ performance portability interface, which is used extensively in high-speed scientific computing.
Virtual member functions cannot be called within a device function, which makes migrating some code bases challenging even if the SYCL standard permits the one-definition rule (ODR) use of virtual inheritance.
Alexey starts his presentation by establishing a simple reference example of a base class with a few virtual methods, followed by direct classes with overrides for those virtual classes and a few offload kernels.
A simple oneAPI kernel property addition for virtual class inheritance.
He starts by including the experimental indirectly callable function properties that are detailed in the sycl_ext_oneapi_kernel_properties GitHub sandbox. This allows a function or offload kernel to be identified as a device function that can be called indirectly.
Why are virtual functions in need of this?
A virtual table of pointers to class overrides is present in a program object. A specific pointer from this table is loaded each time a virtual function is called in order to call the appropriate derived function.
For instance, the Base{}function in violates SYCL device code constraints when foo{} throws an exception and allocates new memory.
The indirectly_callable property declares the virtual function to be a device function with all of its limitations, making it comparable to the SYCL_EXTERNAL macro.
For the same reason, the assume_indirect_calls properties_tag is required. An error will occur if a kernel makes a virtual call without this property.
Alexey then talks about more complex subjects and potential future projects, such optional kernel feature support and reqd_sub_group_size support.
Implementation Considerations
When creating an application with this new capability, there are a few high-level factors to take into account:
- Put each virtual function set into its own device image when using SYCL to construct your application with virtual function support. Make a duplicate with empty functions if you are using any optional kernel features. This offers all of the symbols for the link stage while preventing speculative compilation.
- Connect all device images that have the same virtual function sets for any such kernel-equipped device image.
- The aforementioned occurs at runtime when targeting SPIR-V. Otherwise, the build link step is when it occurs.
For additional information on technological implementation, see the
- Intel’s LLVM GitHub has the ext_intel_virtual_functions specification, and
- The same source code tree’s sycl_ext_oneapi_virtual_functions extension test cases.
Take your SYCL Code to the Next Level with Virtual Functions
With the latest versions of the Intel DPC++ Compatibility Tool 2025.1 and the Intel oneAPI DPC++/C++ Compiler, the suggested virtual function functionality is experimentally accessible and continuously developing.
SPIR-V Backend Use with SYCL
The Khronos Group, the same regulatory organization that oversees SYCL, has created the specification for SPIR-V, a binary intermediate language for describing compute kernels and graphical-shader stages. For heterogeneous accelerators, it offers a portable format that functions as a unifying intermediate representation and programming interface.
It is supported by a diverse ecosystem of languages and APIs
As with all compilers in the CLANG project family, this presents the problem of a duality of intermediate abstracted hardware backend representation for C++ compilers based on LLVM and LLVM Intermediate Representation (LLVM IR).
Although there is an SPIR-V to LLVM Translator providing bi-directional translation, it is not kept up to date as a component of the LLVM project tree, which makes it vulnerable to sporadic incompatibilities and disconnects.
Similar to other hardware target runtimes, Intel’s compiler development team suggests SPIR-V as a standard LLVM code generation target in order to address this. As a result, an SPIR-V backend is included in the LLVM project, guaranteeing thorough integration testing and enabling it to be used with OpenAI Triton backends or graphics-oriented programming models like Vulkan or high-level shader language (HLSL) in addition to heterogeneous computing with OpenCL or SYCL.
With thorough documentation, an active and expanding LLVM SPIR-V working group now supports and maintains the SPIR-V Backend:
- Instructions for SPIR-V Target Users
- Clang Support for SPIR-V
In keeping with Intel’s dedication to the open source community, it compiler developers actively participate in the community and assist in resolving issues pertaining to the mapping of LLVM IR semantics and specifications to SPIR-V.
In his presentation, Alexey Sachkov goes into great depth on them and Intel’s strategy for fixing them.
What Is Spir-V
Graphics shaders and compute kernels are defined in SPIR-V, a high-level binary intermediate language. The OpenGL, Vulkan, and OpenCL consortium Khronos Group developed it.
Here’s what that means and why it matters:
- Intermediate Language (IR): GPU assembly language universal. Developers use high-level languages like GLSL or HLSL instead of developing shader code for each GPU architecture, which would be quite complicated. SPIR-V is generated from this source code by a compiler.
- Binary Format:SPIR-V is distributed as compiled binary, not source code. This has many advantages:
- Drivers don’t need to parse and compile text-based shader code at runtime, speeding application startup and shader loading.
- IP Protection: Shader source code isn’t exposed, making algorithm reverse-engineering tougher.
- Nearer Hardware: SPIR-V’s lower-level representation provides for more direct control and greater performance adjustment than high-level languages.
- Standard and Portable: Each graphics API (like OpenGL or DirectX) handled shaders differently before SPIR-V, necessitating various compilers and a lot of duplicated effort. Graphics and computing APIs can use SPIR-V’s single, open, royalty-free standard:
- This new, low-overhead graphics API Vulkan uses SPIR-V shaders.
- Although not necessary, OpenGL 4.6 and subsequent versions support SPIR-V.
- OpenCL: For GPU and processor parallel computation.
- Microsoft wants to replace DXIL with SPIR-V as the Direct3D interchange protocol in Shader Model 7.0. This is significant for graphics ecosystem unification.
Use SPIR-V as a Compilation Target with your SYCL Code
Although the SPIR-V Backend for LLVM is still being developed, it has been an official goal of the LLVM project since January 2025. Try it out and then leave a remark on the LLVM project RFC page.
Start Using SPIR-V, oneAPI, and SYCL Right Now
Visit the Intel oneAPI DPC++ C++ Compiler and oneAPI Overview landing page to learn more about these and other new features in LLVM-based C++ compilers and toolchains with SYCL support.
