Aclaración antes de empezar, esta entrada es una entrada de especulación que combina lo que sabemos oficialmente de AMD junto a información extra-oficial (patentes) y especulación por mi parte intentando juntar las piezas por lo que no tenéis que aceptarlo como información sino como especulación «informada».

Si me equivoco estoy dispuesto a comer cuervo.

… Al grano.

Por fin AMD ha dado información, aunque no completa, acerca de su arquitectura Navi a la que ha bautizado como RDNA de cara al marketing, siendo las RX 5700 las primeras tarjetas gráficas de PC en llevar esta arquitectura, las cuales se acabaran de presentar en el E3 y saldrán al mercado durante el mes de Julio.

En general el anuncio de AMD ha sido un verdadero…

… a una serie de listillos que han ido sosteniendo una serie de ideas absurdas incluso cuando AMD hacía tiempo que las había descartado o no tenían ningún sentido y lo que hacían era alimentar una conversación absurda y sin sentido. ¿La primera de ellas? Pese a que David Wang había avisado que la arquitectura era monolitica (todo en un mismo chip) aún había gente hasta unas horas antes de la presentación que hablaba de chiplets o configuraciones MCM en cuanto a la nueva GPU de AMD, todas estas especulaciones han quedado completamente destruidas.

La propia Lisa Su ha mostrado el chip con el empaquetado del mismo y se ve que nada de Chiplets, es todo monolítico:

Y el departamento de marketing de AMD en sus diapositivas nos lo re-confirma por completo que estamos ante una GPU monolítica y por tanto nada de una GPU dividida en varios chiplets.

Otro elemento que se ha confirmado es que al igual que comente y que la lógica marcaba es el abandono de la ultra-cara memoria HBM2 por la memoria GDDR6, teniendo en cuenta que no vemos la GPU montada sobre un sustrato/interposer con la memoria HBM2 al lado esta muy claro que la GPU no se va a basar en memoria HBM2 como Vega. El motivo de ello es que la memoria HBM2 es un sinsentido enorme en cuanto a costes y era de esperar que después de la negativa de Nvidia a utilizarla de cara a las tarjetas de su arquitectura más reciente (Turing) estaba mas que claro que AMD acabaría abandonando por completo el uso de la misma en Navi, bueno… Lo que ahora es conocida como arquitectura RDNA (Radeon DNA).

El hecho de no utilizar memoria HBM2 nos confirma definitivamente que la tarjeta gráfica de Stadia no es una Navi/RDNA pese a lo que comente hace unos días. Esto significa que AMD le ha vendido a Google el stock sobrante de las Vega56 a Google, porque si Stadia se basase directamente en RDNA entonces tendríamos a Lisa Su mencionando esto durante la presentación, en cambio la plataforma a futuro que Lisa Su ha mencionado en su presentación del Computex ha sido la PlayStation de siguiente generación.

AMD no ha mencionado el vaporware de Stadia y el hecho que Lisa Su haya re-confirmado lo que dice Cerny no es lo importante, lo importante es que AMD ha hecho referencia que RDNA es una arquitectura para la década siguiente en vez de ser una especie de versión final de la arquitectura GCN. Esto es importante por el hecho que Cerny ya confirmo el soporte Raytracing en su consola y aún tenemos a lerdos de campeonato afirmando que el Raytracing de la siguiente generación de consolas será por softwarep porque claro, es AMD, mientras Nvidia con su marketing no para de repetir que inventaron la rueda de manera continuada y la gente se piensa que AMD nunca va a poder alcanzar a Nvidia. Esta es precisamente la gente que ha ido hundiendo de negatividad todo lo relacionado con Navi en estos últimos meses.

AMD no ha revelado en su presentación de la computex el soporte Raytracing en RDNA, pero teniendo en cuenta que esta confirmado en PS5 podemos decir que esta confirmado en PC.

Por lo que RDNA no se trata de un stop-gap ni un apuramiento de la arquitectura GCN como mucha gente esperaba basandose en que AMD al igual que ocurrió con la gama Bulldozer antes del Zen estaría atrapada en un ciclo sin fin de refritos de la arquitectura GCN. Aunque realmente con todos los cambios que han habido en los últimos años es que no podemos hablar realmente de una arquitectura fija ya que los cambios desde la primera GCN en los diferentes elementos de la GPU han sido constantes pero hay un elemento que todas las arquitecturas GCN han tenido en común y no es otra que la organización de su Compute Unit.

El salto de GCN a RDNA significa un cambio importante en la organización interna de las Compute Units, de la misma manera que AMD cambio la organización de las Compute Units cuando salto de las Terascale (VLIW5) a las GCN y dichos cambios no se van a traducir en la implementación los RT Cores/Traversal Units unicamente para el Raytracing. Pero RDNA al contrario de GCN respecto a Terascale no es un cambio radical realmente y pese al marketing de AMD podemos decir que se basa más bien en los mismos conceptos de diseño que Ryzen. Ahora bien, AMD no ha hablado aún de la Compute Unit de RDNA a nivel arquitectural, pero los pies de nota en su página web sobre el evento en la Computex nos dan ciertas pistas adicionales aparte de las diapositivas.

Las APUs y las GPUs de AMD basadas en arquitecturas Graphics Core Next y RDNA contienen núcleos de GPU compuestos por Compute Units, la cuales se definen como 64 Shaders (o stream processors) trabajando conjuntamente.

Por lo que tenemos de nuevo unas 64 ALUs por Compute Unit como ocurre en GCN. Las RDNACUs tienen dos cambios bastante importantes que AMD no ha revelado aún pero que podemos intuir husmeando un poco, pero antes tenemos que entender que la RDNACU no es un borrón y cuenta nueva de la arquitectura GCN sino que es realmente una forma de aumentar el rendimiento de la misma solventando uno de lo problemas arquitecturales que tiene. Y aquí entramos en otro punto de la más supina ignorancia por parte de los expertillos de foro, cuando dicen que Navi no va a ser tan buena en computación como Vega, cuando lo leo o lo oigo mi reacción siempre es…

Si tan buena es Vega en computación… ¿Como es que AMD ha cambiado precisamente la Compute Unit en su nueva arquitectura? Es que precisamente esto demuestra la imbecilidad supina de muchos y el hablar por hablar. Esta es la misma gente que no paraba de repetir hasta no hace mucho lo de…

En toda API enviamos Workgroups a las Compute Units. Un Workgroup son bloques de hasta 1024 elementos que son enviados a las Compute Units para ser ejecutados. Cada elemento es lo que en GPU llamamo un «kernel» o un hilo que contiene un dato y su instrucción. Pensad en ello como programas de una sola linea de código que se ejecutan y dan un dato de salida que puede ser aprovechado por el hilo siguiente que viene a continuación o es enviado a una étapa posterior del pipeline. Los Workgroup son colocados en los registros de cada Compute Unit para que las ALUs de las mismas los vayan procesando.

Pensad en los registros como una pila en la que en teoría la ALUs toman los datos e instrucciones a procesar de la parte de abajo de la misma y el planificador va llenando la pila de manera progresiva.El problema de la arquitectura GCN es que los registros de cada Compute Unit se reciclan cada 10 Wavefronts, estos nos lleva a una situación cuanto menos curiosa que hace que el rendimiento de las CUs este alejado del ideal.

En la actual arquitectura GCN es que una Compute Unit puede almacenar en sus registros la información necesaria de hasta 2560 hilos, esto son unos 640 hilos por unidad SIMD. El problema es que el planificador soporta como mucho hasta 40 Wavefronts (10 Wavefronts por SIMD) y durante todo ese tiempo los registros no se van alimentando por lo que en GCN si ocupamos todos los registros y por tanto todas las ALUs nos ocurre que en 4 olas ya hemos consumido todos los registros y durante el tiempo de las otras 6 olas la Compute Unit esta…

Si no queremos que la Compute Unit este parada entonces por la falta de registros nos encontramos que solo podemos utilizar 6 ALUS por ciclo de cada SIMD16 dado que solo podemos utilizar olas de 24 elementos. Esto es un nivel de utilización de <40%. Por lo que aumentar el rendimiento no depende directamente como dicen muchos «expertos» de aumentar la cantidad de núcleos (CUs) sino hacer que el rendimiento por núcleo sea mucho mayor y esto implica una serie de cambios en la Compute Unit a nivel interno.

Es posible que AMD actualice el resto de bloques de la GPU pero RDNA va a utilizar buena parte de los componentes de la arquitectura GCN vistos en Vega pero en una organización diferente. Lo que si que vamos a volver a ver es el anillo Infinity Fabric alrededor de los componentes de la GPU para comunicar estos entre si y con la cache L2, pensad que las mejoras en el rasterizador supuestamente implementadas en Vega y en las unidades RBE con tal de implementar el Tile Caching depende del anillo IF que comunica con la cache L2, la cual se encuentra fuera de las Compute Units por lo que no se afectada por los cambios en las RDNACUs.

En la diapositiva nos hablan de «jerarquía de varios niveles de cache», si miramos la organización de una Compute Unit de AMD de la arquitectura GCN veremos que hay una sola cache en ella, la L1 de datos.

La cache de instrucciones en cambio es compartida por hasta 4 CUs.

La cache de instrucciones es leida por el planificador y es donde se encuentran los siguientes Workgroups divididos en olas a procesar por parte de las Compute Units, es de solo lectura porque cuando un kernel/hilo es ejecutado es cuando al planificador general de la GPU (no confundir con el de la Compute Unit) asigna al dado de salida una nueva instrucción y el hilo resultante es enviado a una unidad de función fija o en su defecto a la Cache L1 de instrucciones de un grupo de CUs para ser luego volcado sobre los registros de la unidad SIMD de una Compute Unit.

Esto significa que si Navi es un cambio en las CUs de la arquitectura GCN para crear una de nueva y tenemos una jerarquía de cache entonces si hay un nivel de cache adicional dentro de la CU aparte de la ya existente, L1 de datos, ha de ser una cache L0. Y en efecto, sabemos de la existencia de una cache L0 a través de código encontrado en Github.

Hay que tener en cuenta que a medida que vamos subiendo en la jerarquía las caches y otras memorias intermedias se van haciendo más privativas. No se nos indica si la cache L0 es una cache de datos, instrucciones o ambas pero hay que tener en cuenta que ha de estar en una localización por encima de la L1 en la jerarquía, la cual en el caso de la cache de instrucciones esta fuera de las Compute Units y es aquí donde viene lo interesante:

La cache L0 mantiene todas las operaciones de memoria en orden para los work-items en el mismo wavefront (ola).

Esta es una mención a la Cache L0 relacionada con GFX10/Navi/RDNA por lo que es una confirmación de la misma.

En modo WGP (Workgroup) las olas del Workgroup pueden ser ejecutadas en una u otra CU del WGP. Por lo tanto, es necesario hacer bypasss a la L0 que se encuentra por CU. De lo contrario, en el modo CU y todos los Wavefronts de un Workgroup están en la misma CU, por lo que no es necesario omitir L0.

Esto que parece muy criptico nos confirma que la Cache L0 esta en efecto dentro de cada CU. La idea es que la Cache L1 de instrucciones sigue existiendo pero lo que hace es alimentar a la cache L0 y el planificador lee de la cache L0 directamente para organizar y volcar las olas (wavefronts) en lo registros de la CU. La idea no es otra que el contenido de los registros e vaya renovando continuamente de tal manera que con el máximo de utilización de las ALUs no se produzcan ciclos muerto dado que con la cache L0 se llenarían los registros muy rapidamente.

Y si, se que es dificil de entender pero es la única forma que se me ocurre, tened en cuenta que en GCN si utilizabamos las 64 ALUs entonces los registros duraban 4 Wavefronts solamente. Hay una referencia en otro documento sobre la cache de instrucciones que es cuanto menos extraño…

En GFX10 la I$ (Cache de instrucciones) esta compuesta por lineas de cache de 4×64 bytes.

Por defecto, el prefetcher mantiene una sola linea de cache detrás y lee dos por adelantado.

El motivo de decir… «En GFX10 la $IS…» es una confirmación vedada de que en GFX10/Navi/RDNA dicha cache ha sido cambiada. Un wavefront (ola) son 64×4 bytes y la cache L0 parecer ser solo de 4 Wavefronts de longitud como mínimo pero no es así realmente. El motivo de ello es que el tiempo mínimo de ejecución de un hilo/kernel es de 1 ciclo, teniendo unas 16 ALUs por SIMD entonces el tiempo mínimo son 4 ciclos por lo que la cache L0 alimenta con una linea de cache (64 bytes x4) una ola/wavefront entero a una unidad SIMD un ciclo, a la segunta en el segundo ciclo y así paulatinamente. Pero hemos de tener en cuenta que la Cache L0 puede almacenar hasta un Workgroup (WGP) como mínimo, esto son unos 1024 elementos y por tanto un potencial tamaño de la cache L0 de 4KB para almacenar un Workgroup entero.

La Cache L0 de instrucciones puede ser alimentada de dos maneras, una de ellas es a través del bus de la Compute Unit que la comunica con la cache L2 pero entonces en ese caso estaríamos realizando un bypass a la Cache L1, el otro es viendose alimentada de la cache de instrucciónes L1 pero esta última no alimentaría ya más el planificador de forma directa siendo una cache en un nivel inferior si es que esta al final existe.

¿Puede ser la cache L0 de datos también? Tiene cierto sentido, si tenemo en cuenta que si esta antes de la cache L1 de datos se la llame cache L0. ¿Es posible esto?

Hay que tener en cuenta que las ALUs SIMD están pensadas para operar siempre en modo inmediato sin ningún tipo de direccionamiento, si el dato no se encuentra en los registros o se se hace una referencia a un dato externo entonces se ha de ir buscando en los niveles de cache inferiores hasta encontrarse con los datos.

Los timings de las instrucciones ejecutadas desde los registros mismos son los siguientes:

  • Instrucciones aritméticas y lógicas simples de 32 bits, 1 ciclo por instrucción. 4 ciclos por ola.
  • Instrucciones especiales y trascendentales. 4 ciclos por instrucción, 16 ciclos por ola.
  • Instrucciones de salto, 16 ciclos.

Si la instrucción no se encuentra en los registros entonces ha de buscarse y el timing de las caches en una GPU es cuanto menos… extremadamente alto.

La unidad SIMD si no encuentra los datos en los registros va bajando en la jerarquía de memoria hasta encontrarlos. La segunda memoria de datos (no instrucciones) en esta es la cache L1. Ahora bien, la nueva cache L0 debería colocarse delante de la cache L1 en cuanto al acceso,

En la GCN CU la petición de datos a la L1 de datos se realiza desde las unidades Load/Store asignadas a cada unidad SIMD. La Operand Destination Cache (L0) no se encuentra en el camino de datos de la Cache L1 realmente porque las unidades SIMD pueden acceder directamente a dicha memoria sin tener que tirar de las unidades L/S por lo que la conclusión es que la cache L0 no esta conectada a la cache de datos L1 y por tanto no es una cache de datos sino solamente de instrucciones pero con una particularidad.

La Cache L0 no sería otra cosa que la Operand Destination Cache de las patentes de la unidad Super-SIMD que os he comentado alguna vez en el pasado en este blog.

A esta no solo podían exportar las unidades SIMD (ALU Array en dicha patente) sino además doblaba como cache de instrucciones al poder alimentar el planificador. ¿Es la Operand Destination Cache de dicha patente la Cache L0 de la que estoy hablando? En la arquitectura GCN no existe dicha memoria y el diagrama de la misma patente nos menciona un solo ALU Array sin dicha cache al hablar de la antigua organización.

En ambos casos los arrays son de 64 elementos en total (ver confirmación de AMD más arrib), y en ambos casos tenemos unas 4 unidades SIMD… ¿Entonces a que viene que existan dos ALU Array? La misma patente de la unidad Super-SIMD nos lo explica.

De la siguiente manera:

El bloque Super-SIMD 300 incluye unidades de ejecución en vector 360. Cada una de ellas incluye dos colecciones de Core ALU 362a y 362b y una Side ALU, cada uno de ellas teniendo N numero de ALUs que son iguales a la longitud del SIMD. La Core ALU 362 a puede acoplada con la Side ALU 365 para formar la Full ALU 362. Full ALU es la segunda ALU 230 de la FIG. 1B. Core ALU 362b es la primera ALU 220 de la FIG 1B.

En una implementación, ambas Core ALU tienen N multiplicadores para ayudar a implementar ciertas operaciones de precisión simple como el  fused multiply-add (FMA). En una implementación, la side ALU 365 no tiene multiplicadores pero puede ayudar a implementar operaciones no-esencuiales como instrucciones de conversion. La Side ALU puede co-trabajar con cualquiera de las ALU 362a y 362b para finalizar operaciones complejas como instrucciones trascendentales.

La Cache L0 por lo tanto sería una cache que no solamente doblaría como cache de instrucciones sino que las ALUs podrían exportar a ella de manera directa pudiendo manipular por completo la lista de instrucciones que va a ir a los registros, incluso la cache L0 puede escribir a los registros directamente, lo cual va muy bien para evitar tiempos muertos en la Compute Unit.

Por otro lado lo de las operaciones trascendentales es una de las ventajas que tiene Nvidia sobre AMD en estos momentos.Si miráis los diagramas de las arquitecturas de Nvidia veréis que siempre hay unas unidades llamadas SFU (Special Function Unit) que no están en GCN…

Las SFU se encargan de esas instrucciones trascentales como ahora:

  • Rcp
  • Sqrt
  • rsqrt
  • log
  • pow
  • exp
  • sin
  • cos

AMD ejecuta dichas instrucciones con las unidades SIMD habituales en vez de con unidades especiales. Si hablamos de la ejecución de instrucciones aritméticas simples entonces AMD no puede mejorar el rendimiento pero si que puede mejorar las trascendentales y el uso de la «doble ALU» es para reducir el tiempo por instrucción de dicho tipo de instrucciones que son altamente utilizadas en varios casos. Si comparamos con la unidad SIMD de la unidad GCN entonces nos encontramos que una Full ALU de la misma equivale a Core ALU+Side ALU pero AMD ha añadido una Core ALU hermana al lado de cada unidad SIMD aunque realmente solo se cuenten 64 esto es porque las instrucciones funcionarán de la siguiente manera:

  • Instrucción GCN: Hace uso de la 1 sola Core ALU y el algunas funciones de la Core ALU+Side ALU.
  • Instrucción RDNA (VLIW2) puede hacer uso de la Core ALU+Side ALU o de 2 Core ALU.
  • La Compute Unit siempre ejecuta 64 kernels/hilos simultaneos independientemente si sin RDNA (VLIW2) o GCN.

Las unidades de texturas y la LDS no parece que vayan a tener cambios pero nos queda el elemento final que son las Traversal Units/RT Cores… Las cuales no creo cuya posición sea diferente al concepto de implementar dichas unidades en la AMD Hawaii que os he comentado varias veces.

Las Traversal Unit (TU en el diagrama) acceden a la cache L1 de datos a través de las mismas unidades L/S con las que las unidades SIMD de la CU se comunica con dicha cache. Esta organización es exactamente casi la misma que en Turing…

Con la diferencia de que en Turing, el RT Core esta conectado directamente a la cache L1 y a la LDS (ahora fusionados en la misma memoria) y recibe datos directamente desde las ALU SIMD. La organización de Nvidia no es igual al 100% a la de AMD pero la colocación es cercana a la cache L1 y pudiendo recibir datos de las unidades SIMD. En esto no estoy muy seguro como iría al 100% colocada dicha unidad.

No os voy a marear más con el tema estrictamente técnico, porque la explicación de la RDNACU ya estaría cuasi completa con esto, es posible que haga un diagrama completo pero tened en cuenta que esto no es más que una especulacion con la poca información que tenemos y que se puede incidir de las patentes de AMD de los últimos años y se que a estas alturas muchos estaréis en estos momentos esteréis ya bastante…

La idea de todos estos cambios vendría a ser mejorar la GPU con una serie de parametros concretos:

La parte más importante es la del rendimiento/consumo que ha sido hasta ahora el punto fuerte de Nvidia y el talón de aquiles de AMD. El aumento en este apartado es lo que les ha permitido prescindir de la memoria HBM2 por un lado y por el otro alcanzar velocidades de reloj más altas. El 1.5x de rendimiento/consumo viene de la combinación del paso de los 14nm a los 7nm ya que AMD la esta comparando por lo visto con Vega64 junto a los 1.25x del aumento de rendimiento por la arquitectura. AMD afirma que esta un poco por encima del nivel de la 2070 de Nvidia. Hay que tener en cuenta que la 2070 tiene unos 36 SM/CU y es un poco mejor que la 1080, se ha repetido en los rumores de manera continuada que este chip estaría compuesto por unos 40 CUs. En todo caso la comparación CU con CU debido a los cambios entre GCN y RDNA ya no es válida y por tanto compara FLOPS tampoco.

Es por ello que AMD no esta hablando de TFLOPS en su marketing, pensad que Nvidia tiene cifras menores de TFLOPS respecto a GCN y acaba teniendo mayor rendimiento, un consumo menor… ¿Que ha hecho AMD? Ponerse al día respecto a Nvidia. Algo con lo que los Nvidiotas de los medios y demás astroturfers les ha sentado muy…

Porque si se confirma lo de los $399 que se esta oyendo por ahí con el rendimiento de la RTX 2070 entonces tanto la propia 2070 como la 2060 están jodidas a no ser que Nvidia las baje de precio. Después de esta GFX1010 va a llegar la GFX1000 o «Navi Lite» que muy posiblemente compita contra la gama Turing descafeinada de las TU11x. Por lo que esta llegada de competencia bienvenida sea porque ya hemos visto como se comporta Nvidia cuando no tiene competencia…

Por lo que toda competencia es bienvenida porque nos beneficia a todos, ya hemos visto el impacto de los Ryzen en el monopolio abusivo de Intel en las CPUs y ojala con las GPUs ocurra lo mismo y a la arrogante Nvidia se la ponga en su sitio en cuanto a precios.

Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.