Download Arquitectura
Document related concepts
no text concepts found
Transcript
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