1. No category

TEMA 2.1
ARQUITECTURAS
STREAMING Y
CAUCE GRÁFICO CLÁSICO
Curso 2013 / 14
Procesadores Grácos y Aplicaciones en Tiempo Real
Profesores: David Miraut y Óscar D. Robles
© GMRV 2005-2014 – Febrero 2014
Máster en
Informática Gráfica,
Juegos y Realidad Virtual
David Miraut Andrés
Escuela Técnica Superior
de Ingeniería Informática
Procesadores Grácos y Aplicaciones en Tiempo Real 2013/14
1/
1/3472
ÍNDICE
Historia de las tarjetas gráficas
Introducción al cauce grafico
Arquitecturas streaming
Evolución y procesadores streaming
El cauce gráfico en profundidad
Relación entre el cauce gráfico y la GPU
Lectura recomendada
Bibliografía
c
NOTAS:
Todas las marcas y productos mencionados
en estas trasparencias están registradas por
sus respectivas compañías, y su uso es de
carácter descriptivo con fines docentes.
Parte de las tablas y gráficos están basados en
las presentaciones de GPGPU y streaming
computing de NVidia y ATI-AMD, y en los
libros mencionados en la bibliografía
HISTORIA DE LOS
PROCESADORES
GRÁFICOS DE CONSUMO
(TARJETAS GRÁFICAS)
El mítico PONG
de Atari (1974)
NOTAS:
De la anterior:
En el cálculo en NO tiempo real nosotros programamos con total libertad, de
hecho se suelen hacer los “shaders”/funciones de acuerdo con las estructuras y
efectos que queremos representar (efectos de desplazamiento en la geometría,
modificaciones del comportamiento de la luz sobre la superficie, cálculo del
volumen y de la luz al atravesarlo... )
Mientras que en tiempo real, estos “shaders” deben programarse de acuerdo con
el punto en el que se encuentran dentro del cauce gráfico, hay una cierta libertad
pero está acotada por el tipo de datos que
podemos hacer fluir en ese cauce
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (I)
La idea es muy antigua:
Los ordenadores personales de los años 80 ya contaban con
procesadores separados y específicos para el tratamiento de
gráficos: Atari QT...
En aquella época había gran diferencia y rivalidad
entre consolas y ordenadores de 8 bits
Los PCs “ganaron” la batalla gracias a la reducción de precios
que supuso su arquitectura abierta, pero no porque tuvieran
mejores prestaciones gráficas (como el Atari o los Amstrad),
ni fueran más fáciles de utilizar (como los Apple).
Ni siquiera el producto nacional (DragonPC)
logró una mínima aceptación.
Pero en aquella época las necesidades
eran diferentes (2D, 256 colores...)
NOTAS:
Sumergirse en el mundo de las tarjetas gráficas da un poco de vértigo -- como
dice Manuel Ujaldón-- porque es un terreno en contínua metamorfosis.
Os recomiendo encarecidamente su libro, es el mejor (y el único) del que
disponemos no sólo en español, sino en cualquier lengua, hasta donde yo sé :-)
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (II)
Las tarjetas crecían en prestaciones lentamente
Hercules, EGA, VGA (modo X)...
mem. no lineal
aspect ratio 4:3
compromiso entre
resolución/colores
...
La evolución trajo consigo la guerra de las SuperVGA:
Mayor resolución y más colores
Un caos para los
Pero cada driver era completamente distinto desarrolladores
Los ordenadores no estaban concebidos
para el entretenimiento, sino para
aplicaciones ofimáticas, pero unos cuantos
“apasionados” se empeñaron
Demoscene
Ultima VI
The Stigian Abyss
NOTAS:
de juegos
El stadard VESA
no aprovechaba
todas las
características
ng
asti
c
y
a
(John Carmack) R 286
WolfStein 3D
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (III)
Las fases en la creación de gráficos 3D quedaron bien definidas
(Renderman) y se hicieron esbozos simplificados en el mundo
de los Pcs (los inicios de OpenGL)
Pero los procesadores de la época eran muy limitados
para generar imágenes de calidad en tiempo real.
La visión de 3DFX supuso una revolución, irrumpió en el
mercado con tarjetas de tal calidad que barrió literalmente
eran programables,
a todos los competidores (no
sólo aceleraban parte del cauce)
nVIDIA no tuvo otro remedio que adquirir 3DFX,
mediante una OPA, para sobrevivir. Absorvió a su
enemigo y aprovecho el know-how y sus ingenieros
para ponerse en la punta de lanza.
ATI ha hecho un esfuerzo notable
NOTAS:
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (III)
Las fases en la creación de gráficos 3D quedaron bien definidas
(Renderman) y se hicieron esbozos simplificados en el mundo
de los Pcs (los inicios de OpenGL)
Pero los procesadores de la época eran muy limitados
para generar imágenes de calidad en tiempo real.
La visión de 3DFX supuso una revolución, irrumpió en el
mercado con tarjetas de tal calidad que barrió literalmente
Nuevas alianzas: ATI-AMD
a todos los competidores
nVIDIA y los tablets
nVIDIA no tuvo otro
que adquirir
3DFX,
Intelremedio
en el mundo
de las GPUs
mediante una Microsoft
OPA, paraysobrevivir.
Absorvió
a su
la arquitectura
unificada
enemigo y aprovecho
el know-how(AGEIA,
y sus ingenieros
Tarjetas aceleradoras
para ponerse
en la punta
de “absorción”
lanza.
CausticTwo..)
y su
ATI ha hecho un esfuerzo notable
NOTAS:
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (IV)
OpenGL: Segal y Akeley ‘99
Reyes: Cook/Carpenter/Catmull ‘87
Renderman: Upstill ‘90, Apodaca y Gritz ‘00
Programabilidad y representación:
Shade trees: Cook ‘84
Pipeline programable: Olano ‘98
RenderMan en OpenGL: Peercy ‘00
OpenGL con streams: Owens ‘00
Lenguajes de Shading en tiempo real: Proudfoot ‘01
Smash: McCool ‘01 (API ligeramente basado en OpenGL)
NOTAS:
En el vídeo de la semana se habla largo y tendido de esto y muchas otras cosas.
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (IV)
SHADERS
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (V)
Tiempo
Real
Se suelen distinguir 5 generaciones en las GL-machines:
No confundir
generación
con serie
No
a l corr
Nv as s esp
idi eri ond
a ó es en
d
(que requerían grandes máquinas) AT e
I
Generación “cero”: Sistemas SÓLO SW
Sistemas puramente software
Utilizaban visualizadores vectoriales
El framebuffer era muy caro ( 20k$)
Simuladores de vuelo para combate (militar)
Al no ser HW ni squiera se
suele tener en cuenta a la
hora de contarlo, pero fue
un precedente importante
Evans and Sutherland SP1
(mediados de los años 70)
http://www.referenceforbusiness.com/history2/59/Evans-Sutherland-Computer-Corporation.html
NOTAS:
¿Por qué tanta insistencia con la historia?
En primer lugar para saber qué ha ocurrido, dónde estamos y hacia donde nos
movemos
En segundo lugar, y casi más importante:
Este campo avanza a una velocidad realmente meteórica, de un año para otro casi
hay que tirar las transparencias y esperemos que ATI-AMD no me dé un susto a
mitad de cuatrimestre. <es una forma de poder reciclar las transparencias>
Por ello hay mucha información en Internet, en los artículos y en los pocos libros
que hay, que ha quedado ya obsoleta. Y tenemos que ser consciente de ello para
poder discernir y no confundir conceptos que ya han cambiado. Es esencial mirar
la fecha de publicación de un artículo y ser muy crítico con lo que en ellos se
cuenta, para no hacernos una idea equivocada.
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (V)
Tiempo
Real
Se suelen distinguir 5 generaciones en las GL-machines:
No confundir
generación
con serie
Primera Generación: Gráficos alámbricos
No
a l corr
Nv as s esp
idi eri ond
a ó es en
AT de
I
Vértices: Transfomación, Clipping y proyección
Rasterización: Interpolación de colores (en lineas y puntos)
Fragmentos: Se sobreescribe
Época: entre 1982 y 1987
Sólo podía hacerse en
estaciones de trabajo
(workstations) muy
potentes de la época
Es la forma en la que en las
presentaciones de SGI suelen
explicar la evolución de los
gráficos por ordenador
NOTAS:
Ya se hacen los cálculos con coma flotante, no sólo con precisión fija (aritmética
entera) como estábamos obligados cuando todo era SW
Artículo histórico:
Jim Clark, “The Geometry Engine: A VLSI Geometry System for Graphics”,
SIGGRAPH ’82
En la tetera podemos ver que los segmentos más alejados se atenuaban en su
color, para que pareciera más lejano. (la tetera nos puede servir para apreciar los
avances tecnológicos)
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (V)
Tiempo
Real
Se suelen distinguir 5 generaciones en las GL-machines:
No confundir
generación
con serie
Segunda Generación: Polígonos con colores
sólidos sombreados
Vértices: Cálculo de iluminación
Rasterización: Interpolación de profundidad (triángulos)
Fragmentos: Buffer de profundidad, color blending
Época: 1987 - 1992
NOTAS:
Sólidos / primitivas “rellenas”
Hardware de rasterización y rellenado de polígonos
Iluminación por vértice
Sombreado Goraud (suave)
Sólo estaciones de trabajo
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (V)
Tiempo
Real
Se suelen distinguir 5 generaciones en las GL-machines:
No confundir
generación
con serie
Tercera Generación: Mapeado de Texturas
Vértices: Trasformación de las coordenadas de textura
Rasterización: Interpolación de las coord. de textura
Fragmentos: Evaluación de la textura y antialiasing
Época: 1992-2000
NOTAS:
Ya podemos aplicar texturas por fragmento !!
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (V)
Tiempo
Real
Se suelen distinguir 5 generaciones en las GL-machines:
No confundir
generación
con serie
Cuarta Generación: Programabilidad
Sombreado (shading) programable
Modelado Basado en imagen
Convergencia de los gráficos y el procesado de
2001 Programabilidad
señal en otras señales
2002 Punto Flotante
Superficies curvas
2004 - 2005 Ejecución condicional
NOTAS:
Ya tenemos hardware de consumo: tarjetas gráficas que se pueden comprar
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (V)
Tiempo
Real
Se suelen distinguir 5 generaciones en las GL-machines:
No confundir
generación
con serie
Quinta Generación: Evaluación Global
Ray tracing: visibilidad e integración
Photon Mapping, True Shadows, Path Tracing...
NOTAS:
LA (PRE)HISTORIA DE LOS
PROCESADORES GRÁFICOS (V)
Tiempo
Real
Se suelen distinguir 5 generaciones en las GL-machines:
No confundir
generación
con serie
Quinta Generación: Evaluación Global
Ray tracing: visibilidad e integración
Photon Mapping, True Shadows, Path Tracing...
Hay que tener muy en mente,
la evolución y sobretodo el objetivo
hacia el que nos movemos para
comprender las decisiones que se
reflejan en la arquitectura de las GPUs
NOTAS:
LA LÍNEA ENTRE TIEMPO REAL
Y OFFLINE RENDERING...
Se mueve cada vez más deprisa :-)
NOTAS:
Generational Improvements
Performance
• Triangles/second (geometry)
• Pixels/second (rasterization)
Features
• Hidden surface elimination, texture
mapping, antialiasing …
Quality
• Bits of resolution, filtering …
LA LÍNEA ENTRE TIEMPO REAL
Y OFFLINE RENDERING...
Pero queda mucho camino por recorrer...
“Reality is 80 million polygons.”
– Alvy Ray Smith, Pixar
NOTAS:
REPASO DEL
CAUCE GRÁFICO
Proceso de generación
de imágenes mediante
modelado geomético
1
( ) Existen otras formas de generar imágenes fotorrealistas
que se verán en la asignatura TAG3D
NOTAS:
PIPELINE ó CAUCE GRÁFICO (I)
Vamos a estudiar los pasos del proceso de síntesis de
de gráficos por ordenador más extendido en la actualidad:
el cauce gráfico
Todos sabemos ó intuimos que los artístas “esculpen” sus
modelos en programas CAD y que al final esto se convierte
en imágenes y animaciones realistas (e interactivas si estamos en un juego)
Introducción
Division
Conceptual
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
(3D Total)
De la descripción de una
escena 3D: polígonos que
forman la superficie de los
objetos, materiales, luces...
A una representación
2D convincente desde
un determinado punto
de vista
PIPELINE ó CAUCE GRÁFICO (I)
Vamos a estudiar la serie de pasos del proceso de síntesis de
de gráficos por ordenador más extendido en la actualidad:
el cauce gráfico
Todos sabemos ó intuimos que los artístas “esculpen” sus
modelos en programas CAD y que Pero...
al final esto se convierte
¿Qué
hay si estamos en un juego)
en imágenes y animaciones realistas
(e interactivas
en medio?
Introducción
Division
Conceptual
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
(3D Total)
De la descripción de una
escena 3D: polígonos que
forman la superficie de los
objetos, materiales, luces...
A una representación
2D convincente desde
un determinado punto
de vista
PIPELINE ó CAUCE GRÁFICO (II)
El cauce gráfico es el conjunto de transformaciones y procesados
de imagen que se realiza a los elementos que definen la escena
hasta llegar a la imagen resultante final.
Hoy día, el proceso de generación de imágenes sintéticas que
sigue el pipeline o cauce gráfico es maduro y bien definido,
y este estandar se ha reflejado en las principales APIs gráficas
(como OpenGL) e influye fuertemente en las arquitecturas de
Introducción las modernas tarjetas gráficas.
Division
Este cauce se divide en etapas de procesado, cada una de las
Conceptual
cuales toma como entrada la salida de la anterior, de ahí
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
el símil con un cauce, ya que los datos (no las instrucciones)
fluyen en su interior.
(como trozos de tubería)
etapa 3
etapa 1
etapa 2
PIPELINE ó CAUCE GRÁFICO (III)
El nombre de pipeline viene de un concepto de arquitectura,
ya que las tareas en las que se divide son lo suficientemente
independientes como para realizarse en paralelo (segmentación).
Algo parecido a cómo organizamos la colada cuando volvemos
de viaje y tenemos que poner varias lavadoras:
Introducción
Division
Conceptual
y Funcional
secar
secar
planchar
planchar
plegar
lavar
secar
NOTAS:
lavar
secar
plegar
lavar
planchar
secar
plegar
lavar
secar
planchar
plegar
Hacer tres tandas de lavadoras
es más rápido y aprovechamos
mejor los recursos si lo divid
ven e y
organizamos en paralelo cerás
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
planchar
plegar
planchar
plegar
Un Pentium IV apenas tiene 30-40 etapas
en su pipeline hipersegmentado, una
GeForce3 tiene entre 600 y 800
depediendo del camino que tome
el flujo de datos
DIVISIÓN CONCEPTUAL del CAUCE
Cada autor divide conceptualmente según su propio criterio
(en general se da más relevancia en el esquema a las etapas de transformaciones, aunque todas son igual de importantes)
libro de
S.R.Buss
Modelado
libro de
T. Akenine
Introducción GPU Gems2
R. Fernando
Division
Conceptual
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
Aplicación
Aplicación
Selección
de vista
División
por w
(perspectiva)
Geometría
Representación
Rasterizado
cada una de estas etapas es
también un pipeline en sí misma
Comandos
Geometría
Rasterización
Texturas
Fragmentos
Visualización
En esta parte de la asignatura vamos
a profundizar y ver cómo se implementan
en el hardware gráfico cada una de las
etapas. Pero es indispensable una buena
comprensión de las mismas, por lo que
no dudéis en preguntar cualquier cosa
en RA ó PGATR
ETAPAS del CAUCE GRÁFICO (I)
Tenemos una serie de etapas bien definidas en las que
la información “fluye” en orden de unas a otras
Pipeline gráfico ultra-simplificado:
Estado gráfico
Aplicación
Introducción
Division
Conceptual
y Funcional
Transformación
Vértices
3D
Rasterizado
Triángulos
proyectados
Sombreado
Fragmentos
(pre-píxeles)
Memoria
de video
(Texturas)
Píxeles finales
(color, profundidad)
(vértices 2D)
GPU
Render a textura
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
entran vértices
ordenados
Tres etapas principales
obtenemos
píxeles
Evidentemente todo puede hacerse por software
en procesadores de PC tradicionales, pero es
mucho menos eficiente
ETAPAS del CAUCE GRÁFICO (II)
ETAPA DE TRANSFORMACIÓN
Transforma las coordenadas de los vértices de los objetos
de su sistema local a su respectiva proyección 2D
Espacio
del
Objeto
Espacio
del
Mundo
Espacio
de la
cámara
Espacio
Visualizable
Espacio
de la
Ventana
Introducción
3D
Division
Además se calcula la iluminación en cada vértice
Conceptual
y Funcional
2D
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
Imágenes tomadas del libro
“The Cg Tutorial - The
Definitive Guide To
Programmable Real-Time
Graphics”
ETAPAS del CAUCE GRÁFICO (III)
ETAPA DE TRANSFORMACIÓN
Tenemos muchos vértices y sus posiciones (en principio)
no dependen unas de otras perfectamente paralelizable
Estas transformaciones han de ser muy flexibles y adaptarse
a las necesidades, no sólo un puñado de patrones fijos
debería ser programable
Introducción
Division
Conceptual
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
Imágenes tomadas del libro
“The Cg Tutorial - The
Definitive Guide To
Programmable Real-Time
Graphics”
Iluminación por vértices
ETAPAS del CAUCE GRÁFICO (IV)
ETAPA DE RASTERIZADO
Convierte la representación geométrica (vértices)
a una representación de imagen (fragmentos)
Los fragmentos pueden verse como píxeles “en potencia”
Fragmento = píxel + datos asociados
(potencial) (color, profundidad, pincel...)
Introducción Interpola las cantidades calculadas en cada vértice
Division
a lo largo de los “píxeles”
Conceptual
y Funcional
No es
programable,
por ahora...
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
Rasterizado
Vértices
Fragmentos
NOTAS:
Falta la etapa de geometría, pero eso lo veremos al hablar de la arquitectura
unificada
ETAPAS del CAUCE GRÁFICO (V)
ETAPA DE SOMBREADO
Básicamente, se calcula el color de cada pixel
Han de leerse imágenes de texturas (arrays de memoria)
Estas texturas llevan todo tipo de información (color difuso
sobre la superficie, normales, brillo...)
Introducción Es una tarea fácilmente paralelizable
Division
Ha de ser muy flexible: programable
Conceptual
Suele haber más pixeles
y Funcional
que vértices, y las
Aplicación
operaciones son más
Transformación
complejas
Etapas:
Rasterizado
Sombreado
NOTAS:
Mayor número
de procesadores
de fragmentos
Ya no tenemos el límite
en el número de fuentes
de luz, ni ningún otro...
ETAPAS del CAUCE GRÁFICO (V)
ETAPAS DE ELIMINACIÓN DE DATOS
Al fluir los datos en el cauce, no sólo son transformados de
unos tipos a otros, sino que además su volumen se multiplica.
Podemos imaginarlo como una reacción química en cadena.
Muchos de estos datos no son necesarios de una etapa a la
Introducción siguiente, y conviene eliminarlos tan pronto como sea posible
para no aumentar el coste computacional por su procesado
Division
Conceptual
y Funcional
Así tendremos numerosos test
entre etapas, para dejar pasar
Etapas:
sólo aquellos elementos que
Aplicación
nos interesen
Transformación
Rasterizado
Sombreado
NOTAS:
test
ARQUITECTURAS
STREAMING
(ó CIRCULANTES)
DIFERENCIAS CON
EL MODELO VON
NEUMANN
(1) En español se suele utilizar el término “circulante” en lugar
de flujo, para distinguirlo de otras nociones de arquitectura
NOTAS:
INTRODUCCIÓN
A pesar del vertiginoso aumento de rendimiento en las GPUs
apenas cambiaron su diagrama de bloques general hasta la
llegada de la arquitectura unificada (1)
Refleja la buena cimentación de la arquitectura. La base es
óptima en muchos aspectos y por eso también es escalable
Práctica inexistencia de cuellos de botella en su interior
(de existir, la arquitectura hubiera cambiado hace mucho tiempo)
Facilita su análisis, y nos permite hacer un estudio
general basándonos en los modelos comerciales
de la actualidad
(1) Aún después de la introducción de la Arquitectura Unificada
parte de las etapas del cauce se implementan mediante unidades
funcionales dispuestas según el modelo streaming
NOTAS:
MODELO DE VON NEUMANN
Tradicionalmente los PCs han seguido el modelo de Von Neumann
en el que las instrucciones se almacenan como datos y sus
operadores definen la forma en que se localizan dentro del HW
Esto situa el cuello de botella del PC en el acceso
a memoria, así las optimizaciones en la arquitectura
se han concentrado en reducir la latencia del acceso
individual a los datos (pero no en maximizar su ancho de banda)
NOTAS:
MODELO DE VON NEUMANN
Tradicionalmente los PCs han seguido el modelo de Von Neumann
en el que las instrucciones se almacenan como datos y sus
operadores definen la forma en que se localizan dentro del HW
Esto situa el cuello de botella del PC en el acceso
a memoria, así las optimizaciones en la arquitectura
se han concentrado en reducir la latencia del acceso
individual a los datos (pero no en maximizar su ancho de banda)
Ejemplo del Itanium 2:
Control, comunicaciones, caché...
6’5%
Una docena de ALUs para
aritmética entera un par de
FPUs para coma flotante
area del chip
(podemos considerarlo proporcional a
los transistores dedicados a cada tarea)
NOTAS:
NOTA: Esta comparación no es muy justa porque
el procesador Itanium tiene una arquitectura EPIC
-poco común-, pero nos sirve para tener un idea
respecto a un procesador que está por encima
de la media en capacidad de cálculo)
¿DÓNDE ESTÁ EL TRUCO? (I)
Los procesadores tradicionales (PCs)
son casi todo memoria caché
Pentium III 28,1 M Transistores
Bueno en tareas de control
Malo en procesado de grandes cantidades de datos
GeForce 6800 222 M Transistores
(384 M trts en GeForce 7900)
Aunque existen cachés y juegan
un papel importante, están
orientadas a texturas y la mayor
parte del chip se utiliza para
lógica computacional muy
específica para un flujo de datos
NOTAS:
MODELO DE VON NEUMANN
Tradicionalmente los PCs han seguido el modelo de Von Neumann
en el que las instrucciones se almacenan como datos y sus
operadores definen la forma en que se localizan dentro del HW
Esto situa el cuello de botella del PC en el acceso
a memoria, así las optimizaciones en la arquitectura
se han concentrado en reducir la latencia del acceso
individual a los datos (pero no en maximizar su ancho de banda)
Las aplicaciones gráficas, a pesar de tener unos operadores muy
sencillos son difíciles de programar en tiempo real debido al
gran volumen de información que hay que procesar.
En la última década este modelo se ha aferrado al paralelismo
de datos para poder permanecer vigente en este contexto, mediante
instrucciones SIMD como las orientadas a multimedia (MMX...)
Cualquier arquitectura basada en el patrón
convencional resulta claramente insostenible:
es necesario redefinir el modelo de computación
NOTAS:
MODELO de STREAMING
Si el cuello de botella está en los datos, ¿por qué desplazamos
las instrucciones por el cauce segmentado del procesador y
obligamos a que los datos vayan a su encuentro?
Parece más lógico que los que fluyan por ese cauce sean los
datos, que son la masa crítica del problema, y salir a la caza
de los operadores (instrucciones) que son pocos y simples.
(en el contexto de las aplicaciones gráficas)
RU
INT CCIO
N
DATOS
ES
RU
INT CCIO
Así
le
damos
DATOS
“la vuelta”
DATOS
DATOS
OS
DAT
al embudo
Colocando la parte más ancha en el lado de los datos
y dejando en el estrecho a las instrucciones, que como
en el caso de las GPUs serán cableadas directamente
sobre el HW (digamos que es como si lo configuraramos)
RU
INT CCI
NOTAS:
DAT
OS
ON
ES
N
ES
PROCESADORES DE STREAMS (I)
Veamos más en detalle esta nueva forma de plantear el problema
Antes: Proc. Tradicional
Conjuntos de datos no
conexos ni uniformes
Complejos diagrama
de control en función
de los resultados que
se van obteniendo
Ahora: Modelo de Streams
Streams (Flujos)
Conjuntos de datos con una
estructura bien definida
Todos los datos streams
Nombre explicativo
Kernels
Sus entradas/salidas son streams
Toda operación sobre los
streams se define/expresa
como kernel
Se pueden encadenar
NOTAS:
Aquí se puede hacer el símil con los procesadores sistólicos.
Haciendo hincapié en las diferencias de complejidad, enrutamiento de datos y
“latidos”
PROCESADORES DE STREAMS (II)
Tenemos dos tipos de “paralelismo”:
El propio pipeline hace que
muchas tareas se ejecuten en
paralelo
Se puede operar con muchos
elementos del stream en paralelo
stream
kernel
stream
La comunicación es muy eficiente:
Localidad entre el productor y
el consumidor
Patrón de acceso a memoria
muy predecible:
Minimizamos
el tráfico de memoria
NOTAS:
(insistiremos y veremos en profundidad
estos conceptos más adelante)
Se optimiza para la producción de muchos
elementos no la salida de uno solo
Procesar muchos elementos a la vez
“esconde” la latencia
PROCESADORES DE STREAMS (III)
EL PASADO: HARVEST Y PIXELFLOW
Veamos unos ejemplos ilustrativos de arquitecturas streaming
del mundo académico (donde más se ha investigado hasta la llegada de las GPUs)
Harvest (IBM 7950)
Primer precendente (años 50)
Trataba grandes volumenes de datos
encriptados como flujo, contaba con
un coprocesador especializado para
este tipo de operaciones
http://en.wikipedia.org/wiki/Harvest_(computer)
PixelPlanes (Universidad North Carolina) (años 80)
El nombre refleja la forma en la que trabaja la arquitectura
Procesador central
calcula los vértices
y la geometría
Matriz de coprocesadores asociados
uno a uno a píxeles de la pantalla,
que disponen de unos pocos bytes
de memoria local para procesar los
atributos de cada píxel
http://www.cs.unc.edu/~pxfl/
NOTAS:
Puede considerarse la primera arquitectura streaming, como variante del
supercomputador Strech dentro de un proyecto del ministerio de Defensa
Norteamericano (DARPA)
Por cierto, la noche pasada me encontré una presentación muy curiosa de ATI
(cuando todavía era ATI) llamada “CPU y GPU una convivencia dificil”, en la que
decían que las GPUs no eran arquitecturas streaming, es la primera vez que lo veo,
pero la presentación estaba hecha con saña y no le haría demasiado caso, también
decían que nunca podrían unirse CPU y GPU al ser puntos de vista arquitecturales
radicalmente diferentes y ahí tenemos el Fusión de AMD (nombre en clave Swift) y la
iniciativa de Intel
--> se trata de un procesador multinúcleo que lleva el nombre en clave de Larrabee,
que consta de 16 núcleos con 4 hilos de ejecución cada uno. Estará basado en la
arquitectura x86 aunque incluirá instrucciones especificas de las GPUs por lo que el
software actual seria compatible con el sin apenas modificacion. Se espera que cada
úa
n
i
t
con En
chip alcance rendimientos de 1 TeraFlop y se espera comercializar en 2009-2010.
http://www.elpais.com/articulo/tecnologia/chips/Intel/lanzara/2010/llevaran/tecnologia/UPC/elpeputec/20070726elpcibtec_3/Tes
PROCESADORES DE STREAMS (IV)
EL PRESENTE: MERRIMAC Y CHEOPS
Merrimac e Imagine (Stanford)
Menos unidades de
procesamiento que tareas
Organización multiplexada
en el tiempo
Cada etapa es completamente
programable
Stanford
Imagine
Chip de 16x16mm (Texas Instruments)
21 millones de transistores y 288 Mhz
Rendimiento global del sistema:
· 11’8 GFLOPS en aritmetica de 32 bits
· 23 GFLOPS en aritmetica de 16 bits
procesador de
streams de
32bits para
procesado de
señal, imagen
y gráficos (2001)
16% bancos de registros anexos
26% ALUs
interfaz de memoria,
interfaz de red, enrutado
de datos, unidad de
control...
NOTAS:
Hubo 4 primeras generaciones de Pixel Planes 4ª--> 40.000 trainagulos/sg
de la pga
anterior
5ª + bus interconexión 640MB/s-->2 Millones triag/sg
Todo desemboco en la aparición del PixelFlow en 1992
Imagine (0’18 micras y menos de 10 vatios de consumo )
PROCESADORES DE STREAMS (IV)
EL PRESENTE: MERRIMAC Y CHEOPS
Merrimac e Imagine (Stanford)
Organización multiplexada
en el tiempo
Cada etapa es completamente
programable
Stanford
Imagine
procesador de
streams de
32bits para
procesado de
señal, imagen
y gráficos (2001)
CPU
SDRAM
SDRAM
SDRAM
SDRAM
CONTROLADOR CIRCULANTE
(control del flujo de datos e intrucciones)
interfaz con
memoria principal
Menos unidades de
procesamiento que tareas
8 bloques aritméticos operando bajo
paralelismo SIMD, donde dentro de
cada uno de ellos hay 6 ALUs como
procesador VLIW
Ejecución del kernel
Microcontrolador
Banco de
registros
streaming
(SRF)
ALU Cluster
ALU Cluster
ALU Cluster
De instrucciones
Otros
Clientes
Streaming
De datos
De tareas
Paralelismo:
JERARQUÍA DE MEMORIA
2’1 Gbytes/sg.
(tipo AGP)
25’6 Gbytes/sg.
(inter-cluster)
435 Gbytes/sg.
(intra-cluster)
SIMD = Una sóla instrucción múltiples datos
VLIW = Very Long Instruction Word
NOTAS:
En el dibujo se pueden ver los distintos anchos de banda y formas de paralelismo
Es aritmética de 16 bits.
PROCESADORES DE STREAMS (IV)
EL PRESENTE: MERRIMAC Y CHEOPS
Merrimac e Imagine (Stanford)
NOTAS:
PROCESADORES DE STREAMS (V)
EL PRESENTE: MERRIMAC Y CHEOPS
Merrimac e Imagine (Stanford)
Menos unidades de
procesamiento que tareas
Organización multiplexada
en el tiempo
Cada etapa es completamente
programable
Es el núcleo
del Stanford
Streaming
Supercomputer
En el año 2003 comenzó una nueva
arquitectura en la que se trata de
explotar la escalabilidad
Se trata de maximizar la localidad
mediante una jerarquía de registros y
reducir el ancho de banda necesario
en un orden de magnitud (ó más)
Chip de 124 mm (2004) a 1GHz
Procesador MIPS64
128 GFLOPS
200 FPUs
1000 pin BGA
Interfaz a 16 chips DRAM 20 GB/s
Stanford Merrimac
procesador de streams 64bits para
computación científica (2004)
NOTAS:
PROCESADORES DE STREAMS (VI)
EL PRESENTE: MERRIMAC Y CHEOPS
Cheops (MIT)
Se trata de una arquitectura de streaming modular y compacta para
la adquisición, procesamiento y visualización de video digital
En lugar de utilizar muchas CPUs y descomponer espacial o temporalmente
las secuencias de video para aprovechar el paralelismo de datos, Cheops abstrae
un conjunto de operaciones coputacionalmente intensivas (16 y 24 bits) que
pueden ejecutarse de forma simultánea en modelo streaming
Además cuenta con un procesador tipo Von Neumann que controla el conjunto
y se encarga de las operaciones de 32 bits
El diseño modular favorece la escalabilidad del
sistema, con tres tipos de módulos:
procesamiento
8’5 GFLOPS (sostenido)
entrada/memoria 12’8 GFLOPS (pico)
salida
Dos tipos de buses. memoria de píxeles
(100 MB/s) y de datos y control (32 MB/s)
El diseño está pensado de manera
que es muy fácil reutilizar los
Los tres tipos de modulos
conectados por buses
datos procesados
Diagrama simplificado del proc.
(sin tener que comenzar otro proceso de
renderizado como en las GPUs actuales)
NOTAS:
Recuerda un poco al Cell que habréis visto con Marta
http://web.media.mit.edu/~wad/cheops_CSVT/cheops.html
PROCESADORES DE STREAMS (VII)
ALTERNATIVAS EN SILICIO: VIRAM y RAW
VIRAM (Berkeley)
Para tratar de minimizar el problema del “muro de memoria” (la diferencia
entre la capacidad de cálculo y velocidad del procesador y la memoria) se
integra el procesador dentro del área de memoria para minimizar la latencia
y aumentar el ancho de banda.
Toda la memoria es un inmeso banco de registros
Tiene importantes venjajas en consumo energético,
disipación, coste y área de integración
(NEC ha implementado algo muy parecido en la memoria eRAM de la XBoX 360)
3’2 GFLOPS en
aritmética de 32 bits
13MB de
memoria
principal
200 Mhz
2 unidades de procesamiento
vectorial 128 bits, que se
pueden desdoblar en 4 de 64
bits u 8 de 32 bits
32 registros
de 128 bits
http://iram.cs.berkeley.edu/kozyraki/project/ee241/midterm/report.html
NOTAS:
sólo 200MHz y alcanza 3’2 GFLOPs
¿por que no introducir algunas tareas en la propia memoria? En realidad ya
tenemos unas pocas, pero esto se puede sofisticar.
Normalmente los texels están comprimidos sin pérdidas en memoria, y los
tenemos que coger al menos de 4 en 4 (por el filtrado bilineal), de ahí que se
almacene en forma de curva de Peano.
PROCESADORES DE STREAMS (VIII)
ALTERNATIVAS EN SILICIO: VIRAM y RAW
Más unidades de
procesamiento que tareas
Organización en tareas en
paralelo
Cada “celda” es prograble
Los streams conectan “celdas”
Montañas de ALUs y registros
“Cables” pequeños y
programables
MIT RAW
Tile processing: consiste en colocar
varios procesadores en el área de
silicio dispuestos como azulejos en
una pared, interconecatdos por una
red con la misma topología 2D de
baja latencia (dos estáticas y dos
configurables)
Incluye en cada chip 16 procesadores
RISC con FPU y caché de 128 KB
Paralelismo de datos, a nivel de instrucción y optimizaciones streaming
4’8 GFLOPS pico
200 Mhz
Ej. El proc. Cell tb.
tiene más unidades
de proc. que tareas
IBM
Cell
Las variantes de bajo coste (clusters de GPUs) se verán más adelante
NOTAS:
de nuevo esto nos recuerda bastante a las matrices de procesadores sistólicos
4’8 GFLOPs con 200 Mhz, no está mal
PROCESADORES DE STREAMS (IX)
La diferencia fundamental en nuestro caso es la especialización:
La correspondencia entre las tareas de la síntesis de gráficos
y los conjuntos de procesadores en el procesador de la GPU
ATI Flipper 51 M trans.
NOTAS:
Organización de tareas
en paralelo
Una tarea a cada (conjunto de)
unidades de procesamiento
Las unidades están
cableadas de forma fija
Comunicación eficiente
Arquitectura pensada
“sólo” para gráficos
Tenemos dos tipos de
sub-procesadores
especializados
EL CAUCE GRÁFICO
EN PROFUNDIDAD
Veamos un poco más en
detalle el proceso de
generación de imágenes
desde el punto de vista
del programador y su
implementación en HW
NOTAS:
PROC. DE GENERACIÓN DE IMG. (I)
APLICACIÓN GRÁFICA & APIs
La lista de vértices y sus atributos, los valores iniciales de todos ellos, las
operaciones a realizar y las texturas a aplicar se describen en la capa SW
mediante un programa convencional (C, C++...) que incluye una serie de
llamadas a un API (Application Program interface) OpenGL y DirectX
La CPU ejecuta el programa y como
resultado de las llamadas a la API, se
colocan las texturas en la memoria de
video y se envía el microcódigo que
programa las operaciones a realizar
en la GPU. Después el procesador
gráfico puede recibir la lista de
vértices y ejecuta sobre el
flujo de datos la secuencia de operaciones para la generación de
las imágenes.
Nº
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Atributos de entrada para vértices
Nombre
Descripción
Formato
OPOS
Posición
(x,y,z,w)
WGHT
Peso
(w,0,0,1)
NRML
Vector normal
(x,y,z,1)
COL0
Color primario
(r,g,b,a)
COL1
Color secundario (r,g,b,1)
FOGC
Coord. de niebla
(f,0,0,1)
DIFF
Luz difusa
SPEC
Luz especular
TEX0
Coord. Textura 0 (s,t,r,q)
TEX1
Coord. Textura 1 (s,t,r,q)
TEX2
Coord. Textura 2 (s,t,r,q)
TEX3
Coord. Textura 3 (s,t,r,q)
TEX4
Coord. Textura 4 (s,t,r,q)
TEX5
Coord. Textura 5 (s,t,r,q)
TEX6
Coord. Textura 6 (s,t,r,q)
TEX7
Coord. Textura 7 (s,t,r,q)
Atributos de salida para vértices
Nombre
Descripción
Formato
HPOS
Posición
(x,y,z,w)
COL0
Color prim. frontal
(r,g,b,a)
COL1
Color sec. frontal
(r,g,b,a)
BFC0
Color prim. trasero
(r,g,b,a)
BFC1
Color sec. trasero
(r,g,b,a)
FOGC
Coord. se niebla
(f,*,*,*)
A0
Dir. Indir. Paráms.
(Sin usar)
TEX0
Coord. Textura 0
(s,t,r,q)
TEX1
Coord. Textura 1
(s,t,r,q)
TEX2
Coord. Textura 2
(s,t,r,q)
TEX3
Coord. Textura 3
(s,t,r,q)
TEX4
Coord. Textura 4
(s,t,r,q)
TEX5
Coord. Textura 5
(s,t,r,q)
TEX6
Coord. Textura 6
(s,t,r,q)
TEX7
Coord. Textura 7
(s,t,r,q)
PIPELINE ó CAUCE GRÁFICO (I)
Vamos a estudiar los pasos del proceso de síntesis de
de gráficos por ordenador más extendido en la actualidad:
el cauce gráfico
Todos sabemos ó intuimos que los artístas “esculpen” sus
modelos en programas CAD y que al final esto se convierte
en imágenes y animaciones realistas (e interactivas si estamos en un juego)
Introducción
Division
Conceptual
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
(3D Total)
De la descripción de una
escena 3D: polígonos que
forman la superficie de los
objetos, materiales, luces...
NOTAS:
A una representación
2D convincente desde
un determinado punto
de vista
Veamos un poco las APIs que vamos a utilizar
APIs/INTEFACES: OpenGL
Para poder utilizar la GPU para representar los gráficos primero
hay que cargar una serie de programas en su interior, subir las
texturas a memoria, los descriptores de la geometría...
Las más populares son OpenGL y DirectX:
Bajo nivel
Es una especificación, no exactamente una API
Hay implementaciones en muchos S.O. multiplataforma
No tiene “cosas escondidas”
De la mano de Silicon Graphics
Ciertos estudios de software tienen clara preferencia
Tiene versiones “light” para plataformas móviles
SIGGRAPH ‘10
Presentación
OpenGL 4.0
NOTAS:
APIs/INTEFACES: DirectX
Alto nivel
Es practicamente una plataforma de desarrollo
La API 3D es sólo una parte
Sólo funciona en plataformas Microsoft (Windows, XBoX)
Cerrado
Puede cambiar mucho de una versión a otra
Muy popular en la industría de los videojuegos
Por ahora, tiene menos sobrecarga del” driver” que OpenGL
a la hora de utilizar intensivamente las GPUs
Muchos intereses económicos de por medio...
Windows
Vista
Dx10
NOTAS:
Pelea
Shader
models
Venta
de montones
de tarjet.
PROC. DE GENERACIÓN DE IMG. (II)
AGRUPACIÓN DE VÉRTICES
Con los vértices se componen líneas o triángulos (la primitiva básica)
2 vértices
3 vértices
píxeles 1 línea
píxeles en el área del triángulo
A grosso modo, cuanto mayor sea el número de polígonos, más realismo
tendrán los objetos de la escena y podremos representar objetos más
complejos (veremos trucos para mejorar la calidad utilizando muy pocos polígonos)
Prmitiva OpenGL
Significado
GL_POINTS
Cada vértice es un punto individual.
GL_LINES
Cada par de vértices constituye una línea recta.
GL_LINE_STRIP
Los vértices forman una secuencia de segmentos.
GL_LINE_LOOP
Sobre el anterior, une el último vértice con el primero.
GL_TRIANGLES
Con cada tres vértices consecutivos compone un triángulo.
GL_TRIANGLE_STRIP
Igual que el anterior, pero con triángulos adyacentes.
GL_TRIANGLE_FAN
Idem, pero con triángulos adyacentes con vértice común.
GL_QUADS
Con cada cuatro vértices se compone un polígono.
GL_QUAD_STRIP
Igual que el anterior, pero con polígonos adyacentes.
GL_POLYGON
Los vértices describen un polígono convexo.
ETAPAS del CAUCE GRÁFICO (II)
ETAPA DE TRANSFORMACIÓN
Transforma las coordenadas de los vértices de los objetos
de su sistema local a su respectiva proyección 2D
Espacio Espacio Espacio
Espacio
Espacio
del
de la
del
de la
Visualizable
Ventana
Mundo
cámara
Introducción Objeto
3D
2D
Division
Conceptual Además se calcula la iluminación en cada vértice
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
Imágenes tomadas del libro
“The Cg Tutorial - The
Definitive Guide To
Programmable Real-Time
Graphics”
tetera con pocos polígonos
tetera con más polígonos
NOTAS:
Los 10 tipos de primitivas que se pueden
especificar en OpenGL una vez definida
la lista de vértices
PROC. DE GENERACIÓN DE IMG. (II)
AGRUPACIÓN DE VÉRTICES
v0
v4
v2
v1
v3
v0
v6
v1
v5
v3
v0
v2
Triángulos independientes
v4
v3
Puntos
v0
v2
v5
v7
v2
Líneas independientes
Bucle cerrado de líneas
v2
v3
v4
Tira de lineas
v2
v3
v6
v5
Tira de triángulos
v3
v4
v4
v1
v7
v0
v5
v3
v6
Quads independientes
v0
v2
v1
Abanico de triángulos
(Triangle Fan)
ETAPAS del CAUCE GRÁFICO (II)
v2
v0
v4
v6
v3
v1
v7
v5
ETAPA DE TRANSFORMACIÓN
Transforma las coordenadas de los vértices de los objetos
de su sistema local a su respectiva proyección 2D
Tira de Quads
Espacio Espacio Espacio
Espacio
Espacio
del
de la
del
de la
Visualizable
Ventana
Mundo
cámara
Introducción Objeto
3D
2D
Division
Conceptual Además se calcula la iluminación en cada vértice
y Funcional
Imágenes tomadas del libro
“The Cg Tutorial - The
Definitive Guide To
Programmable Real-Time
Graphics”
Prmitiva OpenGL
Significado
GL_POINTS
Cada vértice es un punto individual.
GL_LINES
Cada par de vértices constituye una línea recta.
GL_LINE_STRIP
Los vértices forman una secuencia de segmentos.
GL_LINE_LOOP
Sobre el anterior, une el último vértice con el primero.
GL_TRIANGLES
Con cada tres vértices consecutivos compone un triángulo.
GL_TRIANGLE_STRIP
Igual que el anterior, pero con triángulos adyacentes.
GL_TRIANGLE_FAN
Idem, pero con triángulos adyacentes con vértice común.
GL_QUADS
Con cada cuatro vértices se compone un polígono.
GL_QUAD_STRIP
Igual que el anterior, pero con polígonos adyacentes.
GL_POLYGON
Los vértices describen un polígono convexo.
v3
v4
Etapas:
v2
v0
v1
Polígono
NOTAS:
v5
v1
v3
v4
v1
Aplicación
Transformación
Rasterizado
Sombreado
v1
v2
v4
v5
v6
v4
v5
v7
v8
v6
v0
v0
v1
Los 10 tipos de primitivas que se pueden
especificar en OpenGL una vez definida
la lista de vértices
PROC. DE GENERACIÓN DE IMG. (III)
TRANSFORMACIÓN EN EL ESPACIO 3D
Se aplican las matrices de rotación y traslación 3D, utilizando el punto de
vista para calcular la profundidad de los objetos en la escena.
También pueden definirse uno o varios focos de que aporten realismo,
es en este punto en el que se suele calcular -tradicionalmente- la intensidad
de la luz en cada punto, e igualmente se “proyectan” las sombras en esta
etapa del renderizado.
ETAPAS del CAUCE GRÁFICO (II)
ETAPA DE TRANSFORMACIÓN
Transforma las coordenadas de los vértices de los objetos
de su sistema local a su respectiva proyección 2D
Espacio Espacio Espacio
Espacio
Espacio
del
de la
del
de la
Visualizable
Ventana
Mundo
cámara
Introducción Objeto
3D
2D
Division
Conceptual Además se calcula la iluminación en cada vértice
y Funcional
Traslación
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
Rotación
Imágenes tomadas del libro
“The Cg Tutorial - The
Definitive Guide To
Programmable Real-Time
Graphics”
PROC. DE GENERACIÓN DE IMG. (IV)
ACOTACIÓN AL ÁREA VISIBLE EN PANTALLA
Delimitación del espacio 2D visible en pantalla (clipping) y de la cara
visible de cada poligono (culling).
La primera operación descarta (parcial o totalmente) los polígonos que
quedan fuera del ángulo de visión definido para la imagen, y la segunda,
los vértices de cada objeto que quedan ocultos tras su cara visible.
El objetivo es reducir el número de datos en el flujo, que no van a aportar
información gráfica a la escena
y agilizar las etapas siguientes
ETAPAS del CAUCE GRÁFICO (V)
ETAPAS DE ELIMINACIÓN DE DATOS
Al fluir los datos en el cauce, no sólo son transformados de
unos tipos a otros, sino que además su volumen se multiplica.
Podemos imaginarlo como una reacción química en cadena.
Muchos de estos datos no son necesarios de una etapa a la
Introducción siguiente, y conviene eliminarlos tan pronto como sea posible
Division
para no aumentar el coste computacional por su procesado
Conceptual
y Funcional Así tendremos numerosos test
entre etapas, para dejar pasar
Etapas:
Aplicación
sólo aquellos elementos que
nos interesen
Transformación
Rasterizado
test
Sombreado
NOTAS:
Puede apreciarse cómo se
han eliminado las caras
posteriores (que quedaban
tapadas) en las teteras
PROC. DE GENERACIÓN DE IMG. (V)
ASOCIACIÓN A LA VENTANA DE VISUALIZACIÓN
Las coordenadas x e y de cada polígono son ahora transformadas a
coordenadas en la pantalla (dependiendo de la posición de la cámara
y las dimensiones de la ventana de visualización). la coordenada z
permanece invariable y se utilizará en rasterizado con el algoritmo
z-buffer
Una vez transformados y proyectados los vértices (y cálculadas sus áreas
visibles) sus coordenadas espaciales son definitivas. Acabamos con los
vértices y comenzamos a procesar los fragmentos (píxeles en potencia)
ETAPAS del CAUCE GRÁFICO (II)
ETAPA DE TRANSFORMACIÓN
Transforma las coordenadas de los vértices de los objetos
de su sistema local a su respectiva proyección 2D
Espacio Espacio Espacio
Espacio
Espacio
del
de la
del
de la
Visualizable
Ventana
Mundo
cámara
Introducción Objeto
3D
2D
Division
Conceptual Además se calcula la iluminación en cada vértice
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
NOTAS:
Imágenes tomadas del libro
“The Cg Tutorial - The
Definitive Guide To
Programmable Real-Time
Graphics”
PROC. DE GENERACIÓN DE IMG. (VI)
CREACCIÓN DE FRAGMENTOS DE LA IMAGEN
En el rasterizado se convierte cada punto, línea y polígono 3D en una
matriz 2D de puntos donde se guarda información del color y profundidad
Dependiendo de la resolución de la pantalla se colocan los vértices y se
interpolan las áreas de los polígonos que contienen en memoria
Tenemos dos áreas de memoria en las que se realiza esta transformación:
Color buffer ó back buffer es una matriz cuyas elementos son ternas
RGB (y un cuarto elemento -alfa- para la trasparencia), que definen el
color para cada uno de los puntos 2D del polígono transformado
Z-buffer o buffer de profundidad es otra matriz en la que se guarda
información de profundidad y se determina si los polígonos quedan
total o parcialmente tapados por otros
Los bufferes y sus
implicaciones en
la arquitectura se
verán en detalle en
el tema de mem.vid.
ETAPAS del CAUCE GRÁFICO (IV)
ETAPA DE RASTERIZADO
Convierte la representación geométrica (vértices)
a una representación de imagen (fragmentos)
Los fragmentos pueden verse como píxeles “en potencia”
Fragmento = píxel + datos asociados
(potencial) (color, profundidad, pincel...)
No es
programable,
Introducción
por ahora...
Division Interpola las cantidades calculadas en cada vértice
Conceptuala lo largo de los “píxeles”
y Funcional
Etapas:
Aplicación
Transformación
Rasterizado
Sombreado
Rasterizado
Vértices
NOTAS:
Fragmentos
Buffer de color + Buffer de profundidad = Frame Buffer
El algoritmo es tan sencillo como mantener en el frame buffer los datos del fragmento
cuya coordenada z sea la más próxima al punto de vista de la escena, y se actualiza
cuando se haya uno que puede estar delante de ellos. si se utilizan trasparencias
(canal alfa) la operación deja de ser conmutativa y haya que procesar primero
los objeto opacos y tener cierto cuidado con el orden de atrás hacia
adelante del resto.
PROC. DE GENERACIÓN DE IMG. (VII)
PEGADO DE TEXTURAS
Se recubre la superficie de cada objeto, pegándole a cada polígono
proyectado la textura que añade realismo a su aspecto externo.
El mapa de texturas debe transformarse de forma acorde con el ángulo,
tamaño y posición de los polígonos a los se va a adherir.
Este complejo proceso se verá en la asignatura de Rendering Avanzado y en
las prácticas de esta asignatura desde el punto de vista de síntesis de texturas.
ETAPAS del CAUCE GRÁFICO (V)
ETAPA DE SOMBREADO
Básicamente, se calcula el color de cada pixel
Han de leerse imágenes de texturas (arrays de memoria)
Estas texturas llevan todo tipo de información (color difuso
sobre la superficie, normales, brillo...)
Introducción
Ya no tenemos el límite
Es una tarea fácilmente paralelizable
en el número de fuentes
Division
de luz, ni ningún otro...
Conceptual Ha de ser muy flexible: programable
y Funcional Suele haber más pixeles
Etapas:
que vértices, y las
Aplicación
operaciones son más
Transformación
complejas
Mayor número
Rasterizado
de procesadores
de fragmentos
Sombreado
NOTAS:
PROC. DE GENERACIÓN DE IMG. (VIII)
MEZCLADO DE ELEMENTOS (BLENDING)
Se trata de la composición final de la escena, en la que se superponen los
nuevos elementos sobre los existentes en la imagen. En esta fase se utilizan
operadores de máscara (AND & OR), filtros... Este mezclado nos permite
reutilizar el renderizado parcial de la escena en los siguientes frames de
una animación o juego.
La GPU realiza estas operaciones de forma ordenada y sistemática, como si
no alterarse la lista de vértices o los atributos, tendríamos siempre la misma imagen,
pero si introducimos una variable los cambios se reflejarán de forma inmediata.
se encontrara en un bucle infinito De
Una vez tenemos la imagen final,
se envía a una zona especial de
memoria donde estos datos
(digitales, normalmente de 16 bits)
se transforman en las señales
que maneja el monitor (sea
digital o analógico)
O bien se realimentan en el
cauce para postprocesado
Sardegna - primavera 2006 (MomaStalker)
NOTAS:
ETAPAS del CAUCE GRÁFICO
Flujo de
Listas de “vértices”
puntos 3D
Flujo de
fragmentos
sin procesar
Texturas
Programa
de vértices
Rasterización
Programa de
fragmentos
Flujo de vértices
transformados
Flujo de triángulos
en el espacio
de pantalla
Flujo de
triángulos
Clip/Cull/
Viewport
Composición
Flujo de
fragmentos
Stream de
píxeles
Píxeles
de colores
Imagen
NOTAS:
Ensamblado
de triángulos
Framebuffer
¿CÓMO ENCAJA EL CAUCE EN LA GPU?
Pasos del Flujo (simplificado)
Arquitectura Tarj. Gráf.
Aplicación
Aplicación
Comandos
Proc. Vértices
Transformación
Proc. Teselación
Geometría
Proc. Geometría
Rasterización
Rasterización
Texturas
Sombreado
Fragmentos
Visualización
NOTAS:
Proc. de
Fragmentos
Visualización
SHADERS: RECONFIGURACIÓN
(SOMBREADORES)
DEL HW GRÁFICO (I)
Las etapas del cauce de segmentación fueron evolucionando durante
la decada pasada, en la que se fueron uniéndose y separándose hasta
alcanzar un punto de madurez en el que se han conformado unas
operaciones fijas y otras programables.
Estas partes programables se implementan mediante un firmware de
forma similar a una unidad de control microprogramada de los años
80 (familia 80x86 de Intel) o a una CPU adaptativa de finales de los 90
(procesadores Crusoe y Caruso de Transmeta).
La programación de operaciones en esta capa firmware está en manos
del programador gráfico (en lugar del fabricante como en los ejemplos mecionados con CPUs)
Llamamos shaders ó sombreadores a los programas que se
“microcodifican” en los procesadores programables de la GPU
El nombre viene de que este programa “oscurece” la función
estándar que tiene asignada la segmentación estandar en esa
etapa, anulándola para reemplazarla por otra nueva
que se coloca en su lugar.
NOTAS:
SHADERS: RECONFIGURACIÓN
(SOMBREADORES)
DEL HW GRÁFICO (II)
Aplicación
Comandos
Geometría
Rasterización
Texturas
Fragmentos
Visualización
NOTAS:
Evaluación
Transformación
Iluminación
Coord. Texturas
Clipping
Shaders para
Vértices,
Teselación y
Geometría
Direc. texturas
Filtro texturas
Regs. combiners
Shader
para
Fragmentos
Niebla
Mezclado
Test Alpha, S y Z
Operadores lógicos
Niebla
Mezclado
Test Alpha, S y Z
Operadores lógicos
Evaluación
Clipping
SHADERS: RECONFIGURACIÓN
(SOMBREADORES)
DEL HW GRÁFICO (III)
Sin los sombreadores, cada programador hubiera incorporado la
funcionalidad que necesitara en un punto arbitratrio del cauce
segmentado, y cada arquitecto hubiera comprimido o expandido
el número de etapas a su voluntad y hoy tendriamos un caos de
operaciones gráficas no facilmente conciliables. (como ocurría a
finales de los 90)
Nomenclatura:
DirectX:
Vertex Shader
Pixel Shader
OpenGL
Vertex Program
Fragment Program
NOTAS:
ensamblador
optimizado
para el perfil
de la GPU
del usuario
traducción al HW y envío
de las instrucciones a través
de la API
En la próxima clase y en el laboratorio lo veremos
mucho más en detalle
LECTURA RECOMENDADA
No es un trabajo, pero
conviene leerlo para
reforzar los conceptos
que hemos visto hoy
y su relación con lo
que habéis estudiando
en Informática Gráfica
El nivel de este paper
es sencillo e introductorio
http://graphics.stanford.edu/~liyiwei/courses/GPU/
NOTAS:
ACTIVIDAD SEMANAL
No es un trabajo, pero
conviene verlo para
reforzar los conceptos
que hemos visto hoy
y su relación con lo
que habeis estudiando
en Informática Gráfica
Bienvenida e Introducción
al Curso de GPGPU
del SIGGRAPH’06
por Marc Olano
El nivel de este vídeo
es sencillo e introductorio
Campus Virtual
Aquellos que no tengáis
todavía acceso, podéis
descargarlo de la
consigna: PGATR
NOTAS:
Marc Olano ha hecho muchas cosas, entre ellas, escribir el libro naraja ;-)
Programmable GPUs are increasingly powerful computational machines. While
GPU shading practitioners must still choose between graphics APIs and languages,
their capabilities and syntax are amazingly similar. This course presents the latest
GPU shading evolution in the next generation hardware, and highlights the
features, similarities and differences between the different API, language and
hardware choices through a series of instructive examples and demos presented
by experts from academia and industry. Unlike previous courses, this year will
focus on examples and general shading techniques that could be ported from
shading language to shading language, but each presented in explicit detail using
one of the API/language/hardware choices to allow course participants to learn
general methods while judging the differences for themselves. In addition, we
highlight the distance that still exists between production and GPU shading and
show the inroads GPUs have made in production rendering
BIBLIOGRAFÍA
(De esta clase)
Capítulo
15
NOTAS:
RESUMEN
(Ideas claves de esta clase)
Los procesadores gráficos son muy interesantes desde el
punto de vista de capacidad de cálculo y programación
de juegos.
Implementan en su hardware el cauce gráfico
Su orientación a datos y especialización hace que tengan una
arquitectura muy especial
Su programación es muy dependiente de la arquitectura del
chip gráfico, por lo que hemos de conocerla bien si queremos
sacarle el máximo partido
Tienen un rápido crecimiento asegurado, aunque se trata de
un mundo en vertiginosa evolución, de ahí la necesidad de
estudiar los procesadores con un espíritu crítico que nos
permita adaptarnos y comprender los cambios
NOTAS: