Skip to main content
AMD Navi

AMD Navi: Qué podemos esperar

Dentro de unos días se espera que AMD presente su nueva arquitectura para GPU bautizada como Navi. Con la sensación de decepción que dejó Vega, uno puede preguntarse qué es lo que pasa a los diseños de AMD para que parezca que no terminen de avanzar al mismo ritmo que los de Nvidia. En los últimos roadmap de AMD podemos ver que Navi sigue siendo de la misma familia de gráficas GCN que llevamos teniendo desde hace unos años. Pero esto no quiere decir que no podamos ver arreglados ciertos cuellos de botella o limitaciones que seguimos teniendo con esta arquitectura. Pero, ¿Qué habría que arreglar?

Roadmap de GPUs de AMD

Fundamentalmente, las gráficas de AMD llevan siendo casi iguales desde Hawaii, vista en productos como la AMD 290. Este es un producto del año 2013. Para aquella época estaba muy bien, pero pasan los años y lo que en aquella época podía estar bien, ahora muestra carencias. No porque en aquel momento fuese un mal diseño, que no lo era, sino porque al intentar extenderlo se ha ido a lo fácil. Los diseños GCN actuales siguen teniendo limitaciones que también tenía Hawaii como arquitectura. Estas limitaciones se maximizan cuando se intenta subir las velocidades de reloj, cuando se intenta meter más shaders y resulta que no se puede, cuando las necesidades de ancho de banda con la memoria se disparan…

Una de las variables que hay que modificar para conseguir una GPU con más potencia es aumentar el número de shaders que tiene el procesador gráfico. El problema de esto es que no puedes simplemente aumentar la cantidad de shaders y dejar lo demás casi sin tocar. Te puedes encontrar con problemas de shaders infrautilizados o un diseño general mal balanceado. Esa infrautilización y mal balanceado es por donde hay que tirar. GCN tiene actualmente una limitación de máximo 4 Shader Engines. Un Shader Engine es un poco en concepto como el SM de Nvidia que comentaba en esta entrada. Aquí también se trata de encapsular en una misma estructura una serie de componentes. Repitiendo esa estructura, escalas la potencia del procesador.

Shader Engine GCN
Shader Engine GCN

Hay ciertas diferencias entre el SM de Nvidia y el Shader Engine de AMD. En el SM de Nvidia no puedes aumentar o reducir el número de shaders que se han elegido para esa arquitectura. Si para Maxwell se decide que cada SM tenga 128 shaders, los tendrá para todas las gráficas de esa arquitectura. En el caso de AMD no hay una limitación así. El número de Compute Units (o CU) que tiene cada Shader Engine no tiene por qué estar ligado a la arquitectura. Así, nos encontramos con casos como Hawaii, con 4 Shader Engines, 11 CU por Shader Engine y 64 shaders por CU o con Vega 64 y sus también 4 Shader Engines pero 16 CU y 64 shaders por CU.

El problema o ventaja según cómo se mire de tener una estructura que es repetible es que hay ciertos recursos que dependen de cuántas estructuras de esas haya en la GPU. Nvidia al tener un SM más pequeño y no tener esas limitaciones de número máximo de SM tiene más cantidad de ciertos recursos que los diseños de AMD. Solucionar en el caso de AMD la limitación de 4 Shader Engines por procesador gráfico solucionaría también el cuello de botella en la capacidad de geometría que muestran sus gráficas. Un Shader Engine de la arquitectura GCN solo tiene un motor de geometría. Esto hace que actualmente haya un máximo de 4 de estos motores de geometría. ¿Para qué serviría entonces meter 4096 shaders como los que tiene Vega 64 si no tienes capacidad suficiente para tratar polígonos? Exacto, para nada. Tienes shaders infrautilizados ocupando espacio y luchando por recursos. Simplemente aumentando los Shader Engines de 4 a 6, se aumentaría en un 50% la capacidad de polígonos por el hecho de tener dos motores de geometría más.

Capacidad de procesar triángulos de diversas GPUs
Capacidad de procesar triángulos de diversas GPUs

Si te fijas en el diagrama de la arquitectura del Shader Engine que he puesto antes, verás que hay otro componente. Los ROP o tradicionalmente llamados rasterizadores. La cantidad máxima de éstos vuelve a estar limitado por la arquitectura actual de CGN a un módulo por Shader Engine con 16 ROPs máximo por módulo dando como total máximo 64 ROPs.

De una forma resumida, los rasterizadores son los encargados de coger la imagen tridimensional que la GPU ha procesado en su interior y transformarla a los pixels y la imagen bidimensional que finalmente se ve en pantalla. Cuantos más ROPs tengas, la tarjeta gráfica podrá por ejemplo mover mayores resoluciones. Y un poco como antes, no sirve de nada tener 4096 shaders como tiene Vega 64 si luego no tienes capacidad de “pintar” la imagen final. De aquí viene lo que a algunas personas les asombró en su día; la AMD Hawaii 290 a resoluciones altas suele tener mejor rendimiento que la Polaris 480X siendo esta última más reciente. La 290X tiene 64 ROPS y a la 480X por ahorro de costes ese número se recortó a 32.

Extracto del análisis de Anandtech de la AMD 480
Extracto del análisis de Anandtech de la AMD 480

Como tercer aspecto a mejorar, está claramente el ancho de banda. Aquí hemos visto a AMD experimentando con nuevas tecnologías como el HBM y llegar a 1TB/sg de ancho de banda. Pues ni aún así parece ser suficiente y overclockeando solamente la memoria, se obtienen interesantes aumentos de rendimiento. Esto es mala señal ya que indica que el ancho de banda tal cual está la GPU de fábrica no es suficiente para las necesidades del procesador gráfico. Si ni con tecnologías exóticas y anchos de banda descomunales puedes alcanzar el máximo rendimiento, tienes un problema. A AMD le falta mejorar mucho los algoritmos de compresión de memoria. Con esto podrían ahorrar mucho ancho de banda, volver a tecnologías de memoria más normales como GDDR6 ahorrando costes y tener un producto con un rendimiento en la práctica más cercano al teórico. Y otra vez como antes, no sirve de nada tener 4096 shaders si no los puedes alimentar.

Con las mejoras comentadas antes, se podrían intentar otras que los productos actuales de AMD también necesitan. En un intento de competir con Nvidia en rendimiento, AMD tiende a lanzar sus GPUs con unas velocidades de reloj demasiado altas para ese diseño que lo sacan de su punto de eficiencia energética óptimo. Si consigues una mejor utilización del hardware en general, no tienes por qué subir tanto las velocidades de reloj pudiendo relajar voltajes, mejorar las temperturas y tener un consumo energético menor.

Es cierto que GCN a través de sus varios diseños ha tenido algunas mejoras en computación, cálculo en FP16 y otros. El problema es que hemos llegado a un punto en el que hace falta empezar a modificar aspectos fundamentales de la arquitectura y no quedarse solamente en cosas secundarias.

Estas soluciones anteriormente propuestas creo que son factibles en Navi. Tienen además como ventaja que todas ellas aumentarían el uso de los shaders haciendo que estén menos infrautilizados. El rendimiento de la GPU en la práctica se acercaría al teórico y además la eficiencia energética mejoraría bastante. Todo es cuestión de si AMD y su división Radeon Technologies Group han podido sacar el presupuesto necesario para afrontar esta serie de cambios. ¿Será esta arquitectura la Maxwell de AMD? Lo veremos dentro de unos días.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.