TEMA 3.1 ORIGEN DE LA ARQUITECTURA UNIFICADA...Procesadores Gráficos -- Máster en Informática Gráfica, Juegos y Realidad Virtual --ORIGEN ARQ.UNIFICADA’13/141/31 TEMA 3.1 ORIGEN

Procesadores Gráficos -- Máster en Informática Gráfica, Juegos y Realidad Virtual -- ORIGEN ARQ.UNIFICADA’13/141/31

Procesadores Gráficos -- Máster en Informática Gráfica, Juegos y Realidad Virtual -- ORIGEN ARQ.UNIFICADA’13/14

TEMA 3.1ORIGEN DE LA

ARQUITECTURA UNIFICADA

Curso 2013 / 14

Procesadores Gráficos y Aplicaciones en Tiempo RealProfesores: David Miraut y Óscar D. Robles

© GMRV 2005-2013 – Febrero 2014


Índice

• Causas y DirectX10• El reto del equilibrado

de carga• La "patente" de la discordia

• Caso de estudio: GeForce 8800 GTX

• Introducción a CUDA

“Si estuviéramos viviendo en una realidad virtual creada por inteligencias superiores, diría que los gráficos están geniales,

pero que el argumento es penoso”- Student of Prof. Brian Whitworth

“We will do a unified architecture in hardware when it makes sense. When it’s possible to make the hardware

work faster unified, then of course we will. It will be easier to build in the future, but for the meantime, there’s plenty

of mileage left in this architecture,” Entrevista a David Kirk 11 Jul 2005

“The vertex shader, pixel shader, ROP (rasterizing operation), tesselator, other hardware units [of the

contemporary graphics processors] will probably evolve into something that can execute everything. But time is

required for, [such evolution] is not possible at one time. Change probably will happen progressively,”

Entrevista a David Kirk en PC Watch 19 Abr. 2006

Todas las marcas y productos mencionados en estas trasparencias están registradas por sus respectivas compañías, y su uso es de carácter descriptivo con fines docentes.

Parte de las tablas y gráficos están basados en las presentaciones de GPGPU y streamingcomputing de NVidia y ATI-AMD, y en loslibros mencionados en la bibliografía

©


Evolución de DirectX y los SMs

Quake 3 Giants Halo Far Cry UE3Half-Life

1998 1999 2000 2001 2002 2003 2004

DirectX 6Multitexturing

Riva TNT

DirectX 8SM 1.x

GeForce 3Cg

DirectX 9SM 2.0

GeForceFX

DirectX 9.0cSM 3.0

GeForce 6DirectX 5Riva 128

DirectX 7T&L TextureStageState

GeForce 256

Poco a poco nos movemos hacia la quinta generación que preveía Silicon Graphics, pero...

el cauce clásico es demasiado rígido


Rasterizado vs. Raycasting

• Para cada objeto– Para cada pixel

• Proyectamos objetos sobre pixeles

• Discretizamos al final• Accedemos a los objetos

una vez– La imagen debe caber en

memoria• Chungo para efectos

complejos• O(n) o incluso más lento

– Pero la constante es muy pequeña

• Para cada pixel– Para cada objeto

• Proyectamos pixeles en los objetos

• Discretizamos al principio• Accedemos a los objetos

muchas veces– La escena debe caber en

memoria• Solución muy general• O(log(n)) con estructuras de

aceleración– Pero la constante es muy

grandeMuy difícil de meter en HW:

dependencias


Microsoft viene al "rescate"

• Reutilización limitada de los datos dentro del cauce• (como entrada de datos de una etapa no pensada)• Gran sobrecarga en cambios de estado• Gran variabilidad de capacidades del HW gráfico• Limitaciones en el conjunto de instr. y datos• Imposibilidad de escribir los datos a mitad del cauce• Limitaciones de recursos (registros, texturas...)

Los ingenieros de Microsoft averiguan los problemas que tienen los desarrolladores de juegos:


• Y propone un modelo de programación y una API que han marcado el curso de los acontecimientos (al tener una influencia decisiva en el ShaderModel 4.0 y 4.1):

DirectX 10

Microsoft viene al "rescate" (2)


Modelo de programación de DX10

• Cauce gráfico clásico al que se le ha añadido una nueva etapa programable: geometría

• Tres etapas programables: vértices, geometría y fragmentos

• Todas las etapas tienen el mismo repertorio de instrucciones y (casi) los mismos recursos

• Memoria compartida simple, aunque los objetos accesibles son distintos


Núcleo de programación de DX10

• Repertorio de instrucciones completo:– Operaciones en coma flotante– Operaciones enteras (nuevo)– Operaciones de ramificación– Código de longitud ilimitada

• Instrucciones vectoriales• Estados en los procesadores• Operaciones independientes

para cada vértice, primitiva o fragmento


Pero esto es sólo una descripción

• Microsoft no soluciona el problema, sólo reclama lo que necesita para poder ofrecer una herramienta (API) que facilite la vida a los desarrolladores

• Deja el balón en otro campo: el de los desarrolladores de chips gráficos

Y se han pedido muchas peras al olmo que ahora ¿hay que injertar?…


Distancia de abstracción

• El repertorio de instrucciones real no tiene porqué coincidir con el "anunciado"– Esto era verdad en la era del "lenguaje ensamblador "

• Postensamblado complejo y optimización en t. de ejecución• Lenguajes en capas (como Cg) 2 capas de optimización

– Incluso más fácil en DirectX 10– Ej. Utilizar un procesador escalar para emular

operaciones vectoriales• No fue posible aplicarlo en los 90

– Las CPUs son mucho más rápidas ahora– La tecnología software ha recorrido un largo camino


Dificultades en la programabilidaddel Output Merger• OM está muy

optimizado– El acceso a memoria es

a menudo e limitador de la GPU

• OM tiene riesgos de datos– Todas las interfaces

programables son memorias de sólo lectura


El diseño de la XBoX360

• Que se supone que tiene arquitectura “unificada”

Michael DoggettArchitectSeptember 1, 2005


El diseño de la XBoX360

• Que se supone que tiene arquitectura “unificada”


Los cuellos de botellaDirectX sólo requiere que los procesadores tengan un juego de instrucciones idéntico (algo que por evolución ya teníamos)

El problema del balanceo de carga se multiplica al introducir una 3ª etapa programable


La patente de la discordia

• ATI presentó esta patente el 20 Nov2003

• Pero nVIDIA había comenzado esa línea de trabajo muuucho antes y existía arte previo que invalidaba la patente


Si queremos afrontar problemas “grandes”…

• Si dividimos una tarea en n partes, idealmente podremos tener una aceleración por n

• Una Geforce 3 tiene un cauce de datos de entre 600 y 800 etapas frente a las 20 de instrucciones de un Intel Pentium IV

• Por ello la CPU requiere un reloj mucho más alto (x100) para hacer el mismo trabajo – en las GPUs el limitante suele ser el BW (a pesar de la prebúsqueda)– Las GPUs son tolerantes a la latencia– El cauce segmentado de una GPU es de datos

En Gráficos combinamos ambas y llevamos el paralelismo y la segmentación a sus últimas consecuenciaspor eso es el campo indicado para que estos modelos muestren sus puntos débiles

Podemos elegir entre dos opciones HW: segmentacióny paralelismo, esto es, dividir o repetir


Si queremos afrontar problemas “grandes”…

• Aquellas etapas que son más lentas o necesitan procesar un mayor número de elementos se “multiplican” dando lugar a cierto paralelismo

• Además tenemos instrucciones vectoriales• 100k-1M+ triángulos/frame, paralelizable• 1-10M+ pixeles/frame, paralelizable

En Gráficos combinamos ambas y llevamos el paralelismo y la segmentación a sus últimas consecuenciaspor eso es el campo indicado para que estos modelos muestren sus puntos débiles

Podemos elegir entre dos opciones HW: segmentacióny paralelismo, esto es, dividir o repetir


Dificultades de la paralelización

• Ordenación de los elementos a calcular– Control del Estado gráfico– Operaciones en el Framebuffer (algoritmo del pintor)– Render to texture / Readback

• Equilibrado de carga– Cambiar primitiva de trabajo +– Cambiar la posición de la primitiva =– Procesadores ociosos y duplicación de trabajo

• Comunicación y ancho de banda hacia el host(CPU)


Recordatorio: medidas sencillas de rendimiento


Escalable en gráficos significa…

• Que se aumente el rendimiento en todas las métricas de la transparencia anterior

• n pipelines /cauces nos debería dar…– La misma entrada n veces más rápido– Una entrada n veces mayor en el mismo tiempo

• Throughput O(n)• Latencia O(1/n) • Coste O(n ) malo malo malo!2


Paralelismo y comunicación en GPUs

Imagine

Pixel-Planes

Anillos

En la pizarra…


Arquitectura Unificada

Un Procesador para calcularlos a todos, Un Procesador para encontrarlos,Un procesador para atraerlos a todos, y transformarlos dentro del cauceEn la Tarjeta Gráfica, donde los shaders esperan…


Diseño Unificado (de verdad)


G80 Characteristics

• 367 GFLOPS peak performance (25-50 times of current high-end microprocessors)

• 265 GFLOPS sustained for apps such as VMD• Massively parallel, 128 cores, 90W• Massively threaded, sustains 1000s of threads per app• 30-100 times speedup over high-end microprocessors on

scientific and media applications: medical imaging, molecular dynamics

“I think they're right on the money, but the huge performance differential (currently 3 GPUs ~= 300 SGI Altix Itanium2s) will invite close scrutiny so I have to be careful what I say publically until I triple check those numbers.”

-John Stone, VMD group, Physics UIUC


Multiprocesador streaming


Arquitectura GPU serie 8

16 multiprocesadores para grancantidad de hebras, >128 FPU’s, 367 GFLOPS, 768 MB DRAM, 86.4 GB/S Mem BW, 4GB/S BW a CPU


Jerarquía de memoria


Modelo arquitectural


Doble personalidad: CUDA


Doble personalidad: CUDA

Documents

TEMA 3.1 ORIGEN DE LA ARQUITECTURA UNIFICADA...Procesadores Gráficos -- Máster en Informática Gráfica, Juegos y Realidad Virtual --ORIGEN ARQ.UNIFICADA’13/141/31 TEMA 3.1 ORIGEN