Skip to content or navigation


What Matters—Vulkan Graphics API is World’s First with Formal Memory Model

Vulkan becomes world’s first graphics application programming interface (API) to support a formal memory model for optimization progressive performance in parallel processing on GPUs.

Advertisement

A relatively new development in the world of computer science, “formal memory models” have risen to meet the challenge and opportunities inherent in multicore processors. Version 11 of the computer language C++ is the first to include a memory model definition for execution on CPUs. The Khronos Group notes on their blog, “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.

Khronos Writes Description of Vulkan Memory Model with MIT’s Alloy

In tandem to writing extensions to the Vulkan API, the group has released a formal description of the Vulkan memory model using Alloy—a computer language developed by MIT for describing logical structures and a tool for exploring them.

While formal memory models were invented concerning multicore CPUs, GPU processors are also parallel and programmable, and their associated shading languages and compilers could benefit from a formal memory model as well. This month 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 conspire to further boost the robustness of the open industry standard Vulkan API.

What is a Memory Model and Why Should I Care

A formal memory model or memory consistency model for a programming language describes how each thread in a parallel system can access shared data and synchronize with each other. This gives the hardware and compilers a liberty to reorder and optimize memory accesses.

The memory models achieve this by specifying precisely 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. The new Vulkan Memory Model Specification includes the extensions for Vulkan, SPIR-V, and GLSL and gives developers additional control over how their shaders synchronize access to the memory in a parallel execution environment.

Khronos has also released a memory model extension conformance test to help shader compilers ensure that they implement the specified memory model synchronization functionality correctly.

Graphics professionals should care about this development because it means greater performance will emerge over time as more 3D graphics software taps the power of the Vulkan API across a large array of computer platforms. For Apple’s customers, many developers we have begun to talk to have said that Vulkan looks very promising as the next path after OpenGL in near-term future.

Releases for Use

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.

Architosh Analysis and Commentary

This post is rather of the “geeky” nature that Architosh sometimes ventures off into and which the site has a long history in writings about processors in general. With parallel processor computing there is the issue of “concurrency” where there are “reads” and “writes” happening at essentially the same time and what values can be read when issued concurrently with writes. 

From quickly reviewing the literature on this particular topic, a key consideration is that GPUs have unique memory systems and concurrency considerations as compared to CPUs. Also, it seems to be from a quick review of academic papers on this topic that there is widespread consensus that programming models and memory behaviors on GPUs are not nearly as well understood as they are on classical CPUs. Thus this work by the Khronos Group is important. It is also timely as more generalized computational work aims at tapping the power of GPUs rather than CPUs. 

For those readers who want to learn a bit more about this subject, this short academic paper here titled, “GPU Concurrency and Consistency” is good. A longer and quite impressive under-graduate researched paper is this one by Tyler Sorensen from the University of Utah titled, “Towards Shared Memory Consistency Models for GPUs.” 

Reader Comments

Comments for this story are closed

architosh

INSIDER Xpresso 
Monthly newsletter with a focus on emTech (AI, machine learning, AAD, AR, robotics, 3d printing, and smart cities) its impact on CAD professionals.)

Subscribe now — it’s free!.

INSIDER Xpresso keeps CAD industry professionals up-to-date on next-gen emerging technologies (emTech) that will revolutionize the worlds of AEC and manufacturing and design. As an Xpresso reader, you will hear from some of the most important voices inventing and using the very latest tech in areas such as AI, machine learning, algorithm-aided design (AAD), AR, VR, MR, 3D printing, 3D computer vision, robotics, and SmartCities technologies.

Each issue arrives in your inbox on the first Sunday of the month. Issue #1 arrived on March 3, 2019. Full archives and easy navigation for your pleasure. Enjoy! 

Sign-up for our monthly newsletter
architosh INSIDER Xpresso.

  • Architosh will never pass any of your information onto third parties.
  • For more information read our privacy policy.
  • It is easy to unsubscribe at any time. Follow the links in the newletter footer.

(Recommended. These infrequent sponsored emails help us to provide our Xpresso newsletter for free.)

 
INSIDER Membership

Read 3 free Feature or Analysis articles per month.

Or, subscribe now for unlimited full access to Architosh.