¿Es posible que la RX 7600 y la arquitectura RDNA 3 sufran de Overhead?

Venimos del artículo de ayer donde hablábamos sobre esta GPU tras ver los datos de las reviews, y en las cuales vimos que el rendimiento no era el esperado y que había un margen muy estrecho entre RDNA 2 y RDNA 3. Tras aquel artículo, el que os escribe estuvo pensando, dándole vueltas a la cabeza durante toda la tarde, porque dados los cambios en la arquitectura era realmente complejo entender qué estaba pasando. Pues bien, vamos a lanzar una nueva teoría encima de la mesa, que puede resultar muy interesante: ¿sufre la RX 7600 Overhead? ¿Tiene la arquitectura RDNA 3 un problema con ello en general?

Antes de nada, dos apuntes rápidos. El primero es la confirmación de que AMD no va a vender su modelo Reference conocido como MBA en todo el mundo, así que la gran mayoría será custom. El modelo como tal existe, pero solo ha sido para los analistas por ahora. El segundo apunte es el interesante, puesto que tiene que ver con la arquitectura y nuevos datos que han surgido y que usaremos para argumentar la teoría que hemos formulado.

AMD RDNA 3 y RX 7600, reviews vs benchmark vs API

Antes de seguir, coged sal, puesto que esto es algo que hemos debatido en redacción a raíz de mi investigación por los Whitepaper y Data Sheet de AMD. No hay confirmación oficial, es posible que la haya nunca, pero intentaremos poner luz al problema de rendimiento de la RX 7600.

Con esto claro, vamos con los datos que se han mostrado. En ellos, dentro de la imagen inferior a este párrafo, tenemos los datos de la RX 6650 XT frente a la RX 7600, ambas a 1 GHz. Como se puede ver, todos ellos han sido recopilados dentro de la suite de 3DMark, que si algo tiene es ser bastante fidedigna para dar medias de rendimiento muy aproximadas.

A 1 GHz ambas tarjetas se puede ver cómo la RX 7600 obtiene en casi todos los benchmark, quitando Fire Strike Extreme, un aumento de rendimiento de dos dígitos. Desde el 8,88% hasta un 21,05%. En cambio, y para contrastar estos datos que son muy superiores a ese 4% o 5% de media que mostraron ayer las reviews, tenemos los datos de por API en cuanto al llamado Overhead.

Aquí las cosas se dan la vuelta, con pérdidas increíbles para la RX 7600 de entre un -21% hasta un -45,09% en Vulkan, pero entonces, ¿qué está pasando? ¿Cómo es posible que en los benchmark de rendimiento muestre hasta 4 veces más GAP porcentual que en las reviews, y en los test de API caiga hasta casi la mitad frente a la RX 6650 XT? Como seguro estarás pensando, tiene que haber alguna explicación plausible.

Proceso litográfico, transistores, densidad y tamaño

Hay mucha disparidad entre los benchmark y las reviews, es decir, entre test sintéticos y juegos, pero es que ahora sumamos las API a la ecuación. En las reviews se puede ver los dos primeros puntos, el tercero lo estamos conociendo ahora y creemos tener la respuesta, o al menos parte de ella, y me explico.

Para aquellos que no se han dado cuenta, la RX 7600 no está fabricada a 5 nm, sino a 6 nm, es decir, en el N6 de TSMC. La RX 6650 XT que tiene prácticamente las mismas características casi clavadas, está fabricada a 7 nm, y por lo tanto, parte con desventaja en el nodo. En términos de transistores tenemos 11.060 millones para la menor y 13.300 millones para la mayor, lo que nos da una diferencia de un 20,25% para un 14% menos de tamaño físico del díe (237 mm2 vs 204 mm2).

Con estos datos podemos sacar las densidades: 46,7 M/mm2 para la RX 6650 XT frente a los 65,2 M/mm2, lo que porcentualmente implica que la RX 7600 es un 39,61% más densa. Esto no explica nada de los datos comentados más arriba, pero nos deja ver algo importante: gracias a esta mayor densidad AMD ha optado por un núcleo monolítico con la caché L3 en el interior, porque le era rentable económicamente, y debido a esto el diseño de la arquitectura RDNA 3 ha sido adaptado para integrar dicha caché en el die.

Y aquí se pone interesante, ya que gracias a esta densidad AMD ha podido prescindir del caro N5 y usar el más barato N6 con una ganancia por chip más alta, que es lo que busca tanto el usuario (gráfica barata) como la empresa (más beneficios). El problema es que los cambios que ha tenido que implementar le han hecho perder el rendimiento que desde ECI especulábamos.

¿Un problema de Overhead?

Vaya por delante la diapositiva oficial de AMD, donde vamos a trabajar la teoría del mal rendimiento. En la parte inferior de la misma los de Lisa Su comentan que gracias a las mejoras de los CU (las comentamos en el artículo de la arquitectura RDNA 3, del cual cogeremos algunos datos ahora y os instamos a leer) la arquitectura habría ganado una mejora clock por clock del 17,4%, lo que tras las pérdidas por la caché L3 y su latencia en las GPU MCM, como las RX 7900 XTX y RX 7900 XT, nos dejaba una escalabilidad aproximada del 15% real, que es lo que estimábamos como poco para la RX 7600 según los datos de AMD y nuestras previsiones.

Bien, los datos de las API, que son nefastos, hacen caso al llamado Overhead, pero es que en el caso de esta suite de 3DMark estos test buscan medir en diferentes API cuántas Draw Calls puede manejar y representar una GPU antes de colapsar o saturar. El método es simple, porque requiere serlo para poder medir con precisión, y se basa en representar muchos objetos en pantalla, y claro, aquí llega lo bueno.

Solo hay dos maneras de colapsar el test:

• La CPU no puede manejar más Draw Calls.
• La GPU está limitada y no puede trabajar tantas Draw Calls.

En el caso de la CPU actualmente no es factible, y menos con Vulkan o DX12, que curiosamente representan las mayores caídas. No vamos a entrar a explicar el porqué, sería demasiado largo y ya se trató en su día, simplemente quédate con la idea.

Entra en juego el Command Processor de AMD

Para que la suite de 3DMark en el apartado API Overhead de unos resultados tan sumamente malos al comparar una arquitectura con otra, a mismas especificaciones y velocidad, solo hay una posibilidad y culpable: el Command Processor de la GPU implicada, en este caso, de la RX 7600, aunque en realidad es cosa de RDNA 3 en conjunto.

Y aquí volvemos a la diapositiva superior suministrada por AMD de la cual ya hemos hablado. Dados todos los cambios que han sufrido los CU, y que como dijimos ayer, no son más que una evolución de la arquitectura RDNA 2 enfocados a paliar los problemas de latencia por los MCD y su L3.

Lo que hizo AMD es incluir una nueva unidad a cada CU y por doble, llamada Float/Matrix SIMD32 por cada Vector GPR. Además de esto, AMD mejoró sus Matrix Operation al implementar la segunda generación de AI Accelerators, lo que hizo que los Scheduler tuviesen que funcionar a mayor frecuencia y la L0 se tuviese que multiplicar por dos para mantener el rendimiento ganado en buenos términos sin entrar en dependencias externas de otros CU.

Pero claro, esto se diseñó pensando en sacar la L3 fuera del die con los MCD, entonces, ¿qué ocurre cuando se incluye de nuevo en el propio die con la RX 7600? Pues que tanto los controladores de memoria como el procesador de comandos tienen que ser adaptados. Y es que el Command Processor tiene que enviar las interrupciones generadas por el hardware al host cuando un comando se complete, lo que implica al mismo tiempo que el controlador de memoria, que tiene acceso a todos los dispositivos de la GPU que tengan memoria, sea esta caché o VRAM, tiene que compensar las direcciones de memoria basadas en los datos solicitados al host.

¿Un cambio de hardware que mezcla RDNA 2 y RDNA 3?

Teniendo en cuenta lo dicho, y que RDNA 3 es una evolución de RDNA 2, donde lo que ha buscado AMD es recortar el tiempo total de la Pipeline gráfica para no subir las frecuencias, y con ello, ser más eficientes en consumo, creemos que el Command Processor y los controladores de memoria son heredados de RDNA 2 en esta RX 7600 (al menos).

¿Por qué creemos algo así? Porque el Command Processors tiene acceso directo al GDS, a la L2, al controlador de memoria y al Dispatch al mismo tiempo. Por lo tanto, este hace una coordinación entre todos ellos y posiblemente al implicar la L3 dentro del die, el diagrama superior no refleje bien la realidad de la RX 7600, aunque sí para el resto de GPU MCM.

Lo que entendemos, es que dado el incremento de rendimiento que supone incluir la L3 de vuelta al die, por mucho MDIA que integra RDNA 3, el hecho de que el número de Unidades Float se haya incrementado por dos para conseguir que un GPR aumente un 50% su rendimiento hace que el Command Processor pueda saturarse cuando le llegan demasiadas Draw Calls. Es decir, el potencial y la mejora de reducir la latencia de la L3 está, el potencial de la arquitectura es palpable, pero está "coja", no está bien resuelta en un chip monolítico.

De hecho, el diagrama de bloques entre RDNA 3 y RDNA 2 es exactamente el mismo, por lo que salvando todos los cambios que se han producido en la arquitectura y que van más enfocados a reducir latencia y potenciar el Ray Tracing, lo que tenemos es casi la misma arquitectura, con pocos cambios, un "refrito" como apuntábamos ayer.

¿Por qué en juegos no consigue aumentar más su rendimiento?

Pues por dos razones. AMD ha supeditado gran parte de su rendimiento al driver, tal y como hace NVIDIA. En concreto en RDNA 3 se incluye dos partes:

• Un programa que se ejecuta en el host.
• Programas, los llamados called shader programs y kernels, que se ejecutan en la GPU RDNA3 en concreto.

Los programas en RDNA 3 están controlados por un driver que se ejecuta en el host que:

• Establece la dirección interna y otros registros de configuración.
• Especifica el dominio de datos en el que operará la GPU.
• Invalida y vacía las cachés en la GPU.
• Hace que la GPU comience la ejecución de un programa.

El software es modificable, el hardware no, se tendrían que sacar nuevos modelos de GPU a modo de "upgrade" posterior para paliar déficits de rendimiento. La dependencia de los drivers para todo el tema del Overhead se dejó atrás con DX11, se le permitió a la CPU trabajar más holgadamente con DX12, por lo que las GPU asumirían gran parte de esta tarea.

NVIDIA tiene un Overhead "arrastrado" de aquello que implica una sobrecarga en los procesadores de Intel y AMD más antiguos, precisamente por la mayor carga de Draw Calls que les requiere a cada arquitectura. O lo que es igual, los procesadores antiguos sufren más con una GPU NVIDIA.

AMD no quiso seguir ese camino y lo apostó todo a los drivers, es decir, las GPU Radeon son muy dependientes del software de AMD, lo cual, es algo ya bastante antiguo, como se ve en muchas diapositivas. Por eso vemos en algunas revisiones de los drivers mejoras de hasta dos dígitos en según qué juegos. Esto no es más que una optimización del driver frente a la API para reducir el Overhead que le produce al Command Processor de las arquitecturas RDNA.

Explicado esto y volviendo a la RX 7600, la diferencia que existe en rendimiento entre juegos vs benchmark, 3DMark para ser concretos, implica dos escenarios distintos y enfrentados: juegos que sobrecargan la API, es decir, hacen demasiado Overhead para el driver, y benchmark que no lo hacen.

Por eso podemos ver en todas las reviews que en los Time Spy o Fire Strike las diferencias entre RX 6650 XT y RX 7600 es mucho más amplia que en un juego muy saturado de Draw Calls para el Command Processor, sobre todo en DX12. Dos ejemplos de esto que acabamos de decir: Days Gone, DOOM Eternal o F1 22 frente a Halo Infinite, Cyberpunk 2077 o Red Dead Redemption 2.

Al enfrentar esos juegos, siempre que la CPU sea suficientemente potente (obvio) lo que podremos ver es que la RX 6650 XT está muy cerca o incluso por encima de la RX 7600, o en cambio, esta última y más nueva vence sobradamente a su homóloga RDNA 2. Además, toda esta explicación que os hemos comentado también funciona para explicar otro fenómeno que todos hemos visto: la escalada de rendimiento frente a la resolución.

A mayor resolución usamos, se requieren más Draw Calls, sobre todo en Vulkan y DX12. A mayor número de núcleos e hilos en una CPU esta puede disponer más rápidamente las Draw Calls a la GPU. Por lo tanto, a mejor hardware más colapsará el Command Processor en AMD, puesto que la reducción de la latencia de la caché impulsa el rendimiento general de cada CU, dejando al CP en la estacada.

Es decir, la mejora del CP para RDNA 3 frente a RDNA 2 es inexistente (al menos en la RX 7600) los cambios introducidos en la primera palían la latencia del MCD, pero cuando no existe dicho MCD y el juego hace uso de la API de forma intensiva, este hace que el Command Processor colapse y el rendimiento ganado se termine perdiendo en gran parte, más conforme se aumenta resolución.

La RX 7600, RX 7900 XTX y el Overhead

Claro, pensarás, ¿qué tiene que ver la RX 7900 XTX en esta ecuación? Bueno, realmente bastante. Tiene dos peculiaridades con su hermana RX 7600 que van ligadas de alguna manera con todo lo dicho. En primer lugar, chip monolítico vs chip MCM, es decir la L3 está fuera en MCD, pero además, sobre el papel y salvando la velocidad de la VRAM que es un poco superior en la mayor, la RX 7900 XTX es, exactamente, tres veces más potente que la RX 7600.

Es decir, coge una RX 7600 y multiplica por tres todas sus unidades: obtendrás el triple de Shaders, el tiple de ROPs, el triple de TMU, bus, VRAM, cachés etc etc etc. Las diferencias principales son las frecuencias, donde tenemos 20 Gbps vs 18 Gbps para VRAM y 2.499 MHz vs 2.625 MHz, y siendo la "misma arquitectura" obtenemos 61,42 TFLOPS frente a 21,5 TFLOPS.

El resultado es un +285% comparando TFLOPS, que serían un +300% si igualamos las frecuencias de los Shaders entre las tarjetas, ¿curioso no? Pues no, realmente no. La RX 7600 es un 33,33% una RX 7900 XTX, pero la diferencia de rendimiento entre ellas es de casi un 220% de media a 1080p siguiendo con los datos de la review de TPU. La explicación, muy breve eso sí, va muy de la mano de lo que hemos visto aquí:

• Overhead.
• Latencias de la caché L3
• Desactivación parcial de los CU en nanosegundos cuando la tasa de FPS es alta para mantener un bajo consumo.

Por eso, pensando en el consumo, la RX 7900 XTX palidece ante la RTX 4090 a mayor resolución, porque se prima la energía al rendimiento y al mismo tiempo, se aumenta el Overhead del juego y la API hacia el Command Processor, donde además comenzamos a llenar en mayor medida la L3 y se está pasando más información y de mayor tamaño entre L2 y L3, con lo que ello supone.

Con esto en mente, se puede ver perfectamente cómo a mayor resolución la RX 7600 comienza a caer muchísimo, y se pasa de 1080p, 2K y 4K frente a la RX 7900 XTX de un +217% para esta última a +256% y +311%. Esto no ocurre al comparar RX 7900 XTX vs RX 7900 XT, donde las diferencias son de un 10%, 14% y 18% según las resoluciones, algo lógico al disponer de menos unidades generales (Shaders, TMU, ROP, Caché, bus, etc) donde a mayor carga gráfica va perdiendo fuerza.

Por lo tanto, y como resumen, RDNA 3 debe mejorar y por eso, ahora lo sabemos, AMD hablaba entre bambalinas de un problema que no podían solucionar por hardware y que debería estar corregido para RDNA 4. Lo que sí que pueden hacer es mejorar por drivers, por software, con los desarrolladores, donde podríamos ver ganancias interesantes si consiguen optimizar las Draw Calls.

Por eso, en las diapositivas, AMD especificaba 32 CU RDNA 3 y no arquitectura RDNA 3 como tal, fueron demasiado específicos, y eso es muy extraño dado que no se había visto en el marketing de las RX 7900, curioso cuanto menos. En cualquier caso, los datos vistos entre DX11 y DX12 / Vulkan muestran un deterioro del rendimiento bastante alto y todo apunta a que la RX 7600 sufre de Overhead mucho más que sus hermanas.

Por último, ¿cuánto rendimiento pierde la RX 7600 por este hecho? Bueno, teniendo en cuenta que la frecuencia de las pruebas se bajó a 1 GHz, a su frecuencia de stock realmente deberíamos poder ver una pérdida de casi el 10% aproximadamente, quizás incluso se acerque al 13%. ¿Cuánto podrían ganar el resto de modelos MCM si no estuviesen afectados por el Overhead? Seguramente una cifra de un dígito, sin datos es complicado acercarse más a una cifra. En cualquier caso, ya tenemos una explicación al bajo rendimiento de esta tarjeta RX 7600.