Download Arquitectura

TEMA 2.2
ETAPA DE
TRANSFORMACIÓN
E IMPLEMENTACIÓN
HARDWARE
Curso 2013 / 14
Procesadores Gráficos y Aplicaciones en Tiempo Real
Profesores: David Miraut y Óscar D. Robles
c
GMRV
2005-2014 – Febrero 2014
David Miraut Andrés
Procesadores Gráficos y Aplicaciones en Tiempo Real 2013/14
1/
70
1/70
Evolución del cauce gráfico
Fuente: Intel
David Miraut Andrés
Etapa de Transformación e implementación Hardware
Índice inicial
2/
70
2/70
Un tour en tres etapas
Arquitecturas
pioneras:
Arquitecturas
circulantes:
Arquitectura
“unificada”:
Futuro
inmediato:
Cauce gráfico
de funcionalidad fija
Cauce gráfico
programable
Cauce gráfico
“actual”
“Cauce”gráfico
a medida con
total flexibilidad
Una mayor flexibilidad implica
una mayor responsabilidad en
el proceso de la síntesis de la
imagen: Es necesario dominar
todos los pasos para ir más allá
Nos meteremos en la piel de un diseñador de chips gráficos
David Miraut Andrés
Etapa de Transformación e implementación Hardware
Índice inicial
3/
70
3/70
Esquema de bloques de la GeForce GTX480
Una parte más
grande e importante
de lo que nos
muestran los
fabricantes sigue
manteniendo la
filosofía streaming
Precisamente la que es más
difícil de “pasar a SW” por
el elevado tráfico de memoria
Nos enfocaremos en ella al tratar las arquitecturas “pioneras”
David Miraut Andrés
Etapa de Transformación e implementación Hardware
Índice inicial
4/
70
4/70
Acerca de los Shader Models
La evolución de la arquitectura de las tarjetas no es errática y
aleatoria, aumentando sin parar la potencia a base de frec. de
reloj y más procesadores, sino que obedece a la presión especifica
del mercado de los videojuegos y los efectos que se desean lograr.
Para comprenderlo hay que bajar al nivel de programación.
Captura del juego de Narnia
David Miraut Andrés
Etapa de Transformación e implementación Hardware
Índice inicial
5/
70
5/70
Sin estándares las cosas se complican
• En la prehistoria (antes de la SuperVGA) los monitores eran
“malillos” y las generaciones de tarjetas se iban sucediendo por
superación técnica y se llegaba a un cierto acuerdo entre
fabricantes (habia pocos y no mucho interés en este campo).
• El mercado de los juegos fue creciendo y con él el interés en
este tipo de productos, cada fabricante proponía sus soluciones
incompatibles con los demás para ganar cuota de mercado (y
torturar a los programadores que tenían que hacer un driver
para cada tarjeta en el juego). VESA trató de unificar sin
mucho éxito y el embrión de OpenGL era demasiado pesado
para aquellos ordenadores
• Después vino 3DFX, arrasó y los fabricantes que sobrevivieron
intentaron seguir un standard (3DFX tenía GLIDE) y OpenGL
fue cogiendo fuerza. Ese fue el primer marco común, pero era
insuficiente basarse en una API para crear tarjetas. . .
David Miraut Andrés
Etapa de Transformación e implementación Hardware
Shader Models
6/
70
6/70
Shader Models
Por ello aparecieron los Shader Models a modo de
especificaciones de comités técnicos que establecían un marco
común de funcionalidades gráficas requeridas por las compañías
de videojuegos, plasmadas en forma de requisitos de hardware de
las etapas del pipeline
Cada versión de Shader Model incluye y añade mejoras a las
propuestas anteriores. Son un acuerdo común entre los
principales creadores de GPUs y las compañías que desarrollan las
APIs para hacer accesibles esas funcionalidades.
David Miraut Andrés
Etapa de Transformación e implementación Hardware
Shader Models
7/
70
7/70
Ejemplos de visualización con diferentes Shader
Models
David Miraut Andrés
Etapa de Transformación e implementación Hardware
Shader Models
8/
70
8/70
Ejemplos de visualización con diferentes Shader
Models
David Miraut Andrés
Etapa de Transformación e implementación Hardware
Shader Models
9/
70
9/70
Arquitecturas
pioneras:
Cauce gráfico
de funcionalidad fija
David Miraut Andrés
Arquitecturas streaming puras
10 /
10/7070
Procesado de geometría
Tenemos dos tipos de operaciones:
• Operaciones sobre vértices
◦ Se actúa sobre vértices individuales
• Operaciones sobre primitivas
◦ Se actúa sobre todos los vértices de cada primitiva
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre vértices
11 /
11/7070
Operaciones sobre vértices
• Transformación de coordenadas y normales
◦ Modelo → Mundo
◦ Mundo → Ojo
• Normalización de la longitud de las normales
• Cálculo de la iluminación por vértices ( gouraud )
• Transformación de las coordenadas de texturas
◦ Se generan en caso necesario
• Transformación de las coordenadas para clipping (proyección)
• Se dividen las coordenadas entre w
• Se aplica la transformación afín de la cámara (x , y y z)
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre vértices
12 /
12/7070
Transformación de coordenadas
Matriz 4 × 4 en coordenadas homogéneas Típicamente en punto
flotante de simple precisión Las matrices se pueden componer:
• En la aplicación
• Dentro del propio cauce
◦ Hay que tener cuidado con la invarianza
x’
m 11 m 12 m 13 m 14
x
y’
m 21 m 22 m 23 m 24
y
m 31 m 32 m 33 m 34
z
m 41 m 42 m 42 m 44
w
z’
w’
David Miraut Andrés
=
Arquitecturas streaming puras
Operaciones sobre vértices
13 /
13/7070
Transformación de las normales
(nx0 , ny0 , nz0 ) = (nx , ny , nz )Mu−1
Mu = parte superior izquierda 3 × 3 de M
(0.0)
• Estrategias para obtener Mu−1
◦ Se puede mantener por separado
◦ Calcular cada vez que las coordenadas de la matriz cambien
◦ Forzar su especificación por la aplicación
• ¿Por qué transformamos las normales?
◦ ¿Se puede calcular la iluminación en las coordenadas del
modelo?
• ¿Por qué normalizamos las normales (longitud unidad)?
◦ Las ecuaciones de iluminación lo necesitan
◦ Un modelo no rígido de la matriz distorsiona las longitudes
◦ Requiere una operación de raíz cuadrada recíproca
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre vértices
14 /
14/7070
Transformación de las normales
(nx0 , ny0 , nz0 ) = (nx , ny , nz )Mu−1
Mu = parte superior izquierda 3 × 3 de M
(0.0)
• Estrategias para obtener Mu−1
◦ Se puede mantener por separado
◦ Calcular cada vez que las coordenadas de la matriz cambien
◦ Forzar su especificación por la aplicación
• ¿Por qué transformamos las normales?
◦ ¿Se puede calcular la iluminación en las coordenadas del
modelo?
• ¿Por qué normalizamos las normales (longitud unidad)?
◦ Las ecuaciones de iluminación lo necesitan
◦ Un modelo no rígido de la matriz distorsiona las longitudes
◦ Requiere una operación de raíz cuadrada recíproca
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre vértices
15 /
15/7070
Iluminación
• Una evaluación de un producto escalar entre n y l
◦ más las componentes especular y ambiental
◦ puede haber múltiples luces
◦ nota: n no es la normal en una faceta
n
l
• El objeto puede tener dos caras
◦ Se calcula para n y −n
-n
◦ Pueden hacer falta ambos resultados
◦ Parte de los cálculos se pueden compartir
• Simplificación en el punto de vista
◦ El vector del punto de vista es [0, 0, 1]
◦ Ahorra cálculos
¡No tenemos algo como la dirección del punto de vista!
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre vértices
16 /
16/7070
No hay interdependencias
Las operaciones de vértices se aplican a los vértices de forma
independiente
Operaciones sobre vértices
• Transformación de coordenadas y normales
◦ Modelo → Mundo
◦ Mundo → Ojo
• Normalización de la longitud de las normales
• Cálculo de la iluminación por vértices ( gouraud )
• Transformación de las coordenadas de texturas
◦ Se generan en caso necesario
• Transformación de las coordenadas para cliping (proyección)
• Se dividen las coordenadas entre w
• Se aplica la transformación afín de la cámara (x , y y z)
David Miraut Andrés
David Miraut Andrés
Arquitecturas streaming puras
Arquitecturas streaming puras
Operaciones sobre vértices
Operaciones sobre vértices
7/
28
7/28
17 /
17/7070
Operaciones sobre primitivas
Ensamblado de primitivas
Transformación de coordenadas y normales
Clipping
Modelo
mundo
Eliminación caras posteriores
Mundo
Ojo
Normalización de la longitud de las normales
Cálculo de la iluminación por vértices
Transformación de las coordenadas de texturas
Transformación de las coordenadas para cliping
Ensamblar vértices en las primitivas
Recortar (clip) las primitivas respecto al frustrum
División por w
Aplicación de la transformación afín de la cámara
Eliminar los triángulos que “dan la espalda”
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre primitivas
18 /
18/7070
Ensamblado de primitivas
• El ensamblado se hace de acuerdo con los comandos enviados
desde la aplicación
◦ Como una tira de triángulos, una malla ó. . .
• Descomponiendo los triángulos
◦ Anterior al clipping para mantener la invarianza
• Propiedades del algoritmo
◦ Tiempo de ejecución fijo (bueno)
•
Todas las operaciones de vértices descritas hasta aquí tienen esta
propiedad
◦ Interdependencias entre vértices (chungo)
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre primitivas
19 /
19/7070
Clipping
• Dos tipos:
◦ Punto, línea: elimina geometría
◦ Polígono: elimina e introduce nuevas aristas
Segmentos de línea
David Miraut Andrés
Arquitecturas streaming puras
Polígono
Operaciones sobre primitivas
20 /
20/7070
Clipping
• Dos tipos:
◦ Punto, línea: elimina geometría
◦ Polígono: elimina e introduce nuevas aristas
• Requerimientos de invarianza
◦ Predescomposión en triángulos
◦ Cuidado con la aritmética de las aristas
• Propiedades del algoritmo
◦ Interdependencias entre vértices (chungo)
◦ Ejecución dependiente de los datos (aún peor)
•
•
Tiempo de ejecución variable (notablemente diferente)
El recorrido del código es diferente
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre primitivas
21 /
21/7070
Culling de caras posteriores
•
•
•
•
•
•
¿La faceta mira ó da la espalda a la cámara?
Necesitamos la normal de la faceta
Cuidado: sólo las primitivas triangulares son planas
Utilizamos la dirección en la que “mira”
Para aplicarlos en la iluminación
Descartar (potencialmente) la primitiva ¿Avanzar en la
secuencia nos ayuda a mejorar la eficiencia?
x2,y2
x0,y0
David Miraut Andrés
Arquitecturas streaming puras
Operaciones sobre primitivas
x1,y1
22 /
22/7070
Ejemplos en arquitecturas streaming puras
• Sistemas
◦
◦
◦
◦
◦
◦
Clark Geometry Engine (1983)
Silicon Graphics GTX (1988)
Silicon Graphics RealityEngine (1992)
Silicon Graphics InfiniteReality (1996)
Modern Geometry Engine (2001)
Primeras GPUs comerciales para mercado doméstico (2001)
• Nos vamos a fijar en:
◦ La organización del sistema de geometría
◦ La distribución de las operaciones de vértices y primitivas
◦ Cómo el clipping afecta a la implementación
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
23 /
23/7070
Clark Geometry Engine (1983)
Coordinate
• Capacidades de 1a generación
• Cauce gráfico simple de funcionalidad
Transform
fija
◦ 12 engines idénticos
◦ Configurados por SW al inicio
• La etapa de clipping requiere la mitad
6-plane
Frustum
Clipping
de la potencia total
◦ Rendimiento invariante (bueno)
◦ Típicamente idle (malo)
Divide by w
Viewport
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
24 /
24/7070
GTX Geometry Engine (1988)
Coord, normal
• Capacidades de 2a generación
• Cauce de funcionalidad variable
◦ 5 engines idénticos
◦ Los modos alteran algunas funciones
•
El equilibrado de carga es no trivial
• El clipping requiere 1/5 de la potencia
de cálculo
◦ El test de clipping tiene arga constante
◦ La acción de clipping
Ralentiza la ejecución del cauce (malo)
al no equilibrarse la carga
• Rara vez se invoca (bueno)
•
Transform
Lighting
Clip testing
Clipping state
Divide by w
(clipping)
Viewport
Prim. Assy.
Backface cull
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
25 /
25/7070
RealityEngine Geometry (1992)
• Capacidades de 3a generación
• Organización con funcionalidad variable
Command
Processor
MIMD
◦ 8 engines idénticos
◦ Asignación de carga mediante
round-robin
◦ Balanceo de carga estatico aceptable
• Procesador de comandos
• Ensamblado de primitivas
◦ Complica la distribución de trabajo
◦ Reduce la eficiencia del procesado de
tiras de triángulos
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
Round-robin
Aggregation
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
26 /
26/7070
Clipping en RealityEngine
• Introduce carga que depende de los datos (dinámica)
◦ No la puede predecir el Command Processor
• El equilibrado se puede realiar mediante
◦ Asignación round-robin
◦ Grandes colas FIFO de entrada y salida
•
Para cada procesador de geometría
◦ Un agran carga de trabajo para cada procesador
•
NO sigue la idea del cauce
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
27 /
27/7070
InfiniteReality Geometry (1996)
• Capacidades de 3a generación
• Organización con funcionalidad variable
Command
Processor
MIMD
◦ 4 engines idénticos
◦ Asignación de carga al menos ocupado
◦ Balanceo de carga estatico aceptable
• Procesador de comandos
• Ensamblado de primitivas
◦ Complica la distribución de trabajo
◦ Reduce la eficiencia del procesado de
tiras de triángulos
Sequence Token
Aggregation
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
28 /
28/7070
Clipping en InfiniteReality
• El equilibrado de carga se logra mediante:
◦ Asignación al menos ocupado
◦ Colas FIFOs aún más largas
◦ Gran carga de trabajo por procesador
• La probabilidad del clipping se puede reducir con
◦ El algoritmo de clipping conservativo guard-band
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
29 /
29/7070
Guard-Band Clipping
• Se extiende el frustrum más allá del campo de visión deseado
◦ Los planos cercano y lejano se mantienen sin cambios
◦ Sólo se realiza el clipping si es necesario
• Casos ideales para primitivas triangulares
◦ Descartamos si está fuera del volumen de visión, sino
◦ Renderinzamos sin clipping si está dentro del frustrum , sino
◦ Realizamos el recorte de las primitivas
•
•
Que cruza tanto los limites del campo de visión como de frustrum
Que cruza el plano cercano ó el lejano
La operación no es perfecta, pero al menos es conservativa
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
30 /
30/7070
Guard-Band Clipping
Renderizado
Descartado
Recortado (Clipped)
Viewport
Guard-band
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
31 /
31/7070
Modern Geometry Engine (2001)
• Aplica un algoritmo de rasterizado homogéneo
◦ No requiere clipping
◦ Por tanto no hay una fase de ensamblado de primitivas antes de
la rasterización
•
La eliminación de caras posteriores pasa a ser responsabilidad del
rasterizado
• Los cálculos en el engine de geometría son
◦ Sobre vértices independientes: la distribución del trabajo es más
sencilla
◦ Se eliminan las posibles dependencias de datos en esta etapa: se
reducen al mínimo las posibilidades de ramificación
• Permite una implementación muy eficiente y el uso de SIMD
Pero, ¿se podría programar un shader aquí?
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
32 /
32/7070
Generacíón de primitivas
¿Para qué complicarnos metiendo esto en la GPU?
Hay algunas razones de peso:
•
•
•
•
Encaja con la semántica de la aplicación
Movemos el cálculo de CPU a GPU
Reduce las necesidades de almacenamiento
Por supuesto, también está motivado por algún perverso deseo
de complicar el diseño de las GPUs
Pero lo más importante:
• Se reduce el volumen de información que hay que comunicar
entre CPU y GPU (un recurso muy escaso)
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
33 /
33/7070
Idea básica
Application
Command
Prim. Generate
Geometry
Rasterization
Texture
•
•
Modos
Valores de los datos (potencialmente puede
ser una gran cantidad)
◦ Se ejecuta la función de generación
•
Fragment
•
Comandos en modo-bloque
Comandos para vértices
• La geometría generada se trata como si
Display
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
David Miraut Andrés
• Se incorpora una nueva etapa en el cauce
◦ Dentro del grupo de geometría
(Transformación)
• En cálculo se realiza en dos fases
◦ Se especifica la función de generación
hubiese sido descrita explícitamente por la
aplicación en las siguientes etapas
Arquitecturas streaming puras
Casos de estudio
34 /
34/7070
Dificultades en la generación de primitivas
• La especificación puede ser muy compleja
◦ Ej. Las mallas 2D de 4o orden a evaluar en OpenGL
◦ Podemos necesitar más datos para la generación que lo que
ocupan las primitivas (triángulos) que obtenemos
◦ La especificación/ejecución puede ser secuencial
•
Requiere doble buffer, separación de los engines de ejecución
• Cracks y vértices-T
◦ Las superficies de diferentes porciones deben encajar
•
Pero la precisión es finita
◦ En general requiere “remiendos”/costuras
•
OpenGL permite cierta evaluación mixta en la que se incluya la
especificación de vértices
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
35 /
35/7070
“Cosido” de parches
5x5 Parche
4x4 Parche
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
36 /
36/7070
“Cosido” de parches
5x5 Parche
4x4 Parche
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
Vértices introducidos para “coser”
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
37 /
37/7070
Dificultades en la generación de primitivas
La implementación puede ser muy compleja
• Ej. Trimmed NURBS
◦ La teselación tiene que hacerse en un tiempo limitado, de
manera que la etapa no bloquee el cauce
◦ NO hay formulación analítica posible para la intersección
genérica de 2 trimmed NURBS
• El algoritmo no es fácil de adaptar en un sistema paralelo (y
menos en una GPU)
¿Dónde deberíamos colocar la generación de primitivas?
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
38 /
38/7070
¿Dónde colocamos la generación de primitivas?
• En los engines de geometría de la etapa de
Transformación
◦ En aquella época podía reducirse el throughput en el
volumen de vértices procesados
•
Command
Processor
Es un procesado costoso (y lento)
◦ Puede llegar a serializar la configuración/ejecución
•
Las GEs no están diseñadas para soportar doble buffer
◦ Complica el equilibrado de carga
•
Se tiene que distribuir la responsabilidad del Command
Processor
Sequence Token
Aggregation
◦ Complica la gestión de estados
•
El Command Processor gestionaba esto
• OpenGL nos da cierta libertad
◦ La semantica no nos restringe en este sentido
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
39 /
39/7070
¿Dónde colocamos la generación de primitivas?
• En un procesador adicional
◦ Requiere invertir recursos y tiene funcionalidad
fija dentro del cauce
•
Estará de brazos cruzados en una ejecución normal
◦ Puede serializar la configuración/ejecución
•
Command
Processor
Primitive
Generation
Command
Processor2
?
Si no se diseña con doble buffer o algo semejante
◦ Sìmplifica
•
•
El equilibrado de carga del GE
La gestión de estados
Sequence Token
Aggregation
• Parece una nueva etapa del cauce
◦ La función del Command Procesor se divide
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
Extraído de la presentación de
Kurt Akeley y Pat Hanrahan
40 /
40/7070
Otras estrategias de reducción de datos
• Hace mucho tiempo que se vienen proponiendo cosas
semejantes a vertex buffer objects. Hoy día están
implementados en la rama principal de OpenGL
◦ Mejoran el uso del bus gráfico
◦ Evitan que se “sobrecargue” el driver
• Descompresión de geometría
◦ strips y mallas
◦ Indices de conjuntos de triángulos
◦ Geometry Compression (Deering ’95)
◦ El último artículo de Tomas Akenine para el
EUROGRAPHICS’13 va también en esta línea (Stochastic
Depth Buffer Compression using Generalized Plane Encoding).
En sistemas comerciales para el mercado doméstico hay que
tener mucho cuidado en qué se ofrece, pues una vez se da una
funcionalidad está debe mantenerse a lo largo del tiempo
(compatibilidad hacia atrás)
David Miraut Andrés
Arquitecturas streaming puras
Casos de estudio
41 /
41/7070
Arquitecturas
circulantes comerciales:
Cauce gráfico
programable
David Miraut Andrés
Arquitecturas streaming comerciales
42 /
42/7070
nVIDIA GeForce 6800
Etapas
Aplicación
Comandos
API
Geometría
Rasterización
Texturas
Fragmentos
Comparación
y tests de prof.
y blending
Visualización
Arquitectura GeForce 6800
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
43 /
43/7070
Especificaciones de la GeForce 6800
* Chip codenamed NV40
Lo que se lee
* 130nm FSG (IBM) technology
* 222 million transistors
en la caja y el
* FC case (flip chip with no metallic cover)
manual cuando
* 256-bit memory interface
uno lo adquiere
* Up to 1 GB of DDR / GDDR -2/ GDDR -3 memory
* Bus interface AGP 3.0 8x
* A special APG 16x mode (both ways), for PCI Express of HSI bridge
* 16 pixel processors, each having a texture unit with an optional filtering of integer and float-point
textures (anisotropy up to 16x).
* 6 vertex processors, each having one texture unit with no value filtration (discrete selection)
* Calculates, blends, and writes up to 16 full pixels (colour, depth, stencil buffer) per clock
* Calculates and writes up to 32 values of depth and stencil buffer per clock (if no operation with
colour is executed)
* Supports a two-way stencil buffer
* Supports special optimisations of geometry rendering for acceleration of shadow algorithms based
on the stencil buffer (the so-called Ultra Shadow II technology)
* Supports pixel and vertex shaders 3.0, including dynamic branchings in pixel and vertex
processors, texture value selection from vertex processors, etc.
en
ta 0
* Texture filtering in the floating-point format
e
j
3.
ar
* Supports framebuffer in the floating-point format (including blending operations)
a t SM
r
* MRT (Multiple Render Targets - rendering into several buffers)
e el
im
* 2x RAMDAC 400 MHz
pr tar
La opor
* 2x DVI interfaces (require external chips)
s
* TV-Out and TV-In interface (requires separate chips)
* Programmable streaming GPU (for video compression, decompression and post-processing)
* 2D accelerator supporting all GDI+ functions
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
44 /
44/7070
Serie 6: En detalle
Chipset
PCI-E
HSI Chip
AGP
Memoria local de la tarjeta y “acelerador”
Buffer Z,
stencil y
de frame
Texturas
Geometría
DDR/GDDR-2/3
Conmutador
Selector de vértice
Caché del buffer normal
y Z, cola de escritura
Caché de vértices
6 Procesadores de vértices
Conjuntos de fragmentos,
Interpolación
Mini Z buffer
Caché post-vértice
Conjuntos de triángulos
Procesador de video y 2D
David Miraut Andrés
Cache de textura L2
4 x cuadruples procesadores
de fragmentos (16 pix.)
4 x quad pool
4 x TMU
Cache de textura L1
Fragmento HSR
4 x 2 x ALU
División en
fragmentos
Blending, Z, Stencil, AA
2 x CRTC, 2 x RAMDAC, DVI, etc...
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
45 /
45/7070
Serie 6: En detalle
Chipset
PCI-E
HSI Chip
Memoria local de la tarjeta y “acelerador”
Buffer Z,
stencil y
de frame
AGP
Texturas
Geometría
DDR/GDDR-2/3
Conmutador
Selector de vértice
Caché del buffer normal
y Z, cola de escritura
Caché de vértices
Dos niveles
de caché!
6 Procesadores de vértices
Conjuntos de fragmentos,
Interpolación
Mini Z buffer
Caché post-vértice
HSR de fragmentos
(Hidden/Hardware Surface Removal)
Conjuntos de triángulos
División en
fragmentos
Procesador de video y 2D
David Miraut Andrés
Arquitecturas streaming comerciales
Cache de textura L2 Novedades a
simple vista
4 x cuadruples procesadores
de fragmentos (16 pix.)
4 x quad pool
4 x TMU
Cache de textura L1
4 x 2 x ALU
Blending, Z, Stencil, AA
(mezcla)
2 x CRTC, 2 x RAMDAC, DVI, etc...
Caso de estudio: GeForce 6800
46 /
46/7070
Serie 6: Comunicación con la CPU
En primer lugar los datos relativos a comandos (sueltos, como
programas ó shaders), texturas y listas de vértices se reciben
desde la CPU (host) a través de bufferes de memoria
compartidos en la memoria de sistema (comunic. via
AGP/PCI-E) ó la memoria del frame-buffer local (realimentación)
Un stream de comandos
se envía desde la CPU para inicializar y modificar
el estado de los procesadores, enviar los comandos
de representación, las referencias de texturas y los
datos de los vértices
Los comandos son interpretados y la unidad de recogida de
vértices se utiliza para leer los vértices que han sido referenciados
en los comandos de representación.
Los comandos, vértices y cambios de estado “fluyen” a través de
las siguientes etapas del cauce gráfico (pipeline)
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
47 /
47/7070
Serie 6: Procesadores de vértices
Los llamados procesadores de vértices permiten
aplicar un programa a cada vértice en un objeto,
aplicar transformaciones, skinning (displacement
mapping) y cualquier otra operación por-vértice
que deseemos en nuestros programas (dentro de
las limitaciones de la arquitectura).
La principal novedad en las GPUs de la serie 6 es la posibilidad
de que los procesadores de vértices puedan acceder a la
memoria de texturas.
Todas las operaciones son realizadas
en coma flotante y 32 bits por componente
(normalmente vectores de 4 elementos).
Es una arquitectura escalable podemos
tener un número variable de proc. de
vértices (activados/no capados) en el chip.
Seis procesadores en las tarjetas de la familia 6800 de gama alta
Entrada de datos
de vértices
Recogida
(Fetch) de
texturas de
vértices
Unidad
FP32
Escalar
Unidad
FP32
Vectorial
Unidad de
ramiificación
Caché de
textura
Ensamblado
de primitivas
Procesado relativo
al punto de vista
A la siguiente
etapa del pipeline
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
48 /
48/7070
Serie 6: Procesadores de vértices
El acceso a la memoria de texturas se realiza por conexión directa
a la memoria caché de texturas (L2) que comparten con los
procesadores de fragmentos.
Además, tenemos cachés “sofisticadas” ANTES y DESPUÉS
de los procesadores para reducir los accesos a memoria de tarjeta
(y bus PCI-E). Veamos un ejemplo, si la llamada a un mismo
vértice ocurre dos veces (muy típico en las tiras de triángulos) no
tenemos que volver a ejecutar todo el programa en el procesador
de nuevo, basta con utilizar el resultado de la caché.
Los vértices son agrupados en primitivas (puntos, lineas y
triángulos). los bloques Cull/Clip/Setup hacen operaciones a
nivel de primitivas, eliminando aquellas que no son visibles en
absoluto, “recortando” aquellas que intersecan con el volumen de
visualización (frustrum) y preparando las ecuaciones de
proyección y plano para dejarselo mascado a la etapa de
rasterización.
49
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
/
49/7070
Ejemplo típico de shader de vértices en Cg
twistling = 4,25
La forma en la que
se le pasan los
datos a la primera
etapa del cauce es
crucial para el
rendimiento de
toda la cadena
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
50 /
50/7070
Serie 6: El “acelerador”
En las trasparencias anteriores vimos un bloque llamado
acelerador, aunque es general vamos a ver su importancia en el
caso de los procesadores de vértices.
Los programas de los procesadores de vértices
tienen una serie de parámetros que desde
el punto de vista de la API pueden ser escalares
y vectores de hasta 4D (en coma flotante o
supuestos enteros)
Pero el programador debe especificar los registros que van a
recibir esos datos en el proc. de vértices (y evitar movimientos
redundantes)
Estos datos en la arquitectura de la serie 6 pueden venir de
varios flujos simultáneamente (hasta 16) con uno o varios
parámetros cada uno.
Chipset
PCI-E
HSI Chip
AGP
Memoria local de la tarjeta y “acelerador”
Buffer Z,
stencil y
de frame
Texturas
Geometría
DDR/GDDR-2/3
Conmutador
Selector de vértice
Caché del buffer normal
y Z, cola de escritura
Caché de vértices
6 Procesadores de vértices
Conjuntos de fragmentos,
Interpolación
Mini Z buffer
Caché post-vértice
Conjuntos de triángulos
Procesador de video y 2D
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
Cache de textura L2
4 x cuadruples procesadores
de fragmentos (16 pix.)
4 x quad pool
4 x TMU
Cache de textura L1
Fragmento HSR
4 x 2 x ALU
División en
fragmentos
Blanding, Z, Stencil, AA
2 x CRTC, 2 x RAMDAC, DVI, etc...
51 /
51/7070
Serie 6: El “acelerador”
El acelerador trata de organizar los datos de modo que se
aproveche la localidad en las cachés y que el sistema sea
inteligente pudiendo utilizar los mismos conjuntos de datos (por
separado) para diferentes objetos.
La utilización de listas de vértices (o valores de texturas) para
hacer indirecciones descabala bastante este esquema.
Estructura de datos de un sólo vértice
B
A
Hebra/Flujo datos 1
D
Hebra/Flujo datos 2
E
Hebra 3 (desde el bus AGP)
A1
B1
C1
D1
E1
A2
B2
C2
D2
E2
A3
B3
C3
D3
E3
A4
B4
C4
D4
E4
Bn
Cn
...
An
...
ej. vectores de coordenadas
de vectores y normales
David Miraut Andrés
C
ej. vectores de coord.
de texturas
Arquitecturas streaming comerciales
...
Dn
En
ej. parámetros no geométricos (como twistling)
Caso de estudio: GeForce 6800
52 /
52/7070
Serie 6: El “acelerador”
Una de las más importantes mejoras
en la serie 6 es la introducción
del Frequency Stream Divider
que permite controlar la velocidad
del flujo de los parámetros y
datos de entrada en los procesadores
tratando de aprovechar al máximo
sus diferentes anchos de banda.
...
...
...
Si comprimimos la geometría
mediante relaciones jerarquicas, o
tenemos cuidado al diseñar nuestras estructuras de datos
podemos ganar mucho en este sentido.
Vértices seleccionados
C1
D1
E1
B2
C1
D1
E1
B3
C2
D1
E1
A4
B4
C2
D1
E1
A5
B5
C3
D2
E2
A
B
D
E
A1
B1
A2
A3
Hebra 1
C
Hebra 2 (/2)
Hebra 3 (/4) (desde AGP)
A1
B1
C1
D1
E1
A2
B2
C2
D2
E2
A3
B3
C3
D3
E3
A4
B4
C4
D4
E4
An
Bn
Cn
Dn
En
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
53 /
53/7070
Serie 6: Las tripas del procesador de vértices
Los seis procesadores son completamente independientes, con
sus propias instrucciones y lógica de control.
Esto es, pueden ejecutar diferentes condiciones de
ramificación simultáneamente (impensable hasta la aparición de
este modelo).
Datos tomados y datos de caché
Control de ejecución
Caché de
texturas L2
TMU
6 procesadores
FP32 ALU
FP32[4] ALU
Registros
Cache de post-datos y ensamblado de triángulos
Culling de vértices (para visibilidad)
Conjunto de triángulos
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
54 /
54/7070
Serie 6: Las tripas del procesador de vértices
En un sólo pulso de reloj:
• una operación vectorial (hasta 4 componentes FP32)
• una operación escalar (Fp32)
• un acceso a textura (sin filtrado, sólo nearest value)
La interfaz a las TMU está muy simplificada en la etapa de
vértices.
No apenas hay apenas restricciones en el número de comandos
(instrucciones) a ejecutar en un programa, aunque la API puede
imponerlos (como el caso de DX9)
Versión del Shader Model Vertex
Número de instrucciones en el
código del procesador
Númemro de instrucciones
ejecutables
David Miraut Andrés
2.0 (R 3 XX)
2. a (NV 3 X)
3.0 (NV40)
256
256
512 y más
65535 y más
65535
65535
Predicados
No
Sí
Sí
Registros temporales
12
13
32
Registros constantes
256 y más
256 y más
256 y más
Saltos estáticos
Sí
Sí
Yes
Ramificación condicional
No
Sí
Yes
Profundidad anidada en los saltos
dinámicos (y ramificación cond.)
No
24
24
Número de texturas accesibles
No
No
Sí (4)
Arquitecturas streaming comerciales
Caso de estudio: GeForce 6800
55 /
55/7070
nVIDIA GeForce 7800 y RSX
302 millones de transistores y un nuevo
nombre clave en el chip ¿significa eso
cambios importantes en la arquitectura?
Ya no hay HSI, soporta
directamente PCI-E
2 proc. más
de vértices
(2x4) = 8
proc. más de
fragmentos
Es el chip gráfico de la PS3
David Miraut Andrés
Arquitecturas streaming comerciales
Caso de estudio: GeForce 7800
56 /
56/7070
Cambios arquitecturales en la serie 7
Lo primero que salta a la vista
es que sólo ha aumentado 30
MHz la velocidad del reloj, eso
sumado al aumento en el no
de transistores y la capacidad,
nos da pistas de la revisión del
nuevo diseño de procesadores
de vértices y fragmentos.
Tras un estudio con 1300 shaders programados por
desarrolladores de distintas compañías se han analizado los
cuellos de botella de la anterior arquitectura y se han tratado de
solventar en el G70.
Manufacturing
technology
Number of transistors
Clock frequency
Graphics memory
controller
Graphics memory
clock frequency
Memory bus peak
bandwidth
Maximum graphics
memory size
Interface
David Miraut Andrés
Arquitecturas streaming comerciales
NVIDIA
GeForce 7800
GTX
NVIDIA
GeForce 6800
Ultra
ATI RADEON X850
XT Platinum Edition
0.11 micron
0.13 micron
0.13 micron low-k
302 mln.
430MHz
256bit GDDR3
SDRAM
222 mln.
400MHz
256bit GDDR3
SDRAM
160 mln.
520MHz
1200 MHz
1100 MHz
1180 MHz
34GB/s
32.8GB/s
33.4GB/s
512MB
512MB
512MB
PCI Express x16
PCI Express x16
PCI Express x16
Caso de estudio: GeForce 7800
256bit GDDR3 SDRAM
57 /
57/7070
Serie 7: Procesadores de vértices
Pasamos de 6 a 8 procesadores de
vértices y en ellos se mejora mucho
el sistema de comunicación con la
memoria de texturas y las unidades
de proceso vectorial y escalar.
(más de un 30% de eficiencia en cada bloque)
Así mismo las unidades de
mezcla han sido rediseñadas
permitiendo hacer HDR un
60% más rápido (ahora es
factible sin necesidad de SLI)
El algoritmo de filtrado
anisotrópico se ha optimizado
(simplificado) y hay a quien no
le gusta (se puede desactivar)
Entrada de datos
de vértices
Recogida
(Fetch) de
texturas de
vértices
La frecuencia de trabajo en
los procesadores de vértices
ahora es distinta y mayor
que la de fragmentos
Caché de
textura L2
Se ha hecho un gran esfuerzo en mejorar
no sólo el rendimiento sino también la
calidad, de ahí los nuevos modos FSAA de
antialiasing a pantalla completa (para quitar
los artefactos de pequeños objetos: césped, pelo..)
David Miraut Andrés
Arquitecturas streaming comerciales
Unidad
FP32
Escalar
Unidad
FP32
Vectorial
Unidad de
ramiificación
Ensamblado
de primitivas
Procesado relativo
al punto de vista
A la siguiente
etapa del pipeline
Caso de estudio: GeForce 7800
58 /
58/7070
El procesador de vértices desde una perspectiva
funcional
El procesador de vértices
reemplaza algunas tareas clave
de la etapa de funcionalidad fija:
pasa a ser resposable de ellas
• Parámetros de entrada:
Coordenadas
de vértices
Atributos
de variables
Variables
Uniform
Shader de
vértices
Variables
de salida
gl_Position
Texturas
◦ Los atributos (atribute variables) de entrada son read-only
◦ Las variables uniform son constantes a lo largo de la primitiva
gráfica y también read-only para todos los tipos de shaders
◦ Las coordenadas de textura se suelen dejar pasar a través
•
A partir de SM 3.0 las podemos utilizar para crear efectos como
mapas de desplazamiento
• Parámetros de salida:
◦ Al menos los necesarios para rasterización: la posición y el
color del vértice
◦ Podemos utilizar otros atributos para dar información a las
David Miraut etapas
Andrés
Arquitecturas streaming comerciales Perspectiva funcional - Shader vértices
siguientes
59 /
59/7070
Ejemplo de shader de vértices en GLSL
Se pasan las coordenadas en el sistema de coordenadas del
mundo ó de la camara en función de un flag. Después en el
shader de fragmentos se colorea en función de dichas
coordenadas.
uniform bool
out vec4
out float
out float
uUseModelCoords;
vColor;
vX, vY, vZ;
vLightIntensity;
void
main( )
{
vec3 TransNorm = normalize( uNormalMatrix * aNormal );
vec3 LightPos = vec3( 0., 0., 10. );
vec3 ECposition = ( uModelViewMatrix * aVertex ).xyz;
vLightIntensity = dot(normalize(LightPos - ECposition),
TransNorm);
vLightIntensity = abs( vLightIntensity );
vColor = aColor;
vec3 MCposition = aVertex.xyz;
if( uUseModelCoords )
{
vX = MCposition.x;
vY = MCposition.y;
vZ = MCposition.z;
}
else
{
vX = ECposition.x;
vY = ECposition.y;
vZ = ECposition.z;
}
gl_Position = uModelViewProjectionMatrix * aVertex;
Tetera cuyos colores vienen determinados por las coordenadas
del mundo (arriba) y con las de la cámara/ojo (abajo)
}
David Miraut Andrés
Arquitecturas streaming comerciales
Perspectiva funcional - Shader vértices
60 /
60/7070
Ejemplo de la práctica 1
Como comprobaremos en la práctica 1, un shader de vértices
puede modificar las coordenadas que recibe. Éste procesado se
hace vértice por vértice de forma independiente.
No puede crear
nueva geometría (para eso utilizaremos
los shaders de teselación y geometría).
Cuando modificamos las coordenadas de los
puntos 3D que definen las mallas, tenemos
que ser cuidadosos y volver a recalcular las normales. Aunque
esta operación puede ser realizada fragmento fragmento, es
necesario que aportemos la información adecuada desde el shader
de vértices.
¿lo podemos hacer en todos los casos?
Superficie con normales que pueden ser calculadas de forma analítica
David Miraut Andrés
Arquitecturas streaming comerciales
Perspectiva funcional - Shader vértices
61 /
61/7070
Etapas de funcionalidad fija tras el procesador
de vértices
Por ahora algunas de las tareas críticas en la etapa de
transformación son realizadas por unidades funcionales que
mantienen la arquitectura streaming (por ello hemos hecho mayor
énfasis al revisar los modelos “pioneros”):
• Todo el clipping, tanto el del volumen de visualización,
definido por el usuario
• la división por coordenadas homogéneas
• el procesamiento directamente relacionado con el viewport
• el escalado del rango de profundidad
• la eliminación de primitivas que pueden quedar ocultas, total o
parcialmente
El ensamblado de primitivas se lleva a cabo una vez terminado el
procesador de vértices y antes de enviarse al resto de etapas
(como las formadas por shaders de teselación ó geometría en
62 /
arquitectura
unificada)
David
Miraut Andrés
Arquitecturas streaming comerciales Perspectiva funcional - Shader vértices
62/7070
Arquitectura
“unificada”:
Cauce gráfico
“actual”
David Miraut Andrés
Etapas de transformación en arquitectura unificada
63 /
63/7070
Geforce GTX680: ¿Dónde está la etapa de
Transformación?
David Miraut Andrés
Etapas de transformación en arquitectura unificada
Caso de estudio: GeForce 680GTX
64 /
64/7070
Cauce gráfico en Arquitectura Unificada
Desde el punto de vista de las APIs (OpenGL)
Shader de vértices
Variables
entr./salid
Ensamblado de primitivas
Shader de control de teselación
Variables
entr./salid
Variables (atributos)
por vértice
Variables
Uniform
Generador de primitivas de teselación
Shader de evaluación de teselación
Variables
entr./salid
Ensamblado de primitivas
Shader de Geometría
Ensamblado de primitivas
Variables
entr./salid
Rasterizador
Shader de fragmentos
David Miraut Andrés
Etapas de transformación en arquitectura unificada
Caso de estudio: GeForce 680GTX
65 /
65/7070
Geforce GTX680: ¿Dónde están los procesadores
de vértices?
Fijaros nosotros programamos para 3
"procesadores" en la etapa de
Transformación:
• Shaders de vértices
• Shaders de teselación
• Shaders de geometría
Y en este esquema intervienen dos
partes con diferente diseño (desde el
punto de vista en Arquitectura)
David Miraut Andrés
Etapas de transformación en arquitectura unificada
Caso de estudio: GeForce 680GTX
66 /
66/7070
Etapa de Teselación
EN EL SIGUIENTE BLOQUE DE TRANSPARENCIAS
David Miraut Andrés
Etapas de transformación en arquitectura unificada
Etapa de Teselación
67 /
67/7070
Bibliografía sobre arquitecturas pioneras en la
etapa de Transformación
• High-Performance Polygon Rendering, Akeley and Jermoluk,
Proceedings of SIGGRAPH ’88.
• RealityEngine Graphics, Akeley, Proceedings of SIGGRAPH
‘93.
• InfiniteReality: A Real-Time Graphics System, Montrym,
Baum, Dignam, and Migdal, Proceedings of SIGGRAPH ’97.
• Stream Processor Architecture. Scott Rixner. Springer
David Miraut Andrés
Etapas de transformación en arquitectura unificada
Bibliografía
68 /
68/7070
Bibliografía sobre arquitecturas streaming
comerciales
• Procesadores gráficos para PC. Manuel Ujaldón Martínez.
Ciencia 3
• GPU Gems 2: Programming Techniques for High-Performance
Graphics and General-Purpose Computation. Matt Pharr,
Randima Fernando, Tim Sweeney.
• OpenGL Shading Language. Randi J. Rost. 3rd Edition.
Addison-Wesley Professional
• Real-Time Rendering. Tomas Akenine-Moller, Eric Haines,
Naty Hoffman. Third Edition. AK Peters
• The Cg Tutorial: The Definitive Guide to Programmable
Real-Time Graphics, de Randima Fernando y Mark J. Kilgard.
• Advanced Lighting and Materials with Shaders. Kelly
Dempski. Jones & Bartlett Publishers
• Interactive Computer Graphics: A Top-Down Approach with
69 /
Shader-Based
Angel,
Shreiner. 6th
David Miraut
Andrés
Etapas OpenGL.
de transformaciónEdward
en arquitectura
unificada Dave
Bibliografía
69/7070
Bibliografía sobre arquitectura unificada
• Computer Architecture: A Quantitative Approach. J. Hennessy
and D. Patterson. Fourth edition. Morgan-Kaufmann
• Graphics Shaders: Theory and Practice. Mike Bailey, Steve
Cunningham. Second Edition. A K Peters/CRC Press
• Programming Massively Parallel Processors – A Hands-on
Approach. D. B. Kirk and W. W. Hwu. Morgan Kaufmann.
David Miraut Andrés
Etapas de transformación en arquitectura unificada
Bibliografía
70 /
70/7070