AMD enfrenta nuevos problemas en los Ryzen 9000 y Zen 5: TLB L2, codificación y CPPC, ¿las mejoras de Windows 11 no bastarán?

No paran de salir datos sobre más y más problemas con los Ryzen 9000 desde varios puntos del mundo. Hoy en concreto tenemos que tratar dos, el primero, la codificación del tamaño de la TLB L2 en instrucciones y datos, el segundo, el CPPC de los Ryzen 9000 y Zen 5. ¿No van a ser suficientes los cambios que introducirá Microsoft de la mano de AMD en Windows 11?

Decir ante todo que aunque los datos están demostrados como tal, no hay una correlación confirmada por parte de AMD o Microsoft, pero tampoco podemos descartar nada. Cuando hablamos del "Doble" DECODER que introducía Zen 5 no íbamos muy desencaminados con el problema, ya que finalmente se dio un paso más arriba, situando el problema en el Branch Prediction. Con este hilo argumental ya visto días atrás, comenzaremos a explicar lo que se está viendo online.

AMD tendrá que revisar la codificación del tamaño de la TLB L2 en instrucciones y datos para Windows 11

Podría ser un tema muy importante en la gestión de la latencia que hay entre CCD dentro de una CPU, y de esta con la memoria RAM. Los tiempos no son buenos y lo que vamos a ver podría explicar gran parte del problema. En orden cronológico, hemos de decir que AMD presentó todas las mejoras de Zen 4 a Zen 5 en una tabla que volvemos a recoger hoy.

En dicha tabla se aprecia el tamaño de la ITLB (Instructions Translation Lookaside Buffer) y el de la DTLB (Data Translation Lookaside Buffer). Los tamaños pasaron de 512 a 2.048 y de 3.072 a 4.096, hasta ahí nada raro, una mejora interesante para ambos tipos de caché.

El problema es que analizando el CPUID de una CPU Zen 5 como el Ryzen 9 9950X se puede ver perfectamente que AMD ha sobrepasado el tamaño de la codificación de dichas cachés, situado en 12 bits, y por lo tanto, el registro CPUID.80000006h, del cual Windows obtiene la capacidad de ambas, podría estar mal informando al SO.

¿Por qué? Porque los 4.096 KB de la DTLB L2 en binario requerirían 13 bits para ser representado en su totalidad. ¿Qué ha hecho AMD?

Cambiar la codificación del registro del CPUID a 128 y 64 respectivamente, por lo que habría que multiplicarlo por 32 para obtener el tamaño real de dicho registro por parte de Windows 11.

Ni que decir tiene que si el SO de Microsoft no es capaz de entender esta nueva codificación la gestión de la memoria RAM y las cachés se ve afectada, como así lo demuestra los datos de las tablas que veremos más abajo y que enfrentan al Ryzen 9 9950X y al Ryzen 9 7950X para los mismos tamaños.

¿Cuál es la relación entre el Branch Prediction y la TLB L2 en datos e instrucciones?

Es bastante sencillo de comprender y los resultados hablan por sí solos, puesto que en las tablas cuando se llega a 32 MB y estamos en valores medios y altos en stride las latencias llegan a duplicarse, o más, en según qué casos entre ambos procesadores.

Lo que hay que comprender es que el hecho de que AMD haya aumentado el tamaño de los TLB L1 y L2 es debido a todos los cambios realizados en el resto del Front-End, sobre todo en el tipo de Branch Prediction y el DECODER. Si la predicción del BP falla, las pipelines dobles de los decoder van a quedarse vacías temporalmente, parcial o totalmente, puesto que el flujo de instrucciones se cortará en mayor o menor medida.

Es decir, si el Branch Prediction falla, con sus L1 BTB y L2 BTB, arrastra a la Op Cache, la cual informa de los "misses" (pérdidas) al Fetch Queue, y en ese caso necesitan nuevas direcciones de memoria físicas. Ahí entra la ITLB L1 y L2, así como la L1I (Caché de Instrucciones de nivel 1) donde se va a buscar una nueva dirección de memoria, la cual normalmente no está, ya que hay demasiados datos en ella, y por eso, en casi todas las circunstancias, hay que pasar a la TLB L2.

Si la dirección de la memoria está en esta TLB L2, no hay mucha pérdida de latencia, pero si los misses también se presentan aquí, ya se podría, repito, podría (es importante entender la posibilidad, no la obligación) de acceder a la memoria RAM pidiendo dichas direcciones, y por tanto, el rendimiento de la CPU caería bastante debido a la latencia, por no hablar del mayor consumo de energía.

¿Cómo se palía este posible acceso a la memoria RAM? Dando el salto a la L3 a buscar las direcciones físicas, donde gracias a su mayor tamaño el porcentaje de aciertos aumenta drásticamente. Esto palía el consumo del procesador, ya que en la gran mayoría de ocasiones sí que hay un Match, pero hemos hecho dos saltos entre cachés, con sus latencias correspondientes, para encontrar la dirección de memoria específica, y eso cuesta mucho tiempo, pero solo algo de consumo extra.

Windows, Branch Prediction y TLB L1 y L2, ¿ocultaba algo más AMD?

Es posible. Resulta muy raro que den con el problema del Branch Prediction y nadie haya caído en cómo se gestionan las TLB L1 y L2. Es posible que Windows 11 no interprete bien el cambio de codificación de 12 bits a 13 bits, de 4.096 a 128x32, y de ahí los problemas finales en la L3. Pero hay más, no hemos terminado aquí.

Algunos usuarios están reportando problemas con el CPPC (Collaborative Power and Performance Control) de los Ryzen 9000. Se dice que hay errores cuando los núcleos acceden a las frecuencias más altas dentro de los SKU, ¿tiene esto sentido con todo lo que hemos hablado?

Sabiendo que el CPPC que integra AMD actualmente es un factor crucial para la eficiencia y el rendimiento, ya que permite un equilibrio mejorado en los Ryzen 9000 para con sus frecuencias y voltajes.

Lo que podemos interpretar a mano alzada como hipótesis es que el hecho de que los problemas de Windows 11 con la codificación de la TLB L2 y los errores en el Branch Prediction hacen que el algoritmo del CPPC esté cambiando las frecuencias del procesador más al alza en un intento de compensar la mayor latencia generada.

Esto explicaría algo muy importante: el mayor consumo en idle de los Ryzen 9000 que tan poco gusta. Al final, todos los elementos de un procesador están relacionados entre ellos, y con el software. Podría entrar aquí también perfectamente el driver del chipset de la placa base, un elemento más en discordia que podría estar empeorando no solamente el rendimiento de estos procesadores, sino también su consumo en ciertas situaciones.

Lógicamente, el efecto en el consumo no se verá tan fácilmente cuando el procesador esté bajo carga, se verá sin problemas en el rendimiento. De ahí las críticas por el poco margen de mejora y las alabanzas por la mejor eficiencia vista en las reviews.

El mal rendimiento de la latencia L3 y los CCD, ¿explicado junto con el mal consumo en idle?

Un solo apunte más, si estamos en lo cierto, el impacto en un CCD, como el que tienen el Ryzen 5 9600X y Ryzen 7 9700X, existirá, pero será menor que en los dos Ryzen 9 al incluir dos CCD, principalmente debido a que ambos CCD intercambian datos y pueden, en teoría, buscar direcciones físicas en la L3 del contrario antes que acceder al IMC y este a la RAM. Esto explicaría los peores datos de latencia entre los procesadores de un CCD y dos CCD.

Volviendo a los vatios y las cargas, cuando es a la inversa, es decir, no hay demandas altas de cargas de trabajo, el consumo es el que se vería perjudicado porque el CPPC estaría elevando de más las frecuencias en idle, y por ende, arrastra al voltaje. Por suerte, si estamos en lo cierto, y toquemos madera, es algo que por software se puede solucionar de forma simple.

Microsoft ya va a abordar el problema con el Branch Prediction, AMD puede hacer lo propio con su driver. Quizás en breve estemos hablando de un salto de rendimiento interesante en los Ryzen 9000 que los conviertan del peor lanzamiento de AMD de la historia, en uno realmente destacable. Veremos si esto se cumple o no en breve.