About memory residency and Vulkan API

As far as I understand Vulkan API does not offer any methods to check for GPU memory residency of resources. So if the operating system decides to move a memory block to RAM for example, we have no control of seeing this in Vulkan.

DirectX 12 however can control memory residency. Microsoft however has it much easier because they only support Windows 10, not all platforms like Vulkan API.

Will features like this ever be in Vulkan API?


1 Like

As I started to write this answer, I came to realize that the term “resident” is overloaded in this case. Both Vulkan and D3D12 talk about “residency”, but they’re talking about different things. So I’m going to ignore that word and use more descriptive terms.

From a quick skimming of the Residency page on D3D12, what D3D12 offers is knowledge of, and some limited control over, virtual memory being paged in/out of actual device memory.

It provides a priority system to “heaps” (memory allocations in Vulkan terminology) to tell the system which “heaps” are more important to keep in GPU-accessible memory and which are not. It has some notion of how much memory the application can use safely (the “budget”) and if it is exceeded, then things could start to be paged out of GPU-accessible memory.

Vulkan doesn’t provide any of those. As far as the Vulkan abstraction is concerned, memory allocations belong to your application. They are always where they appear to be, and if any kind of paging out of memory happens, then the implementation is responsible for paging it back in should you use that memory.

Vulkan’s notion of “residency” is something quite different. It has, as an optional feature, explicit control over the mapping between virtual addresses and their backing memory storage. Memory consuming resources (images and buffers) can be “sparse”; that is, the backing memory for them may not be truly contiguous or only some of the apparent memory may be backed by actual memory.

Sparse allocations are basically just allocating virtual addresses. You can then assign a portion of a sparse allocation to actual memory. You can evict portions from backing storage too, and this means that the data in that storage is lost (it’s now free to be allocated later).

This isn’t like virtual paging at all.

In any case, the extensions VK_EXT_memory_budget and VK_EXT_memory_priority provide most of the functionality of D3D12. The former lets you query for your memory “budget” dynamically. And the latter lets you specify priorities for allocations.

These extensions seem to be fairly widely supported on desktop Vulkan implementations. No Intel drivers exist for them, but as integrated a UMA system, that makes sense. For some reason, Linux NVIDIA drivers don’t seem to support priority, but they do support budget.

It doesn’t provide a way to “evict” an allocation the way D3D12 does, but even D3D12’s documentation suggests that you prefer deallocation to eviction.

1 Like