La GPU de la RX 7600 es RDNA 3 Lite, está capada, ¿por qué lo hizo AMD?
Lo veníamos diciendo desde hace algunas semanas, en concreto desde que se presentó la RX 7600 y mostró su rendimiento. Lanzamos un artículo muy interesante que seguro recordaréis afirmando que esta GPU sufría de un claro Overhead, y hoy no solamente se confirma lo dicho, sino que se profundiza en todo esto mostrando el rendimiento interno. La conclusión es clara, la RX 7600 tiene una GPU Navi 33 con arquitectura RDNA 3 Lite, parecida a RDNA 2 que a sus hermanas de la serie RX 7000.
RDNA 3 fue un salto adelante en algunos aspectos frente a RDNA 2. Muchos de los cambios fueron introducidos por el sistema MCM de la arquitectura y por el aumento de rendimiento que se quería dar al Ray Tracing y a la IA con sus respectivas unidades. El mayor cambio dentro del funcionamiento de la arquitectura es muy poco comentado y ayuda bastante a temas como el consumo y el desacoplamiento sufrido en la arquitectura, como es la independencia de las frecuencias Frontend y Shader, pero, ¿qué tiene que ver esto con la tarjeta de marras?
Navi 33 no es una GPU RDNA 3 "Big"
Ya deslizamos los diagramas de bloques entre RDNA 2 y RDNA 3 junto a más datos clave, los cuales volvemos a poner aquí, principalmente porque es la base de toda la explicación. Pero para comprenderla volvemos a aquel artículo, donde comentábamos el tema del overhead y el procesador de comandos.
RX 6600 | RX 6600 XT | RX 6650 XT | RX 7600 | |
---|---|---|---|---|
Arquitectura | RDNA 2 | RDNA 2 | RDNA 2 | RDNA 3 |
Shaders | 1792 | 2.048 | 2.048 | 2.048 |
Frecuencia Shaders | 2.491 MHz | 2.589 MHz | 2.635 MHz | 2.625 MHz |
TMU | 112 | 128 | 128 | 128 |
ROP | 64 | 64 | 64 | 64 |
L0 | 32 KB por WGP | 32 KB por WGP | 32 KB por WGP | 32 KB por WGP |
L1 | 128 KB por Array | 128 KB por Array | 128 KB por Array | 128 KB por Array |
L2 | 2 MB | 2 MB | 2 MB | 2 MB |
L3 | 32 MB | 32 MB | 32 MB | 32 MB |
Bus | 128 Bits | 128 Bits | 128 Bits | 128 Bits |
Frecuencia VRAM | 1.750 MHz o 14 Gbps | 2.000 MHz o 16 Gbps | 2.190 MHz o 17,5 Gbps | 2.250 MHz o 18 Gbps |
VRAM | 8 GB | 8 GB | 8 GB | 8 GB |
TBP | 132W | 160W | 176W | 165W |
Como bien dijimos lo que tenemos es un problema de Draw Calls y el procesador de comandos está en medio. No lo comentamos en dicho artículo, aunque dejamos los datos, pero hoy podemos afirmar lo que en aquella ocasión no nos atrevimos por no poder probar la GPU in situ.
Pero sí, los cambios en Navi 33 en cuanto al registro de vectores por SIMD es un problema. En aquel momento, sin datos comparativos en la mano, pensamos que la mayor L0 para Vectores iba a paliar el hecho de que AMD en Navi 33 había incluido 128 KB de archivo de registro por SIMD, algo así como lo que ha hecho NVIDIA con los buses vs la mayor caché.
Pero no, esos 128 KB de VRF son exactamente los mismos que se introdujeron en RDNA 2 y la caché no puede paliar la bajada de rendimiento. Por lo tanto, AMD habría incluido prácticamente el mismo Procesador de Comandos en Navi 33 que en Navi 23, lo cual es lógico si el rendimiento no es paliado por la mayor L0 en VRF, y la caché de datos L1 tampoco puede marcar la diferencia. Además, dado que no se pueden recibir las suficientes peticiones de comandos por el menor tamaño de los registros, donde como decimos, la caché y su mayor tamaño no ayudan, esto hace que el CP termine ofreciendo un precioso Overhead, que no es tanto por su culpa, sino por lo que vamos a comentar, ahora.
Esto lo vamos a ver a continuación con los datos extraídos de los compañeros de Chips and Cheese.
Rendimiento del Front end y el procesador de comandos
Lo que sospechábamos en su momento es que el procesador de comandos, dentro del Front end, tenía un rendimiento menor en Navi 33 que en Navi 31, y así es. El desacople de las frecuencias del Front end y los Shaders dan como resultado que en una RX 7900 XT, por ejemplo, las diferencias de MHz sean mayores, pero en la RX 7600 se comportan como en RDNA 2, ya que sus valores están muy próximos.
Los valores afirman que la mayor de las hermanas puede ver una variación de entre un 5% y un 10% en sus frecuencias, pero en la RX 7600 esto no ocurre.
Por lo tanto, Navi 33 tarda más en terminar con el trabajo por cada comando y esto ineludiblemente es afectado por el procesador de comandos que está adaptado en esta arquitectura RDNA 3 Lite, de ahí el problema de las Draw Calls.
Pero realmente nos quedamos cortos, porque el mayor problema llega desde los archivos de registro de los vectores, que sí que tienen un cuello de botella en la arquitectura que, a diferencia del ejemplo y símil de NVIDIA, los WGP no pueden compensar.
Rendimiento en vectores limitado por sus registros
Es el gran punto a tratar tras la explicación del procesador de comandos, ya que aquí tenemos el segundo cuello de botella que impide aumentar el rendimiento de la GPU. Bajar de 192 KB que tiene el Navi 31 a 128 KB de este Navi 33, aun duplicando la caché L0 de vectores y texturas por CU, es una caída demasiado grande que afecta al rendimiento de cada unidad.
El VRF ha perdido un 33,3% de capacidad, la L0 se ha incrementado en un 100%, ¿resultado? Los CU no trabajan bien, sobre todo cuando hablamos de tener que mover los datos o extraerlos de la L2 y L3. Se puede ver perfectamente que a partir de 64 Threads el rendimiento de RDNA 3 Lite cae ostensiblemente, y ahí empieza a escalar hacia abajo gradualmente en tiempos más cortos por Thread asignado.
Hay un dato clave que seguramente pasaréis por alto, y es que si os fijáis, RDNA 3 Lite hace asignaciones de 16 en 16 a partir de 64, RDNA 3 Big cae en 96 y asigna de 24 en 24 para los registros, lo que indica que, efectivamente, hay un cuello de botella perfectamente calculado en RDNA 3 Lite para Wave32, que se duplica cuando se usa Wave64.
Esto lo tenéis detallado perfectamente en el artículo de las instrucciones RDNA 3 más importantes que lanzamos este fin de semana, pero parafraseando a Lázaro:
- Las olas de Wave32 emiten cada instrucción como máximo una vez.
- Las olas Wave64 suelen emitir cada instrucción dos veces: una vez para la mitad baja (elementos de trabajo 31-0) y luego nuevamente para la mitad alta (elementos de trabajo 63-32).
Por lo tanto, al problema de Draw Calls y el Command Processor hay que sumarle las sospechas que teníamos (ahora confirmadas) de los VRF.
¿Qué hay de la latencia entre escalares y vectoriales?
Pues es lo que se esperaba viendo todo lo que hemos vistos alrededor de la arquitectura desde que la dimos en su momento. Con una L0 de 32 KB, una L1 de 128 KB, una L2 de 2 MB y una L3 Infinity Caché de 32 MB, se pueden ver perfectamente los saltos entre ellas según el tamaño asignado frente a la latencia, tanto en Scalar como en Vector.
El salto de rendimiento con la parte de la arquitectura que sí mantiene de RDNA 3 por lo comentado se nota, la latencia es inferior a la RX 6600 XT, lo que ayuda a impulsar y paliar lo visto más arriba.
Pero, ¿y si comparamos RDNA 3 Big con RDNA 3 Lite? Pues que se ven las costuras de la arquitectura MCM en la mayor. Navi 33 tarda un 58% menos que Navi 31 en obtener datos de la Infinity Cache, por lo que se ve perfectamente los problemas de una arquitectura heterogénea.
Eso contando con los problemas descritos de los VRF, porque si os fijáis, en Scalar las diferencias son mayores que en Vector, donde el GAP se reduce por lo comentado.
El escalado de resolución, el front end, Command Proccesor y el Hit Rate
Ahora es cuando todo se une y podemos entender mucho mejor los cuellos de botella que se producen y por qué las Draw Calls no pueden ser resueltas a tiempo. Los clocks terminan siendo los mismos entre Front end y Shaders, no exactos, pero sí muy cercanos, además, AMD estipula que el Hit Rate óptimo para 1080p es 32 MB, lo que produce que a mayor resolución la tasa de fallos aumente si tenemos en cuenta la suma de lo dicho.
Se sale de rango, comienza a perder rendimiento porque los Hit Rates se incrementan y el menor tamaño del VRF lógicamente no ayuda a esto, al revés, junto con el Procesador de Comandos lo termina por estropear.
Vamos a sumarle el hecho de que hay una pequeña pérdida de rendimiento por su PCIe 4.0 x8, que será un problema en las placas base PCIe 3.0 con x8 como tal (pocas eso sí). Es un cúmulo de detalles, que ahora teniendo datos, podemos explicar convenientemente.
Conclusión de RDNA 3 Lite y RX 7600
¿Por qué AMD ha hecho esto con la RX 7600? Costes, simple y llano. Reducir el PCIe 4.0 x16 a x8 es un ahorro considerable de por sí, esto arrastra de alguna forma a los cambios en la arquitectura, que también se ven empujados por un nodo N6 que apenas aporta nada sobre el N7 anterior, y al no usar el N5, que sí que logra ventajas de área y consumo, AMD al final se ha visto empujada a crear esta RDNA 3 Lite para cuadrar el círculo.
Y es que mantener el VRF al nivel de RDNA 3 supone un área de troquel mayor, lo que en términos de costes no ayuda si el rendimiento no escala y justifica el precio mayor que iba a tener esta tarjeta. Reduces VRF, cambias CP, creas un problema interno de rendimiento que se suma al problema de las Draw Calls donde la mayor caché L0 y L1 no lo compensan y todo por reducir el área, no salirte de Hit Cache y no subir el precio por chip.
El resultado de todo lo que hemos ido viendo en sucesivos artículos es este, una arquitectura mixta, que es "casi" un refrito de RDNA 2 más que un paso adelante de lo que es RDNA 3, que tampoco es la panacea como tal, pero que por lo menos con el MCM llevó a AMD a acometer más cambios que si se hubiese visto un chip monolítico. Esta RX 7600 con Navi 33 es una pequeña prueba de ello con RDNA 3 Lite.