Implementación de algoritmos a través de sombreadores informáticos frente a sombreadores de canalización


10

Con la disponibilidad de sombreadores de cómputo tanto para DirectX como para OpenGL, ahora es posible implementar muchos algoritmos sin pasar por la tubería de rasterización y, en cambio, usar computación de propósito general en la GPU para resolver el problema.

Para algunos algoritmos, esto parece convertirse en la solución canónica intuitiva porque no son inherentemente basados ​​en rasterización, y los sombreadores basados ​​en rasterización parecen ser una solución alternativa para aprovechar la potencia de la GPU (ejemplo simple: crear una textura de ruido. No es necesario rasterizar aquí ningún quad) )

Dado un algoritmo que puede implementarse en ambos sentidos, ¿existen beneficios generales (potenciales) de rendimiento sobre el uso de sombreadores de cómputo frente a la ruta normal? ¿Hay inconvenientes que debemos tener en cuenta (por ejemplo, ¿hay algún tipo de sobrecarga inusual para cambiar / calcular sombreadores en tiempo de ejecución)?

¿Hay quizás otros beneficios o inconvenientes a considerar al elegir entre los dos?


Si la etiqueta de rendimiento es realmente relevante, considere ver este video del artículo "Simulación de tela" de Game Engine Gems de Marco Fratarcangeli: youtube.com/watch?v=anNClcux4JQ . Podrías leer los comentarios y descubrir algo incómodo: la implementación basada en GLSL / shader fue más rápida que usar CUDA u OpenCL (esto último debido a la falta de soporte del controlador en ese momento, en 2010). Hay ciertas diferencias de bajo nivel que ... marcan la diferencia.
teodron

@teodron No tengo GPU Gems disponibles y no puedo encontrar el código fuente. ¿El autor realmente usó sombreadores de vértices + píxeles GLSL o usó sombreadores de cálculo GLSL?
TravisG

¡Si! Antes de CUDA, así es como la comunidad implementó las características de GPGPU. Aquí hay un enlace a OpenCloth para ver cómo se puede lograr eso usando GLSL OR Cuda puro: code.google.com/p/opencloth/source/browse/trunk/…
teodron

Respuestas:


7

No hay una respuesta correcta si se va a beneficiar directamente de la aplicación de sombreadores de cálculo / GPGPU, esto depende en gran medida del tipo de algoritmo que esté implementando, los sombreadores de cálculo y CUDA / OpenCL son un enfoque más generalizado para superar algunas de las limitaciones de ese viejo lenguaje de sombreado. Los beneficios más importantes que obtendrá:

  • Acceso a información espacial. en el viejo truco GLSL (bueno, ¡fue un truco!) solo da poca información sobre fragmentos vecinos ya que usa coordenadas de textura. En cómputo de sombreadores / CUDA / OpenCL, el acceso a la información espacial es mucho más flexible, ahora puede implementar algoritmos como la ecualización de histogramas en la GPU con acceso de textura / buffer no ordenado.
  • Te da sincronización de hilos y atómica .
  • Compute Space: el viejo truco GLSL conectará el espacio de cómputo de vértices / fragmentos a su sombreador. El sombreador de fragmentos se ejecutará con el número de fragmentos, el sombreador de vértices se ejecutará con el número de vértices. En el sombreador de cálculo, usted define su propio espacio.
  • Escalabilidad : su sombreador de cómputo / CUDA / OpenCL puede escalar hasta el número de GPU SM (Multiprocesador de transmisión) disponibles a diferencia de su antiguo sombreador GLSL que debería ejecutarse en el mismo SM. (Según los comentarios de Nathan Reed, dice que eso no es cierto, y los sombreadores deberían escalar tan bien como deberían hacerlo los sombreadores informáticos. Todavía no estoy seguro, aunque necesito verificar la documentación).
  • Cambio de contexto : debería haber algún cambio de contexto, pero diría que depende de la aplicación, por lo que su mejor opción es perfilar su aplicación.

Bueno, en mi opinión , si desea seguir la ruta de los sombreadores de cómputo, aunque ciertos algoritmos pueden ser más adecuados, hay ciertas consideraciones que debe tener en cuenta:

  1. Hardware y compatibilidad con versiones anteriores . Los sombreadores informáticos solo están disponibles en el hardware más nuevo y si va a buscar un producto comercial (por ejemplo, un juego), debe esperar que muchos usuarios no puedan ejecutar su producto.
  2. Por lo general, es necesario tener conocimientos extra en la GPU / CPU arquitectura , programación paralela y multi-hilo (por ejemplo, compartir la memoria, la coherencia de la memoria, la sincronización de hilos, atómica y de efecto en el rendimiento) que por lo general no es necesario el uso normal de los shaders rounte.
  3. Recursos de aprendizaje , por experiencia, hay muchos menos recursos de aprendizaje para los sombreadores Compute, OpenCL y CUDA (que también ofrecen interoperabilidad OpenGL) que la ruta de sombreadores habitual.
  4. Las herramientas de depuración , con la falta de una depuración adecuada, el desarrollo de herramientas puede ser mucho más difícil que la mayoría de los sombreadores, al menos los sombreadores se pueden depurar visualmente.
  5. Espero que los sombreadores informáticos ofrezcan un mejor rendimiento que el mismo algoritmo en otros sombreadores; si se hicieron correctamente teniendo en cuenta las cosas desde el punto 2, ya que fueron diseñados para evitar los pasos adicionales para la representación gráfica. Pero no tengo ninguna evidencia concreta para apoyar mi reclamo.
  6. También debe considerar CUUDA / OpenCL para GPGPU si va por esa ruta.

Sin embargo, estoy seguro de que es excelente para el futuro y será una gran experiencia de aprendizaje. ¡Buena suerte!


Creo que el OP podría estar preguntando esto: ¿por qué resolver un problema usando sombreadores GLSL puros versus codificarlo en CUDA? Hay un artículo de Game Programming Gems sobre simulación de telas en el que el autor hace exactamente eso. Y la forma hacky GLSL es mejor que la forma CUDA en términos de rendimiento. Probablemente deberías señalar por qué si tienes alguna idea de por qué.
teodron

2
No creo que su punto de escalabilidad sea correcto: los sombreadores de vértices y fragmentos son tan capaces de escalar en toda la GPU como los sombreadores de cómputo. En realidad, calcular los sombreadores puede ser más difícil de escalar, ya que el tamaño del grupo de subprocesos y el uso de memoria compartida pueden poner límites adicionales a la cantidad de subprocesos de sombreador que se pueden ejecutar a la vez.
Nathan Reed

2
Además, si está rellenando una textura (por ejemplo, generando ruido o haciendo algún otro algoritmo de procedimiento), en mi experiencia, un sombreador de fragmentos será más rápido que un sombreador de cómputo si simplemente está evaluando una fórmula en cada píxel. Supongo que esto se debe a que el orden de los fragmentos coincide con el orden interno de píxeles en mosaico / mosaico, obteniendo así una mejor ubicación de memoria que el sombreador de cómputo que desconoce este orden. Los sombreadores informáticos son solo más rápidos si puede usar sus características especiales, por ejemplo, memoria compartida, para acelerar mucho las cosas en relación con un sombreador de fragmentos.
Nathan Reed

2
OK, último comentario. :) Creo que la mayoría de las GPU actuales tienen algún tipo de cambio de contexto o cambio de modo al pasar de gráficos a computación y viceversa. Entonces, si ejecuta algunos sombreadores de gráficos, luego envía un sombreador de cómputo, luego ejecuta algunos más sombreadores de gráficos, etc., está experimentando un cierto impacto en el rendimiento al cambiar de un lado a otro. Eso es algo que tendría que perfilar, pero podría ser otra razón para seguir con los sombreadores de gráficos en un caso particular.
Nathan Reed

@NathanReed gracias por los comentarios. Actualizaré mi respuesta.
concept3d
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.