tema 2.2 et ap a de e implement a ciÓn hard w are · tema 2.2 et ap a de transforma ciÓn e...

TEMA 2.2ETAPA DE

TRANSFORMACIÓN E IMPLEMENTACIÓN

HARDWARE

Curso 2013 / 14Procesadores 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/701/70

Evolución del cauce gráfico

Fuente: Intel

David Miraut Andrés Etapa de Transformación e implementación Hardware Índice inicial 2/702/70

Un tour en tres etapas

Arquitecturas pioneras:

Cauce gráficode funcionalidad fija

Cauce gráficoprogramable

Arquitecturascirculantes:

Cauce gráfico“actual”

Arquitectura“unificada”:

Futuro inmediato:

“Cauce”gráficoa medida con

total flexibilidad

Una mayor flexibilidad implicauna mayor responsabilidad en el proceso de la síntesis de la imagen: Es necesario dominartodos los pasos para ir más allá

Nos meteremos en la piel de un diseñador de chips gráficos


Esquema de bloques de la GeForce GTX480

Una parte más grande e importantede lo que nos muestran los fabricantes sigue manteniendo lafilosofía streaming

Precisamente la que es másdifícil de “pasar a SW” porel elevado tráfico de memoria

Nos enfocaremos en ella al tratar las arquitecturas “pioneras”


Acerca de los Shader Models

La evolución de la arquitectura de las tarjetas no es errática yaleatoria, aumentando sin parar la potencia a base de frec. dereloj y más procesadores, sino que obedece a la presión especificadel 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


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 porsuperación técnica y se llegaba a un cierto acuerdo entrefabricantes (habia pocos y no mucho interés en este campo).

• El mercado de los juegos fue creciendo y con él el interés eneste tipo de productos, cada fabricante proponía sus solucionesincompatibles con los demás para ganar cuota de mercado (ytorturar a los programadores que tenían que hacer un driverpara cada tarjeta en el juego). VESA trató de unificar sinmucho éxito y el embrión de OpenGL era demasiado pesadopara aquellos ordenadores

• Después vino 3DFX, arrasó y los fabricantes que sobrevivieronintentaron seguir un standard (3DFX tenía GLIDE) y OpenGLfue cogiendo fuerza. Ese fue el primer marco común, pero erainsuficiente basarse en una API para crear tarjetas. . .

David Miraut Andrés Etapa de Transformación e implementación Hardware Shader Models 6/706/70

Shader Models

Por ello aparecieron los Shader Models a modo deespecificaciones de comités técnicos que establecían un marcocomún de funcionalidades gráficas requeridas por las compañíasde videojuegos, plasmadas en forma de requisitos de hardware delas etapas del pipelineCada versión de Shader Model incluye y añade mejoras a laspropuestas anteriores. Son un acuerdo común entre losprincipales creadores de GPUs y las compañías que desarrollan lasAPIs para hacer accesibles esas funcionalidades.


Ejemplos de visualización con diferentes ShaderModels


Arquitecturas pioneras:

Cauce gráficode funcionalidad fija

David Miraut Andrés Arquitecturas streaming puras 10/7010/70

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/7011/70

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)


Transformación de coordenadas

Matriz 4× 4 en coordenadas homogéneas Típicamente en puntoflotante de simple precisión Las matrices se pueden componer:• En la aplicación• Dentro del propio cauce◦ Hay que tener cuidado con la invarianza

m11 m12 m13 m14

m21 m22 m23 m24

m31 m32 m33 m34

m41 m42 m42 m44

x

y

z

w

x’

y’

z’

w’

=


Transformación de las normales(n′x , n′y , n′z) = (nx , ny , nz)M−1

u

Mu = parte superior izquierda 3× 3 de M(0.0)

• Estrategias para obtener M−1u

◦ 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


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

• El objeto puede tener dos caras◦ Se calcula para n y −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!

n

l

-n


No hay interdependenciasLas 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)



Operaciones sobre primitivas

Ensamblado de primitivas

Clipping

Eliminación caras posteriores

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

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/7018/70


• El ensamblado se hace de acuerdo con los comandos enviadosdesde 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)


Clipping

• Dos tipos:◦ Punto, línea: elimina geometría◦ Polígono: elimina e introduce nuevas aristas

Segmentos de línea Polígono


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


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 lasecuencia nos ayuda a mejorar la eficiencia?

x0,y0 x1,y1

x2,y2


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/7023/70

Clark Geometry Engine (1983)

• Capacidades de 1a generación• Cauce gráfico simple de funcionalidadfija◦ 12 engines idénticos◦ Configurados por SW al inicio

• La etapa de clipping requiere la mitadde la potencia total◦ Rendimiento invariante (bueno)◦ Típicamente idle (malo)

Coordinate

Transform

6-plane

Frustum

Clipping

Divide by w

Viewport

Extraído de la presentación deKurt Akeley y Pat Hanrahan


GTX Geometry Engine (1988)

• 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 potenciade 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)

Coord, normal

Transform

Lighting

Clip testing

Clipping state

Divide by w

(clipping)

Viewport

Prim. Assy.

Backface cull



RealityEngine Geometry (1992)

• Capacidades de 3a generación• Organización con funcionalidad variableMIMD◦ 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

Command Processor

Round-robin Aggregation



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


InfiniteReality Geometry (1996)

• Capacidades de 3a generación• Organización con funcionalidad variableMIMD◦ 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

Command Processor

Sequence Token Aggregation



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


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


Guard-Band Clipping

Viewport

Guard-band

Renderizado

Descartado

Recortado (Clipped)


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 SIMDPero, ¿se podría programar un shader aquí?


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 deseode complicar el diseño de las GPUs

Pero lo más importante:• Se reduce el volumen de información que hay que comunicarentre CPU y GPU (un recurso muy escaso)


Idea básica

Prim. Generate

Command

Geometry

Rasterization

Texture

Fragment

Display

Application


• 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• Modos• Valores de los datos (potencialmente puede

ser una gran cantidad)◦ Se ejecuta la función de generación• Comandos en modo-bloque• Comandos para vértices

• La geometría generada se trata como sihubiese sido descrita explícitamente por laaplicación en las siguientes etapas


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


“Cosido” de parches

4x4 Parche 5x5 Parche



“Cosido” de parches

4x4 Parche 5x5 Parche

Vértices introducidos para “coser”



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 (ymenos en una GPU)

¿Dónde deberíamos colocar la generación de primitivas?


¿Dónde colocamos la generación de primitivas?

• En los engines de geometría de la etapa deTransformación◦ En aquella época podía reducirse el throughput en el

volumen de vértices procesados• 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◦ Complica la gestión de estados• El Command Processor gestionaba esto

• OpenGL nos da cierta libertad◦ La semantica no nos restringe en este sentido

Command Processor




¿Dónde colocamos la generación de primitivas?

• En un procesador adicional◦ Requiere invertir recursos y tiene funcionalidadfija dentro del cauce• Estará de brazos cruzados en una ejecución normal

◦ Puede serializar la configuración/ejecución• Si no se diseña con doble buffer o algo semejante

◦ Sìmplifica• El equilibrado de carga del GE• La gestión de estados

• Parece una nueva etapa del cauce◦ La función del Command Procesor se divide

Command Processor2


Primitive Generation

?

Command Processor



Otras estrategias de reducción de datos• Hace mucho tiempo que se vienen proponiendo cosassemejantes a vertex buffer objects. Hoy día estánimplementados 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 (StochasticDepth Buffer Compression using Generalized Plane Encoding).

En sistemas comerciales para el mercado doméstico hay quetener mucho cuidado en qué se ofrece, pues una vez se da unafuncionalidad está debe mantenerse a lo largo del tiempo(compatibilidad hacia atrás)


Cauce gráficoprogramable

Arquitecturascirculantes comerciales:

David Miraut Andrés Arquitecturas streaming comerciales 42/7042/70

nVIDIA GeForce 6800

Aplicación

Comandos

Geometría

Rasterización

Texturas

Fragmentos

Visualización

Etapas

Arquitectura GeForce 6800

Comparación y tests de prof.

y blending

API

David Miraut Andrés Arquitecturas streaming comerciales Caso de estudio: GeForce 6800 43/7043/70

Especificaciones de la GeForce 6800 * Chip codenamed NV40 * 130nm FSG (IBM) technology * 222 million transistors * FC case (flip chip with no metallic cover) * 256-bit memory interface * 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. * Texture filtering in the floating-point format * Supports framebuffer in the floating-point format (including blending operations) * MRT (Multiple Render Targets - rendering into several buffers) * 2x RAMDAC 400 MHz * 2x DVI interfaces (require external chips) * 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

Lo que se leeen la caja y el

manual cuandouno lo adquiere

La primera

tarje

ta en

soporta

r el S

M 3.0


Serie 6: En detalleChipset

PCI-E

HSI Chip

Memoria local de la tarjeta y “acelerador”

Texturas GeometríaBuffer Z,stencil yde frame

DDR/GDDR-2/3

Conmutador

AGP

Selector de vértice

Caché de vértices

Caché del buffer normal y Z, cola de escritura Cache de textura L2

Caché post-vértice

Conjuntos de triángulos

Mini Z buffer

Conjuntos de fragmentos,Interpolación

Fragmento HSR

División enfragmentos

Procesador de video y 2D

6 Procesadores de vértices

4 x cuadruples procesadoresde fragmentos (16 pix.)

Blending, Z, Stencil, AA

4 x 2 x ALU

Cache de textura L1

4 x TMU

4 x quad pool

2 x CRTC, 2 x RAMDAC, DVI, etc...


Serie 6: En detalleChipset

PCI-E

HSI Chip



DDR/GDDR-2/3

Conmutador

AGP


Caché de vértices




Mini Z buffer


HSR de fragmentos





Blending, Z, Stencil, AA

4 x 2 x ALU

Cache de textura L1

4 x TMU

4 x quad pool


Dos niveles de caché!

Novedades a simple vista

(Hidden/Hardware Surface Removal)

(mezcla)


Serie 6: Comunicación con la CPUEn primer lugar los datos relativos a comandos (sueltos, comoprogramas ó shaders), texturas y listas de vértices se recibendesde la CPU (host) a través de bufferes de memoriacompartidos en la memoria de sistema (comunic. viaAGP/PCI-E) ó la memoria del frame-buffer local (realimentación)Un stream de comandosse envía desde la CPU para inicializar y modificarel estado de los procesadores, enviar los comandosde representación, las referencias de texturas y losdatos de los vérticesLos comandos son interpretados y la unidad de recogida devértices se utiliza para leer los vértices que han sido referenciadosen los comandos de representación.Los comandos, vértices y cambios de estado “fluyen” a través delas siguientes etapas del cauce gráfico (pipeline)


Serie 6: Procesadores de vérticesLos llamados procesadores de vértices permitenaplicar un programa a cada vértice en un objeto,aplicar transformaciones, skinning (displacementmapping) y cualquier otra operación por-vérticeque deseemos en nuestros programas (dentro delas limitaciones de la arquitectura).La principal novedad en las GPUs de la serie 6 es la posibilidadde que los procesadores de vértices puedan acceder a lamemoria de texturas.

Caché detextura

Unidad de ramiificación


Procesado relativoal punto de vista

Entrada de datosde vértices

A la siguiente etapa del pipeline

Recogida(Fetch) detexturas de

vértices

Unidad FP32

Escalar

UnidadFP32

Vectorial

Todas las operaciones son realizadasen coma flotante y 32 bits por componente(normalmente vectores de 4 elementos).Es una arquitectura escalable podemostener un número variable de proc. devértices (activados/no capados) en el chip.Seis procesadores en las tarjetas de la familia 6800 de gama alta


Serie 6: Procesadores de vérticesEl acceso a la memoria de texturas se realiza por conexión directaa la memoria caché de texturas (L2) que comparten con losprocesadores de fragmentos.Además, tenemos cachés “sofisticadas” ANTES y DESPUÉSde los procesadores para reducir los accesos a memoria de tarjeta(y bus PCI-E). Veamos un ejemplo, si la llamada a un mismovértice ocurre dos veces (muy típico en las tiras de triángulos) notenemos que volver a ejecutar todo el programa en el procesadorde nuevo, basta con utilizar el resultado de la caché.Los vértices son agrupados en primitivas (puntos, lineas ytriángulos). los bloques Cull/Clip/Setup hacen operaciones anivel de primitivas, eliminando aquellas que no son visibles enabsoluto, “recortando” aquellas que intersecan con el volumen devisualización (frustrum) y preparando las ecuaciones deproyección y plano para dejarselo mascado a la etapa derasterización.


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


Serie 6: El “acelerador”En las trasparencias anteriores vimos un bloque llamadoacelerador, aunque es general vamos a ver su importancia en elcaso de los procesadores de vértices.

Chipset

PCI-E

HSI Chip



DDR/GDDR-2/3

Conmutador

AGP


Caché de vértices




Mini Z buffer


Fragmento HSR





Blanding, Z, Stencil, AA

4 x 2 x ALU

Cache de textura L1

4 x TMU

4 x quad pool


Los programas de los procesadores de vérticestienen una serie de parámetros que desdeel punto de vista de la API pueden ser escalaresy vectores de hasta 4D (en coma flotante osupuestos enteros)Pero el programador debe especificar los registros que van arecibir esos datos en el proc. de vértices (y evitar movimientosredundantes)Estos datos en la arquitectura de la serie 6 pueden venir devarios flujos simultáneamente (hasta 16) con uno o variosparámetros cada uno.


Serie 6: El “acelerador”El acelerador trata de organizar los datos de modo que seaproveche la localidad en las cachés y que el sistema seainteligente pudiendo utilizar los mismos conjuntos de datos (porseparado) para diferentes objetos.La utilización de listas de vértices (o valores de texturas) parahacer indirecciones descabala bastante este esquema.

A1

A2

A3

A4

An

A B

B1

B2

B3

B4

Bn

C

C1

C2

C3

C4

Cn

D

D1

D2

D3

D4

Dn

E

E1

E2

E3

E4

En

Hebra/Flujo datos 1 Hebra/Flujo datos 2 Hebra 3 (desde el bus AGP)

Estructura de datos de un sólo vértice

... ... ...

ej. vectores de coordenadas de vectores y normales

ej. vectores de coord.de texturas

ej. parámetros no geo-métricos (como twistling)


Serie 6: El “acelerador”

A1

A2

A3

A4

An

B1

B2

B3

B4

Bn

C1

C2

C3

C4

Cn

D1

D2

D3

D4

Dn

A B C D E

A5 B5 C3 D2 E2

A3 B3 C2 D1 E1

A2 B2 C1 D1 E1

A1 B1 C1 D1 E1

A4 B4 C2 D1 E1

E1

E2

E3

E4

En

Hebra 1 Hebra 2 (/2) Hebra 3 (/4) (desde AGP)

Vértices seleccionados

... ... ...

Una de las más importantes mejorasen la serie 6 es la introduccióndel Frequency Stream Dividerque permite controlar la velocidaddel flujo de los parámetros ydatos de entrada en los procesadorestratando de aprovechar al máximosus diferentes anchos de banda.Si comprimimos la geometríamediante relaciones jerarquicas, o

tenemos cuidado al diseñar nuestras estructuras de datospodemos ganar mucho en este sentido.


Serie 6: Las tripas del procesador de vérticesLos seis procesadores son completamente independientes, consus propias instrucciones y lógica de control.Esto es, pueden ejecutar diferentes condiciones deramificación simultáneamente (impensable hasta la aparición deeste modelo).

Control de ejecución 6 procesadores

Datos tomados y datos de caché

Caché de texturas L2 TMU FP32 ALU FP32[4] ALU

Cache de post-datos y ensamblado de triángulos

Culling de vértices (para visibilidad)

Conjunto de triángulos

Registros


Serie 6: Las tripas del procesador de vérticesEn 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 devértices.No apenas hay apenas restricciones en el número de comandos(instrucciones) a ejecutar en un programa, aunque la API puedeimponerlos (como el caso de DX9)

Versión del Shader Model Vertex 2.0 (R 3 XX) 2. a (NV 3 X) 3.0 (NV40)

Número de instrucciones en el código del procesador

256 256 512 y más

Númemro de instrucciones ejecutables

65535 65535 65535 y más

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)

David Miraut Andrés Arquitecturas streaming comerciales Caso de estudio: GeForce 6800 55/70

55/70

nVIDIA GeForce 7800 y RSX302 millones de transistores y un nuevo nombre clave en el chip ¿significa eso cambios importantes en la arquitectura?

2 proc. más de vértices

(2x4) = 8 proc. más de fragmentos

Ya no hay HSI, soporta directamente PCI-E

Es el chip gráfico de la PS3David Miraut Andrés Arquitecturas streaming comerciales Caso de estudio: GeForce 7800 56/70

56/70

Cambios arquitecturales en la serie 7

NVIDIA

GeForce 7800 GTX

NVIDIA GeForce 6800

Ultra

ATI RADEON X850 XT Platinum Edition

Manufacturing technology

0.11 micron 0.13 micron 0.13 micron low-k

Number of transistors 302 mln. 222 mln. 160 mln.

Clock frequency 430MHz 400MHz 520MHz

Graphics memory controller

256bit GDDR3 SDRAM

256bit GDDR3 SDRAM

256bit GDDR3 SDRAM

Graphics memory clock frequency

1200 MHz 1100 MHz 1180 MHz

Memory bus peak bandwidth

34GB/s 32.8GB/s 33.4GB/s

Maximum graphics memory size

512MB 512MB 512MB

Interface PCI Express x16 PCI Express x16 PCI Express x16

Lo primero que salta a la vistaes que sólo ha aumentado 30MHz la velocidad del reloj, esosumado al aumento en el no

de transistores y la capacidad,nos da pistas de la revisión delnuevo diseño de procesadoresde vértices y fragmentos.Tras un estudio con 1300 shaders programados pordesarrolladores de distintas compañías se han analizado loscuellos de botella de la anterior arquitectura y se han tratado desolventar en el G70.


Serie 7: Procesadores de vértices

Caché detextura L2

Unidad de ramiificación


Procesado relativoal punto de vista

Entrada de datosde vértices

A la siguiente etapa del pipeline

Recogida(Fetch) detexturas de

vértices

Unidad FP32

Escalar

UnidadFP32

Vectorial

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 unidadesde 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 un60% más rápido (ahora esfactible sin necesidad de SLI)

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..)

La frecuencia de trabajo en los procesadores de vértices

ahora es distinta y mayor que la de fragmentos

El algoritmo de filtrado anisotrópico se ha optimizado (simplificado) y hay a quien no le gusta (se puede desactivar)


El procesador de vértices desde una perspectivafuncional

Coordenadas de vértices

Atributos de variables

VariablesUniform

Texturas

Variables de salida

gl_Position

Shader devértices

El procesador de vérticesreemplaza algunas tareas clavede la etapa de funcionalidad fija:pasa a ser resposable de ellas• Parámetros de entrada:◦ 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 comomapas 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

etapas siguientesDavid Miraut Andrés Arquitecturas streaming comerciales Perspectiva funcional - Shader vértices 59/7059/70

Ejemplo de shader de vértices en GLSLSe pasan las coordenadas en el sistema de coordenadas delmundo ó de la camara en función de un flag. Después en elshader de fragmentos se colorea en función de dichascoordenadas.

uniform bool uUseModelCoords;out vec4 vColor;out float vX, vY, vZ;out float vLightIntensity;

voidmain( ){

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/7060/70

Ejemplo de la práctica 1

Como comprobaremos en la práctica 1, un shader de vérticespuede modificar las coordenadas que recibe. Éste procesado sehace vértice por vértice de forma independiente.

Superficie con normales que pueden ser calculadas de forma analítica

No puede crearnueva geometría (para eso utilizaremoslos shaders de teselación y geometría).Cuando modificamos las coordenadas de lospuntos 3D que definen las mallas, tenemosque ser cuidadosos y volver a recalcular las normales. Aunqueesta operación puede ser realizada fragmento fragmento, esnecesario que aportemos la información adecuada desde el shaderde vértices.¿lo podemos hacer en todos los casos?

David Miraut Andrés Arquitecturas streaming comerciales Perspectiva funcional - Shader vértices 61/7061/70

Etapas de funcionalidad fija tras el procesadorde vértices

Por ahora algunas de las tareas críticas en la etapa detransformación son realizadas por unidades funcionales quemantienen 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 oparcialmente

El ensamblado de primitivas se lleva a cabo una vez terminado elprocesador de vértices y antes de enviarse al resto de etapas(como las formadas por shaders de teselación ó geometría enarquitectura unificada)David Miraut Andrés Arquitecturas streaming comerciales Perspectiva funcional - Shader vértices 62/70

62/70

Cauce gráfico“actual”

Arquitectura“unificada”:

David Miraut Andrés Etapas de transformación en arquitectura unificada 63/7063/70

Geforce GTX680: ¿Dónde está la etapa deTransformación?

David Miraut Andrés Etapas de transformación en arquitectura unificada Caso de estudio: GeForce 680GTX 64/7064/70

Cauce gráfico en Arquitectura UnificadaDesde el punto de vista de las APIs (OpenGL)

Variablesentr./salid




Variables (atributos)por vértice

VariablesUniform

Shader de vértices




Shader de control de teselación

Generador de primitivas de teselación

Shader de evaluación de teselación

Shader de Geometría

Rasterizador

Shader de fragmentos


Geforce GTX680: ¿Dónde están los procesadoresde vértices?

Fijaros nosotros programamos para 3"procesadores" en la etapa deTransformación:• Shaders de vértices• Shaders de teselación• Shaders de geometríaY en este esquema intervienen dospartes con diferente diseño (desde elpunto de vista en Arquitectura)


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/7067/70

Bibliografía sobre arquitecturas pioneras en laetapa 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/7068/70

Bibliografía sobre arquitecturas streamingcomerciales• Procesadores gráficos para PC. Manuel Ujaldón Martínez.Ciencia 3

• GPU Gems 2: Programming Techniques for High-PerformanceGraphics 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 ProgrammableReal-Time Graphics, de Randima Fernando y Mark J. Kilgard.

• Advanced Lighting and Materials with Shaders. KellyDempski. Jones & Bartlett Publishers

• Interactive Computer Graphics: A Top-Down Approach withShader-Based OpenGL. Edward Angel, Dave Shreiner. 6thEdition. Addison-Wesley


http://www.lulu.com/shop/manuel-ujald%C3%B3n-mart%C3%ADnez/procesadores-gr%C3%A1ficos-para-pc/ebook/product-16670342.html

Bibliografía sobre arquitectura unificada

• Computer Architecture: A Quantitative Approach. J. Hennessyand D. Patterson. Fourth edition. Morgan-Kaufmann

• Graphics Shaders: Theory and Practice. Mike Bailey, SteveCunningham. Second Edition. A K Peters/CRC Press

• Programming Massively Parallel Processors – A Hands-onApproach. D. B. Kirk and W. W. Hwu. Morgan Kaufmann.


tema 2.2 et ap a de e implement a ciÓn hard w are · tema 2.2 et ap a de transforma ciÓn e...

Documents