Una cosa a tener mucho cuidado con los de CUDA es que el flujo de control divergentes en su código del núcleo MATA absolutamente rendimiento, debido a la estructura del hardware de la GPU subyacente. Las GPU suelen tener cargas de trabajo paralelas masivas con flujo de control altamente coherente (es decir, tienes un par de millones de píxeles, cada uno de los cuales (o al menos grandes franjas) será operado por el mismo programa de sombreador mismo, incluso tomando la misma dirección a través de todas las ramas. Esto les permite realizar algunas optimizaciones de hardware, como tener un solo caché de instrucciones, unidad de recuperación y lógica de decodificación para cada grupo de 32 subprocesos. En el caso ideal, que es común en los gráficos, puede transmitir la misma instrucción a los 32 conjuntos de unidades de ejecución en el mismo ciclo (esto se conoce como SIMD, o de un solo instrucción múltiple-Data). pueden emular MIMD (Multiple-instrucción) y SPMD (Single-Programa) , pero cuando los hilos dentro de un Streaming Multiprocessor (SM) divergen (toman diferentes rutas de código de una rama), la lógica de problemas realmente cambia entre cada ruta de código en ciclo por ciclo. Puede imaginarse que, en el peor de los casos, donde todos los hilos están en rutas separadas, su utilización de hardware se redujo en un factor de 32, lo que elimina con eficacia cualquier beneficio que hubiera tenido si ejecutara una GPU sobre una CPU, especialmente considerando la sobrecarga asociada con la clasificación del conjunto de datos de la CPU, sobre PCIe, a la GPU.
Dicho esto, el trazado de rayos, mientras que los datos en paralelo en cierto sentido, ha ampliamente divergentes flujo de control, incluso para escenas modestamente-complejos. Incluso si logras mapear un grupo de rayos espaciados estrechamente que lanzas uno al lado del otro en el mismo SM, la localidad de datos e instrucción que tienes para el rebote inicial no se mantendrá por mucho tiempo. Por ejemplo, imagina los 32 rayos altamente coherentes que rebota en una esfera.Todos ellos irán en direcciones bastante diferentes después de este rebote, y probablemente golpearán objetos hechos de diferentes materiales, con diferentes condiciones de iluminación, y así sucesivamente. Cada material y conjunto de condiciones de iluminación, oclusión, etc. tiene su propia secuencia de instrucciones asociada (para calcular la refracción, reflexión, absorción, etc.), por lo que resulta bastante difícil ejecutar la misma secuencia de instrucciones incluso en una fracción significativa. de los hilos en un SM. Este problema, con el estado del arte actual en el código de trazado de rayos, reduce la utilización de su GPU por un factor de 16-32, lo que puede hacer que el rendimiento sea inaceptable para su aplicación, especialmente si es en tiempo real (por ejemplo, un juego). Todavía podría ser superior a una CPU para, p. Ej. una granja de render.
Hay una clase emergente de aceleradores MIMD o SPMD que se observan ahora en la comunidad de investigación. Consideraría estas como plataformas lógicas para el software, trazado de rayos en tiempo real.
Si está interesado en los algoritmos involucrados y los asigna al código, consulte POVRay. También busque en el mapeo de fotones, es una técnica interesante que incluso va un paso más cerca de representar la realidad física que el raytracing.
Tengo un pequeño proyecto para construir mi primer raytracer y nunca he trabajado en CUDA, así que estoy en una posición deficiente para hacer algo grandioso, pero durante el año que viene estoy trabajando con la tecnología GPGPU. Esto me lleva a familiarizarme con CUDA y me preguntaba hasta qué punto puedo usar este conocimiento. –
¿Estás seguro de que es un problema embarazosamente paralelo? La solución para encontrar el siguiente objeto de reflexión y las variaciones en el manejo del material (como lo señaló Matt J) parece que podrían romper el paralelismo de manera significativa. Pero por favor corrígeme si estoy equivocado. –