Discover SPIR-V and how it lets SYCL support heterogeneous C++ virtual functions. This post covers two notions that take SYCL in different directions.

At the 13th IWOCL International Workshop on OpenCL and SYCL, Intel's Alexey Sachiko presented several experimental ideas to expand SYCL's use and scope as a cross-architecture framework for accelerated computing from edge to cloud and AI PC to supercomputer.

Virtual functions are discussed first. SYCL aims to make C++ to multiarchitecture computing a smooth transition. Virtual functions can be redefined in derived classes to offload kernels, so expanding them is consistent.

The second concept is abstraction, although not of base class functions. Increased SPIR-V backend abstraction support will help SYCL's low-level implementation interface with the wide range of hardware architectures and custom accelerators available. The purpose is to improve SYCL LLVM-SPIR-V collaboration.

In many ways, SYCL is becoming more general. SYCL abstraction, from low-level hardware abstraction to C++ virtual function objects, will be discussed as its development continues.

SYCL Virtual Functions

Virtual functions have been used in C++ program development since its inception. Popular backend abstractions like the Kokkos C++ performance portability interface, used in high-speed scientific computing, require it.

Even though the SYCL standard allows one-definition rule (ODR) virtual inheritance, device functions cannot invoke virtual member functions, making code migration difficult.

Alexey begins his talk with a simple base class with a few virtual methods, direct classes with overrides, and offload kernels.

Easy oneAPI kernel property addition for virtual class inheritance.

The experimental indirectly callable function properties from the sycl_ext_oneapi_kernel_properties GitHub sandbox are included first. A function or offload kernel can be identified as a device function and invoked indirectly.

Why do virtual functions need this?

Program objects have virtual class overrides tables. For each virtual function call, a pointer from this table is loaded to call the relevant derived function.

In the Base function, SYCL device code limitations are violated when foo throws an exception and allocates memory.

The indirectly_callable feature makes the virtual function a device function with all its limitations, like the SYCL_EXTERNAL macro.

For the same reason, assume_indirect_calls properties_tag is needed. Kernel virtual calls without this property fail.

Alexey then discusses more advanced topics and future projects like optional kernel feature support and reqd_sub_group_size.

Considering Implementation

When designing an app with this new functionality, consider these high-level factors:

SYCL applications with virtual function support should separate each virtual function set into a device image. If you use optional kernel features, duplicate with empty functions. This provides all link stage symbols without speculative compilation.

For kernel-equipped device images, connect all images with the same virtual function sets.

When targeting SPIR-V, this happens runtime. Otherwise, it happens during build link.

See the for more on technology implementation.

Ext_intel_virtual_functions is in Intel's LLVM GitHub.

Test cases for sycl_ext_oneapi_virtual_functions extension in the same source code tree.

Improve SYCL Code using Virtual Functions

Recent versions of the Intel DPC++ Compatibility Tool 2025.1 and the Intel oneAPI DPC++/C++ Compiler include experimental and evolving virtual function functionality.

SPIR-V Backend SYCL Application

SPIR-V, a binary intermediate language for compute kernels and graphical-shader stages, was specified by the Khronos Group, which regulates SYCL. Its portable format unifies intermediate representation and programming interface for heterogeneous accelerators.

A varied language and API environment supports it

This creates a duality of intermediate abstracted hardware backend representation for C++ compilers based on LLVM and LLVM Intermediate Representation, as with all CLANG project compilers.

The SPIR-V to LLVM Translator provides bidirectional translation, however it is not updated as part of the LLVM project tree, making it prone to rare incompatibilities and disconnects.

To remedy this, Intel's compiler development team recommends SPIR-V as a normal LLVM code generation target, like other hardware target runtimes. Thus, the LLVM project includes an SPIR-V backend to ensure thorough integration testing and allow it to be used with OpenAI Triton backends, graphics-oriented programming models like Vulkan or HLSL, and heterogeneous computing with OpenCL or SYCL.

With extensive documentation, an active and growing LLVM SPIR-V working group supports and maintains the Backend:

SPIR-V Target User Guide

Clang SPIR-V Support

Intel compiler developers help resolve LLVM IR semantics and specifications to SPIR-V mapping difficulties as part of Intel's commitment to the open source community.

In his presentation, Alexey Sachkov details them and Intel's solution.

Is Spir-V?

SPIR-V, a high-level binary intermediate language, defines compute kernels and graphics shaders. It was created by Khronos Group, an OpenGL, Vulkan, and OpenCL organisation.

What that means and why it matters:

IR: GPU assembly language universal. Developers utilise GLSL or HLSL instead of writing shader code for each GPU architecture, which is complicated. Compilers create SPIR-V from this source code.

SPIR-V comes as compiled binary, not source code. This has numerous benefits:

Application startup and shader loading are faster when drivers don't parse and compile text-based shader code.

IP Protection: Shader source code is hidden, making algorithm reverse-engineering harder.

Closer Hardware: SPIR-V's lower-level representation allows more direct control and performance adjustment than high-level languages.

Standard and Portable: Before SPIR-V, each graphics API (like OpenGL or DirectX) handled shaders differently, requiring several compilers and duplication. SPIR-V is a royalty-free, open standard for graphics and computing APIs.

New, low-overhead graphics API Vulkan leverages SPIR-V shaders.

Although optional, OpenGL 4.6 and later support SPIR-V.

OpenCL: GPU/processor parallelism.

In Shader Model 7.0, Microsoft aims to replace DXIL with SPIR-V for Direct3D interoperability. Important for graphics ecosystem unity.

SYCL Code Compilation Target: SPIR-V

The SPIR-V Backend for LLVM is still being developed, however it has been a project target since January 2025. Try it and comment on the LLVM project RFC page.

Use SPIR-V, oneAPI, and SYCL Now