Yesterday, the Khronos Group announced that its Vulkan API (modern cross-platform graphics and compute API) has become the world’s first graphics API to include a formal memory model (Vulkan Memory model) for its associated GLSL™ and SPIR-V™ programming languages.
This 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.
The Vulkan memory model
Vulkan’s memory model is based on the C++ memory model. However, it adds valuable functionality such as scopes, storage classes, and memory availability and visibility operations. These capabilities can be exploited to reduce the cost of synchronization and thus increase performance.
- 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.
Additional memory model materials
The Khronos Group has lined up additional 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 additional memory model materials include:
A provisional Vulkan Memory Model Specification: This specification 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.
Memory model extension conformance tests to help shader compilers ensure that they implement the specified memory model synchronization functionality correctly.
A formal description of the Vulkan memory model using Alloy, which is a language developed by MIT for describing logical structures and a tool for exploring them. This is the first instance where Khronos has used an Alloy model for its specifications. This is because, Alloy precisely documents the interactions of memory operations between multiple threads and devices, and enables formal modeling and experimentation.
To know more about the Vulkan Memory model in detail, visit its GitHub page.
Read Next
AMD open sources V-EZ, the Vulkan wrapper library
Think Silicon open sources GLOVE: An OpenGL ES over Vulkan middleware
