February 5, 2026 by Tobias Hector - AMD Software Architect / Vulkan Strategy Officer
When those of us in the Vulkan® working group want to modify the API—whether it’s a new hardware feature to expose, a new use case we want to address, or even just a gap in the spec we want to address—we have one invaluable tool that we make heavy use of: extensions!
Extensions are a wonderful way for us to get improvements to the Vulkan API out to developers without waiting for a new core version. They let vendors expose novel functionality and enable us to gather community feedback on new features before we firm them up into a core specification.
Amazing! So we get new functionality out to developers quickly—what’s not to love!? Well…
The Extension Explosion Problem 💥
Having access to this much extensibility comes at a cost. As we add more extensions to the API, we sometimes inadvertently obscure the simplest way to use it. What functionality can you rely on always being there? How many ways are there to do what you want to do? Which of those ways will give the best performance? How many paths through the API can you reasonably support in one application?
We sometimes lovingly refer to this as the “extension explosion problem” due to the number of extensions we have now—and how many existed in OpenGL/ES™ beforehand. The more we add, the more they chain off of and interact with each other, adding combinatorically to the decision space for developers.
This is a persistent challenge that we’ve heard loud and clear from Vulkan’s developer base, but until now we haven’t had a good solution.
When we produced Vulkan 1.0, it gave us a clean slate moving from OpenGL® , but now 10 years into Vulkan we are facing the same problem again. So, what’s the answer? Should we rebuild the entire API from scratch every few years?
No—believe it or not, we add more extensions!
... continue reading