- AMD HighestFreq añade a CPPC un dato directo de frecuencia máxima por núcleo para mejorar la planificación de tareas.
- Windows y Linux dejarán de estimar el boost y podrán leerlo desde el firmware, reduciendo errores en la elección de núcleos.
- La función se integra con ACPI 6.7 y el driver AMD P-State, preparada para los Ryzen basados en Zen 6.
- Zen 6 combinará más núcleos por CCD, más caché y mayor IPC, donde HighestFreq ayudará a exprimir mejor el rendimiento.
AMD HighestFreq es una nueva pieza clave en la estrategia de la compañía para sacar más jugo a sus futuros procesadores Ryzen, especialmente a partir de la arquitectura Zen 6. No es una función vistosa de cara al usuario como un nuevo modo turbo u overclock automático, pero sí un cambio profundo en cómo el procesador y el sistema operativo hablan entre sí para decidir qué núcleo debe trabajar, a qué frecuencia y en qué momento.
En los próximos años veremos CPUs con más núcleos, frecuencias más altas y algoritmos de boost más complejos, y eso obliga a refinar también el firmware y el soporte en Windows y Linux. Aquí entra en juego HighestFreq, una extensión del estándar CPPC que permitirá que el sistema operativo deje de «adivinar» hasta dónde puede llegar cada core y pase a leer esa información directamente del firmware de AMD con total precisión.
Contexto: de los procesadores mononúcleo a los Ryzen de muchos hilos
Hace un par de décadas lo normal en un PC doméstico era tener un procesador de un solo núcleo que se ponía al límite enseguida. La multitarea tal y como la entendemos hoy era bastante más precaria: sí, se podían abrir varios programas y dejar procesos en segundo plano, pero el sistema se saturaba rápido en cuanto se le pedía un poco de alegría.
Fue entonces cuando AMD e Intel empezaron a popularizar los procesadores de dos núcleos, y poco después los de cuatro cores. Durante bastante tiempo Intel llevó la voz cantante en rendimiento bruto, especialmente en escritorio, hasta que llegó el gran giro de guion: el lanzamiento de los primeros Ryzen, que cambió por completo el equilibrio de fuerzas en el mercado.
Hoy lo habitual en un PC para jugar o trabajar es tener CPUs de 6 u 8 núcleos como mínimo, porque se alinean bien con lo que montan las consolas y con los motores de juego actuales. En gamas más altas ya nos movemos en cifras de 12, 16 e incluso más cores, con Intel llegando a 24 hilos físicos en consumo y AMD plantando cara con sus Ryzen de alto rendimiento.
En este contexto de proliferación de núcleos y arquitecturas cada vez más complejas, la forma en la que el sistema operativo gestiona el trabajo entre los distintos cores es crítica. No basta con tener muchos núcleos; hay que saber cuándo usar cada uno, a qué frecuencia, y qué tareas colocar en los núcleos más capaces para exprimir el hardware.
Ese reparto lo decide en gran parte el planificador del sistema operativo (scheduler) apoyado en información que le proporciona el procesador mediante estándares como ACPI y tecnologías como CPPC (Collaborative Processor Performance Control). Y precisamente es en ese punto donde AMD quiere dar un salto con HighestFreq.
Qué es exactamente AMD HighestFreq dentro de CPPC
AMD HighestFreq es, en esencia, un nuevo campo o parámetro dentro de CPPC que sirve para informar al sistema operativo de la frecuencia máxima real que puede alcanzar cada núcleo del procesador. En lugar de enviar solo valores abstractos de rendimiento, el firmware expone de forma directa el pico de frecuencia de cada core.
La tecnología CPPC ya se emplea en los procesadores modernos de AMD para compartir con el sistema operativo datos clave como el núcleo preferido (preferred core), el rendimiento relativo o los límites de energía. En Linux, toda esta información la gestiona el driver AMD P-State; en Windows se aprovecha para planificar tareas, gestionar el aumento de frecuencia (boost) y equilibrar la carga entre núcleos rápidos y lentos.
Hasta ahora, tanto Windows como Linux dependen de indicadores de rendimiento aproximados y modelos internos para estimar cuál es el máximo boost de cada núcleo. Esos indicadores funcionan razonablemente bien, pero no son una lectura directa de la frecuencia real, sino una especie de «puntuación» a partir de la cual el sistema intenta inferir el comportamiento del chip.
AMD señala que la relación entre rendimiento y frecuencia no es lineal ni uniforme entre todos los cores, especialmente en las generaciones más recientes de Ryzen. Eso significa que, si el sistema operativo se apoya solo en esos valores abstractos, puede cometer errores a la hora de calcular el boost óptimo o elegir qué núcleo es realmente el más rápido para una tarea concreta.
Con HighestFreq, la idea es sencilla pero potente: en lugar de estimar el pico de frecuencia, el sistema operativo lo lee directamente del firmware de AMD, por ejemplo tras una actualización del BIOS o UEFI. Cada núcleo expone su frecuencia máxima real, y el scheduler puede basar sus decisiones en un dato mucho más fiel a la realidad del silicio.
Limitaciones del método actual de selección de núcleos
El sistema actual se apoya en CPPC para que el procesador comunique al sistema operativo qué núcleos son preferentes y cómo escalan en rendimiento, pero la frecuencia máxima se deduce de forma indirecta. Windows y Linux trabajan con valores de capacidad o rendimiento óptimo que luego traducen en decisiones de planificación.
Este modelo, aunque funcional, tiene varias pegas en CPUs modernas con comportamientos de boost complejos. No todos los núcleos suben igual, algunos pueden mantener su frecuencia turbo más tiempo o a menor voltaje, y la curva frecuencia/rendimiento varía según la carga, la temperatura y otras condiciones del sistema.
Además, los sistemas operativos tienden a tratar los núcleos de un mismo procesador como si fueran casi idénticos en capacidad máxima, más allá de marcar algunos como preferentes. En arquitecturas con cores asimétricos o con CCD distintos, como ocurre en muchas CPUs Ryzen modernas, ese enfoque pierde precisión.
Todo esto se traduce en que, en la práctica, el scheduler puede no aprovechar siempre el núcleo más capaz para las tareas más sensibles a la latencia o al rendimiento monohilo. Funciona, sí, pero deja margen de mejora, sobre todo cuando hablamos de cargas muy dependientes de un único hilo (juegos, ciertas aplicaciones creativas o procesos de respuesta rápida).
AMD ha detectado que, al no tener una lectura exacta del boost, las estimaciones pueden fallar más de la cuenta en sus procesadores más recientes. De ahí la necesidad de refinar el canal de comunicación entre firmware y sistema operativo con un dato más directo y confiable.
Cómo mejora AMD HighestFreq la interacción con Windows y Linux
La gran aportación de HighestFreq es que el firmware pasa a exponer al sistema operativo la frecuencia máxima real por núcleo de forma explícita. De este modo, Windows y Linux no necesitan interpolar, aproximar ni derivar ese valor a partir de otros indicadores de rendimiento; simplemente lo leen y lo usan.
En Linux, esta información encajará con el trabajo ya en marcha en torno al driver AMD P-State y las optimizaciones de CPPC que se han ido integrando en el kernel. El driver podrá alimentar al scheduler con datos de boost mucho más precisos, afinando cómo reparte las cargas y cómo decide qué core es el mejor candidato en cada momento.
En Windows, aunque todavía no se ha detallado públicamente cómo lo integrará Microsoft, lo lógico es que el planificador de tareas y los algoritmos de gestión de energía se apoyen también en HighestFreq para asignar núcleos preferentes y ajustar el comportamiento del boost de forma más consistente.
Este cambio no introduce un nuevo modo de overclocking ni permite a la CPU subir a frecuencias imposibles; AMD recalca que HighestFreq no aumenta los límites de frecuencia, solo mejora la precisión de la información con la que trabajan los sistemas operativos. El objetivo es tener una base de datos más exacta, no empujar el hardware por encima de sus especificaciones.
Cuando el sistema sabe con certeza cuál es el pico real de cada núcleo, puede identificar mejor qué core es realmente el más rápido y mantener una política de boost más coherente. Esto reduce el margen de error en la asignación automática de tareas, especialmente en situaciones de carga cambiante o cuando hay que priorizar la respuesta rápida.
Impacto práctico: elección de núcleos y rendimiento en el día a día
En el uso real, la consecuencia más tangible de HighestFreq está en la cola de ejecución de tareas que maneja el scheduler. Cuando el sistema operativo tiene información precisa sobre qué núcleo puede sostener la mayor frecuencia turbo, será más probable que coloque ahí las cargas que se benefician de un hilo muy rápido.
Esto tiene aplicación directa en los juegos, que a menudo dependen mucho de uno o pocos hilos críticos, y en tareas sensibles a la latencia como ciertos procesos de audio, interfaces muy reactivas o aplicaciones que necesitan respuestas inmediatas. No significa que vayamos a ver saltos de rendimiento brutales en todos los escenarios, pero sí una mejora en la consistencia del comportamiento.
En procesadores Ryzen modernos, donde los algoritmos de boost ya son bastante sofisticados y se ajustan en función de temperatura, carga y límites de energía, cualquier error de estimación puede traducirse en que el trabajo no recaiga en el núcleo más apropiado. HighestFreq reduce ese riesgo porque la base de cálculo es mucho más fiel a la realidad del chip.
También encaja con la tendencia reciente de AMD en Linux de exprimir mejor el hardware mediante cambios en el kernel: mejoras en soporte de HDMI 2.1, ajustes en la gestión interna de energía y, en general, una afinación progresiva de cómo el sistema se comunica con cada nueva generación de CPUs.
La diferencia aquí es que no se trata solo de retocar políticas o parámetros, sino de cambiar el tipo de información que recibe el sistema operativo desde el firmware. Que el OS deje de «adivinar» el boost y pase a leerlo directamente puede parecer un matiz menor, pero para la planificación de hilos es un detalle que pesa más de lo que parece.
Relación con ACPI 6.7 y el driver AMD P-State
Uno de los puntos interesantes es que AMD está trabajando para que HighestFreq se integre dentro de la especificación ACPI 6.7. ACPI es el estándar que define cómo el sistema operativo descubre y controla las características de energía y rendimiento del hardware, y llevar esta función a la especificación significa convertirla en parte de la base de la plataforma, no en un apaño puntual.
Si HighestFreq termina incluido en ACPI 6.7, tanto Windows como Linux podrán apoyarse en la misma fuente de datos estándar para entender el comportamiento de los procesadores Ryzen. Esto facilita que los distintos sistemas operativos ofrezcan un soporte coherente y reduzcan las diferencias de comportamiento entre plataformas.
En paralelo, AMD está moviendo ficha en el lado de Linux con el driver AMD P-State, que ya trabaja estrechamente con CPPC. Al incorporar HighestFreq, el driver podrá exponer al scheduler un mapa mucho más exacto del boost de cada core, lo que refuerza todo el ecosistema de gestión de energía y rendimiento en el kernel.
Esta combinación de cambios —estándar ACPI por un lado, driver específico por otro— indica que AMD no busca solo mejorar un detalle menor, sino asentar una nueva forma de comunicar el potencial de sus CPUs a los sistemas operativos de forma transversal y duradera.
Aunque el foco inicial esté en Linux (donde ya hay parches en preparación), no tendría sentido que Microsoft se quedara fuera. Lo razonable es que, una vez que ACPI 6.7 y HighestFreq estén asentados, Windows 11 adopte también esta información para mejorar la planificación y la gestión del boost en los Ryzen.
AMD HighestFreq, Zen 6 y el salto de núcleos en los futuros Ryzen
La llegada de HighestFreq no se entiende aislada, sino ligada a la próxima gran generación de arquitectura de AMD: Zen 6, cuyo nombre en clave es Morpheus. Esta arquitectura está llamada a marcar un antes y un después en la gama de consumo por el gran incremento en el número de núcleos por CCD.
Con Zen 6, AMD dará su primer gran salto de núcleos por CCD desde prácticamente los inicios de la familia Zen, pasando de los actuales chiplets de 8 cores a nuevos CCD de hasta 12 núcleos. Eso supone un aumento del 50 % de núcleos por chiplet, lo que en la gama alta de PC podría traducirse en procesadores de hasta 24 núcleos físicos.
Además del incremento de núcleos, se espera una mejora de IPC (instrucciones por ciclo) en torno al 15 %, acompañada de un aumento del 50 % en la memoria caché L3. Todo ello, combinado con el uso del nodo de fabricación TSMC N2 de 2 nm, debería permitir alcanzar frecuencias en el entorno de los 6 GHz en determinados modelos o escenarios de boost.
Cuando se juntan más núcleos, un IPC superior y un boost más agresivo, la complejidad de gestionar el comportamiento de la CPU se dispara. No basta con tener un buen silicio: hay que coordinar de forma muy fina qué cores suben más, cuáles mantienen la frecuencia y cómo se reparte la carga según el tipo de tarea.
En este escenario, AMD HighestFreq encaja como una herramienta pensada precisamente para que los sistemas operativos estén mejor informados sobre el verdadero potencial de cada núcleo en Zen 6. Si el planificador sabe con exactitud qué core puede llegar más alto, le resultará más fácil sacar partido a los chips con 24 núcleos y a las nuevas políticas internas de rendimiento como la función «Performance Priority» que se asocia también a esta generación.
Disponibilidad prevista en Linux y Windows 11
Por ahora, los indicios más claros de HighestFreq han aparecido en el trabajo de parches para el kernel de Linux. AMD está colaborando para que el soporte quede integrado junto al driver AMD P-State y como parte de la adopción de ACPI 6.7, lo que apunta a que Linux será uno de los primeros entornos en aprovechar esta novedad.
Aunque muchas menciones iniciales se centran en Linux, nada hace pensar que esta función vaya a quedarse exclusiva en el mundo del software libre. Lo más lógico es que, en paralelo, Microsoft integre soporte para HighestFreq en Windows 11, especialmente teniendo en cuenta que este sistema operativo ya ha mostrado ciertas complicaciones con el comportamiento de frecuencia turbo en procesadores como los Ryzen 9000.
Si AMD lanza Zen 6 con CPUs de hasta 24 núcleos, sería poco sensato no acompañarlo de una puesta al día de la gestión de núcleos y frecuencias en Windows. De hecho, tiene todo el sentido que el aterrizaje de HighestFreq y de funciones como «Performance Priority» coincida en el tiempo con la llegada al mercado de estos nuevos procesadores.
La idea de base es clara: al alinear firmware, estándar ACPI y soporte en los principales sistemas operativos, AMD se asegura de que los futuros Ryzen no dependan de estimaciones poco precisas para rendir bien, sino de datos exactos proporcionados directamente por el propio procesador.
A medida que se acerque el lanzamiento de Zen 6, es previsible que vayan apareciendo más detalles sobre cómo se materializará el soporte en cada plataforma, pero el movimiento de fondo ya está en marcha: dejar de intuir el boost y empezar a leerlo tal cual desde el firmware.
Con todo este panorama, AMD HighestFreq se perfila como una mejora silenciosa pero muy relevante: no es un extra llamativo en la caja del procesador, pero sí una de esas funciones que, bien implementadas en Windows y Linux, marcan la diferencia en cómo se aprovecha cada núcleo, cómo responden los juegos y aplicaciones exigentes y, en definitiva, cómo se saca partido a la próxima hornada de CPUs Zen 6 con más núcleos, más caché y frecuencias de vértigo.
