Vulkan gets industry's first formal memory model

The Khronos Group, which is responsible for the OpenGL and Vulkan graphics application programming interface (API) standards, has announced the release of a formal memory model for Vulkan - the first, it claims, in the graphics API industry.

Memory modelling is a key features of many-threaded programming: A memory model tells a programming language how operations affecting the memory work, in what order, and how and when they and the data on which they are operating can be exposed, shared, and used by other threads. Without a memory model, parallel processing becomes fraught with difficulty: It's either incredibly slow because you need to manually check that nothing is going to conflict, or incredibly unreliable because everything conflicts.

That, The Khronos Group explains, is the reason it has been working on a formal memory model for the Vulkan API's GLSL and SPIR-V programming languages - the first graphics API to feature such a thing, it claims, while admitting that its memory model specification is still in a provisional state.

'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,' the Group claims in its announcement. '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 optimisations.'

While the existence of a formal memory model specification is of most interest to developers - who can find a specification, conformance tests, and a description written in MIT's Alloy language on the Group's GitHub repository - it will have an effect on end-users, too: A more robust graphics standard means, in theory at least, increased reliability, while increasingly aggressive compiler optimisations allowed by said robustness will hopefully boost performance.

More information is available on the Khronos Group blog.