A change merged yesterday to the Intel Mesa graphics driver code lessens a restriction around the amount of system memory (RAM) that can be used by processes for the Vulkan system heap. This will allow more games/apps to work with the Intel integrated graphics that previously exceeded the driver-enforced limits but at the risk of running into broader out-of-memory behavior if under too much memory pressure.
The change is about restoring a previously-set 75% limit of RAM for the system heap with the Intel ANV Vulkan driver. For the past eight years there’s been a 50% limit of RAM for the system heap.
Intel Linux graphics driver engineer Paulo Zanoni argued in the year-old Mesa merge request:
“Unfortunately we can’t make everyone happy, but my main motivation here is that certain workloads can actually work with my system, and the only thing stopping them from working is this restriction is we inflict in ourselves. Examples: Deathloop on 16GB TGL, certain graphics settings of Spider-Man Remastered on my 16GB non-upgradeable-RAM LNL, Renderdoc.
Of course, this always brings the risk that running too many things at once may awake the OOM monster, but IMHO, completely preventing certain workloads from working is too high of a price to pay in a situation where you can just use /usr/bin/kill something. Still, I’m open to discussion here. We don’t need to apply all patches in the series.”
That merge request was under discussion since April 2024 and finally now merged for Mesa 25.1. Raising this RAM restriction is all the more important with the newest Lunar Lake SoCs having non-upgradeable system memory but this change will help users at large too.
The actual patch goes on to further describe this behavior and prior and new limits:
anv: restore the old behavior of up to 75% of RAM for the system heap
“We paid for sixteen gigs of RAM, so we gonna use the whole damn sixteen gigs of RAM!”
– My MomFirst, some history:
The Anv 50%-or-75% rule was originally added in 2017 by 060a6434eca9 (“anv: Advertise larger heap sizes”). When i915.ko started reporting memory sizes in its ioctls, it didn’t impose any restrictions: 100% of SRAM was reported as available, so the restriction was in Mesa. When xe.ko was introduced, it only reported 50% of the SRAM as available through its ioctls, so commit b571ae6e7a76 (“intel: Make memory heaps consistent between KMDs”) adapted the code to not take an extra 25% of the 50% that was already cut, and restricted i915.ko to 50% instead of the 50%-or-75%. In Kernel commit d2d5f6d57884 (“drm/xe: Increase the XE_PL_TT watermark”), xe.ko changed to reporting 100% of SRAM through its ioctls, so we adapted Mesa to do the right thing depending on which Kernel version was running.
While this was all happening, we were discussing about which behavior was actually the best: restrict everything to 50% in order to avoid issues when many things are running in parallel, or keep the restriction only at 75% in order to allow high demanding workloads to make full use of the hardware.
The way I see, if parallel applications are causing the system to run out of resources, the user always has the option to kill applications and use one thing at a time. On the other hand, if a single application needs more than 50% of the SRAM and we don’t allow it in our heaps, the application will never work (unless, of course, the user patches Mesa). So in this commit we go back to allowing high-demanding applications to work by restoring the 50%-or-75% rule.
This commit is especially useful in systems with integrated graphics, like LNL, where the option to upgrade RAM is not present.
Intel Linux graphics users can look forward to this change with Mesa 25.1 that should be out as stable by/around the end of May.
