Vulkan Memory Allocator 1.0

Full application control over GPU memory is one of the major differentiating features of the newer explicit graphics APIs such as Vulkan® and Direct3D® 12. In previous APIs, the GPU driver would have complete control over the surfaces and buffers you create, marshaling the memory to hopefully extract good performance, based on an inferred view of how the application wants to render via the API calls you make, and a need for the GPU to be shared with other system elements like the display compositor.

In modern explicit APIs the GPU is still a shared resource, meaning the driver still has some work to do, but now you’re in full control over the GPU memory used by your application, such as where it’s placed, how it’s allocated and how it is moved around to suit what you’re rendering. That’s a new burden for you as the application developer, and it’s often not clear what the best strategy to deal with it is.

As part of our work on Vulkan gaming applications that are trying to solve these problems, we’ve created a straightforward memory allocator for Vulkan that we’re continuing to develop. It’s at the stage where we’d like to release it for you to start using it, while we continue to incrementally improve it and think about integrating it with our other Vulkan technologies where we can.

Version 1.0 supports easy allocation of buffer and image storage out of larger allocated blocks, and comes with a small sample that shows you how to use it. The sample renders a cube with an index buffer, vertex buffer and texture, all allocated using the library.

Our plans for 2.0 and beyond include support for an allocation strategy that’s suitable for games that need to do texture streaming. Please keep an eye out for future library updates.

The API is defined in a single well-documented header, much like STB, and the code is MIT licensed with a single Apache-licensed dependency, MathFu (only used for the sample, not the library). We’ve also engineered it to make it very easy to swap in your own STL variant where you need to for the container types the library currently needs, or even remove our STL-compatible data structures entirely, in favour of your own. So if you use something like EASTL, or define your own in-house STL-compatible structures as we do, the library needs minimal work to integrate.

As with most things on GPUOpen, the code is on GitHub and we encourage you to use it in anger in your projects, to file issues for us to look at, and we’d also love to see changes to help us improve it in the future.

Source Code

GitHub

Product Page

Vulkan Memory Allocator on GPUOpen