codepixel - GPU Architecture: Implications & Trends

David Miraut

| 193.147.61.xxx | 2008-08-21 13:32:57

Hola,

Es una pena que estas transparencias estén sin comentar, pueden dar lugar a pequeñas confusiones :-( espero no liarlo más con esta explicación rápida.

De la evolución y herencia de los procesadores streaming de los años 80/90 se puede leer una introducción bastante buena -aunque un poco antiquada- en el capítulo 15 del libro de Tomas Akenine: Real Time Rendering (la segunda edición con la portada del camaleón, en la tercera edición está un poco más desperdigado ¿capítulo 18?)

Hace unos años (2002-03) los procesadores de vértices y fragmentos eran notablemente diferentes, no sólo en su modo de acceder a los datos, también en el juego de instrucciones a "ejecutar" (el porqué de las comillas es muy largo de contar) y especialmente en la precisión de los cálculos que realizaban. Esta decisión de diseño fue debida a que en aquella época, las escenas a renderizar solían tener un numero drásticamente menor de primitivas (tríángulos) que de fragmentos (píxeles potenciales que al final podían o no acabar en el framebuffer), dado que en las últimas etapas del cauce se tenía que procesar un volumen de datos mayor y comenzaban a darse ciertas facilidades para su "programación" se decidió que lo más sencillo era establecer un cauce fijo en que los datos fueran "evolucionando".
Imaginaros un cauce segmentado gigante por el que circulan datos en lugar de instrucciones, o una cadena de montaje de coches, la etapa más lenta establece el ritmo al que se pueden sacar los resultados. Por esa razón se puso un número menor de procesadores de vértices (para los cálculos de transformación e iluminación de los vértices) y notablemente mayor de fragmentos (que ocupaban un área mayor del chip) para balancear la carga de forma fija.
La tecnología de integración fue mejorando con el tiempo y al poder poner más transistores en el mismo área también se pudieron mejorar las capacidades de los procesadores de fragmentos (sobretodo la precisión de sus unidades de coma flotante), por otro lado con el shader model 3.0 se abría la posibilidad de que los procesadores de vértices accedieran a memoria de vídeo (antes sólo podían "reaccionar" a los datos que le llegaban por el cauce), con lo que ambos tipos de procesadores se fueron pareciendo cada vez más.

La carga de los procesadores de uno y otro tipo, que inicialmente se había pensado para la representación de escenas estandar (de ahí que los recursos fuesen fijos) quedó obsoleta a a medida que los efectos gráficos se han ido sofisticando y el número de vértices y efectos de luces aumenta. Era muy difícil pedir a los programadores que adaptaran dinámicamente la complejidad de la escena a en función de los requerimientos y la carga en la tarjeta. La aparición de nuevas funcionalidades en el cauce en forma de una nueva etapa programable -la de grometría- en el el shader model 4.0, hacía las cosas aún más complicadas desde el punto de vista de balanceo de carga con un cauce con recursos "fijos", ya que muchos de los procesadores podían estar completamente idle mientras que otros estarían saturados, enlenteciendo la salida el cauce. Este fue el factor que impulsó la aparición de la arquitectura unificada, algo que se veía venir con esta convergencia de las capacidades de ambos tipos de procesadores. Supongo que esto es lo que comentó David Luebke al final de la presentación o en las preguntas, ya que hay unas transparencias al respecto al final del PDF, es una pena que todavía no podamos tener el vídeo de la conferencia :-(

Era un reto muy dificil desde el punto de vista de arquitectura, ya que se rompe el modelo streaming (de comunicaciones locales, tipo productor-consumidor) para pasar a un modelo de paralelismo many-core en el que el gasto energético y la latencia en el acceso a los datos se disparan debido a que todos los procesadores pueden acceder en lectura y escritura a la memoria de sistema. La forma en la que se ha tratado de paliar es mediante una sofisticada jerarquía de memoria, unos buses un tanto especiales y sobretodo un sistema ligero que permite ejecutar muchos threads simultáneamente en cada multiprocesador (de modo que siempre haya que ejecutar cuando otros están a la espera de un dato), pero es otra historia.

Con un único tipo de (multi)procesadores este problema de balanceo de carga se alivia, ya que en función de los requerimientos de cada frame a representar se dedican más o menos recursos a cada etapa.

El concepto de "thread" de la arquitectura unificada actual está ligado al modelo de computación paralela SPMD -> un sólo programa multiples datos. Se remonta a la aparición de la serie 8 de nVIDIA, aunque lo intenten vender de nuevo como algo nuevo y nos pueda dar la impresión de que es propio de las GT2X0.

La parte más confusa de las transparencias es lo que han llamado SIMT...
El SIMT tiene que ver con el conceto de warp y el compromiso entre integrar unidades de proceso completas y ejecutar código muy parecido para datos que tienen una misma estructura (como pasa en SPMD). SPMD es un modelo muy cómodo y fácil de adaptar en el render de gráficos en tiempo real, ya que muchos de los datos se tratan de forma casi idéntica (se les aplica el mismo programa/shader), digamos que tenemos un mismo programa que se ejecuta muchas veces ó en distintas unidades, una vez por cada dato que tenemos -> lo podemos dividir en threads con muchísima facilidad. Por ello no parece que tenga mucho sentido gastar espacio y transistores en duplicar las unidades de control si básicamente van a tener que decodificar la misma instrucción una y otra vez; sobretodo si esos transistores se pueden invertir en meter más FPUs... no hay que olvidar que el chip que lleva el GTX280 es el más grande que se haya comercializado nunca (1400 millones de transistores) y que por mucho que venga ayudado por la tecnología de integración tiene un coste de fabricación muy alto (a más transistores también más probabilidad de que falle alguno y tengan que tirar el chip) además del consumo no sólo cuando calcula sino también por las corrientes de fuga.

De modo que en nVIDIA decidieron agrupar los procesadores en grupos de 8, cuya unidad de decodificación de instrucciones está separada, de modo que los 8 procesadores ejecutan la instrucción que les "masca" esta unidad al unísono. Esta separación permite mayor grado de sofisticación en la unidad de decodificación, que tiene mecanismos de marcación y gestión de bloques de threads para asegurarse de que la próxima instrucción a ejecutar tiene los datos listos en sus registros y no va a producir ningún bloqueo. Aunque la caché de instrucciones es muy rápida y estas operaciones se van haciendo en paralelo, lleva cierto tiempo y tampoco parece demasiado horrible que la granularidad en la ejecución no sea de 1 ciclo, por lo que se hacen grupos de 32 hebras/threads -los llamados warps- y se procesa una nueva instrucción en 32 hebras cada 4 ciclos. Las unidades de acceso a memoria de video y las cachés también están compartidas, lo que permite un buen ahorro de transistores y la posibilidad de establecer mecanismos baratos de sincronización entre grupos "cercanos" de threads.

Respecto a lo que comentas de "hace cosas como ejecutar todas las opciones y quedarse con la correcta" es más o menos así, los multiprocesadores evalúan las condiciones, si no se cumple para todo el grupo de 32 hebras (el warp) se ve obligado a hacer predicación y tiene que ejecutar ambas ramas de un if-else para luego aplicar los cambios de acuerdo con una máscara (para ello tiene registros extras que no son accesibles de forma directa). Si se programa bien se puede evitar la pérdida de rendimiento debido a esta forma de hacer las ramificaciones, que por otra parte es MUCHO más eficiente que lo que teníamos antes de la arquitectura unificada.

Por último solo puntualizar que los chips gráficos que han sido diseñados bajo el paradigma de arquitectura unificada ya no son streaming (salvo algunas partes configurables "no programables"), y han pasado a la arquitectura Von Neumann, con memoria de instrucciones, lo que les permite mayor flexibilidad con el tamaño de los programas, que ya no tienen que ser shaders pequeñitos. De hecho en una 8800GTX no hay problema para meter programas de casi 2 millones de instrucciones, lo cual da cierta idea de lo grande que pueden ser (aunque puede no ser interesante si eso enlentece una determinada etapa excesivamente debido a la longitud del código a ejecutar).

No me quiero hacer el listo, me falta mucho por aprender y descubrir de esta materia, pero si tenéis curiosidad, podéis ver el material que tengo en la asignatura del máster de informática gráfica del la URJC, o veniros algún día por allí. nVIDIA, AMD & Cia (¿Intel?) no van a dejar que me aburra ningún año, me van a tener haciendo transparencias nuevas cada año :-) (éste le tome prestadas unas pocas a David Kirk).

Citar