¿Cuáles son los pros y los contras de HLSL vs GLSL vs cg? [cerrado]


61

¿Cuáles son los pros / contras de los tres?


2
Parece que primero necesitarías decidir qué API estabas buscando (OGL o DX) y qué plataformas antes de decidir qué lenguaje de sombreador.
Tetrad

1
Creo que esta pregunta es brillante. ¿Qué tal un wiki comunitario? Soy nuevo en todo esto y una pregunta sobre las diferencias con los sombreadores es exactamente lo que necesito saber.
Mladen Mihajlovic

3
Corrección: "cerrado como no constructivo" debería decir "cerrado como violando la política de tontos", porque ES ES constructivo.
Lennart Rolland

Respuestas:


42

coderanger tiene razón acerca de que HLSL apunta a DirectX, GLSL apunta a OpenGL y CG está disponible con ambas interfaces.

Sin embargo, hay otras cosas a considerar (aprendidas en el foro OGRE):

  • CG no le permitirá utilizar las últimas funciones de GLSL (no estoy seguro acerca de HLSL). Es un término medio, por lo que no podrá explotar completamente las características de GLSL, solo la común hasta Shader Model 3.0 (AFAI entendido).
  • CGidia está hecho por NVidia que lo optimiza para su tarjeta pero no parece hacer mucho trabajo para las tarjetas ATI ... algunas personas informan que podría haber problemas con las tarjetas ATI que usan CG.
  • OpenGL parece ser un poco más lento que DirectX en plataformas Windows. Eso es realmente relativo a lo que está haciendo y la razón de esto encuentra su origen en las implementaciones de los controladores, pero es bueno saberlo antes de elegir la API y el lenguaje de sombreador asociado. Sin embargo, OpenGL es la única interfaz disponible en todas las plataformas (win / mac / unix / algunas consolas). Entonces, sabiendo eso, usar exclusivamente GLSL podría ser la mejor opción para un juego multiplataforma no centrado en Microsft.
  • Los controladores NVidia en Linux parecen ser más estables que los controladores ATI, lo que hace que CG sea más interesante si necesita asegurarse de que funciona bien en Linux (eso es toda la información reportada, tendrá que verificar los detalles)

Entonces, si no está utilizando las últimas funciones de sombreado, CG parece una buena opción. GLSL parece mejor si vas a usar OpenGL completo. HLSL si vas exclusivamente a plataformas Microsoft.

Ahora, desarrollar primero en HLSL para Windows para usar DirectX y luego convertirlo a GLSL para Linux y Mac podría ser la mejor solución para estar seguro del rendimiento y tener disponible el conjunto más amplio de características de sombreado. Sin embargo, podría ser mucho trabajo (no lo hice yo mismo, así que no puedo decirlo). El motor de gráficos OGRE (y otros motores) permiten usar cualquier API (DirectX u OpenGL u otros), por lo que ayuda, pero todavía hay un código de sombreador para convertir si sigue este camino.

Esa es toda la información que reuní al elegir mi idioma de sombreador (aún no he tomado una decisión).


Actualización: Valve realizó una conversión de uno de sus juegos a OpenGL y no encontró forma de hacer que la versión de DirectX sea más rápida que la de OGL . Tenga en cuenta que el estado de la implementación del controlador, la calidad de la API, etc., todo eso cambia demasiado cada año para que pueda confiar totalmente en el rendimiento bruto como argumento para elegir uno u otro. Con esto en mente, elija OpenGL / GLSL para simplificar su vida cuando trabaje (o tenga planes o espere trabajar) con otras plataformas que no sean Windows, use DirectX / HLSL si realmente quiere usar solo plataformas y enfoque de Microsoft y tal vez tener algo bueno API más rápido que OpenGL (esto se está invirtiendo ahora, así que no cuentes con eso); use CG si desea proporcionar ambas posibilidades al usuario, pero si tiene la fuerza de trabajo (y las herramientas) para hacerlo, usar GLSL y HLSL también podría ser una solución viable.


Actualización (2012): es importante tener en cuenta que CG ha sido descontinuado y Nvidia ya no lo respalda ni lo trabaja activamente. Nvidia recomienda que todos los usuarios cambien a una combinación de GLSL y HLSL, o una biblioteca más nueva como nvFX (en github). Esto se debe a que era demasiado difícil mantener la compatibilidad de características entre GLSL y HLSL.


2
. A NVIDIA no parece importarle los problemas con las tarjetas ATI.
bobobobo

44
"OpenGL parece ser un poco más lento que DirectX en plataformas Windows". En la mayoría de los casos, generalmente se debe a que el soporte de proveedores para controladores con OpenGL no es tan bueno en Windows como lo es con DirectX.
ChrisC

1
Nota: Elegí OpenGL / GLSL al final debido a las mejoras recientes y la necesidad de asegurarme de que mi juego funcione en algunas tabletas que no son MS.
Klaim

2
@Comunidad: ¿Tiene algún enlace para suspender el soporte para Cg?
Nicol Bolas


15

Solo puedo hablar de CG vs HLSL porque esos son los 2 que he usado hasta ahora.

Cg no es lo mismo que HLSL.

En CG, NVIDIA hizo un excelente trabajo al crear una sintaxis de sombreador muy limpia. Es muy similar a HLSL.

Pero , la vinculación con D3D9 / D3D11 (código de inicio, código de compilación del sombreador) es mucho más limpia en HLSL que Cg. -1 Cg. Cg tiene un código de inicio desagradable que ni siquiera necesita tener para HLSL sobre D3D.

En Cg, debe "cgGetNamedParameter" para cada uniform variable de sombreador que desee establecer / modificar. Y debe mantener una CGparameterreferencia en su código para esa variable

// C++ code to interact with Cg shader variable (shader language independent)
CGparameter mvp = cgGetNamedParameter( vs, "modelViewProj" ); 
CG::getLastError("Getting modelViewProj parameter");  // check for errors
cgSetMatrixParameterdr( mvp, &modelViewProj._11 ) ;   // setting the matrix values

En HLSL, esto termina siendo mucho más limpio, solo una línea, y no tiene que mantener esa CGparametervariable.

// D3D9 C++ code to interact with HLSL shader variable
DX_CHECK( id3dxEffect->SetMatrix("modelViewProj", &mvp._11 ), "Set matrix" ) ;

En lo anterior, DX_CHECKes solo una función simple que verifica el HRESULT que se devuelve de la SetMatrixllamada. El código anterior es d3d9 . D3D10 y 11, por supuesto, son mucho más dolorosos (ya que no hay un objeto ID3DX11Effect).

Antes de comenzar a usar HLSL, solía mirar este código y realmente me ponía celoso .

Aunque NVIDIA hicieron todo lo posible para hacer una interfaz común para CG entre OpenGL / D3D, en la práctica su no de esa manera, y tiene cgGL*, cgD3D9, cgD3D10,cgD3D11 grupos de funciones que lidiar. ¡Así que todo funciona para OpenGL y D3D! reclamo solo va tan lejos. Todavía tiene que envolver todo en #ifdefgrupos de tipo OpenGL / D3D para que funcione en diferentes plataformas. -2 Cg.

Además, recientemente tuve una mala experiencia con las tarjetas Cg / ATI, que estoy bastante seguro de que no es mi mala. (¿Alguien más lo prueba?). Creo que puede ser cierto que NVIDIA no prueba completamente las tarjetas ATI, como afirma Klaim. O que ATI no prueba en Cg. De una forma u otra, hay un desajuste allí y algún tipo de conflicto de intereses. -3 Cg.

En general, preferí Cg. Su sintaxis y denominación de código de sombreador es limpia, dulce y ordenada. Es una lástima que tenga estos otros problemas.


10

Mi comprensión básica es que HLSL es solo para DirectX y GLSL es solo para OpenGL. Cg es básicamente el mismo lenguaje que HLSL, pero se puede usar con DirectX u OpenGL (aunque a través de un código de tiempo de ejecución diferente).


+1 Eso también lo entiendo, personalmente me gusta usar cg siempre que puedo, pero agrega una dependencia adicional más allá del sistema de renderizado en sí; y creo recordar haber tenido algunos problemas extraños con los controladores OpenGL, cg y ATI con algunos efectos más complejos ...
Riley Adams

Estoy usando Ogre y, por lo tanto, tengo los tres disponibles, pero si quiero tener DirectX y OpenGL, ¿tengo que escribir los sombreadores en HLSL y GLSL o simplemente cg? ¿Está bien?
Z_guy

14
-1. Esta es una respuesta extremadamente rudimentaria y uno esperaría encontrar información más extensa en este sitio.
bobobobo

2
-1: Estoy de acuerdo con bobobobo.
Nicol Bolas

1
Lamentablemente tengo que -1 por las mismas razones que bobobobo.
Jonathan Dickinson

8

Otra diferencia crucial entre HLSL y GLSL (no conozco CG así que no puedo hablar por ello) es que con HLSL Microsoft proporciona el compilador de sombreado como parte del tiempo de ejecución D3D mientras que con GLSL su proveedor de hardware lo proporciona como parte de su conductor.

Esto tiene ventajas y desventajas en ambos lados.

Con el método GLSL, el proveedor puede ajustar el compilador a las capacidades de su hardware. Conocen mejor su propio hardware, saben qué hacer y qué no hacer. Por otro lado, la desventaja es que, en un mundo donde hay múltiples proveedores de hardware, existe una situación en la que puede haber inconsistencias entre los compiladores de sombreadores, y el proveedor también tiene un reinado libre completo para fastidiar.

Con el método HLSL, Microsoft controla el compilador. Todos tienen una base tecnológica constante, y si un sombreador se compila con éxito en un lugar, se puede suponer razonablemente que se compilará en todas partes. El mismo sombreador producirá la misma salida compilada independientemente del proveedor (todas las demás cosas son iguales, por supuesto). Por otro lado, el compilador HLSL tiene que ser un "funciona de manera consistente en todo", por lo que no es capaz de sacar ningún truco específico del proveedor para sacar las últimas gotas de jugo del tanque.

Si esto aparece como si tuviera preferencia por la visión HLSL del mundo, es porque lo hago. Me han mordido mucho antes por un comportamiento muy inconsistente en diferentes plataformas, y en un caso incluso tuve que llevar una carga de GLSL a ARB ASM solo para obtener una línea de base que funcionó. El compilador GLSL de NVIDIA se puede ver como particularmente notorio aquí: incluso aceptará la sintaxis y las palabras clave de HLSL, lo que significa que si no tiene cuidado puede terminar produciendo sombreadores que solo funcionarán en NVIDIA y nada más. Es una jungla alla afuera.


1
Para ser justos, el compilador GLSL de NVIDIA se ha vuelto bastante más estricto acerca de lo que hace y no acepta desde aquellos días. Pero incluso hoy, hay lo que yo llamo "trampas NVIDIA" que hacen que sea fácil hacer algo que crees que debería funcionar, pero no de acuerdo con las especificaciones reales y los controladores AMD.
Nicol Bolas

Incluso iría tan lejos como para decir que el desarrollo en ATI / AMD, o al menos la verificación cruzada con ATI / AMD de forma regular, sigue siendo una necesidad absoluta. Obtienes dos asesinatos por el precio de uno allí, ya que también detectarás errores en su controlador OpenGL.
Maximus Minimus

Al apuntar a implementaciones de Vulkan u OpenGL que admiten SPIR-V, los sombreadores GLSL se pueden precompilar en SPIR-V.
Andrea

@Andrea: sí, eso es correcto; obviamente, ni Vulkan ni SPIR-V existían en el momento en que se hizo la pregunta (y se escribió la respuesta).
Maximus Minimus

1

He estado usando ambos, comencé con glsl y me mudé a hlsl solo porque el proyecto lo exige. Dada la opción, es glsl todo el camino. glsl se siente muy hábil y hlsl parece que salió de la banca de pasatiempos de un ingeniero.


1

Es posible que también desee ver el RTSS (Sistema de sombreado de tiempo de ejecución) que viene con Ogre. Es bastante nuevo, pero básicamente escribes sombreadores en código en lugar de archivos externos. Todavía no lo he implementado, pero definitivamente planeo usar esto cuando llegue el momento.

Aquí hay una gran serie de tutoriales en la wiki de Ogre también para escribir sombreadores. http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide

En cuanto a su pregunta original, como dijo Praetor, no es realmente una cuestión de pros / contras, es una cuestión de qué sistema de renderización desea utilizar. Dado que usar DX / OpenGL con Ogre es solo cuestión de cargar el complemento, lo más probable es que desee usar el formato .cg.

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.