Existe una diferencia abismal entre los FPS medios y lo mal que se ve un juego. Puedes tener una media de 60 y que la experiencia resulte desastrosa si sufres tirones constantemente. Ese es el ámbito de los FPS mínimos, y es precisamente donde más problemas tienen las consolas portátiles con procesadores AMD.
David Vernet, desarrollador del kernel de Linux en Meta, ha propuesto un parche para solucionar precisamente ese problema. Los datos que aporta son sorprendentes: en Civilization VI ejecutado en una Steam Deck, los FPS mínimos (el 1 % inferior) suben un 31,8 %.
Lo interesante es que la media no cambia. No se trata de un parche que haga que el juego vaya más rápido, sino de uno que consigue que deje de tropezar. Y eso es lo que realmente se nota en la práctica.
No requiere hardware nuevo, ni que el juego esté actualizado, ni ninguna acción por parte del usuario más allá de contar con un kernel con el parche aplicado. Es puro software solucionando una tontería de gestión de frecuencias.
El problema: el hilo que va y viene engaña a la CPU
Para comprender el funcionamiento del parche, es necesario entender un detalle sobre cómo los procesadores modernos deciden su velocidad de funcionamiento.
Los procesadores AMD actuales cuentan con un sistema llamado CPPC. En este, el sistema operativo no establece una frecuencia concreta, sino que le indica al procesador una preferencia entre rendimiento y consumo, el conocido EPP (Energy Performance Preference). El chip se encarga del resto por su cuenta, basándose en el nivel de uso que esté registrando.
Este mecanismo funciona muy bien para casi todo, pero falla precisamente con el patrón típico de un videojuego.
Por qué los juegos rompen el modelo
Un juego suele tener un hilo principal muy cargado que se duerme constantemente durante ratos cortísimos: espera a la tarjeta gráfica, al vsync o a que termine un fotograma. Desde fuera parece que la CPU está muy ocupada, pero en realidad se trata de microrráfagas de trabajo separadas por microsiestas.
Y cada una de esas siestas provoca que la señal interna de rendimiento del procesador decaiga. Cuando el hilo despierta, milisegundos después, el chip ya ha reducido el punto de trabajo y arranca con una frecuencia más baja de la necesaria. Tarda un poco en volver a subir. Ese “un poco”, repetido miles de veces, es precisamente lo que se refleja en las estadísticas como un percentil 99 malo y unos FPS mínimos malos.
La CPU está prácticamente al 100 % de uso real, pero el procesador cree que puede relajarse. Tal como resumía la propia propuesta, el modo EPP activo estándar se porta mal con “un hilo ocupado que se duerme con frecuencia durante periodos cortos”.
Por qué esto se ceba con una portátil. En un sobremesa conectado a la corriente, lo habitual es que el perfil esté configurado en rendimiento y la frecuencia no baje en ningún momento. El problema casi no existe.
En una Steam Deck o en cualquier portátil con APU de AMD, el sistema está optimizado para el bajo consumo: el perfil predeterminado prioriza el ahorro, la ventana térmica es reducida y la batería es la prioridad. En estos casos, sí afecta que el chip pierda potencia entre fotograma y fotograma.
La solución: subir a tope solo el núcleo que lo necesita
La idea del parche es sencilla y por eso funciona: en lugar de cambiar el perfil de energía de todo el sistema —lo que dispararía el consumo—, actúa núcleo por núcleo.
El mecanismo, tal y como está escrito:
- Cada núcleo se muestrea como mucho cada 10 milisegundos.
- Si en esa muestra el núcleo está ocupado al 50 % o más, se le pone el EPP a rendimiento máximo (valor 0).
- Ese estado se mantiene hasta que pasen 300 milisegundos sin volver a detectarlo ocupado, momento en el que se devuelve a la política que tuviera antes.
Es decir: el núcleo que lleva el juego se mantiene despierto, mientras que los demás siguen ahorrando energía como siempre. Además, el driver solo escribe en el registro del procesador en los cambios de estado, no de forma continua, para no añadir sobrecarga.
Los números
Las mediciones se han realizado en una Steam Deck con Civilization VI, un juego seleccionado deliberadamente porque depende mucho de un solo hilo y dispone de una prueba comparativa repetible:
| Métrica | Resultado |
| FPS mínimos (1 % inferior) | +31,8 % |
| Tiempo de fotograma (percentil 99) | +4,1 % |
| FPS medios | Sin cambios |
| Percentil 99,9 | Sin cambios |
| Frecuencia mediana | De 2,43 GHz a 3,5 GHz |
La frecuencia es el dato que mejor explica lo sucedido: la mediana sube de 2,43 GHz a 3,5 GHz. El procesador no es más rápido, sino que simplemente deja de estar medio dormido en los momentos en los que debe trabajar.
Cabe destacar que la media de FPS no mejora ni empeora, al igual que ocurre con el percentil 99,9. No se trata de un parche que suba el techo, sino de uno que suba el suelo. Los valores de significancia estadística que acompañan a las mediciones (p = 0,014 y p = 0,015) indican que no es ruido.
Cuidado con el titular. El 31,8 % corresponde a un juego, en un aparato, medido por el autor del parche. Se trata de un resultado creíble y bien presentado, pero es una sola muestra.
En teoría, debería beneficiar a otros juegos con el mismo patrón de un hilo dominante y a cualquier portátil con Linux y APU de AMD —no solo a la Steam Deck—, pero eso está por confirmar de forma independiente. Un juego bien paralelizado, o uno limitado por la GPU, probablemente no note nada.
Cuándo llega y qué falta para que lo tengas
Es momento de moderar las expectativas: el parche no está en el kernel de Linux. Se publicó a finales de julio de 2026 como una serie RFC (request for comments), que es la etiqueta utilizada para una propuesta sometida a discusión, consistente en cuatro parches sobre la documentación y el driver amd-pstate.
Una RFC es el primer paso del proceso, no el último. Puede acabar integrada tal cual, puede cambiar tras la revisión o puede no llegar nunca. Ese camino suele durar meses.
Actualmente la función es opcional y está desactivada: es necesario compilar un kernel con los parches y arrancar con el parámetro amd_pstate.epp_boost=1. Es territorio de gente que se compila sus propios kernels, no del usuario final.
Lo que probablemente se discuta
Un detalle llamativo de la propuesta es que los tres números clave están fijados en el código: los 10 milisegundos de muestreo, el umbral del 50 % y los 300 milisegundos de espera antes de soltar. No se pueden ajustar.
Estos valores están claramente ajustados para el escenario que midió el autor. Es razonable esperar que, durante la revisión, se solicite que sean configurables o que se debata si el criterio del 50 % es el apropiado para cargas de trabajo que no sean un videojuego. Estas son precisamente las conversaciones para las que existe una RFC.
Lo relevante de fondo: que siga habiendo una mejora de esta magnitud disponible sin tocar hardware dice mucho de cuánto rendimiento se sigue perdiendo en la gestión de frecuencias de los procesadores portátiles.
Y encaja con un patrón recurrente: el hardware de las portátiles con Linux lleva tiempo rindiendo más de lo que parece, y gran parte de las mejoras de los últimos años han llegado del software, no de chips nuevos. Ya ocurrió con los drivers de AMD para juegos en Linux.
Fuentes
