La semana pasada, se celebró un evento de nvidia , donde las empresas emergentes podían mostrar sus avances a ver si conseguían inversión o simplemente adquisiciones por parte de grandes emrpesas. También los desarrolladores más experimentados podían mostrar aplicaciones desarrolladas con la GPU, y los grupos de investigación podían mostrar sus avances en estos campos . Acaban de publicar los vídeos de las conferencias en la página web .

 Jen Hsun, CEO de la compañía, nos habla de las posibilidades que hay en invertir en tecnología, y los retos que tiene llevar una startup hacia el éxito, ya que la conferencia tiene un alto perfil inversor para pequeñas compañías. Nos recuerda que hay que creer en la compañía, y si consigues el dinero, y crees en la idea, podrás crecer y prosperar. En España es prácticamente imposible encontrar dinero , así que nos quedaremos con las charlas técnicas.

La conferencia más interesante es la que comienza Richard Kerris, CTO de Lucas films, nos habla de cómo usaron las GPU's en cine. Es un tema de bastante actualidad, porque con el tiempo, parece que tanto los videojuegos se están acercando al cine, como el cine comienza a usar tecnología realtime. En este vídeo se muestra cómo el estudio usa GPUs para las simulaciones de partículas, y nos habla de su granja de GPUs para cálculos intensivos. Es la típica charla de ILM dónde nos muestran las capas de renderizado, pero lo interesante es que nos muestran cómo ha mejorado el pipeline de producción . También nos muestran su aplicación zViz, que es un editor 3D construido para diseñar la película, y exportar todos los efectos a render.

NVIDIA ha anunciado su nueva arquitectura de hardware, llamada Fermi

Características

El chip está formado por 16 celdas de stream (Streaming Multiprocessor) con 32 cores por celda, con un total de 512 cores, diseñado para ejecutar una enorme cantidad de tareas en paralelo. En total son 3.000M de transistores.

Los programas de la GPU se denominan kernels. Un kernel se ejecuta en un grid de bloques de threads. Cada thread dentro del bloque de threads ejecuta una instancia del kernel, y tiene asignado su propio id de thread, que utiliza para acceder a un conjunto de datos. Un bloque de threads es un conjunto de threads que se colaboran entre sí, usando sistema de control como barreras, y memoria compartida, para realizar el trabajo del kernel. Un grid es un conjunto de bloques de threads, que lee datos de la memoria principal y devuelve los resultados. De este modo, los threads disponen de memoria local, los thread blocks disponen de memoria compartida, y los grid usan la memoria global. La ejecución en paralelo se gestiona en el controlador GigaThread, que puede gestionar hasta 1.536 threads simultaneamente.

Streaming Multiprocessor

Cada bloque de threads se divide en "warps" de 32 threads, que es la unidad mínima de gestión. Cada SM tiene 2 unidades para gestionar warps, con lo que se pueden enviar 2 warps a cada SM en cada ciclo. El gestor de warps envia las instrucciones a los cores para ejecutar así 32 instrucciones en paralelo.

Los 32 cores del SM no tienen registros, a diferencia de los procesadores normales, ni unidades de traducción de direcciones, etc. Deja todo esto al SM. Los cores son unidades muy simples que pueden cambiar de thread de forma extremadamente rápida.

Cada core del SM tiene una unidad simple de coma flotante que permite pipeline, otra para los enteros, una parte de lógica, un dispacher y una cola de resultados. Todos ellos comparten una zona de memoria especial, a modo de registros locales, de 4kb, que reside en el SM.

Cada SM dispone de 16 unidades de load/store, con lo que se pueden calcular direcciones de memoria para 16 threads de forma concurrente. Los cores usan estas unidades para acceder a los datos exernos al SM.

Para acelerar los cálculos de coma flotante, en cada SM se incluyen 4 procesadores especiales para operaciones complejas, como seno, coseno, etc, denominado Special Function Units (SFUs). Al sacarlos de los cores, el diseño de estos es todavía más sencillo.

Memoria y Caché

Para acceder a la RAM de la tarjeta, se dispone de seis particiones de 64bits, en un interfaz de 384bits, dando una capacidad máxima de 6Gb de memoria DDR5 en la tarjeta.

Se incluyen comprobaciones de fallos de escritura (Error checking and correction) que en general hacen el sistema más estable.

Para acceder a la memoria global del sistema, se usa un path a memoria de tipo "enlace PCI-Express bidirecional", consiguiendo los 12Gb/sec, frente a los 3GB/sec que lograba el anterior path unidireccional.

El chip tiene 1Mb de caché, repartida en grupos de 64Kb, y 768Kb de caché unificada de nivel 2. Esto es un gran avance, ya que anteriormente, las GPUs no disponian de caché para sus cálculos. La arquitectura de caché L1 permite dividir los 64k de cada procesador stream en 2 zonas, una es caché normal, y otra es un local scrachpad (48k cache, 16k local, o viceversa). La idea es que la memoria scrachpad es una memoria que está al mismo nivel que la caché en cuanto a velocidad, pero es controlable por la aplicación (tiene instrucciones propias para escribir en ella), y está pensada como una zona de memoria temporal para cálculos que no se copian a la ram global. Con esto evitamos problemas de contención (muchas celdas escribiendo en el bus de datos). Esta capacidad de poder configurar la forma en que funciona la memoria local, tendrá que ser explorado en el futuro, sobre todo por el compilador.

Programación

Se ha mejorado el set de instucciones, de tal forma que se podrán desarrollar compiladores genéricos, para C++, OpenCL, DirectCompute, etc. Según la información de NVIDIA, el chip ha sido especialmente optimizado para OpenCL y DirectCompute (quizás reconociendo que este será el futuro de las API's). En concreto, permite a los compiladores optimizar el layout de memoria de los arrays, algo que hace que estas APIs ganen en rendimiento.

Las instrucciones ahora son predicadas, eliminando la necesidad de diferentes ramas de ejecución para secuencias de código.

El chip dispone de 64bits para el tamaño virtual de memoria, gracias a un nuevo juego de instrucciones. Los punteros de memoria ahora son unificados. Esto es, ya no existen distintos tipos de memoria enlos kernels, con espacios de memoria distintos. Los 64bits ahora permiten mapear todos los tipos de memoria de la GPU (en programas compilados para la GPU).

Las operaciones atómicas, usadas para el control de bloqueos entre threads, se han optimizado, y ahora son entre un 5X y un 20X más rápidas.

Los cambios de contexto en la ejecución son más rápidos, unos 25ms entre programas Además, se puede ejecutar un kernel, mientras otro está comunicándose con el bus principal de datos. La ventaja es que se puede cambiar varias veces de kernel en cada frame, evitando así los problemáticos übershaders.

Hay posibilidades de depuración como en los procesadores normales: breakpoints, single step, traps, etc. Con ello se facilita enormemente la programación de estas arquitecturas. Este es un cambio crucial, ya que se espera poder depurar CUDA directamente en el depurador del visual studio para GPUs.

Problemas

Todavía dispone de una reducida memoria para cada celda, limitando mucho los programas que se pueden ejecutar.

No es posible mapear la memoria de la GPU directamente, con lo que se pierde mucho tiempo enviado los datos a la GPU desde el programa principal. Además, la ley de Amdahl nos dice que si una parte de un proceso paralelo es lento, todo el programa se limitará a este proceso.

Enlaces

• GT300 en la wikipedia.

• web oficial de fermi.

• The Top 10 Innovations in the New NVIDIA Fermi Architecture, and the Top 3 Next Challenges

 más info en el wiki de codepixel .

Esta web tiene una curiosa implementación del Julia set, similar al que hizo iq en su momento con ambient occlusion. La novedad es que calcula el ambient occlusion basado en el nivel de recursión que ha usado para calcular el objeto. En la web hay varios enlaces sobre el tema. Esta versión está desarrollada en los pixel shaders del motor de adobe, por lo que se puede ejecutar en el photoshop.

Estos días se celebra el encuentro de desarrolladores de intel, que tiene especial relevancia por el Larrabee, y las expectativas de que salga pronto a la venta. En la presentación de Sean Maloney , pudimos ver el Quake Enemy Territory usando este procesador para dibujar y sombrear usando raytracing. Hay que reconocer que la imagen aunque está bien, no es una cosa especialmente impresionante. Se ha confirmado, eso sí, que en el futuro el Larrabee estará integrado con la CPU de alguna forma. De todas formas, no se ha revelado mucha cosa.

También se ha anunciado una tienda para aplicaciones , similar al Apple Store, donde se podrán vender programas para los netbooks basados en Atom, con apoyo comercial de Intel. La idea es que el desarrollador se lleva el 70% de las ventas.

El tema de hacer un juego online suele estar bastante minusvalorado por la gente y los productores nóveles. Blizzard ha revelado datos de su infraestructura .

Son 30 departamentos. Tienen 37 diseñadores de videojuego, que se encargan de niveles, magias, eventos, diseño de los mapas, etc.  Sólo del diseño de sus propiedades, porque para modelado/dibujo/etc tienen a 51 artistas. PAra programación (engine*red/ui/tools) son 32 personas.

Pero lo gordo es el mantenimiento. 340 personas hacen falta para la gestión de facturas. 275 para la traducción, 240 para el control de calidad y testeo, y nada menos que 2000 masters para llevar la comunidad. Para los 13.500 servidores, necesitan 68 personas. Sumando equipo de recursos humanos, márqueting, finanzas, etc, hace un total de 4600 personas, y 20.000 equipos, que gastan 1.3 petabytes de almacenamiento.

Desde intel, nos hacen referencia a esta oferta de empleo , para el que le pueda interesar.

Es en Guadalajara, méjico, y está relacionado con la parte de gráficos de la compañia.

En campos como el ray tracing o la simulación física, la intersección de rayo/triángulo es una rutina clave, donde se invierte mucha parte del tiempo de cálculo.

El primer método propuesto se basa en mirar las coordenadas baricéntricas de la intersección del rayo con el plano del triángulo, para comprobar posteriormente si están dentro del triángulo. Este método se describe en raytracing news de noviembre del 88, o en el libro Graphics Gems de Andrew Glassner, de 1990. Es fácil de entender y de derivar en papel con conocimientos básicos de matemáticas. Hay que tener cuidado con temas como puntos en el origen, triángulos de área 0, etc, ya que el código requiere de divisiones. Por ejemplo, recordad que los números en coma flotante en un ordenador incluyen el -0.0, comprobaciónes del tipo x > 0 se evalúan incorrectamente con el 0 negativo.

El segundo método, y el más usado en muchos campos, es el que denomina MT97, por los autores del paper Fast Minimum Storage Ray Triangle Intersection, publicado en 1997. Se basa en desplazar y rotar el rayo a un espacio de coordenadas donde u,v son las coordenadas baricéntricas. Lo más importante de este algoritmo es que no requiere de precálculos, ahorrando así mucha memoria y el proceso de previo de generar datos por cara. La función sólo necesita los 3 vértices del triángulo para devolver un resultado correcto. Es la opción más adecuada para soluciones "on the fly" de generación de triángulos.

El tercer método, es el propuesto en Interactive Rendering with Coherent Ray Tracing, por Ingo Ward en sus trabajos de ray tracing en tiempo real. El método se basa en que la baricéntricas de la intersección son las mismas aunque veamos el triángulo proyectado en un plano. El cálculo es un poco mayor que el MT97 si lo hacemos por fuerza bruta. Pero lo interesante es que podemos precalcular muchos datos necesarios en una tabla antes de realizar las intersecciones. Usando este tabla, se logra un aumento considerable de velocidad, a costa de más accesos a memoria. La estructura de aceleración ocupa unos 48 bytes por cara, que son unos aceptables 48Mb en una malla típica de 1M de triángulos. Pero lo que hace realmente potente este método es la facilidad con la que se adapta a SSE. Permitiendo así testear 4 rayos contra 1 mismo triángulo en pocos ciclos.

El cuarto método, propuesto en Ray-Triangle Intersection Algorithm for Modern CPU Architectures, usa coordenadas plücker, que es un sistema de coordenadas muy apropiado para resolver problemas de intersecciones. El problema es que, a parte de ser 6D, son costosas de calcular. Pero permiten elimitar divisiones costosas. Y funciona muy bien cuando comprobamos 4 rayos, o incluso paquetes de 4x4 rayos contra un triángulo. Ademas, si los triángulos comparten bordes, se pueden aprovechar cálculos entre cada testeo de intersección.

Más información en el wiki de codepixel .

El tema del raytracing en tiempo real y la representación de vóxeles está tomando cada vez más importancia en el mundo de los gráficos. En el último SIGGRAPH de Nueva Orleans se han presentado muchas cosas interesantes sobre este tema.

Por ejemplo, el pasado SIGGRAPH 2008, id software presentó imágenes de lo que será su motor, basado en vóxeles , que aumenta el detalle de los escenarios. Rapidamente, otras empresas están trabajando en esta tecnología, y crytek ha presentado recientemente cosas sobre esto (aqui y aqui ).

Por ejemplo, este investigador, Cyril Crassin , se dedica especialmente a estudiar el tema de los vóxeles de gran tamaño. Este es el enlace a su última charla, que repasa el tema aplicado a los nuevos motores de juegos , donde nos explica un pipeline basado en GPU para representar la información, y una estructura de octrees, empaquetando los nodos hoja en bricks o ladrillos, que almacenan datos globales para todo el paquete, como la opacidad. También nos habla de temas a destacar para el realtime, como la instanciación, el filtrado de los bordes, sombras suaves, y efectos como depth of field.

 Otra tecnología que parece al menos curiosa, es el motor de raytracing de NVIDIA, Optix Ray tracing , basado en shaders para evaluar los rayos. Recordad que NVIDIA es dueña de Mental Ray, y por ahí puede introducir este tipo de tecnologías en el mercado. Lo más interesante es el pipeline que proponen para extender todo esto en la tarjeta. Esta presentación del SIGGRAPH 2009 nos habla más de los shaders que podemos definir en el recorrido de rayos. Las posibilidades todavía están por descubrir, falta investigación en este campo. NVIDIA presenta el ejemplo de implementar photon mapping en espacio de pantalla usando Optix, para simular iluminación global a un framerate interactivo.

El pipeline cambia con la llegada de CUDA, OpenCL o Larrabee, y la posibilidad de instanciar muchos hilos simultaneos, pero con poco acceso a memoria. Sobre todo esto se habla en esta larga presentacion de NVIDIA sobre pipelines alternativos de render.

Estos días estoy probando a optimizar la intersección de un rayo con un triángulo, y en especial el tema de la estructura de aceleración que almacena los triángulos. Mi iea es sacar provecho del SSE y lanzar 4 rayos al mismo tiempo.

Estoy en concreto probando los kd trees, sobre todo porque estoy leyendo unas tesis muy detalladas sobre el tema. En el wiki tenéis más información y una lista completa de enlaces. En general se considera que es la estructura más rápida para lanzar rayos, pero es muy costosa de generar rápidamente. Por eso hay motores de raytracing que prefieren usar BVH. El coste de creación es muy importante en las partes dinámicas de la escena, y hay papers que hablan de cómo reaprovechar un BVH para crear el del siguiente fotograma.

Lo que estoy haciendo ahora es crear un árbol optimizado. Para ello uso el Surface Area Heuristics, que no es más que dar una función de coste a los futuros nodos hijos, teniendo en cuenta el número de objetos candidatos y el volumen que ocupan. También se tiene en cuenta el coste de no hacer ninguna división (por ejemplo, si el area que ocupan todos los triángulos es muy reducido). El algoritmo busca la opción con el menor coste.

Además, se elimina el espacio vacío, creando nodos de 0 elementos. Asi el algoritmo de intersección no perderá el tiempo intentando colisionar contra triángulos, en amplias zonas de la geometría.

La tesis que más me ha gustado por ahora es esta , de Carsten Benthin.

Los siguientes pasos son el intentar optimizar el árbol teniendo en cuenta la cámara. Ya que si sabemos a priori dónde vamos a lanzar los rayos, podremos optimizar la colocación del rayo.

El problema principal que tengo es el excesivo consumo de memoria. Cada paso necesito ir creando unas listas de bboxes que son bastante costosas en cuanto a memoria, y me limitan bastante en cuanto a la cantidad de triángulos que puedo manejar. He leído de gente que usa listas enlazadas en vez de arrays, para reutilizar la lista de candidatos...

Como véis, para desarrollar uso el interface de blender. Así puedo editar y ver rápidamente los nodos. Trabajar así es verdaderamente cómodo, y me permite ir probando diferentes casos sin tener que recompilar.

Entre las innumerables charlas de este año en SIGGTRAPH, shash nos ha destacado en la lista de correo de codepixel esta sesión sobre la programación de shaders modernos. Algunos pdf´s interesantes:

Beyond Programmable Shading Retrospective; charla de un miembro deATi con una visión general de los pipelines de render, su evolución ylos retos que tienen para el futuro, sobre todo en paralelismo.

Parallel Graphics in Frostbite - Current & Future : charla de DICE (mirror' s edge, battle field) sobre le motor de render que usan. Esta charla es muy completa y contiene muchísimas ideas sobre cómo paralelizar el motor. Al parecer, la técnica de dividir la pantalla en tiles, a la hora de iluminar, se está convirtiendo en un standard, sobre todo en PS3. El motor trabaja usando jobs que forman un joblist ordenado. En la propia presentación se exponen algunos ejemplos de trabajos que se paralelizan. Es interesante también ver el gráfico de las dependencias para ver la complejidad que todo esto está tomando.

id tech 5 Challenges : sobre el nuevo y espectacular motor de render de id softwar. A parte de las capturas (creo recordar que era una especie de sistema de voxeles), nos habla de cómo maneja las texturas y de detalles interesantes del sistema multitarea, evitando bloqueos y dependencias.

GPU Primitives---Case Study: Hair Rendering : sobre el renderizado de pelo, y la importancia de ordenar las curvas para calcular las sombras y la opacidad total.

Innovating in a Software Graphics Pipeline : habla sobre técnicas que podremos utilizar para no enviar tanta información a la tarjeta, como dividir la textura, aplicar listas de texturas, lita de render targets, usar pequeños tiles para aprovechar mejor la caché, etc.

A Real-Time Micropolygon Rendering Pipeline Is Not Far Away : sobre aplicar el tipo de render de renderman (arquitectura REYES) a las tarjetas actuales. Un completo repaso de su arquitectura y pipeline.

En el SIGGRAPH 2009 se están presentando muchas novedades y tecnologías. Entre ellas, el khronos group acaba de anunciar OpenGL 3.2 , 

Jon Valdés nos ha escrito un resumen en la lista de correo donde apunta las diferencias de esta versión. Os transcribo aquí los puntos importantes:

•  Geometry shaders: Igual que la extensión que ya había, pero ya es parte del core.

• Layered Rendering:  Cualquier textura 2D (FBOs, etc) puede tener varias capas. El geometry shader puede especificar a qué capa envía cada primitiva (gl_Layer). Esto permite renderizar algo en todas las caras de un cubemap en un único pase, por ejemplo.
  

• Flat shading de variables de GLSL: Si especificas que el varying es flat, la variable no se interpola entre los vértices de la primitiva. Por defecto se toma el valor del último vértice de la primitiva, pero también se puede pedir que use el primero.
  

• Disable Depth clipping: Permite eliminar el near y el far plane, teniendo depth buffers no limitados al rango [0,1]
  

• Texturas multisample: Toda textura 2D puede tener varios samples en cada texel, incluyendo los FBOs. Han metido también instrucciones de GLSL para leer samples concretos de una textura. Esto permite generar un FBO multisampleado, y luego hacerle un pase al FBO leyendo todos sus samples --> Deferred shading+ MSAA !! (Tengo la impresión de que esto lo han implementado usando los layers de antes, siendo cada layer un grupo de samples...)
  

• Seamless cubemaps: El filtrado de texturas en los bordes de las imágenes de un cubemap ahora lee las imágenes adyacentes para hacer el filtrado linear.
  

• Sync objects: permiten esperar (hacer un wait) a que OpenGL termine una determinada operación, o comprobar si la ha terminado ya (es como glFinish, pero más fino). Tiene timeouts e informa de si ha habido errores en la ejecución. Todavía no está implementado, pero está pensado para poder hacer waits a comandos concretos (para OpenGL 3.3, supongo).

ArtFutura y LABoral convocan sus conocidos y prestigiosos premios de animación y desarrollo de videojuegos, con premios de 6.000€ repectivamente.

Los plazos son el 10 de Septiembre para la animación, y 20 de Septiembre para el videojuego.

Los premios ya tienen tradición en el panorama indy español, como una plataforma excelente para dar a conocer proyectos y equipos de trabajo.

Los ganadores recibirán su premio en Art Futura 2009, que se celebrará entre el 29 de Octubre al 1 de Noviembre en Barcelona, con proyecciones simultáneas en otras ciudades de España y Argentina.

En la web de intel, y sus publicaciones gráficas , podemos leer varios papers sobre raytracing, y en especial sobre raytracing orientado a tiempo real.

Fast Ray Tracing for Modern General Purpose CPU : datos generales sobre cómo acelerar el raytracing, y temas a tener en cuenta. Nos habla, por ejemplo, de los costes de recorrer un kd-tree, de forma bastante ilustrativa.

Multi-Level Ray Tracing Algorithm : sobre cómo recorrer un árbol usando grupos de rayos.El paper muestra muchas características que se pueden tener en cuenta si los rayos son similares y coherentes. Por ejemplo, si lanzamos varios rayos con los mismos signos en su dirección, hay muchos descartes que podemos aprovechar. Lo mismo sucede con el propio recorrido del árbol, que podemos recordar de alguna forma para no volver a comenzar desde el nodo raiz. 

Fast, parallel, and asynchronous construction of BVHs for ray tracing animated scenes : trata el tema del multithreading para generar el BVH. El paper propone reconstruir la estructura cada pocos fotogramas, y usar una arquitectura asíncrona para ir recreando la estructura en paralelo, aprovechando ciertas características de la reación de esta estructura.

Efficient SIMD single-ray traversal using multi-branching BVHs : algoritmo muy paralelizable para recorrer la geometría. El paper estudia un BVH con 16 hijos y se testean grupos de 16 triágulos en las hojas. La creación se basa en un BVH binario, pero cambiando las condiciones para colapsar nodos teniendo en cuenta que intersecar 1 triángulo ahora es lo mismo que 16. Por lo que cambia la heurística para tomar decisiones a la hora de crear la estructura.

En la web Dimension 2.5 han publicado un completo resumen de las conferencias de este año en Mundos Digitales 2009.

En el resumen podeis leer sobre las chalas de ilion, la de efectos de javier romero y la de personajes de juan solís. Tambien hay charlas interesantes en general, como la de ziah fogel (aunque fue muy corta), o la de Diego Gutierrez, del GIGA de Zaragoza, que ha sido  muy comentada entre los asistentes. Y como siempre,a conferencia de Jordi Barés, The mill, donde nos cuenta los secretos para el rodaje de anuncios para nike.Una suerte que estos profesionales de esta altura nos cuenten cómo funciona le mundo del cine por dentro.