La división del trabajo se define como:

La división del trabajo es la fragmentación o descomposición de una actividad productiva en tareas más elementales, así como su reparto entre diferentes personas, según su fuerza física, habilidad y conocimientos.

Este concepto se ha producido en el mundo de lo microprocesadores con la segmentación donde a la hora de procesar una instrucción cada paso del procesamiento era llevado por una unidad distinta de manera secuencial de tal manera que el la pieza encargada de la étapa anterior no tiene que esperar a completar la anterior instrucción al 100%.

La segmentación mejoro enormemente tanto el IPC como el CPI de los procesadores, pero no solo es aplicable a nivel de instrucciones sino en pipelines enteros como es el pipeline gráfico haciendo que cada parte del pipeline gráfico sea realizada por una parte distinta de la GPU.

Pese a que las partes «programables» son hechas todas desde las mismas unidades, las llamadas unidades shader, todo sigue una secuencia ordenada completamente segmentada donde ocurre como con las CPUs segmentadas, no se ha de esperar a que se termine de procesar un grupo de primitivas en forma de píxeles en pantalla para empezar a procesar las siguientes primitivas.

Pero la segmentación es eficiente para optimizar el código en serie, hay otro tipo de código que va por divisíón de trabajo que es la paralelización, que es el hecho de procesar varios datos al mismo tiempo, las GPUs son expertas en eso, pero no todo el código se puede paralelizar y es ahí donde entra la ley de Amdahl.

En las CPUs ocurre que el hecho de ir aumentando los núcleos y/o los hilos de ejecución esta muy bien pero nos encontraremos con que lo que ocurrirá es que a medida que aumentemos la cantidad de núcleos para la parte paralelizable esta se resolverá cada vez en menos tiempo pero la parte secuencial se mantendrá por lo que llegará un punto en que añadir más núcleos/hilos no aumenta el rendimiento sino que disminuirá el rendimiento aportado por núcleo.

Las GPUs lo que hacen es trabajar con multitud de primitivas en paralelo en cada étapa del pipeline, vertices, fragmentos no texturizados, fragmentos texturizados… Todos ellos en cantidades ingentes lo que les convierte en el tipo de núcleo más paralelizable y con un rendimiento pésimo para el código secuencial.

Lo que significa que podemos tener grandes cantidades de núcleos e incluso de procesadores que se repartan las mismas tareas para diferentes datos.

Un metodo de paralelización multinúcleo fue el llamado SLI de 3Dfx para sus Voodoo donde en un monitor CRT VGA una tarjeta dibujaba las lineas de escaneo pares y la otra las impares, dividiendose así el trabajo. Con la llegada de los LCD esa tecnica quedo desfasada y se obto por alternar fotogramas entre las dos o varias GPUs pero de manera segmentada, en que cada GPU se encargaba de un fotograma al completo.

Hasta la llegada de DX12 esto fue un infierno para los programadores por el problema de manejar dos pozos de memorias,uno para cada GPU, y estar coordinando entre ambas, con DX12 se permitio utilizar un direccionamiento común entre ambas y trabajar ambas en paralelo realmente dividiendose un mismo fotograma.

Pero poca gente tenía una configuración con doble tarjetas en sus PCs. Esto llevo a que AMD eliminase la funcionalidad de doble tarjeta en sus modelos y desapareciese. Lo cual teniendo en cuenta el posible advenimiento del Cloud Gaming sorprende enormemenente por el hecho que dividir en partes un fotograma y asignar una parte a cada GPU disminuye la latencia por fotograma, lo cual es crucial para el Cloud Rendering donde la latencia añadida por la red le da menos tiempo total a la GPU para renderizar.

Y por favor, que nadie me diga que Stadia, que no deja de ser un vulgar PC es el hardware adecuado para el Cloud Gaming…

… que no es más que un PC en el fondo y por tanto no una buena solución para solventar el problema, porque no lo es, solo hay que ver sus especificaciones que son las de un vulgar PC, eso si, con un SO a medida que necesita juegos a medida, pero nada más.

¿Entonces existe una solución al handicap de la latencia? La hay y precisamente desde hace unas semanas que quería comentar esto, se trata de una serie de patentes que si que van a hacer posible lo que es lo que podríamos llamar CGPU (Cloud GPU) pero las he de ir comentando una por una, ¿el motivo por el cual he hablado de la división del trabajo? Ahora lo entenderéis, vayamos para eso a la primera patente.

Veamos lo que dice la patente de la FIG. 2…

Pasando ahora a la FIG. 2, se muestra un diagrama de bloques de otra realización de un sistema informático 200. El sistema informático 200 es otro ejemplo de un sistema que puede implementar las técnicas descritas aquí para mejorar la localidad de datos para unidades de procesamiento distribuido. Como se muestra en la FIG. 2, el sistema 200 incluye una pluralidad de pilas de computación 210A-N acopladas a un procesador de comandos 205. Las pilas de computación 210A-N son representativas de cualquier número y tipo de pilas de computación.

En una GPU el Procesador de Comando esta en la parte central del chip, no solo en las de AMD sino que es independiente a la marca de la GPU, pues bien, en este caso tenemos una GPU dividida en chiplets pero donde el elemento central es el procesador de comandos, el cual reparte entre los diferentes chiplets el renderizado de una pantalla, donde cada chiplet se encarga en paralelo de una parte distinta del fotograma. ¿Y todos esos chips apilados? Pues se trata de una GPU con memoria apilada encima, una configuración 3DIC más que 2.5DIC, a la cual se hace referencia en otra patente.

La idea de apilar memoria encima de las GPUs en formato 3DIC utilizando vias a través de silicio (TSV) ya lo probo AMD con GCN e incluso público resultados en el paper del EHP, un motivo de diseñar la arquitectura RDNA es precisamente su experimentación con este tipo de memorias a la hora de probarlas con la arquitectura GCN donde no podían alcanzar ciertas velocidades de reloj.

La base de la pila es la GPU misma, el siguiente piso es el uncore de la GPU así como la interfaz de memoria y el resto son los chips de memoria apilados conectado vía TSV, por lo que cada pila es una GPU con su memoria pero quitando el procesador de comandos, el cual estaría en un chiplet aparte. ¿Que ventaja tiene tener la memoria tan junta? Pues reduce la latencia de las operaciones sensibles a la misma.

En realidad la ventaja de esto es poder montar una MegaGPU pudiendo superar sin problemas los límites de la retícula del chip, es algo que a nivel de economía de escala es imposible en un sistema doméstico, pero en un servidor basado en el Cloud Gaming dentro de un mainframe tiene mucho sentido.

Gracias a ello podemos tener ingentes cantidades de Compute Units en el sistema que de otra manera serían imposibles, la siguiente imagen es antigua pero el hecho de tener 320 o 384 Compute Units es algo que hace que el tiempo de resolución de cada fotograma disminuya enormemente hasta el punto de eliminar por completo el problema de la latencia en el caso del Cloud Gaming, entonces ya no haría falta que todo el mundo tuviese una GPU en su casa, se podría jugar de manera remota, pero eso si, con una configuración y una potencia que requeriría una infraestructura imposible en un sistema doméstico que es la parte negativa de todo ello, pero la idea del Cloud Gaming es dejar a mínimos el hardware que el usuario tenga en su casa, eso si, forzará al proveedor del servicio a gastar mucho más dinero que el que se debería gastar el usuario en un sistema local para que funcione el experimento, dinero que acabará siendo cargado en la tarjeta de crédito o a la cuenta bancaria de los que utilicen el servició.

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