Esto quería comentarlo hace ya bastantes días pero tenía mi cabeza hecha un lio y no encontraba la forma de ordenar las ideas, es algo de lo que he hablado mucho en el blog, la transformación de los SoC clasicos a MCM interconectados a través de un NoC de cara al futuro. Hace unas semanas, David Wang quien es el vicepresidente de AMD dejaba claro que el mercado donde no vamos a ver el concepto multi-GPU en un MCM es el mercado de los videojuegos.

Lo mejor es ir a la noticia:

David Wang, el nuevo Vicepresidente sénior de ingeniería para AMD Radeon Technologies Group (RTG), ha dado a conocer que el silicio GPU Navi seguirá ofreciendo un diseño monolítico tradicional, ya que, a diferencia de las CPUs AMD Ryzen / EPYC, el mundo de los videojuegos no cuenta con un software que haga posible una gráfica con un diseño MCM (Multi-Chip Module / Infinity Fabric, sin ir más lejos).

David Wang lo explicó de una forma muy sencilla. Una GPU con un diseño MCM sería como ofrecer una configuración CrossFire en un solo silicio, y ya sabemos el problema que ello conlleva, y es que muchos proveedores de software independientes están dejando de ofrecer soporte multi-GPU, a lo que se le suma que son cada vez menos los juegos que están realmente optimizados para el uso de configuraciones de más de una GPU, por lo que se está bloqueando un camino que, en caso de ser escogido, traería muchos más problemas que beneficios.

Esa infraestructura no existe en ninguna tarjeta gráfica más allá de las configuraciones CrossFire de AMD y SLI de Nvidia, pero incluso este soporte está prácticamente muerto. Un ejemplo es que la tarjeta gráfica icónicamente más popular de Nvidia, la serie GeForce x60, perdió la capacidad de conformar la capacidad SLI con la GeForce GTX 1060, a lo que se le suma que los desarrolladores de juegos no quieren gastar recursos para codificar sus juegos específicamente para trabajar con una matriz multi-GPU (al ser muy poco popular), y eso sería lo mismo que diseñar una GPU con un diseño MCM.

El problema real, no es el hecho de tener que trabajar con dos GPUs ya que en ese caso la API la que se encarga de gestionar los recursos en comunicación con el procesador de comandos de la GPU. Más bien, los desarrolladores de juegos que ante la perspectiva de tener que trabajar con dos GPUs, dos pozos de memoria distintos su filosofía es la de…

thanks-but-no-thanks

¿Cual es el problema real? Las GPUs contemporaneas son multihilo en la computación pero son monohilo en gráficos, solo hay que ver la arquitectura de las propias GPUs de AMD…

GPUScheduler

Solo tenemos un procesador de comandos gráficos por el hecho de tenemos que renderizar una sola escena. Siendo las unicas GPUs realmente multinúcleo los Tile Renderers que subdividen la pantalla en Tiles para ser renderizados cada uno independientemente. Pero el caso es que en un Inmediate Renderer como son las GPU de AMD (y Nvidia) no podemos asignar varias GPUs a una escena, como mucho existe el Split Frame Rendering o el Renderizado Intercalado.

Direct-x-12-split-frame-rendering

Pero en ese caso es la API la que va enviando imagenes de manera intercalada a cada GPU o genera dos listas de pantalla a partir de una sola lista y envia a ambas GPUs. Pero casi nadie tiene dos GPUs en su sistema. En PC los desarrolladores de videojuegos se niegan a desarrollar para nada que tenga varias GPUs. Hoy en día todo el mundo tiene en su PC dos GPUs siendo una dla dedicada y la otra la integrada en el procesador que se podría re-enfocar a otras tareas. ¿La realidad? La mayoria de los desarrolladores de videojuegos pasan de utilizarlas dos GPUs incluso cuando hay dos de ellas disponibles en el hardware que tiene la gente. ¿El problema? El hecho de tener que lidiar con dos pozos de memoria, lo cual es:

headache-gif-2

Por el momento la única configuración posible que tiene AMD a mano es el MCM con una sola GPU y no varias si nos atenemos a las palabras de Wang. ¿Cual? Pues coger un AMD Epyc y cambiar una de sus CPUs por una GPU, una sola GPU.

AMD-EPYC-ZEN-3

Claro esta que el primer problema que nos encontrariamos sería que esa GPU no recibiría el suficiente ancho de banda para operar en condiciones por lo que tendria que tener un canal de memoria local, rompiendo por tanto con el concepto de coherencia en todos los espacios de la memoria que busca AMD. ¿Pero conseguimos dicha coherencia de memoria en un MCM? En los SoC de PC lo que se hizo fue eliminar el bus Garlic de la ecuación y dejar el Onion para todo el sistema, pero se necesito modificar la GPU y otorgarle el Address Translation Cache en las caches y el controlador de memoria porque la GPU a nivel interno sigue entendiendo su propia forma de ver la memoria y sigue actuando como tal.

slide-20-hsa-accel-features_575px

Pero esto es para comunicar una GPU con una o varias CPUs. ¿Como lo hacemos para comunicar varias GPUs trabajando en la misma escena? Renderizando dos escenas diferentes no hay problema porque no tiene que haber coherencia. ¿Pero como divides una GPU en partes y mantienes la coherencia para renderizar una misma escena? ¿Y que significa coherencia?

La coherencia de memoria hace referencia a la necesidad de establecer la lógica necesaria para que los distintos datos replicados a lo largo de la jerarquía de memoria, contengan la misma información si se trata de la misma dirección física. Por ejemplo, un dato que se encuentra en el nivel más alto de la jerarquía, esto es, en la cache de L1, y que ha sido modificado, deberá activar los mecanismos necesarios para que esta modificación se lleve a cabo en el resto de niveles, donde este dato también existe.

Esto puede cobrar más relevancia en el caso de los procesadores multinúcleos, donde, en general, se comparte un nivel de cache, L2 o Ln(donde n podrá ser cualquier número natural), pero cada núcleo dispone de su propia L1 donde modifica los datos, pudiendo haber una incoherencia de los datos que lee un núcleo y que han sido modificados recientemente por otro, disponiendo el dato sin modificar en la cache compartida.

¿Una misma dirección de memoria? Pues si, esto es lo que muchos afirman que se va  a convertir Navi, en una GPU dividida en sub-GPUs que compartirian por tanto todos el mismo pozo de memoria y por tanto la Cache L2 sería común. Un camino que por cierto AMD también seguirá.

nvidia-2017-multidie.png

¿El problema de cara a los videojuegos? Sería comunicar todas las porciones de la Cache L2 entre si.

gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-34-638.jpg

Tenemos un ancho de banda por partición de 64 bytes/ciclo por partición. A la cache L2 solo accede la Cache L1 de manera directa, dicha Cache L1 o L2 esta a un ratio de 1:3 o 1:4 respecto a las Compute Units porque de tener que acceder cada una de las CUs por ejemplo de un AMD Vega entonces la complejidad del cableado sería enorme y el ancho de banda interno también. AMD da un ejemplo de ese problema utilizando un chip ficticio de 64 núcleos en un paper que luego comentare y que tiene que ver mucho con los NoC y el uso de MCMs.

Volviendo al artículo del principio.

Pese a esto, el diseño MCM en el silicio Navi sí podría tener sentido en el entorno profesional, tal y como explicó AMD:

“Eso es en los juegos”, dijo Scott Herkelman de AMD. “En las cargas de trabajo profesionales e Instinct, el diseño multi-GPU es considerablemente diferente, todos estamos de ese lado. Incluso en las aplicaciones de blockchain, todos participamos en multi-GPU. Por otro lado, en el apartado gaming debe ser habilitado por los ISV. Y los ISV lo ven como una carga tremenda”.

(Entrevistador) ¿Eso significa que podríamos terminar viendo arquitecturas divergentes de GPU para los espacios profesionales y de consumo para habilitar MCM en un lado y no en el otro?

“Sí, definitivamente puedo ver eso”, dijo David Wang, “una de las razones la acabamos de hablar, una carga de trabajo es mucho más escalable y tiene diferente sensibilidad en la comunicación multi-GPU o multi-die. En comparación con la otra carga de trabajo o aplicaciones que son mucho menos escalables desde ese punto de vista. Así que sí, definitivamente puedo ver la posibilidad de que las arquitecturas comiencen a divergir”.

Es decir, vamos a tener a corto plazo dos soluciones por parte de AMD, una para la gama de computación que será en forma de MCM y la otra para el mercado doméstico que será monolítica. El caso es que esto choca con lo que la propia AMD «presento» unos días más tarde y esto puede llevar a confusión a mucha gente. Y lo pongo entre comillas porque de esto he hablado muy continuamente.

NoC2

Lo que quiere hacer AMD es convertir el Interposer Pasivo de ser un simple Crossbar Switch, utilizado actualmente por todos los sistemas integrados ya sean homogeneos o heteregeneos.

4_8

Donde su complejidad es n^2 donde n son todos los elementos dentro del SoC. Es decir, si yo diseño un procesador con 8 elementos internos que se han de comunicar entre si yo tendré que colocar un Crossbar de 64 nodos, solo que añade 1 más tendre que modificarlo para añadirle otro nodo. ¿El problema? El Crossbar Switch provoca puntos muertos porque el cableado es común por lo que hace falta un control de la logística de datos más avanzado. Es ahi donde entra el concepto de NoC y alto que esto se lleva una década hablando de ello en la industria.

NoC+Features+and+Advantages

¿Que es un NoC? Lo he puesto muchas veces pero como es importante en el contexto lo voy a poner de nuevo.

Network on chip o network on a chip (NoC o NOC) es un subsistema de comunicación en un circuito integrado tipicamente entre núcleos de propiedad intelectual (IP) en un SpC. Los NoC puede generar señales a velocidades de reloj sincronas y asincronas o utilizar lógica asincrona. Utiliza la teoría de redes y la metodología para la comunicación y trae importantes beneficios sobre los buses convencionales y las intercomunicaciones crossbar. Los NoC aumentan la escalabiliddad de los SoC y la eficiencia energética de los SoC complejos en comparacion con otros diseños.

Se trata por tanto de utilizar la clásica infraestructura de red como puede ser una red local, internet… De tal manera que tengamos en cada elemento de la red un router y que haya una cadena de routers intermedios que vayan pasando los datos en paquetes y los vayan distribuyendo.

Pues bien, por internet me encontre hace dias una noticia en concreto sobre un paper presentado recientemente por AMD.

Hay (al menos) un problema: Pese a que cada el sistema de enrutamiento en cada chiplet puede funcionar perfectamente, cuando se les conecta todos juntos a la red del interposer puede ocurrir la situacion donde una red intenta enrutar los datos de tal manera que se produzca un embotellamiento en el trafico de datos que termina bloqueando el sistema. «Puede ocurrir un punto muerto donde tengas que circular y circular diferentes mensajes, todos ellos intentando competir por el mismo tipo de recursos causando que todo el mundo tenga que esperar a todo el mundo» Explica Loh.

«Cada uno de esos (chiplets) individuales podrían ser diseñados para que nunca tuviesen puntos murtos» dice Loh «pero una vez los ponemos todos juntos, aparecen nuevos caminos y rutas que nadie había planeado de antemano.» Intentar evitar esos nuevos caminos diseñando los chiplets con un tipo de red interposer en concreto defendería las ventas de la técnica: Los chiplets, entonces no podrian ser diseñados y optimizados por equipos separados, y no se podrían mezclar y emparejar para formar nuevos sistemas. En el International Symposium on Computer Architecture que se realizo a principios de este mes, AMD presento una solución potencial a este problema.

untitled-5

El equipo de AMD ha encontrado que los puntos muertos en un interposer activo basicamente desaparecen si sigues una simples eglas diseñando «on-chip Netorks» Esas reglas gobiernan donde los datos tienen permitido entrar y salir y también restringen la información a donde pueden ir cuando entran por primera vez en el chip. Increiblemente, si sigues esas reglas puedes pretender que cualquier cosa este en el interposer, todos los chiplets lógicos, la memoria, la propia red de los interposers, todo. Es solo un nodo más de una red. Sabiendo que, equipos diferentes podrán diseñar chiplets sin tener que preocuparse sobre como las redes en otros chiplets funcionan o como los interposers activos funcionan.

Puede pasar algún tiempo antes de que este truco sea necesario. Pero los llamados interposers pasivos, aquellos que contienen interconexiones pero no circuitos de red, ya están en uso.

Esto no es nuevo, AMD lleva años hablando de tener un interposer activo que tenga un NoC en su interior encargado de llevar todo el cableado de comunicación. Esto no se debe confundir con el interposer de las AMD Vega, AMD Fury, Nvidia P100 y Nvidia V100 porque en ese caso el Interposer es el que se encuentra entre la memoria HBM2 y el controlador de memoria, pero en ese caso no tenemos  varias GPUs y CPUs comunicadas entre si en el sustrato/interposer. ¿Y con que me encuentro? Fijaos en la imagen de la cita que acabo de poner… ¿No os suena de algo? Bueno, os refrescare la memoria…

EHP

Es el mismo diagrama que el EHP, exactamente el mismo. AMD no lo había dicho todavía pero desde hacía tiempo que se sabía que el concepto era el de colocar un NoC en el Interposer y que este se encargue de la comunicación de todos los componentes entre si. Esto es el desacople de las funcionalidad y la logística, dejando que la transmisión de datos sea llevada por la infraestructura tipo NoC existente en el Interposer. Pero hay un pequeño detalle del que nadie se ha fijado y que es importante.

En la ilustración de la cita hay un detalle que nos dice como AMD ha solventado el problema. Re-organizando la GPU (Chiplet) de tal manera que utilice un NoC para su comunicación interna.

GPUNoC

¿Y para que sirve esto? Pues de esta manera se convierten en extensiones a la red del Interposer activo y se pueden comunicar, dejar de estar aisladas las partes por estar en chips diferentes, la Cache L2 pasa a ser completamente coherente y el sistema de memoria se unifica de tal manera que los GPU Chiplets son vistos en conjuntos a ojos del software como una sola entidad que aparte comparten memoria con otro tipo de dispositivos. Tenemos con ello por tanto un MCM con acceso con coherencia a la memoria. Esto no es lo mismo que el Crossfire, esto hace que a ojos de los desarrolladores y de los programas los diferentes Chiplets actuen como si fuesen un único procesador en vez de varios por lo que las reticencias de los desarrolladores de videojuegos desaparecerían.

Las GPUs actuales utilizan un Crossbar Switch al mismo nivel, la ventaja de colocarlo en un Interposer por debajo es que puedes crear en ese interposer una comunicación en matriz que te de un ancho de banda enorme e incluso puedes optar por una comunicación en matriz 3D.

NoC+Architectures+■+Variants+of+NoC+architecture

Lo que te da un ancho de banda inmenso. ¿Y como es que necesitamos semejante ancho de banda? Uno de los papers recientes de AMD comenta acerca de la idea de tener que comunicar una ingente cantidad de núcleos con un procesador «ficticio»para ilustrar el problema y la limitación de tener un NoC 2D.

Para hacer el problema más concreto, consideremos un sistema como el de la Fig 3(a) con cuatro pilas de memoria y un procesador de 64 núcleos.

Fig(a=(.PNG

Vamos a utilizar el ancho de banda previo estimado de 128 GB/s por pila (512 GB/s en total). Además, el sistema también soportaría multiples canales de memoria externa (por ejemplo DDR3, DDR4)con multiples pilas de memoria. Es poco probable que todo el sistema de memoria entero sea provéido por la RAM apilada. Asumiremos cuatro canales de memoria DDR4 operando a ∼21 GB por canal o ∼83 GB/s en total.

En nuestro primer escenario, consideramos una aplicación bien equilibrada donde el trafico de memoria en cada procesador es uniformemente extraido en origen de cada pila de memoria y de los canales dememoria externa. Más especificamente, cada una de las pilas de 128 GB/ se deverán dividir entre los diferentes núcleos (Unos 2GB/s por núcleo  por pila). De la misma manera cada canal de memoria externa de 21GB/S se divide en 0.32 GB/s por nucleo por canal.

FigB.PNG

La Fig 3(b) ilustra como 32 núcleos a la derecha consumiran 64GB/S de ancho de banda de cada de las pilas de memoria de la izquierda más otros 10GB/s de cada nivel de memoria. Esto significa que el NoC subyacente (En el Interposer) tendrá que soportar unos 148 GB/s en esa bisección para no ser un cuello de botella.

Además, el tráfico de los nucleos a la izquierda será simétrico, por lo que la interconexión debe dar soporte a ∼148 GB/s en cada dirección a través de la biseccion. Para hacer las cosas peor, los número estimados aquí solo son los traficos de memoria en bruto. Se necesita ancho de banda eidiconal para la coherencia de cache entre los núcleos.

Las aplicacione reales en general no van a demostrar un acceso perfectamente uniformemente distribuido en los accesos a memoria.

FigC.PNG

La Fig 3 (c) nos provee un ejemplo en el otro extremo. En ese caso, todas los núcleos en el lado derecho reciben todo el tráfico de los recursos de memoria a la izquierda. Como tal, todo el tráfico de memoria a través de la bisección se dobla a los  ∼298 GB/s (y otra vez, podemos necesitar más ancho de banda a ser soportado para el tráfico de la coherencia de cache). En la práctica una aplicación real caera entre estos dos casos, pero el ejemplo nos sirve para ilustrar el rango de anchos de banda para que la interconexión no se convierta en un cuello de botella a la memoria.

Si habéis entendido el concepto veréis que la velocidad de comunicación que se requiere es enorme, la solución que da AMD es la de un interposer activo pero recuerda que dicho planteamiento tiene también sus problemas añadidos.

Con los interposers 3D, las posibilidad son más grandes en terminos de que las topologias 3D con los routers y el cableado tanto en el procesador como en las capas del interposer. Por ejemplo, una malla 3D puede ser implementada a través de todas las capas como se muestra en la Fig. 4 (a).

Fig4A.PNG

Sin embargo, los interposers activos también introducen nuevos desafios a la implementación de un NoC. Primero, como se ha mencionado antes, el interposer puede estar implementado en una tecnología (nodo) de una generación más antigua con tal de ser efectivos en cuanto a costes. Sin embargo, esto significa que las diferentes porciones del NoC serían implementadas con diferentes carácteristicas. Esto crea nuevos desafios a nivel de circuitos haciendo que todos los componentes operen a la misma velocidad (de otra manera, en el peor de los casos, la red entera ha de operar a la misma velocidad que el componente más lento). Con un interposer pasivo todos los componentes estan en la misma capa y todos tienen las mismas carácteristicas de rendimiento. Los dispositivos operativos de diferentes geneaciones pueden introducir también desafios relacionados con el consumo donde los elementos de generaciones más antiguos requieran funcionar a voltajes menos eficientes para alcanzar la velocidad deseada, lo que supone la distribucíón a dos niveles de voltaje. Pueden haber sobrecargas de latencia y de voltaje por los conversores de subida y bajada de voltaje.

¿La solución a ello? Pues crear el MCM de tal manera que todos los componentes esten pensados para formar parte de una misma red y la puedan extender. Esto significa que la comunicación interna de las GPUs y la de las CPUs se haga a través de un NoC que sirva com extensión de otras red ya existente, la cual se encontraría en el interposer.

¿Y que ocurre si a esto le aplicamos el concepto Chiplet?

Mientras que en los ejemplos anteriores hemos ilustrado un chip multi-núcleo monolítico apilado en un interposer, otro acercamiento es el de apilar varios chip chips en el interposer. Por ejemplo, en vez de un chip con 64 núcleos, cuatro chips más pequeños con 16 núcleos serían montados para proveer la misma capacidad de computación como se muestra en la Fig. 4(b) que seguramente sean más baratos por el mayor rendimiento de las obleas.

FIG4B

Sin embargo, esto complica el diseño del NoC, debido a que alguas de las comunicaciones núcleo a núcleo deben navegar a través del interposer. Esto puede llevar a topologias NoC asimétricas como la de la Fig. 4(b) con un enrutado más complejo y una mayor susceptibilidad a embotellamientos en la red

¿Que significa esto? Esto es un baño de realidad a los medios que se llenaban la boca de «Chiplets» todo el rato porque los ingenieros de la propia AMD reconocen que el hecho de dividir un sistema multinúcleo en partes añade latencias adicionales que hace que rindan mucho peor que la solución monolítica. Es decir, la idea de dividir la GPU en piezas más pequeñas es una idea de bombero, la idea de tener varias GPUs lo es también en el mercado doméstico porque nadie quiere trabajar con varias. ¿Entonces? La idea es la de una GPU monolitica encima de un interposer con un NoC en el mismo pero esto supone cambiar la organización interna de la GPU.

Lo que tenemos ahora a nivel de la arquitectura GCN es que cada Compute Unit comparte con otras 2 o 3 Compute Units el acceso a la Cache L1. Esto es para reducir la complejidad de las interconexiones.

Una evolución lógica para AMD sería mover la Cache L1 a cada Compute Unit, y comunicar la CU+L1 con la Cache L2 no en horizontal sino en vertical haciendo que la Cache L2 se encuentre en el sustrato/interposer en una configuración 3D NoC. Lo que supone una re-organización en si misma en la que las GPUs pasarían a estar formadas por elementos diferenciados. Para que la gente lo entienda, en un sistema con unas 64 CUs por ejemplo donde se comparte la Cache L1 entre 4 CUs el ancho de banda total con la cache L1 es de:

(64 CUs/4 CUs por Cache L1)*64 Bytes/ciclo= 1024 bytes ciclo

De la otra manera:

64 CUs*64 Bytes/ciclo= 4096 bytes ciclo

Debido al ratio de la Cache L1 con la Cache L2 de la GPU el ancho de banda de estas aumentara. ¿Pero para que queremos semejante ancho de banda? Pues porque con los 4K y la VR combinados que veremos en unos años el ancho de banda necesario para los ROPS va a subir de una manera que asusta realmente.

1.PNG

Esto significa aumentar el número de ROPS en cantidades ingentes… ¿Primer problema? Ni la GDDR6 puede otorgar esos anchos de banda. ¿Como lo solucionamos? Enchufando los ROPS a la Cache L2…

VegaL2Cache

¡Pero eso limita la cantidad de RBE/ROPS que queremos tener! ¿La idea? Muy posiblemente no solamente tener Cache L1 por cada CU sino también un RBE… ¿Pero es necesario? Precisamente algo mucho más efectivo que los RBE/ROPS es lo que comente hace unos días y que es típico de los Tile Renderers, el Pixel Local Storage. Con la Cache L1 en la Compute Unit y el concepto del PLS combinados podemos hacer que el pipeline de comunicación no escriba a los ROPS/RBE sino a la Cache L1 y esto facilita enormemente la comunicación computación-gráficos permitiendo intercomunicar las diferentes etapas. Dicho de otra manera, con ello eliminas los RBE/ROPS para siempre por el hecho que trasladas la L1 a nive del CU te permite escribir el resultado sobre la misma sin problemas en el pipeline gráfico permitiendo pasar muy rapidamente al post-procesado sin tener que tocar la memoria externa para luego tener que recuperar el dato de nuevo.

Pero de esta última parte no están hablando estos últimos días pero es lo que se llega por deducción lógica, bueno, reconozco que más bien es una suposición mía viendo a como van  a ir las cosas a medio/largo plazo. Hay que tener en cuenta que la GPU mencionada en el EHP esta pensada para más allá de 2020 por lo que no estoy hablando de Navi que sería el punto y final a la arquitectura GCN sino de algo que va más allá, de ahí a que la entrada se llame GPU 2020

¿Pero es todo esto viable más allá de la teoria?

El mes pasado TSMC presento un tipo de integración de circuitos en 3D llamada Wafer on Wafer Technology.

En su 24 Simposió Anual de Tecnologia en Santa Clara, TSMC anuncio su tecnologia Oblea-sobre-Oblea Wafer-on-Wafer (“WoW”), la cual puede una bendición para el rendimiento de las GPUs de la misma manera que el apilamiento vertical ha mejorado la fabricación en las DRAM y su rendimiento. La tecnología como el nombre sugiere, apila capas de lógica una encima de la otra utilizando interconexiones de vias a través de silicio (TSV). Con el limitado espacio lateral en los Wavers, la tecnología WoW debería permitir chips más grandes con mayor densidad de area en el mismo espacio utilizando interconexiones de alta velocidad y baja latencia.

¿Y que tiene que ver? Pues precisamente TSMC no haría una tecnología así si no tuviese clientela dispuesta a utilizarla porque TSMC no diseña chips sino que los fabrica. El concepto no sería otro que tener en una oblea lo que son las unidades de ejecución y en la otra el Interposer con el NoC y sería a través del TSV (que realmente sería la malla 3D del NoC). Es decir, el core en la parte superior y el uncore en la parte inferior, más o menos (esto es de manera ilustrativa) así:

3DLogic

Todo esto concuerda con los papers presentados por AMD en los últimos años, todo esto tiene sentido y va en contra de los «Chiplets» los que continuamente han ido hablando los medios y que como mucho veremos en el mercado de la computación de alto rendimiento pero fuera de las GPUs convencionales, no lo veremos en Navi lo de los Chiplets, tampoco en la GPU con la nueva arquitectura por los motivos que he comentado antes, al menos a nivel doméstico que es el gaming.

¿El objetivo? Los 4K120hz que van a ser posibles con el HDMI 2.1. Mientras que las consolas se moveran al UHD, el PC que siempre va un paso por delante se moverá a la VR UHD. Y alto que esto no va a ser un camino que tome solamente AMD sino que Nvidia va detrás. En realidad todas las compañías van detrás de esto y esto va a cambiar el paradigma, solo que AMD esta siendo la más vocal sobre esto.