// PC GAMER — GAMING
The latest SteamOS beta update includes a performance boost for GPUs with limited VRAM, though devices with iGPUs probably won't see any gains
But if the device is a certain Machine, then this is definitely good news.
When you purchase through links on our site, we may earn an affiliate commission. Here’s how it works.
If there is one thing that is common across all devices that natively run SteamOS, it's that the graphics chips inside them don't have access to a great deal of VRAM. That's a bit of a problem with some games, but thanks to the genius of a handful of coders, a solution has been rolled out in the latest 3.8.20 beta version of Valve's operating system.
As noted by TechPowerUp, one of the coders in question is Natalie Vock, who describes their role as "an independent contractor for Valve on RADV, the community-developed open-source Vulkan driver for AMD GPUs." Earlier this year, Vock published a blog post on a solution to issues with how Linux handles VRAM allocation and usage, so it's not in the least bit surprising that Valve implemented this in SteamOS.
As I'm sure you all know, discrete GPUs have a pool of memory dedicated entirely to them (aka VRAM). However, that's not the only memory they get to play around with, and there is an additional pool within the system memory called a Graphics Translation Table (GTT for short). Although this is managed by the OS, it is fully visible to the GPU.
The main problem with the GTT is that the GPU accesses it over the device's PCIe interface, which has way less bandwidth (plus worse overall latencies) than the dedicated VRAM. That means if the data the GPU is requested is located within the GTT, then the performance at that stage will tank.
Games and other applications handle this by ensuring that what the GPU actually needs resides in the VRAM, but if there's more data in total than there's available in the dedicated pool, the operating system will move stuff about (i.e. carry out an eviction process) to keep important stuff in VRAM and the excess in the GTT.
You can probably see why evictions are the real problem here. First of all, the OS has no idea what data is or isn't important; as graphics memory is virtualised for the GPU, it doesn't know either. Secondly, constantly shifting data around between memory pools is a recipe for a performance stall, so an 'allocation strategy' was developed for Linux's memory manager.
"Instead of specifying VRAM as the only acceptable domain to place the allocation in, every VRAM allocation request would specify both “VRAM” and “GTT” as possible memory domains," explains Vock. "The kernel would interpret this as VRAM being preferred, but if there was no space, GTT was an acceptable fallback and the kernel wouldn’t try to kick out other VRAM memory to make space."
Keep up to date with the most important stories and the best deals, as picked by the PC Gamer team.