trazado de rayos con CUDA
https://stackoverflow.com/questions/39473
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Actualmente estoy implementando un raytracer.Dado que el trazado de rayos requiere una gran cantidad de cálculo y que de todos modos voy a investigar la programación CUDA, me preguntaba si alguien tiene alguna experiencia en la combinación de los dos.Realmente no puedo decir si los modelos computacionales coinciden y me gustaría saber qué esperar.Me da la impresión de que no es exactamente una combinación perfecta, pero un aumento de velocidad decente sería mejor que nada.
Solución
Una cosa de la que hay que tener mucho cuidado en CUDA es que el flujo de control divergente en el código del kernel MATA absolutamente el rendimiento, debido a la estructura del hardware de la GPU subyacente.Las GPU suelen tener cargas de trabajo masivas de datos paralelos con un 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 de ellos) serán operados por el exacto mismo programa de sombreado, incluso tomando la misma dirección a través de todas las ramas.Esto les permite realizar algunas optimizaciones de hardware, como tener solo un caché de instrucciones, una unidad de recuperación y una lógica de decodificación para cada grupo de 32 subprocesos.En el caso ideal, que es común en gráficos, pueden transmitir la misma instrucción a los 32 conjuntos de unidades de ejecución en el mismo ciclo (esto se conoce como SIMD, o Datos múltiples de instrucción única).Ellos pueden emular MIMD (Instrucción múltiple) y SPMD (Programa único), pero cuando los subprocesos dentro de un multiprocesador de transmisión (SM) divergen (toman diferentes rutas de código de una rama), la lógica del problema en realidad cambia entre cada ruta de código en un ciclo. -base del ciclo.Puede imaginar que, en el peor de los casos, donde todos los subprocesos están en rutas separadas, la utilización de su hardware se redujo en un factor de 32, eliminando efectivamente cualquier beneficio que hubiera obtenido al ejecutar una GPU sobre una CPU, especialmente considerando la sobrecarga asociada con la clasificación del conjunto de datos desde la CPU, a través de PCIe, a la GPU.
Dicho esto, el trazado de rayos, aunque en cierto sentido es paralelo a los datos, tiene un flujo de control muy divergente incluso para escenas modestamente complejas.Incluso si logra mapear un grupo de rayos muy espaciados que lanza uno al lado del otro en el mismo SM, la localidad de datos e instrucciones que tiene para el rebote inicial no se mantendrá por mucho tiempo.Por ejemplo, imaginemos los 32 rayos altamente coherentes rebotando en una esfera.Todos 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, etc.Cada material y conjunto de iluminación, oclusión, etc.Las condiciones tienen su propio flujo de instrucciones asociado (para calcular la refracción, la reflexión, la absorción, etc.), por lo que resulta bastante difícil ejecutar el mismo flujo de instrucciones incluso en una fracción significativa de los subprocesos en un SM.Este problema, con el estado actual del arte en el código de trazado de rayos, reduce la utilización de la GPU en un factor de 16 a 32, lo que puede hacer que el rendimiento sea inaceptable para su aplicación, especialmente si es en tiempo real (p. ej.un juego).Aún podría ser superior a una CPU, por ejemplo.una granja de renderizado.
Actualmente la comunidad investigadora está analizando una clase emergente de aceleradores MIMD o SPMD.Las consideraría plataformas lógicas para software, trazado de rayos en tiempo real.
Si está interesado en los algoritmos involucrados y en asignarlos al código, consulte POVRay.Mire también 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 trazado de rayos.
Otros consejos
Ciertamente se puede hacer, se ha hecho y es un tema candente actualmente entre los gurús del trazado de rayos y Cuda.Yo empezaría examinando http://www.nvidia.com/object/cuda_home.html
Pero es básicamente un problema de investigación.Las personas que lo están haciendo bien obtienen artículos de investigación revisados por pares.Pero Bueno En este punto, todavía significa que los mejores resultados de GPU/Cuda son aproximadamente competitivos con las mejores soluciones de su clase en CPU/multinúcleo/SSE.Así que creo que es un poco pronto para asumir que el uso de Cuda acelerará un trazador de rayos.El problema es que, aunque el trazado de rayos es "vergonzosamente paralelo" (como dicen), no es el tipo de problema de "tamaño fijo de entrada y salida" que se asigna directamente a las GPU: desea árboles, pilas, estructuras de datos dinámicas, etc. .Se puede hacer con Cuda/GPU, pero es complicado.
Su pregunta no fue clara sobre su nivel de experiencia o los objetivos de su proyecto.Si este es tu primer trazador de rayos y solo estás tratando de aprender, evitaría Cuda: te llevará 10 veces más desarrollarlo y probablemente no obtendrás una buena velocidad.Si eres un programador de Cuda con experiencia moderada y estás buscando un proyecto desafiante y el trazado de rayos es algo divertido de aprender, intenta hacerlo en Cuda.Si estás creando una aplicación comercial y estás buscando obtener una ventaja competitiva en velocidad, bueno, probablemente sea una apuesta perdida en este momento...es posible que obtenga una ventaja en el rendimiento, pero a expensas de un desarrollo más difícil y de la dependencia de un hardware concreto.
Vuelva a consultar dentro de un año, la respuesta puede ser diferente después de una o dos generaciones más de velocidad de GPU, desarrollo del compilador Cuda y experiencia de la comunidad de investigación.
Nvidia hizo una demostración de un trazador de rayos en CUDA en su conferencia NVision de este año.Aquí hay un enlace a sus diapositivas al respecto.
