Abstract:

This presentation by Eric Tumusk explores the fundamental incompatibilities between the C++ object model and the programming paradigms of GPU accelerator APIs like OpenCL and Vulkan. The talk posits that the C++ model, which thrives on local reasoning, RAII, and encapsulation, is enabled by the abstraction of a large, virtualized memory space. In contrast, accelerator APIs are low-level, C-style interfaces that demand explicit resource management for performance, featuring a complex web of interconnected objects with dynamic dependencies that break the principles of C++ abstraction.

The presentation introduces SYCL as a higher-level C++ abstraction layer that bridges this gap. Key SYCL concepts like reference semantics (approximating RAII with a PIMPL-like pattern) and opaque interfaces create a crucial decoupling between the user's code and the underlying accelerator backend. This indirection gives the SYCL runtime the latitude to manage the complex, non-deterministic hardware resources on the user's behalf. Finally, the talk connects this model to the needs of functional safety, where determinism is paramount. It argues that the separation of concerns enabled by SYCL's high-level abstraction makes it technically feasible to create a safety-certifiable GPU API that is both performant and compatible with the C++ object model.

Bridging the Gap: C++, GPUs, and Functional Safety

• 01:22 The C++ Object Model and Local Reasoning: The C++ object model is built on principles like RAII (Resource Acquisition Is Initialization), encapsulation, and ownership.

  • Key Takeaway: The primary goal of these features is to enable local reasoning, allowing developers to manage complexity by focusing on isolated components. This is heavily supported by the abstraction of a large, virtualized memory hierarchy provided by CPUs and operating systems.

• 13:50 The Challenge of Accelerator APIs (OpenCL & Vulkan): GPU programming APIs like OpenCL are typically low-level C interfaces designed for maximum performance through explicit resource management.

  • Details: These APIs feature a complex web of object types (contexts, queues, buffers, kernels) with intricate and dynamic dependencies.
  • Key Takeaway: They lack invariants, RAII, and clear ownership, which breaks the C++ object model and makes local reasoning extremely difficult. This explicit control is a feature for performance, not a bug.

• 22:30 Why Simple C++ Wrappers Fail: Attempting to simply wrap low-level accelerator objects (like an OpenCL context or buffer) in C++ classes does not solve the underlying problem.

  • Details: A simple wrapper can be dangerous, as RAII could destroy an object that other objects still depend on, creating dangling references. The complex, non-hierarchical ownership model of the backend APIs is fundamentally incompatible with C++'s scoped ownership.

• 32:14 SYCL: A Higher-Level Abstraction: SYCL is a C++ abstraction layer for programming accelerators that offers a more compatible model.

  • Details: It uses two key concepts:
    1. Reference Semantics: User-facing objects are lightweight handles (similar to std::shared_ptr), which approximates RAII and simplifies resource management for the developer.
    2. Opaque Interfaces: The API is decoupled from the backend implementation. The SYCL runtime decides when and how to allocate and manage the actual low-level GPU resources, allowing for advanced optimizations.

• 46:01 The Requirement of Functional Safety (FuSa): In safety-critical systems (automotive, aerospace), a primary requirement is determinism.

  • Key Takeaway: The software must behave identically and within a strict time budget on every run. This is challenged by the non-determinism inherent in memory caches and complex, shared GPU resources.

• 50:47 Combining C++, GPUs, and Safety with SYCL's Model: The high-level, decoupled nature of the SYCL model provides a path to creating a safety-certifiable GPU API that works with C++.

  • Details: The abstraction creates a "separation of concerns." It allows the application and its libraries to be developed with local reasoning while a specialized, safety-critical runtime manages the complex backend resources deterministically.
  • Key Takeaway: By viewing the program as a sequence of actions submitted to the runtime, it becomes possible to ensure a deterministic resource footprint (determinism in space) and a deterministic execution schedule (determinism in time), satisfying the needs of functional safety.