codepixel - Raytracing con CUDA: faaaaaast!

Rasty3D

| 81.208.36.xxx | 2008-11-22 00:54:58

Yo también estuve mirando un poco usar CUDA para raytracing, pero no he llegado a ese nivel. Lo hice un poco para ver como funcionaba CUDA. Lo único que hago es renderizar esferas con una textura procedural muy sencilla (bolas de billar).

Lo acabo de lanzar y 16 bolas a 1280x1024 con depth blur (matemático, ya que son bolas y es sencillo) a 30 fps.

Conseguí muchísima mejora cuando la escena la cargo en memoria compartida. Pero hay un límite de 16 Kb. Si he entendido bien lo que dice en el link (me lo he leído por encima) usa la memoria de textura para almacenar los datos de la escena.

Probé brevemente las reflexiones (ahora las tengo desactivadas), pero me aparecieron problemas de límite de registros. Así que el tamaño del kernel limita el número de threads en paralelo.

Yo creo que CUDA es realmente interesante, pero hay que tener mucho ojo de como se implementan las cosas para poder sacarle provecho.

Por cierto, vi en una conferencia en Turín la demo de NVIDIA de realtime raytrace. Usaban dos NVIDIA Quadro Plex con dos tarjetas cada una y renderizaban la escena del coche con suavizado y super-resolución en tiempo real. Cuando se empezaba a subir el antialiasing o el número de reflexiones empezaba a sufrir un poco el sistema y caían los fps (absolutamente normal).

Citar

inigo quilez

| 81.243.230.xxx | 2008-11-22 10:44:39

la gente de envidia lleva una temporada experimentando también con raytracing. me comentaron que consiguen entre 30 y 40 MRPS también, lo cual comparando con los 12 de las implementaciones actuales en CPU (2 cores) esta bastante bien. Pero la gran ventaja de las implementacones en GPU es que no sufren de la incoherencia de los rayos (ie, montecarlo), mientras que las CPU sólo consiguen sus 12 MRPS para los rayos primarios y sombras (rayos coherentes). Además la implementación en CUDA es mucho más sencillas; no hay paquetes que romper, ni paquetes de ningún tipo, ni MRLTA, ni nada, sólo el arbol y la intersección con triángulos. Vamos, todo ventajas salvo por la limitación de la cantaidad de memoria de las GPUs.

Citar

inigo quilez

| 81.243.230.xxx | 2008-11-22 10:46:18

quise decir, "nVidia" (el chistecillo al final se ha colado en mi subconsciene!)

Citar

Rasty3D

| 81.208.36.xxx | 2008-11-22 12:05:31

Hay también una "pequeña" limitación de CUDA y es que no puedes hacer recursividad. Así que el raytrace se complica un poco.

Citar

David Miraut

| 84.77.150.xxx | 2008-11-22 13:18:30

#Rasty 3D

Hay unos cuantos trucos para evitar esa recursividad de forma sencilla, como implementar la pila en memoria compartida ó -más eficiente- utilizar estructuras jerarquicas hilvanadas.
No me he mirado el código de esta implementación. Por lo que tengo entendido, el mayor reto a la hora de sacarle realmente el jugo a la tarjeta en CUDA para raytracing es bajar todo lo posible el numero de registros a utilizar en el multiprocesador (para aumentar el número de hilos) y organizar los paquetes de manera que aprovechen lo mejor posible el ancho de banda fusionando peticiones a memoria.

Si no me equivoco hay un chico de la Complutense que está comenzando su tesis en este tema. Esta semana estuvo en la URJC, pero no pude hablar con él.

Citar

Rasty3D

| 81.208.36.xxx | 2008-11-22 13:45:14

No tengo ni idea de como se implementa lo de la pila en memoria compartida y todavía menos que es eso de estructuras jerárquicas hilvanadas. Pero suena interesante. ¿Tienes algún link sobre eso?

Lo que hice yo en plan chapucero es poner un bucle, pero se limita mucho el número de threads.

De todas formas, con mi implementación por lo menos, el uso de la memoria compartida para cargar la escena fue el gran salto en rendimiento. La reducción del número de threads casi no me repercutió en el rendimiento. Pero solo hacía un paso de reflexión. Quizás con más puede ser más relevante.

Citar

- greenbite - Muy interesante

| 83.43.134.xxx | 2008-11-22 14:25:46

Es muy interesante este tema, yo también quiero investigar un poco sobre Cuda. Sobre todo el problema del raytracing es muy paralelizable y el futuro está en esto, aprender a paralelizar los calculos de manera eficiente.

Citar

derethor

| 91.117.5.xxx | 2008-11-22 20:33:18

pues yo hace que no uso recursividad... un bucle de "hasta que el rayo muera" es bastante más eficiente, no?

Citar

inigo quilez

| 81.241.25.xxx | 2008-11-22 22:04:52

si, es lo que todo el mundo usa (a lo Wald). Ah, cuando dije que la GPU no sufre de incoherencia me refería claro está a que a diferencia de las implementaciones sobre CPU, las figuras de rendimiento actuales en las GPUS no se basan en explotar la coherencia tanto como en la CPU, así que los rayos desordenados hacen menos daño que en el caso de la CPU.

Citar

xnormal

| 87.220.157.xxx | 2008-11-24 07:58:47

Yo estaba implementando ray tracing en CUDA para mi programita... pero creo que voy a esperar a OpenCL para que vaya en ATI también... no me hace mucho tilín tener que codear dos veces lo mismo ( uno en CUDA y otro en StreamSDK ) la verdad...

Citar

- greenbite - opencl

| 212.122.101.xxx | 2008-11-24 11:13:08

¿Se sabe el estado actual de OpenCL?

Citar

mimestim

| 84.79.161.xxx | 2008-11-24 12:52:24

Pues en cuanto a OpenCL , no se si es bueno o malo , pero parece ser que han tardado solo 6 meses (lo digo porque ha veces tardan años y tampoco sale nada bueno)en realizar la especificación (ahora estan comprobando si no imcumple temas de propiedad intelectual).

http://www.macrumors.com/2008/11/19/opencl-specification-completed-in-record-time-for-snow-leopard/

En un principio parace malo, ya que todo apunta ha que se han dado prisa porque a apple le interesaba que estuviese lo antes posible de cara al Snow Leopard...

Citar