- Los parches de Natalie Vock para el kernel y KDE priorizan la VRAM del juego en primer plano, reduciendo el uso del GTT y el stuttering.
- dmemcg-booster y plasma-foreground-booster coordinan kernel y escritorio para proteger la memoria de la GPU asignada al juego activo.
- Las mejoras benefician sobre todo a GPUs AMD con 8 GB de VRAM o menos, ya disponibles de forma sencilla en CachyOS y previstas para integrarse upstream.
- El nuevo sistema aprovecha mejor cada MB de VRAM, estabiliza los FPS mínimos y alarga la vida útil de tarjetas de gama media en Linux.
Si juegas en PC con Linux y sigues tirando de una gráfica con 8 GB de VRAM o menos, seguro que has sufrido tirones, microparones y bajones de FPS en los títulos más modernos. Lo llamativo es que, muchas veces, esa mala experiencia no se debe tanto a la potencia bruta de tu GPU como a cómo el sistema gestiona la memoria de vídeo cuando las cosas se ponen feas.
Todo esto acaba de dar un giro bastante serio gracias al trabajo de Natalie Vock, ingeniera del equipo de drivers gráficos de Valve, especializada en RADV (el driver Vulkan para GPUs AMD). Vock ha desarrollado una batería de parches para el kernel de Linux, KDE Plasma y el ecosistema de Gamescope que cambia por completo la forma en la que el sistema decide qué se queda en la VRAM y qué es expulsado a la RAM del sistema cuando ya no queda espacio.
El problema de las GPUs con 8 GB de VRAM en Linux
En los últimos años, la cantidad de memoria de vídeo se ha convertido en un cuello de botella muy real. Los juegos actuales cargan texturas enormes, geometría compleja y efectos avanzados que devoran la VRAM. Con 8 GB o menos, algo muy habitual en la gama media, es fácil que el juego llene la memoria de la gráfica en cuanto subes un poco los ajustes.
En Linux, cuando la VRAM empieza a rebosar, entra en juego el llamado Graphics Translation Table (GTT). Básicamente, el sistema comienza a mover parte de los datos de la GPU a la memoria RAM del equipo para evitar cuelgues. El problema es que la RAM, aunque sea rápida, es bastante más lenta que la VRAM, y ese salto de latencia se traduce en stuttering, picos de tiempo de frame y una sensación de juego a trompicones.
Hasta ahora, el kernel de Linux no tenía una forma realmente fina de decidir qué datos merecían quedarse en la VRAM y cuáles podían ser mandados a la RAM sin que pasara nada grave. El sistema no tenía en cuenta adecuadamente si el proceso era un juego a pantalla completa o un navegador perdido en segundo plano. En muchas situaciones, era el propio juego el que terminaba parcialmente expulsado fuera de la VRAM, mientras aplicaciones de escritorio menos relevantes seguían ocupando memoria de vídeo.
Todo esto se traducía en un escenario muy poco ideal para los jugadores: con una GPU de 8 GB, en títulos exigentes como Cyberpunk 2077 bajo Steam Play, el sistema apenas aprovechaba 6 GB de VRAM, mientras más de 1,3 GB se iban al GTT en RAM, algo totalmente contrario a lo deseable. En resumen: sobraba VRAM libre y, aun así, el juego sufría.
La consecuencia práctica para el usuario era clara: FPS mínimos inestables, tirones al cargar nuevas zonas, pequeños congelones al girar la cámara o al entrar en un área diferente y una sensación general de que “la gráfica va justa”, cuando en realidad el cuello de botella venía de una gestión de memoria poco afinada.
La propuesta de Valve y Natalie Vock: priorizar el juego en la VRAM
Para atacar este problema de raíz, Vock ha diseñado una solución que combina cambios en el kernel con herramientas en espacio de usuario. La idea central es sencilla de explicar, aunque por debajo haya mucha ingeniería: decirle claramente a Linux qué aplicación está en primer plano y debe tener prioridad absoluta en la VRAM.
El núcleo técnico de esta propuesta son unos parches para el controlador de cgroups de memoria de dispositivo DRM (Device Memory cgroup) y una serie de modificaciones profundas en el subsistema de gestión de memoria TTM (Translation Table Maps) del kernel. TTM es el encargado de decidir cómo se asigna y se expulsa memoria en los dispositivos gráficos, así que es el lugar perfecto para enseñarle al sistema una nueva forma de pensar.
Lo que hacen estos parches es permitir que el kernel identifique el grupo de memoria asociado al juego en primer plano y le dé trato VIP. Cuando hay que expulsar algo de la VRAM porque ya no cabe más, el sistema va a buscar primero en los procesos de escritorio, navegadores, reproductores o utilidades que se están ejecutando en segundo plano, dejando el contenido crítico del juego como última opción.
En palabras menos técnicas: a partir de ahora, si estás jugando y tienes varias ventanas abiertas, la VRAM «pertenece» antes al juego que a cualquier otra cosa. Solo cuando ya no quede literalmente otra opción, Linux tocará los recursos del título activo, reduciendo muchísimo la probabilidad de que aparezcan tirones por culpa de una mala decisión de expulsión.
Detrás de este cambio hay una integración muy estrecha con las funcionalidades de cgroups de Linux, un mecanismo que ya utiliza systemd para aislar y controlar recursos de cada aplicación. Vock ha aprovechado este sistema para crear una forma de clasificar y proteger la memoria de la GPU por grupos de procesos, permitiendo que el kernel sepa en todo momento qué hay que preservar y qué se puede sacrificar.
dmemcg-booster: el corazón del nuevo control de memoria de dispositivo
La pieza clave en espacio de usuario se llama dmemcg-booster. Se trata de un servicio para systemd que se encarga de orquestar cómo se aplican los límites y prioridades de los Device Memory Control Groups (DMEM cgroups) sobre las aplicaciones que usan la GPU.
Su función principal es indicarle claramente al sistema qué programa debe estar protegido en la VRAM en cada momento. Cuando lanzas un juego y este pasa a ser la ventana principal, dmemcg-booster lo marca como proceso prioritario dentro de su cgroup, de modo que el kernel entiende que esa memoria de vídeo no se puede tocar a la ligera.
En ausencia de este mecanismo, el kernel veía todos los usos de la VRAM prácticamente al mismo nivel, lo que llevaba a expulsiones “a ciegas”. Con dmemcg-booster en marcha, si hay que hacer hueco porque la memoria se llena, los primeros en salir hacia la RAM serán los procesos secundarios: escritorios, navegadores o aplicaciones que no estén en foco.
Esta priorización no reduce mágicamente el consumo de VRAM del juego, pero sí aprovecha al máximo hasta el último megabyte disponible. De este modo, una GPU que antes parecía quedarse corta por cómo se gestionaba la memoria, ahora puede rendir mucho más cerca de su verdadero potencial.
En las pruebas que ha compartido Vock con Cyberpunk 2077 en una tarjeta de 8 GB usando Steam Play, el cambio es muy evidente: antes de los parches, el juego apenas utilizaba unos 6 GB de VRAM, con alrededor de 1,37 GB derramados al GTT en RAM. Tras activar la nueva arquitectura de memoria, el título llega a usar unos 7,4 GB de VRAM reales, mientras que el uso del GTT baja a unos 650 MB, es decir, se reduce a menos de la mitad.
plasma-foreground-booster y la coordinación con KDE Plasma
Para que todo este sistema de prioridades funcione de forma fina, no basta con modificar el kernel; el entorno de escritorio también tiene que decirle al sistema qué ventana está realmente en primer plano. Aquí entra el segundo componente desarrollado por Valve: plasma-foreground-booster.
Este módulo está pensado para integrarse con KDE Plasma y actúa como un puente entre el escritorio y los mecanismos de cgroups de memoria de dispositivo. Su misión es sencilla, pero clave: informar en tiempo real de qué ventana es la activa (normalmente, tu juego a pantalla completa) para que el sistema pueda ajustar dinámicamente las prioridades de VRAM.
Cuando cambias de aplicación o alt+tab a otra ventana, plasma-foreground-booster actualiza la información que llega al kernel y a dmemcg-booster, de modo que la «corona» de prioridad sobre la VRAM puede cambiar si así lo decides. Es una coreografía entre escritorio y kernel que antes, simplemente, no existía.
Además de KDE Plasma, Valve ha pensado en quienes usan otros escritorios. Para esos casos, la solución pasa por aprovechar las versiones más recientes de Gamescope, el ya conocido micro-compositor de Valve ampliamente usado en Steam Deck y en entornos orientados al juego. Gamescope puede encargarse de hacer una función similar a la de Plasma: identificar la ventana del juego y marcarla para recibir prioridad de recursos, o, en algunos flujos, usar herramientas como Bottles para gestionar sesiones de compatibilidad.
La idea de fondo es construir un ecosistema coordinado, desde el kernel hasta el escritorio, en el que todo el sistema esté alineado con lo que el usuario realmente quiere: que el juego que tiene delante vaya lo más fluido posible, incluso aunque haya otras cosas corriendo por detrás.
Resultados prácticos en juegos como Cyberpunk 2077
Más allá de la teoría, lo importante es cómo se traduce todo esto en la experiencia de juego diaria. En los ejemplos públicos que ha mostrado Vock, uno de los casos más representativos es Cyberpunk 2077 corriendo bajo Steam Play en una GPU de 8 GB.
En la situación anterior a los parches, el título funcionaba con un uso de VRAM que, sobre el papel, parecía aceptable, pero en realidad estaba lejos de aprovechar toda la memoria disponible: unos 6 GB en la GPU y 1,37 GB «derramados» al GTT. Este derrame constante hacía que una parte relevante de los datos gráficos estuviera realmente en la RAM del sistema, obligando a la GPU a consultarlos a través del GTT y generando saltos en el tiempo de respuesta.
Con la nueva arquitectura en marcha, el escenario cambia notablemente. Cyberpunk 2077 pasa a utilizar casi toda la VRAM disponible, alrededor de 7,4 GB, mientras que el uso del GTT desciende a unos 650 MB. Menos memoria expulsada significa menos accesos lentos a la RAM y, por tanto, una experiencia de juego mucho más estable.
Es importante recalcar que estos parches no están orientados tanto a aumentar el FPS máximo, ese numerito que ves al mirar a una pared, sino a mejorar los FPS mínimos y la estabilidad del frame time. Es decir, se reduce el stuttering, se suavizan los picos y se gana en sensación de fluidez general, que es lo que realmente nota el jugador cuando se mueve por Night City o por cualquier otro mundo abierto exigente.
En la práctica, el beneficio es especialmente notable en sistemas donde la VRAM ya iba muy al límite: gráficas de 8 GB o menos ejecutando juegos AAA modernos, con varios programas abiertos al mismo tiempo. Es justo en esos escenarios de «todo justito» donde una buena gestión de expulsiones y prioridades puede alargar la vida útil de la tarjeta un par de generaciones más.
Distribuciones, compatibilidad y estado actual de los parches
En el momento en que se han publicado los detalles, la forma más sencilla de probar esta nueva arquitectura de memoria es usar CachyOS, una distribución que se ha adelantado al resto e integra de serie estos parches tanto en el kernel como en los componentes de espacio de usuario.
Para otras distros, es posible compilar el kernel parcheado y los paquetes dmemcg-booster y plasma-foreground-booster por cuenta propia, aunque esto ya implica un nivel de conocimientos algo mayor. La intención de Vock y del ecosistema es que, con el tiempo, todas estas mejoras se integren upstream en el kernel oficial de Linux y en los repositorios formales de KDE y de Valve, de manera que usuarios de Ubuntu, Fedora, Arch y compañía puedan beneficiarse sin tener que tocar nada raro; y, para quienes necesiten capas de compatibilidad, también existen opciones como Wine.
Hay un matiz importante: estos cambios están pensados principalmente para GPUs AMD con drivers abiertos y el stack RADV. La razón es sencilla: la gestión de memoria de las tarjetas NVIDIA depende en gran parte de drivers propietarios cerrados, lo que limita mucho lo que se puede hacer desde el kernel y desde espacios de usuario libres. En el caso de AMD, el hecho de contar con drivers open source permite ajustar mucho mejor la interacción entre kernel, DRM, TTM y el driver gráfico.
Respecto a los plazos, ya hay distribuciones moviéndose para integrar estas mejoras a corto y medio plazo. A medida que el kernel con soporte para el controlador DMEM cgroup y los parches de TTM se consolide en versiones estables, será más habitual encontrarse con distros que traigan priorización de VRAM para juegos prácticamente «out of the box».
Para quienes usen otros escritorios distintos de KDE Plasma, el camino más lógico será aprovechar Gamescope en su versión más reciente, ya que Valve lo está convirtiendo en la pieza estándar para gestionar sesiones de juego, especialmente en hardware como Steam Deck o hipotéticas futuras máquinas de la compañía.
Impacto en la experiencia de juego y vida útil del hardware
La consecuencia directa de todo este trabajo es que millones de jugadores con GPUs de 8 GB pueden seguir exprimiendo sus tarjetas un poco más sin tener que bajar tanto los gráficos o cambiar inmediatamente de hardware. El enfoque de Vock y Valve pone el énfasis en la eficiencia del software y la asignación inteligente de recursos, compensando, hasta cierto punto, las limitaciones físicas del propio chip y su memoria.
En lugar de resignarse a que la VRAM se llene y el sistema eche a suerte qué se expulsa, ahora hay una estrategia clara: el juego en primer plano es el último en salir de la VRAM. Eso quiere decir que incluso con texturas pesadas y escenarios complejos, el motor del juego tendrá más probabilidades de mantener sus datos críticos en la memoria rápida de la GPU, minimizando los parones bruscos.
Para el usuario corriente, esto se traduce en algo muy tangible: puedes seguir usando tu escritorio, tener un navegador abierto con varias pestañas, algún reproductor de música o apps de chat, sabiendo que, llegado el momento crítico, serán ellos los que se sacrifiquen primero en cuanto a VRAM, y no tu partida.
Desde una perspectiva más amplia, el trabajo de Vock también refuerza el mensaje de que Valve va en serio con el gaming en Linux. No se queda solo en sacar consolas tipo Steam Deck o posibles Steam Machines con 8 GB de GDDR6 como memoria de vídeo compartida, sino que pone recursos en mejorar el ecosistema entero: kernel, drivers, escritorio y herramientas como Gamescope.
Para quienes se preocupan por la latencia, los frame times y la estabilidad en títulos complejos, estos parches aportan justo lo que hacía falta: una gestión de expulsiones consciente del contexto, que entiende qué es un juego a pantalla completa y qué es simple ruido de fondo en el escritorio.
En definitiva, la nueva infraestructura que ha impulsado Natalie Vock supone un salto de calidad en cómo Linux maneja la memoria de vídeo en sistemas con recursos limitados. Al combinar cgroups de memoria de dispositivo, parches al subsistema TTM, el servicio dmemcg-booster y la integración con KDE Plasma y Gamescope, se consigue por fin que el sistema se ponga de parte del jugador y no al revés. Para cualquiera que juegue en Linux con una GPU de 8 GB o menos, es una de esas mejoras silenciosas que, una vez las pruebas, se echan mucho de menos si desaparecen.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.