Vulkan has just become the world’s first graphics API with a formal memory model. So, what is a memory model and why should I care?
A memory model, or memory consistency model, for a programming language describes how threads in a parallel processing system can access shared data and synchronize with each other, while allowing compilers and hardware the freedom to reorder and optimize memory accesses. This is achieved by precisely specifying where and how instructions and memory operations can be reordered, and in what order the effects of those memory operations can become visible to other threads.
Formal memory models are a relatively recent development in computer science, coinciding with the rise in availability of multicore processors. C++11 was the first version of C++ to include a memory model definition for execution on CPUs. There is still a lot of active research being done on how to make these models scale to massively parallel systems with new notions like scoped synchronization.
As GPUs have become more parallel and programmable, and their associated shading languages and compilers have become more sophisticated, the need for a formal memory model for GPU graphics and compute programming has become increasingly acute.
This week, Vulkan® has become the world’s first graphics API to include a formal memory model for its associated GLSL™ and SPIR-V™ programming languages. This significant announcement has a number of components that come together to significantly boost the robustness of the Vulkan standard for programming correctness and sophisticated compiler optimizations.
Firstly, Khronos® has released a provisional Vulkan Memory Model Specification that includes extensions for Vulkan, SPIR-V, and GLSL that gives Vulkan developers additional control over how their shaders synchronize access to memory in a parallel execution environment. In tandem with the extension specification, Khronos has released memory model extension conformance tests to help shader compilers ensure that they implement the specified memory model synchronization functionality correctly.
In parallel with the specification extensions, Khronos has released a formal description of the Vulkan memory model using Alloy - a language developed by MIT for describing logical structures and a tool for exploring them. This is the first time that Khronos has an Alloy model for one of its specifications. It precisely documents the interactions of memory operations between multiple threads and devices and enables formal modeling and experimentation.
The Vulkan memory model is based on the C++ memory model, but adds valuable functionality including scopes, storage classes, and memory availability and visibility operations. Scopes allow synchronization to be limited to threads in close proximity to each other. Storage classes allow synchronization to be limited to specific types of memory. Availability and visibility operations give control over when and how cache maintenance operations are performed in systems with noncoherent cache hierarchies. Each of these capabilities enable an additional level of control compared to the baseline C++ model, which can be exploited to reduce the cost of synchronization and thus increase performance.
Khronos has released these memory model materials in provisional form, to enable feedback from the C++ community, academics, compiler engineers and software developers throughout the industry with experience in multi-threaded communication and memory usage. The Vulkan Working Group will incorporate feedback into the memory model specification before finalizing. All provisional materials are available today, and comments and feedback are welcome, on the Vulkan memory model GitHub repository.