There is no vendor-agnostic way for a Linux program to ask how much video memory a system has, or how much of it is in use. In 2026.

Tvrtko Ursulin of Igalia has posted an RFC to change that.

Where the request came from

The motivating case is pleasingly mundane: a developer wanted to size swap space correctly during OS installation based on how much video memory the machine has.

That is a reasonable thing to want. Hibernation writes system memory to swap, and on systems where graphics memory is carved out of system RAM the arithmetic changes. To do it properly the installer needs a number, and today there is no portable way to get one.

Every driver reports differently. AMDGPU has its own files, Intel has others, NVIDIA’s open driver something else again, and anything wanting to work across all of them ends up with a per-vendor parsing function and a guess for anything it does not recognise.

The proposal

A standardised sysfs interface:

/sys/class/drm/card1/memstat/

Inside it, one entry per memory region, such as VRAM and GTT, each exposing:

• Total memory available, in MB
• Currently used memory for that region

GTT, the Graphics Translation Table, is system memory the GPU can address directly, which is why more than one region matters. A discrete card has dedicated VRAM plus GTT. An integrated GPU has no VRAM in the dedicated sense at all. One number was never going to describe both.

Implementation requires a small callback in each DRM driver reporting its region list and current figures. The kernel side then presents them uniformly under memstat. The RFC includes a working implementation for AMDGPU as a demonstration.

Why this has not happened already

Partly because everyone who needed the number badly enough wrote vendor-specific code and stopped caring, which removes the pressure to standardise.

Partly because “how much memory is in use” is genuinely ambiguous on a GPU. Memory can be resident, evicted to system RAM, shared between processes, or reserved without being touched. Agreeing on what “used” counts is harder than exposing a file, and a standard interface that different drivers interpret differently is worse than none.

There is also a device memory cgroup controller where it is present and enabled, which addresses accounting and limits rather than the simpler question of what the hardware has.

What it would enable

• Installers sizing swap and making sensible partitioning decisions
• System monitors showing GPU memory next to system memory without vendor-specific backends
• Container and VM schedulers placing GPU workloads by available memory
• Ordinary troubleshooting, where “is the GPU out of memory” currently requires knowing which vendor’s file to read

# what you have to do today, per vendor
cat /sys/class/drm/card0/device/mem_info_vram_total 2>/dev/null
cat /sys/class/drm/card0/device/mem_info_vram_used 2>/dev/null

# the general view
sudo lshw -C display
glxinfo -B 2>/dev/null | grep -i memory

Status

This is a request for comments, not a merge candidate. It is the stage where the interface shape gets argued about, and the definitional question of what counts as used memory is where the argument will be.

It sits alongside other cross-cutting graphics work this cycle, including Intel’s Xe driver adding VRAM health checks and degraded memory handling for 7.4. Reporting what the memory is doing and reporting whether it is healthy are adjacent problems, and both have been left to individual drivers for a long time.