¿Cómo funciona una tarjeta gráfica gaming si su GPU tiene chiplets?

La arquitectura que tratamos en este artículo no se encuentra todavía disponible en el mercado, ni tan siquiera ha sido presentada, pero es producto de un análisis de los avances producidos en los últimos años, así como de las diferentes patentes sobre las Multi-GPU chiplets que tanto AMD, NVIDIA e Intel han ido publicando en los dos últimos años. Es por ello que hemos decidido coger esa información y sintetizar para que tengáis una idea de cómo funcionan este tipo de GPUs y que problemas gráficos vienen a solventar.

Renderizado 3D tradicional con múltiples GPU

El utilizar múltiples tarjetas gráficas para combinar su potencia para renderizar cada fotograma en los videojuegos en 3D no es una novedad, desde las Voodoo 2 de 3dfx que es posible dividir el trabajo de renderizado, total o parcialmente, entre varias tarjetas gráficas. Siendo la forma más habitual de hacerlo el Alternate Frame Rendering, donde la CPU envía la lista de pantalla de cada fotograma de manera alterna a cada GPU. Por ejemplo que la GPU 1 se encargue de los fotogramas 1, 3, 5, 7, mientras que la GPU 2 se encarga de los fotogramas 2, 4, 6, 8, etc.

Existe otra forma de renderizar una escena en 3D que es el Split Frame Rendering, la cual consiste en que varias GPU renderizan una sola escena y se reparten el trabajo, pero con los siguientes matices: una GPU es la GPU maestra que lee la lista de pantalla y se encarga de manejar el resto. Las primeras etapas del pipeline, previas al rasterizado, se realizan en exclusiva en la primera GPU, en cuanto al rasterizado y las etapas posteriores estás se realizan de manera equitativa en cada GPU.

El Split Frame Rendering parece una forma equitativa para repartir el trabajo, no obstante, ahora veremos cuáles son los problemas que este método conlleva y con qué limitaciones se encuentra.

Limitaciones del Split Frame Rendering y la solución

Cada GPU contiene 2 colecciones de unidades DMA, el primer par pueden leer o escribir de manera simultánea datos en la RAM del sistema a través del puerto PCI Express, pero en muchas tarjetas gráficas con soporte Crossfire o SLI existe otra colección de unidades DMA, las cuales permiten acceder a la VRAM de la otra gráfica. Eso sí, a la velocidad del puerto PCI Express, lo cual supone un auténtico cuello de botella.

Lo ideal sería que todas las GPU que trabajan en conjunto tuvieran el mismo pozo de memoria VRAM en común, pero no es así. Por lo que los datos están duplicados tantas veces como la cantidad de tarjetas gráficas que participan en el renderizado, lo cual es sumamente ineficiente. A esto hemos de añadirle la forma en la que las tarjetas gráficas funcionan a la hora de renderizar los gráficos en 3D a tiempo real, lo cual ha provocado que la configuración con tarjetas gráficas múltiples ya no se utilice.

Tile Caching en una Multi-GPU por chiplets

El concepto del Tile Caching empezó a utilizarse a partir de la arquitectura Maxwell de NVIDIA y de la arquitectura Vega de AMD, se trata de tomar algunos conceptos del renderizado por tiles, pero con la diferencia que en vez de renderizar cada tile en una memoria aparte y solo escribirlo en la VRAM cuando este está acabado se hace sobre la caché de segundo nivel. La ventaja de esto es que permite ahorrar en el coste energético de algunas operaciones gráficas, pero la desventaja es que depende de la cantidad de caché de último nivel que haya en la GPU.

El problema es que una caché no funciona como una memoria convencional y en cualquier momento y sin control del programa una línea de caché puede ser enviada hacía el siguiente nivel de la jerarquía de la memoria. ¿Qué ocurre si decidimos aplicar la misma funcionalidad a una GPU basada en chiplets? Pues es aquí donde entra el nivel de caché adicional. Bajo el nuevo paradigma la caché de último nivel de cada GPU es ignorada como memoria para el Tile Caching y pasa a utilizarse la caché de último nivel de la Multi-GPU, la cual se encontraría en un chip aparte.

La LCC en una Multi-GPU por chiplets

La caché de último nivel para Multi-GPUs basadas en chiplets reúne una serie de características comunes que son independientes a quien sea el fabricante, por lo que la siguiente lista de características se aplica a cualquier GPU de este tipo, independientemente de cuál sea el fabricante.

• No se encuentra en ninguna de las GPU, sino que es externa a ellas y por tanto está en un chip aparte.
• Utiliza un interposer con una interfaz de muy alta velocidad como un puente de silicio o interconexiones TSV para comunicarse con la caché L2 de cada GPU.
• El alto ancho de banda necesario no permite interconexiones convencionales y por tanto sólo es posible en una configuración 2.5DIC.
• El chiplet donde se encuentra la caché de último nivel no solamente almacena dicha memoria, sino también es donde se encuentra todo el mecanismo de acceso a la VRAM, que de esta manera queda desacoplado del motor de renderizado.
• Su ancho de banda es mucho más alto que el de la memoria HBM, es por ello que hace uso de tecnologías de interconexión 3D más avanzadas, que permiten anchos de banda mucho más altos.
• Además, como toda caché de último nivel tiene la capacidad de dar coherencia a todos los elementos que son clientes de la misma.

Gracias a esta caché se evita que cada GPU tenga su pozo de VRAM propio para pasar a tener uno compartido, lo que reduce enormemente la multiplicidad de los datos y elimina los cuellos de botella que son producto de la comunicación en una multi-GPU convencional

GPU maestra y subordinadas

En una tarjeta gráfica basada en una Multi-GPU por chiplets sigue existiendo la misma configuración que en una Multi-GPU convencional a la hora de crear la lista de pantalla. Donde se crea una sola lista, que recibe la primera GPU que se encarga de gestionar al resto de GPUs, pero la gran diferencia es que el chiplet LLC que os hemos comentado en la sección anterior permite que la primera GPU pueda coordinar y enviar tareas al resto de unidades de proceso de la multi-GPU por chiplets.

Una solución alternativa es que todos los chiplets de la Multi-GPU vayan a carecer por completo del Procesador de Comandos y este se encuentre en la misma circuitería que donde se encuentra el chiplet LCC como director de orquesta y aprovechando toda la infraestructura de comunicación existente para enviar los diferentes hilos de instrucciones a diferentes partes de la GPU.

En el segundo caso no tendríamos una GPU maestra y el resto como subordinadas, sino que todo el circuito integrado 2.5D sería una sola GPU, pero en vez de ser monolítica estaría compuesta por varios chiplets.

Su importancia para el Ray Tracing

Uno de los puntos más importantes a futuro es el Ray Tracing, el cual para funcionar requiere que el sistema cree una estructura de datos espacial sobre la información de los objetos para poder representar el transporte de la luz. Se ha demostrado que si dicha estructura está cercana al procesador la aceleración que sufre el Ray Tracing es importante.

Eso sí, dicha estructura es compleja y ocupa mucha memoria. Es por ello que en el futuro será sumamente importante tener una caché de LLC de gran tamaño. Y este es el motivo por el cual la caché LLC va a ir en un chiplet aparte. Para tener la mayor capacidad posible y hacer que dicha estructura de datos esté lo más cercana posible a la GPU.

A día de hoy buena parte de la lentitud en el Ray Tracing es debido a que muchos de los datos se encuentran en la VRAM y existe una enorme latencia en su acceso. Hay que tener en cuenta que la caché LLC en una Multi-GPU tendría las ventajas no solo en ancho de banda, sino también de latencia de una caché. Además, su gran tamaño y las técnicas de compresión de datos que se están desarrollando en los laboratorios de Intel, AMD y NVIDIA harán que la estructuras BVH que se utilizan para la aceleración se puedan almacenar dentro de la memoria «interna» de la GPU.