Muchas de las respuestas aquí son realmente buenas. Pero el problema de OpenGL y Direct3D (D3D) probablemente debería abordarse. Y eso requiere ... una lección de historia.
Y antes de comenzar, sé mucho más sobre OpenGL que sobre Direct3D . Nunca he escrito una línea de código D3D en mi vida, y he escrito tutoriales en OpenGL. Entonces, lo que voy a decir no es una cuestión de parcialidad. Es simplemente una cuestión de historia.
Nacimiento del conflicto
Un día, a principios de los 90, Microsoft miró a su alrededor. Vieron que SNES y Sega Genesis eran increíbles, ejecutaban muchos juegos de acción y demás. Y vieron DOS . Los desarrolladores codificaron juegos de DOS como juegos de consola: directo al metal. Sin embargo, a diferencia de las consolas, donde un desarrollador que hizo un juego SNES sabía qué hardware tendría el usuario, los desarrolladores de DOS tuvieron que escribir para múltiples configuraciones posibles. Y esto es bastante más difícil de lo que parece.
Y Microsoft tuvo un problema mayor: Windows. Mira, Windows quería ser dueño del hardware, a diferencia de DOS, que prácticamente permitía a los desarrolladores hacer lo que sea. Ser propietario del hardware es necesario para tener cooperación entre las aplicaciones. La cooperación es exactamente lo que odian los desarrolladores de juegos porque consume recursos de hardware preciosos que podrían estar utilizando para ser increíbles.
Para promover el desarrollo de juegos en Windows, Microsoft necesitaba una API uniforme que fuera de bajo nivel, se ejecutara en Windows sin ser ralentizada y, sobre todo , en hardware cruzado . Una única API para todos los gráficos, sonido y hardware de entrada.
Por lo tanto, nació DirectX .
Los aceleradores 3D nacieron unos meses después. Y Microsoft se encontró con un problema. Vea, DirectDraw, el componente gráfico de DirectX, solo se ocupó de gráficos 2D: asignando memoria de gráficos y haciendo bits de bits entre diferentes secciones asignadas de memoria.
Así que Microsoft compró un poco de middleware y lo transformó en Direct3D Versión 3. Fue universalmente vilipendiado. Y con buena razón; mirar el código D3D v3 es como mirar el Arca del Pacto.
El viejo John Carmack de Id Software echó un vistazo a esa basura y dijo: "¡A la mierda!" y decidí escribir para otra API: OpenGL.
Mira, otra parte de la bestia de muchas cabezas que es Microsoft había estado ocupada trabajando con SGI en una implementación de OpenGL para Windows. La idea aquí era cortejar a los desarrolladores de aplicaciones GL típicas: aplicaciones de estaciones de trabajo. Herramientas CAD, modelado, ese tipo de cosas. Los juegos eran lo más alejado en su mente. Esto era principalmente una cosa de Windows NT, pero Microsoft decidió agregarlo a Win95 también.
Como una forma de atraer a los desarrolladores de estaciones de trabajo a Windows, Microsoft decidió intentar sobornarlos con acceso a estas nuevas tarjetas gráficas 3D. Microsoft implementó el protocolo Installable Client Driver: un fabricante de tarjetas gráficas podría anular la implementación del software OpenGL de Microsoft con una basada en hardware. El código podría usar automáticamente una implementación de hardware OpenGL si hubiera una disponible.
En los primeros días, las tarjetas de video a nivel de consumidor no tenían soporte para OpenGL. Eso no impidió que Carmack solo transfiriera Quake a OpenGL (GLQuake) en su estación de trabajo SGI. Como podemos leer del archivo Léame de GLQuake:
Teóricamente, glquake se ejecutará en cualquier OpenGL compatible que admita las extensiones de objetos de textura, pero a menos que sea un hardware muy potente que acelere todo lo necesario, el juego no será aceptable. Si tiene que pasar por alguna ruta de emulación de software, es probable que el rendimiento sea muy inferior a un cuadro por segundo.
En este momento (marzo de '97), el único hardware estándar de opengl que puede reproducir razonablemente el terremoto es un realismo intergráfico, que es una tarjeta MUY costosa. 3dlabs ha estado mejorando significativamente su rendimiento, pero con los controladores disponibles todavía no es lo suficientemente bueno para jugar. Algunos de los controladores actuales de 3dlabs para placas de brillo y permedia también pueden bloquearse NT al salir de una ejecución de pantalla completa, por lo que no recomiendo ejecutar glquake en el hardware de 3dlabs.
3dfx ha proporcionado un opengl32.dll que implementa todo lo que necesita Glquake, pero no es una implementación completa de opengl. Es muy poco probable que otras aplicaciones opengl funcionen con él, así que considérelo básicamente como un "controlador de terremoto".
Este fue el nacimiento de los controladores miniGL. Con el tiempo, estos evolucionaron hacia implementaciones completas de OpenGL, ya que el hardware se volvió lo suficientemente potente como para implementar la mayoría de las funciones de OpenGL en el hardware. nVidia fue el primero en ofrecer una implementación completa de OpenGL. Muchos otros proveedores tuvieron problemas, por lo que los desarrolladores prefirieron Direct3D: eran compatibles en una gama más amplia de hardware. Finalmente, solo quedaron nVidia y ATI (ahora AMD), y ambos tuvieron una buena implementación de OpenGL.
Ascendente OpenGL
Así, el escenario está listo: Direct3D vs. OpenGL. Es realmente una historia increíble, considerando lo malo que era D3D v3.
El OpenGL Architectural Review Board (ARB) es la organización responsable de mantener OpenGL. Emiten una serie de extensiones, mantienen el repositorio de extensiones y crean nuevas versiones de la API. El ARB es un comité compuesto por muchos de los actores de la industria gráfica, así como algunos fabricantes de sistemas operativos. Apple y Microsoft han sido miembros del ARB en varias ocasiones.
3Dfx sale con el Voodoo2. Este es el primer hardware que puede hacer texturas múltiples, que es algo que OpenGL no podía hacer antes. Si bien 3Dfx estaba fuertemente en contra de OpenGL, a NVIDIA, fabricantes del próximo chip de gráficos multitextura (TNT1), le encantó. Entonces, el ARB emitió una extensión: GL_ARB_multitexture, que permitiría el acceso a la multitextura.
Mientras tanto, sale Direct3D v5. Ahora, D3D se ha convertido en una API real , en lugar de algo que un gato podría vomitar. ¿El problema? Sin multitextura.
Ups
Ahora, eso no dolería tanto como debería, porque la gente no usaba mucho el multitexturing. No directamente. Las texturas múltiples perjudicaron bastante el rendimiento, y en muchos casos no valió la pena en comparación con las pasadas múltiples. Y, por supuesto, a los desarrolladores de juegos les encanta asegurarse de que sus juegos funcionen en hardware antiguo, que no tenía multitextura, por lo que muchos juegos se envían sin él.
D3D recibió así un indulto.
El tiempo pasa y NVIDIA implementa la GeForce 256 (no GeForce GT-250; la primera GeForce), prácticamente terminando la competencia en tarjetas gráficas durante los próximos dos años. El principal punto de venta es la capacidad de hacer transformaciones e iluminación de vértices (T&L) en hardware. No solo eso, NVIDIA amaba tanto a OpenGL que su motor T&L era efectivamente OpenGL. Casi literalmente; Según tengo entendido, algunos de sus registros tomaron los enumeradores de OpenGL directamente como valores.
Sale Direct3D v6. Múltiples texturas al fin pero ... sin hardware T&L. OpenGL siempre había tenido una línea T&L, aunque antes del 256 se implementaba en software. Así que para NVIDIA fue muy fácil convertir su implementación de software en una solución de hardware. No sería hasta D3D v7 hasta que D3D finalmente tuviera soporte T&L de hardware.
Dawn of Shaders, Crepúsculo de OpenGL
Entonces, salió GeForce 3. Y muchas cosas sucedieron al mismo tiempo.
Microsoft había decidido que no iban a llegar tarde otra vez. Entonces, en lugar de mirar lo que estaba haciendo NVIDIA y luego copiarlo después del hecho, tomaron la asombrosa posición de ir a hablar con ellos. Y luego se enamoraron y tuvieron una pequeña consola juntos.
Un divorcio desordenado se produjo más tarde. Pero eso es para otro momento.
Lo que esto significó para la PC fue que GeForce 3 salió simultáneamente con D3D v8. Y no es difícil ver cómo GeForce 3 influyó en los sombreadores de D3D 8. Los sombreadores de píxeles del Shader Model 1.0 eran extremadamente específicos para el hardware de NVIDIA. No se hizo ningún intento de abstraer el hardware de NVIDIA; SM 1.0 fue justo lo que hizo la GeForce 3.
Cuando ATI comenzó a lanzarse a la carrera de la tarjeta gráfica de rendimiento con la Radeon 8500, había un problema. La canalización de procesamiento de píxeles del 8500 era más poderosa que las cosas de NVIDIA. Entonces, Microsoft emitió Shader Model 1.1, que básicamente era "Lo que sea que haga el 8500".
Eso puede sonar como un fracaso por parte de D3D. Pero el fracaso y el éxito son cuestiones de grados. Y estaba ocurriendo un fracaso épico en OpenGL-land.
NVIDIA amaba OpenGL, por lo que cuando llegó GeForce 3, lanzaron una gran cantidad de extensiones OpenGL. Extensiones propietarias de OpenGL: solo NVIDIA. Naturalmente, cuando apareció el 8500, no podía usar ninguno de ellos.
Vea, al menos en D3D 8 land, puede ejecutar sus sombreadores SM 1.0 en hardware ATI. Claro, tenía que escribir nuevos sombreadores para aprovechar la frescura del 8500, pero al menos su código funcionó .
Para tener sombreadores de cualquier tipo en Radeon 8500 en OpenGL, ATI tuvo que escribir varias extensiones de OpenGL. Extensiones propietarias de OpenGL: solo ATI. Así que necesitabas una ruta de código NVIDIA y una ruta de código ATI, solo para tener sombreadores .
Ahora, usted podría preguntar: "¿Dónde estaba el OpenGL ARB, de quién era el trabajo para mantener actualizado OpenGL?" Donde a menudo terminan muchos comités: fuera de ser estúpido.
Mira, mencioné ARB_multitexture arriba porque tiene mucho en cuenta todo esto. El ARB parecía (desde la perspectiva de un extraño) querer evitar por completo la idea de los sombreadores. Se dieron cuenta de que si aplicaban suficiente capacidad de configuración en la tubería de función fija, podrían igualar la capacidad de una tubería de sombreador.
Entonces, el ARB lanzó extensión tras extensión. Cada extensión con las palabras "texture_env" fue otro intento de parchear este diseño antiguo. Verifique el registro: entre las extensiones ARB y EXT, se hicieron ocho de estas extensiones. Muchos fueron promovidos a versiones principales de OpenGL.
Microsoft era parte del ARB en este momento; se fueron alrededor del momento en que D3D 9 golpeó. Por lo tanto, es muy posible que estuvieran trabajando para sabotear OpenGL de alguna manera. Personalmente dudo de esta teoría por dos razones. Primero, habrían tenido que obtener ayuda de otros miembros de ARB para hacerlo, ya que cada miembro solo obtiene un voto. Y lo más importante, dos, el ARB no necesitaba la ayuda de Microsoft para arruinar las cosas. Veremos más evidencia de eso.
Finalmente, el ARB, probablemente bajo la amenaza de ATI y NVIDIA (ambos miembros activos) finalmente sacó la cabeza lo suficiente como para proporcionar sombreadores de estilo ensamblador reales.
¿Quieres algo aún más estúpido?
Hardware T&L. Algo que OpenGL tuvo primero . Bueno, es interesante Para obtener el máximo rendimiento posible del hardware T&L, debe almacenar sus datos de vértice en la GPU. Después de todo, es la GPU la que realmente quiere usar sus datos de vértice.
En D3D v7, Microsoft introdujo el concepto de búferes Vertex. Estas son franjas asignadas de memoria de GPU para almacenar datos de vértices.
¿Quieres saber cuándo OpenGL obtuvo su equivalente de esto? Oh, NVIDIA, siendo un amante de todo lo relacionado con OpenGL (siempre que sean extensiones propietarias de NVIDIA), lanzó la extensión de rango de matriz de vértices cuando llegó por primera vez la GeForce 256. Pero, ¿cuándo decidió el ARB proporcionar una funcionalidad similar?
Dos años despues . Esto fue después de que aprobaron los sombreadores de vértices y fragmentos (píxeles en lenguaje D3D). Ese es el tiempo que le tomó al ARB desarrollar una solución multiplataforma para almacenar datos de vértices en la memoria de la GPU. Una vez más, algo que el hardware T&L necesita para lograr el máximo rendimiento.
Un idioma para arruinarlos a todos
Entonces, el entorno de desarrollo de OpenGL se fracturó por un tiempo. Sin sombreadores de hardware cruzado, sin almacenamiento de vértices de GPU de hardware cruzado, mientras que los usuarios de D3D disfrutaron de ambos. ¿Podría empeorar?
Tú ... podrías decir eso. Ingrese a 3D Labs .
¿Quiénes son, podrías preguntar? Son una compañía extinta a la que considero los verdaderos asesinos de OpenGL. Claro, la ineptitud general del ARB hizo que OpenGL fuera vulnerable cuando debería haber sido dueño de D3D. Pero 3D Labs es quizás la razón más importante en mi opinión para el estado actual del mercado de OpenGL. ¿Qué podrían haber hecho para causar eso?
Diseñaron el lenguaje de sombreado OpenGL.
Mira, 3D Labs era una empresa moribunda. Sus costosas GPU estaban siendo marginadas por la creciente presión de NVIDIA en el mercado de estaciones de trabajo. Y a diferencia de NVIDIA, 3D Labs no tenía presencia en el mercado principal; Si NVIDIA ganaba, morían.
Lo cual hicieron.
Entonces, en un intento por seguir siendo relevante en un mundo que no quería sus productos, 3D Labs se presentó a una Conferencia de Desarrolladores de Juegos con presentaciones para algo que llamaron "OpenGL 2.0". Esta sería una reescritura completa desde cero de la API de OpenGL. Y eso tiene sentido; En ese momento, había mucho cruft en la API de OpenGL (nota: ese cruft todavía existe). Basta con mirar cómo funciona la carga de textura y la unión; Es semi-arcano.
Parte de su propuesta era un lenguaje de sombreado. Naturalmente. Sin embargo, a diferencia de las extensiones ARB multiplataforma actuales, su lenguaje de sombreado era de "alto nivel" (C es de alto nivel para un lenguaje de sombreado. Sí, de verdad).
Ahora, Microsoft estaba trabajando en su propio lenguaje de sombreado de alto nivel. Lo que ellos, en toda la imaginación colectiva de Microsoft, llamaron ... el lenguaje de sombreado de alto nivel (HLSL). Pero su era un enfoque fundamentalmente diferente de los idiomas.
El mayor problema con el lenguaje de sombreado de 3D Labs fue que estaba incorporado. Vea, HLSL era un lenguaje definido por Microsoft. Lanzaron un compilador para él, y generó el código de ensamblaje Shader Model 2.0 (o modelos posteriores de shader), que ingresaría en D3D. En los días D3D v9, HLSL nunca fue tocado por D3D directamente. Era una bonita abstracción, pero era puramente opcional. Y un desarrollador siempre tuvo la oportunidad de ir detrás del compilador y ajustar la salida para obtener el máximo rendimiento.
El lenguaje de 3D Labs no tenía nada de eso. Le diste al conductor el lenguaje tipo C, y produjo un sombreador. Fin de la historia. No es un sombreador de ensamblaje, no es algo que alimentes con otra cosa. El objeto OpenGL real que representa un sombreador.
Lo que esto significa es que los usuarios de OpenGL estaban abiertos a los caprichos de los desarrolladores que solo estaban aprendiendo a compilar lenguajes similares a los ensamblados. Los errores del compilador corrían desenfrenados en el recientemente bautizado OpenGL Shading Language (GLSL). Lo que es peor, si lograste que un sombreador se compilara en múltiples plataformas correctamente (no es tarea fácil), aún estarías sujeto a los optimizadores del día. Que no eran tan óptimos como podrían ser.
Si bien esa fue la mayor falla en GLSL, no fue la única falla. Por el momento .
En D3D, y en los lenguajes de ensamblaje más antiguos en OpenGL, puede mezclar y combinar sombreadores de vértices y fragmentos (píxeles). Siempre que se comuniquen con la misma interfaz, puede usar cualquier sombreador de vértices con cualquier sombreador de fragmentos compatible. E incluso había niveles de incompatibilidad que podían aceptar; un sombreador de vértices podría escribir una salida que el sombreador de fragmentos no haya leído. Etcétera.
GLSL no tenía nada de eso. Los sombreadores de vértices y fragmentos se fusionaron en lo que 3D Labs llamó un "objeto de programa". Entonces, si quería compartir programas de vértices y fragmentos, tenía que construir varios objetos de programa. Y esto causó el segundo mayor problema.
Mira, 3D Labs pensó que estaban siendo inteligentes. Basaron el modelo de compilación de GLSL en C / C ++. Toma un .c o .cpp y lo compila en un archivo objeto. Luego, toma uno o más archivos de objetos y los vincula a un programa. Así es como se compila GLSL: compila su sombreador (vértice o fragmento) en un objeto sombreador. Luego coloca esos objetos de sombreado en un objeto de programa y los vincula para formar su programa real.
Si bien esto permitió ideas geniales como tener sombreadores de "biblioteca" que contenían código adicional que los sombreadores principales podían llamar, lo que significaba en la práctica era que los sombreadores se compilaron dos veces . Una vez en la etapa de compilación y otra en la etapa de vinculación. El compilador de NVIDIA en particular era conocido por ejecutar básicamente la compilación dos veces. No generó algún tipo de código de objeto intermediario; solo lo compiló una vez y tiró la respuesta, luego la compiló nuevamente en el momento del enlace.
Por lo tanto, incluso si desea vincular su sombreador de vértices a dos sombreadores de fragmentos diferentes, debe compilar mucho más que en D3D. Especialmente porque la compilación de un lenguaje tipo C se realizó sin conexión , no al comienzo de la ejecución del programa.
Hubo otros problemas con GLSL. Quizás parezca incorrecto echarle la culpa a 3D Labs, ya que el ARB finalmente aprobó e incorporó el lenguaje (pero nada más de su iniciativa "OpenGL 2.0"). Pero fue su idea.
Y aquí está la parte realmente triste: 3D Labs tenía razón (principalmente). GLSL no es un lenguaje de sombreado basado en vectores como HLSL era en ese momento. Esto se debió a que el hardware de 3D Labs era hardware escalar (similar al hardware moderno de NVIDIA), pero finalmente estaban en la dirección en la que muchos fabricantes de hardware fueron con su hardware.
Tenían razón al elegir un modelo de compilación en línea para un lenguaje de "alto nivel". D3D incluso cambió a eso eventualmente.
El problema era que 3D Labs tenía razón en el momento equivocado . Y al tratar de convocar el futuro demasiado pronto, al tratar de ser a prueba del futuro, descartan el presente . Suena similar a cómo OpenGL siempre tuvo la posibilidad de funcionalidad T&L. Excepto que la tubería de T&L de OpenGL todavía era útil antes de T&L de hardware, mientras que GLSL era una responsabilidad antes de que el mundo lo alcanzara.
GLSL es un buen lenguaje ahora . Pero por el momento? Fue horrible. Y OpenGL sufrió por ello.
Cayendo hacia la apoteosis
Si bien mantengo que 3D Labs dio el golpe fatal, fue el propio ARB el que clavó el último clavo en el ataúd.
Esta es una historia que quizás hayas escuchado. En el momento de OpenGL 2.1, OpenGL se encontraba con un problema. Tenía mucho legado cruft. La API ya no era fácil de usar. Había 5 formas de hacer las cosas, y no tenía idea de cuál era la más rápida. Podrías "aprender" OpenGL con tutoriales simples, pero realmente no aprendiste la API de OpenGL que te dio un rendimiento real y potencia gráfica.
Entonces el ARB decidió intentar otra reinvención de OpenGL. Esto era similar al "OpenGL 2.0" de 3D Labs, pero mejor porque el ARB estaba detrás de él. Lo llamaron "Longs Peak".
¿Qué tiene de malo tomarse un tiempo para mejorar la API? Esto era malo porque Microsoft se había dejado vulnerable. Mira, esto fue en el momento del cambio de Vista.
Con Vista, Microsoft decidió instituir algunos cambios muy necesarios en los controladores de pantalla. Obligaron a los conductores a someterse al sistema operativo para la virtualización de la memoria de gráficos y varias otras cosas.
Si bien uno puede debatir los méritos de esto o si realmente fue posible, el hecho sigue siendo esto: Microsoft consideró que D3D 10 era solo Vista (y superior). Incluso si tuviera hardware que fuera capaz de D3D 10, no podría ejecutar aplicaciones D3D 10 sin ejecutar también Vista.
También puede recordar que Vista ... um, digamos que no funcionó bien. Entonces, tenía un sistema operativo de bajo rendimiento, una nueva API que solo se ejecutaba en ese sistema operativo y una nueva generación de hardware que necesitaba que la API y el sistema operativo hicieran algo más que ser más rápidos que la generación anterior.
Sin embargo, los desarrolladores pueden acceder a las características de clase D3D 10 a través de OpenGL. Bueno, podrían hacerlo si el ARB no hubiera estado ocupado trabajando en Longs Peak.
Básicamente, el ARB pasó un buen año y medio o dos años de trabajo para mejorar la API. Para cuando salió OpenGL 3.0, la adopción de Vista había terminado, Win7 estaba a la vuelta de la esquina para poner a Vista detrás de ellos, y la mayoría de los desarrolladores de juegos no se preocupaban por las características de clase D3D-10 de todos modos. Después de todo, el hardware D3D 10 ejecutó aplicaciones D3D 9 muy bien. Y con el aumento de los puertos de PC a consola (o los desarrolladores de PC saltan al desarrollo de la consola. Elija), los desarrolladores no necesitaban características de clase D3D 10.
Ahora, si los desarrolladores tenían acceso a esas características anteriormente a través de OpenGL en máquinas WinXP, entonces el desarrollo de OpenGL podría haber recibido una inyección muy necesaria en el brazo. Pero el ARB perdió su oportunidad. ¿Y quieres saber la peor parte?
A pesar de pasar dos preciosos años intentando reconstruir la API desde cero ... todavía fallaron y volvieron al estado actual (excepto por un mecanismo de desaprobación).
Entonces, el ARB no solo perdió una oportunidad crucial , sino que ni siquiera realizó la tarea que los hizo perder esa oportunidad. Bastante épico fallar por todos lados.
Y esa es la historia de OpenGL vs. Direct3D. Una historia de oportunidades perdidas, estupidez, ceguera voluntaria y simple tontería.