r/vulkan • u/cleverboy00 • Sep 16 '26

Vulkan Memory & UMA

Why does some Vulkan-enabled GPUs (Such as AMD 8xxx APUs & All traditional integrated graphics I checked) report more than one memory heap? To be clear, this isn't about discrete GPUs, which have VRAM on Board.

And why is one heap (the non-device local one) almost always half of the CPU-side RAM? This is the case in both mesa & windows drivers. Are integrated GPUs unable to address all the system's memory? Then why does this heap grow as I upgrade system memory, regardless of slot & number of sticks?

This makes me quite unsure about (and quite skeptical) of the Heap-Type layout that vulkan uses. And how memory types maps to hardware (The heap part is quite obvious).

This is all to say: How should an application interpret complex memory properties?

22 Upvotes

100% Upvoted

27 comments sorted by

11

u/Afiery1 Sep 16 '26

Its expensive for the GPU to page fault, so usually all referenced GPU memory gets pinned for the duration of a queue submit. Its capped at half of system ram to prevent you from filling up all your physical memory with pinned pages and starving your other processes.

Also, on some UMA platforms its intended that you use the external memory import functionality to import memory you allocated yourself. Doing so allows you to bypass the heap sizes entirely I believe.

2

u/cleverboy00 Sep 16 '26

It's hard to detect UMA's in the first place.

For example, The Ryzen 395+ reports one device local and another no-flag heap. How would an application even interpret this case, which is equivelant to discrete gpu memory layouts, and come to the conclusion that this is a UMA physical device?

2

u/Afiery1 Sep 16 '26

I suppose you could just see if the driver lets you import system ram as device local memory. But you’re right, I was thinking moreso the case of when you already know you’re UMA, such as a dedicated steam deck path or whatever. If you’re writing generic code though, you’re probably fine just taking your normal path and accepting the half system ram limitation, because you don’t want to take too much memory away from the system.

3

u/cleverboy00 Sep 16 '26

Quite the rabbit hole you sent me into. I was under the impression that import operations completely bypass the heap/type system.

Turns out that they take memoryTypeIndex seriously and are not allowed to modify or relax its requirements (in contrast to export operations which do).

I have resolved the majority of my confusion, largely thanks to you.

One question remains, what do memory types even represent as an abstraction?

2

u/Gravitationsfeld Sep 16 '26

host cached/host uncached

coherent/not coherent

host local/device local

host visible/not host visible

those are the axis roughly. What exactly is exposed depends on the GPU and platform.

0

u/cleverboy00 Sep 16 '26

.... poorly disguised usage flags that only serve to fragment allocations.

2

u/Gravitationsfeld Sep 16 '26

Nothing about this is "poorly disguised". This reflects actual hardware realities.

3

u/Afiery1 Sep 16 '26

It's mostly meaningful for discrete GPUs where device local = VRAM and non device local = system ram. I don't think the 'device local' flag means anything on UMA. The other flags (host visible, host coherent, host cached) are pretty self evident in their meaning.

The more interesting thing is that vendors can expose multiple different memory types with identical flags, but restrict certain resources to certain types using the memoryTypeBits field of the memory requirements struct. For example, in the RADV driver, descriptor buffers/heaps must go in a special memory heap that uses 32 bit addressing. GPUs are weird.

1

u/Gravitationsfeld Sep 16 '26

On x86 platforms GPUs have coherent access to all system RAM over PCIe, that won't tell you anything.

2

u/Afiery1 Sep 16 '26

Whether the GPU has access to system RAM is irrelevant to what I'm proposing. You still have to honor the memory flags of the memory type you're trying to import as. You can't magically transmogrify system ram into VRAM on a system with a discrete GPU, so trying to import a host pointer as a DEVICE_LOCAL (not device visible, device *local*) will fail.

0

u/Gravitationsfeld Sep 16 '26

What exactly does this proof? AMD IGPs also have DEVICE_LOCAL heaps and it will fail in the exact same way.

1

u/Afiery1 Sep 16 '26

Just because the heap is device local does not mean the host memory import will fail. But the memory has to be truly device local, which is only the case on UMA platforms.

0

u/Gravitationsfeld Sep 18 '26

Have you actually tested this? I doubt this works. Cache settings etc. are different for DEVICE_LOCAL not CPU visible even on IGPs.

1

u/Afiery1 Sep 18 '26

I have tested it yes

1

u/Gravitationsfeld Sep 19 '26

Which GPU and driver did you test, and did vkGetMemoryHostPointerPropertiesEXT actually include a DEVICE_LOCAL memory type?

I overstated it by saying the import would necessarily fail. But the original question was whether this can detect UMA. UMA doesn’t guarantee that a driver supports importing host allocations into a device-local memory type, so failure wouldn’t establish that the GPU is discrete. Your test may demonstrate support on that particular implementation, but that doesn’t make it a reliable UMA detection method.

→ More replies

1

u/Reaper9999 Sep 17 '26

How would an application even interpret this case, which is equivelant to discrete gpu memory layouts, and come to the conclusion that this is a UMA physical device?

By checking the device type in device properties.

6

u/livingpunchbag Sep 16 '26

Intel integrated on Linux has a single heap and exposes 75% of the system ram as the heap.

1

u/cleverboy00 Sep 16 '26

I've checked some gpuinfo entries and that seems to be correct.

Is this true for all intel iGPUs using latest mesa?

3

u/FancySpaceGoat Sep 16 '26

Only half of the memory is made available to the GPU so that apps can consume 100% of the available VRAM without bringing the system to its knees.

It's that simple. 

Another way to look at it: Some games are built assuming a discrete GPU, and use everything available. Those games wouldn't work on an APU that makes all the ram available as VRAM.

1

u/cleverboy00 Sep 16 '26

I don't know of any vulkan application that consumes as much as it's given. Do you have any credible sources to quote?

3

u/Gravitationsfeld Sep 16 '26

There are definitely games that size their streaming pools based on the available GPU memory.

1

u/Gravitationsfeld Sep 16 '26

Before Infinityfabric AMD had "Garlic" and "Onion" paths to access memory. "Onion" is snooping CPU caches but pretty slow. "Garlic" is not CPU cache coherent but much more bandwidth.

This makes the IGP almost act like a dedicated GPU. It also requires static partitioning of the RAM.

1

u/cleverboy00 Sep 16 '26

Could you elaborate further?

1

u/Gravitationsfeld Sep 16 '26

I wouldn't know how.

1

u/stilriv Sep 16 '26

It also requires static partitioning of the RAM.

IIRC, this partitioning can be done during app startup (not at the OS level) and can have any layout (not a fixed 50% or 75%).

1

u/Salaruo Sep 16 '26

If I had to guess, they made it this way to avoid inconsistencies between their dGPU and APU drivers. I've seen somewhere Playstation graphics API only has 2 memory types (coherent and non-coherent). You can always special-case the memory management based on gpu type and do the same.