Propuesta para estandarizar las estadísticas de memoria de vídeo en Linux

Que en Linux no exista una forma homogénea de preguntar cuánta memoria de vídeo queda libre es una de esas cosas que sorprenden hasta que llevas un rato peleándote con ellas. Cada driver DRM expone lo que quiere, como quiere y donde quiere. Hoy se ha propuesto un estándar para acabar con eso, y viene de alguien que se topó con el problema en el sitio menos pensado: el instalador del sistema operativo.

Tvrtko Ursulin, de Igalia, quiere poder dimensionar correctamente la swap durante la instalación a partir de la memoria de vídeo disponible en la máquina. Para eso necesita leer ese dato de forma que funcione con cualquier tarjeta y cualquier driver, y hoy no puede. Su propuesta define una interfaz en sysfs, del estilo /sys/class/drm/card1/memstat/, donde cada región de memoria se publica como un directorio propio: la vRAM, la GTT y las que cada driver tenga.

Qué expone y qué hace falta para que funcione

Por cada región habría dos valores: el total de memoria disponible, en MB, y la cantidad usada en ese momento. Nada más. La gracia está en que el formato sea idéntico venga de una GPU AMD, Intel o NVIDIA, y eso es precisamente lo que no ocurre ahora.

El precio a pagar es que el estándar no sirve de nada sin la parte de abajo. Cada driver DRM tiene que integrarse: hace falta un callback nuevo que devuelva la lista de regiones de memoria y sus estadísticas, y a partir de ahí el kernel las cuelga del directorio memstat de forma uniforme. Sin ese trabajo por driver, la interfaz queda vacía.

Ursulin acompaña la propuesta con un parche que implementa la interfaz en el driver AMDGPU, para que se vea funcionando sobre código real y no sobre una diapositiva. La discusión está abierta en la lista dri-devel, en formato RFC, es decir, pidiendo comentarios antes de plantear nada definitivo.

Conviene recordar que ya existe el controlador de cgroups de memoria de dispositivo, que permite limitar y contabilizar el uso de memoria de la GPU donde está disponible y habilitado. Lo que no había hasta ahora era una vía de solo lectura, común a todos los fabricantes, para consultar el estado de esas regiones.

Por qué importa

A quien administre servidores con GPU compartida, a quien escriba herramientas de monitorización o a quien tenga que automatizar despliegues, un dato como este le ahorra depender de binarios propietarios o de leer ficheros distintos por cada vendor. También le importa a quien mantenga un instalador, que es de donde sale todo esto.

El historial de intentos anteriores juega en contra: la idea lleva tiempo rondando y en 2026 sigue sin entrar en el kernel principal. Si esta vez cuaja, dependerá de cuántos mantenedores de drivers acepten implementar el callback y de si el formato concreto sobrevive a la revisión de la lista.