Hay una diferencia enorme entre los FPS medios y lo mal que se ve un juego. Puedes tener 60 de media y que la experiencia sea un desastre si cada dos por tres se te cuela un tirón. Ese es el terreno de los FPS mínimos, y es justo donde las consolas portátiles con procesadores AMD lo pasan peor.
David Vernet, desarrollador del kernel de Linux en Meta, ha propuesto un parche que ataca exactamente ese problema. Y los números que aporta son de los que llaman la atención: en Civilization VI sobre una Steam Deck, los FPS mínimos (el 1 % inferior) suben un 31,8 %.
Lo interesante es que la media no cambia. No es un parche que haga que el juego vaya más rápido: es un parche que hace que deje de tropezar. Que en la práctica es lo que de verdad se nota.
Y no requiere hardware nuevo, ni un juego actualizado, ni nada por parte del usuario más allá de un kernel con el parche aplicado. Es puro software arreglando una tontería de gestión de frecuencias.
El problema: el hilo que va y viene engaña a la CPU
Para entender el parche hay que entender un detalle de cómo los procesadores modernos deciden a qué velocidad ir.
En los AMD actuales existe un sistema llamado CPPC, en el que el sistema operativo no fija una frecuencia concreta: le comunica al procesador una preferencia entre rendimiento y consumo, el famoso EPP (Energy Performance Preference). El chip decide el resto por su cuenta, mirando cuánto se le está usando.
El mecanismo funciona muy bien para casi todo. Y falla justo 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, espera al vsync, espera a que termine un fotograma. Desde fuera parece una CPU ocupadísima, pero desde dentro son microrráfagas de trabajo separadas por microsiestas.
Y cada una de esas siestas hace que la señal interna de rendimiento del procesador decaiga. Cuando el hilo despierta —milisegundos después— el chip ha bajado ya el punto de trabajo y arranca desde una frecuencia más baja de la que necesita. Tarda un poco en volver a subir. Y ese “un poco”, repetido miles de veces, es exactamente lo que aparece 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. 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 enchufado a la corriente, lo normal es que el perfil esté puesto en rendimiento y la frecuencia no baje nunca. El problema casi no existe.
En una Steam Deck o cualquier portátil con APU de AMD, el sistema está afinado para gastar poco: el perfil por defecto favorece el ahorro, la ventana térmica es estrecha y la batería manda. Ahí sí importa que el chip se desinfle 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 —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, y los demás siguen ahorrando como siempre. Y el driver solo escribe en el registro del procesador en los cambios de estado, no continuamente, para no añadir sobrecarga.
Los números
Las mediciones son sobre una Steam Deck con Civilization VI, un juego elegido a propósito porque depende mucho de un solo hilo y trae 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 |
El dato que mejor explica lo que ocurre es el de la frecuencia: la mediana pasa de 2,43 GHz a 3,5 GHz. El procesador no es más rápido; simplemente deja de estar medio dormido cuando le toca trabajar.
Y ojo al detalle de que la media de FPS no mejora ni empeora, igual que el percentil 99,9. No es un parche que suba el techo: es un parche que sube 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 % es un juego, en un aparato, medido por el autor del parche. Es 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 APU de AMD y Linux —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
Aquí toca frenar un poco 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, la etiqueta que se usa para una propuesta que se somete a discusión— de cuatro parches sobre el driver amd-pstate y su documentación.
Una RFC es el primer paso del proceso, no el último. Puede acabar integrada tal cual, puede cambiar de forma tras la revisión, o puede no llegar nunca. Ese camino suele durar meses.
De momento la función es opcional y está desactivada: hay que compilar un kernel con los parches y arrancar con el parámetro amd_pstate.epp_boost=1. Territorio de gente que se compila sus propios kernels, no de usuario final.
Lo que probablemente se discuta
Un detalle que llama la atención 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 son ajustables.
Esos valores están claramente afinados para el caso que el autor midió. Es razonable esperar que en la revisión se pida hacerlos configurables, o que se discuta si el criterio del 50 % es el adecuado para cargas distintas de un videojuego. Son exactamente las conversaciones para las que existe una RFC.
Lo relevante de fondo: que una mejora de esta magnitud siga estando disponible sin tocar hardware dice mucho de cuánto rendimiento se pierde todavía en la gestión de frecuencias de los procesadores portátiles.
Y encaja con un patrón que se repite: el hardware de las portátiles con Linux lleva tiempo dando más de lo que aparenta, y buena parte de las mejoras de los últimos años han venido del software, no de chips nuevos. Ya pasó con los drivers de AMD para juegos en Linux.
Fuentes
