🕑 📭 🚶 Direct3D vs OpenGL: una historia de confrontación 👌🏿 🥕 👨🏼‍🏫

Hasta el día de hoy, existe un debate en Internet sobre qué API de gráficos es mejor: ¿Direct3D u OpenGL? A pesar de su naturaleza religiosa, tales batallas verbales brindan resultados útiles en forma de buenas revisiones históricas del desarrollo de gráficos acelerados por hardware.

imagen

El propósito de esta publicación es traducir una de estas excursiones a la historia.escrito por Jason L. McKesson en respuesta a la pregunta "¿Por qué los desarrolladores de juegos prefieren Windows"? Es poco probable que este texto responda a la pregunta planteada, pero describe la historia del desarrollo y la confrontación de las dos API gráficas más populares de una manera muy colorida y bastante detallada, por lo que conservé el marcado del autor en la traducción. El texto fue escrito a mediados de 2011 y cubre un período de tiempo que comienza poco antes del advenimiento de Direct3D y hasta el momento de la escritura. El autor del texto original es un desarrollador de juegos experimentado, un participante activo en StackOverflow y el creador de un extenso libro de texto sobre programación moderna de gráficos 3D. Así que demos la palabra a Jason.

Prólogo

Antes de comenzar, me gustaría decir que sé más sobre OpenGL que sobre Direct3D. En mi vida no he escrito una sola línea de código en D3D, pero he escrito manuales de OpenGL. Pero de lo que quiero hablar no es de prejuicios, sino de historia.

El nacimiento del conflicto

Una vez, a principios de los 90, Microsoft miró a su alrededor. Vieron que SNES y Sega Genesis son geniales, puedes jugar muchos juegos de acción y todo eso. Y vieron los dos. Los desarrolladores escribieron juegos de dosovskie como consola: cerca del hierro. Sin embargo, a diferencia de las consolas, donde el desarrollador sabía qué tipo de hardware tendría el usuario, dos desarrolladores se vieron obligados a escribir bajo muchas configuraciones. Y esto es mucho más complicado de lo que parece.

Pero Microsoft tuvo un problema mayor: Windows. Verá, Windows quería poseer el hardware por completo, a diferencia de DOS, lo que permitía a los desarrolladores hacer cualquier cosa. La posesión de hierro es necesaria para la interacción entre aplicaciones. Pero este tipo de interacción es exactamente lo que odian.desarrolladores de juegos porque consume recursos preciosos que podrían usar para todo tipo de cosas geniales.

Para promover el desarrollo de juegos en Windows, Microsoft necesitaba una API uniforme que fuera de bajo nivel, funcionara en Windows sin pérdida de rendimiento y fuera compatible con varios hardware . Una API única para gráficos, sonido y dispositivos de entrada.

Así nació DirectX.

Los aceleradores 3D aparecieron unos meses después. Y Microsoft se metió en problemas. El hecho es que DirectDraw, un componente gráfico de DirectX, funcionaba solo con gráficos 2D: asignaba memoria de gráficos y realizaba operaciones rápidas de bits entre diferentes sectores de la memoria.

Por lo tanto, Microsoft compró un software de terceros y lo convirtió en Direct3D versión 3. Fue regañadoabsolutamente todo Y había una razón: leer el código en D3D v3 parecía una decodificación del lenguaje escrito de una antigua civilización extinta.

El viejo John Carmack en Id Software miró esta desgracia, dijo "Sí, fue ...", y decidió escribir usando otra API: OpenGL.

Sin embargo, el otro lado de esta historia confusa fue que Microsoft trabajó con SGI para implementar OpenGL para Windows. La idea era atraer a desarrolladores de aplicaciones GL típicas para estaciones de trabajo: CAD, sistemas de modelado y similares. Los juegos fueron lo último que pensaron. Esto se refería principalmente a Windows NT, pero Microsoft decidió agregar OpenGL a Windows 95 también.

Para atraer a los desarrolladores de software para estaciones de trabajo en Windows, Microsoft decidió sobornarlos con acceso a nuevos aceleradores 3D. Implementaron un protocolo para controladores de clientes instalados: una tarjeta gráfica podría reemplazar el software OpenGL de Microsoft con su implementación de hardware. El código usaba automáticamente hardware OpenGL, si había uno disponible.

Sin embargo, en esos días las tarjetas gráficas de consumo no tenían soporte OpenGL. Esto no impidió que Carmack transfiriera Quake a OpenGL en una estación de trabajo SGI. En el archivo Léame de GLQuake, puede leer lo siguiente:

, glquake OpenGL, texture objects. , , , . - , .

( 1997), opengl , glquake , intergraph realizm. 3dlabs , . 3dlabs glint permedia NT , glquake 3dlabs.

3dfx opengl32.dll, glquake, opengl. opengl- , « glquake».

Este fue el nacimiento de los controladores miniGL. Eventualmente evolucionaron a implementaciones completas de OpenGL tan pronto como el hardware se volvió lo suficientemente poderoso como para soportar esta funcionalidad en el hardware. nVidia fue el primero en ofrecer una implementación completa de OpenGL. Otros proveedores todavía eran lentos, lo que fue una de las razones de la transición a Direct3D, respaldada por una gama más amplia de equipos. Al final, solo quedaron nVidia y ATI (que ahora es AMD), y ambos tuvieron buenas implementaciones de OpenGL.

Amanecer de OpenGL

Entonces, los participantes están definidos: Direct3D contra OpenGL. Esta es realmente una historia increíble, considerando lo malo que era el D3D v3.

La Junta de Revisión Arquitectónica de OpenGL (ARB) es la organización responsable de mantener y desarrollar OpenGL. Lanzan muchas extensiones, contienen un repositorio con extensiones y crean nuevas versiones de la API. ARB es un comité compuesto por una gran cantidad de jugadores en la industria de gráficos por computadora y algunos fabricantes de sistemas operativos. Apple y Microsoft también fueron miembros de ARB en diferentes momentos.

3Dfx entra en escena con su Voodoo2. Esta es la primera tarjeta de video que le permite realizar múltiples texturas, que no se proporcionaba anteriormente en OpenGL. Mientras que 3Dfx se oponía fuertemente a OpenGL, nVidia, el siguiente fabricante del chip multitexturing (TNT1), estaba loco por OpenGL. Luego, ARB lanzó la extensión GL_ARB_multitexture, que proporcionó acceso a múltiples texturas.

Mientras tanto, aparece Direct3D v5. Ahora D3D realmente se ha convertido en una API , no en una especie de tontería. Cual es el problema En ausencia de multitextura.

Ups

Pero esto no causó los inconvenientes que podía generar, porque casi nadie usó texturizado múltiple. La multitextura casi no daña el rendimiento y, en muchos casos, la diferencia es invisible en el contexto de las pasadas múltiples. Y, por supuesto, a los desarrolladores de juegos les gusta mucho que sus juegos trabajen con confianza en el hardware antiguo, que no tenía soporte para múltiples texturas, por lo que muchos juegos se lanzaron sin él.

D3D suspiró aliviado.

Pasó el tiempo y nVidia lanzó la GeForce 256 (que no debe confundirse con la primera GeForce GT-250), deteniendo la lucha en el mercado de las tarjetas gráficas durante los próximos dos años. La principal ventaja competitiva de esta placa fue la capacidad de realizar transformaciones de vértices e iluminación (transformación e iluminación, T&L) en hardware. Pero eso no es todo: nVidia OpenGL amó tanto que su T & L-motor realidad ha sido OpenGL. ¡Casi literalmente! Según tengo entendido, algunos de sus registros recibieron directamente valores numéricos de variables del tipo GLenum.

Sale Direct3D v6. Finalmente, las texturas múltiples llegaron a tiempo ... pero sin el hardware T&L. OpenGL siemprehubo una tubería T&L, aunque antes de GeForce 256 se implementó en software. Por lo tanto, para nVidia, resultó ser bastante simple rehacer la implementación del software en una solución de hardware. En D3D, el hardware T&L apareció solo en la séptima versión.

Dawn of the Shader Age, OpenGL en la oscuridad

Luego vino GeForce 3. Al mismo tiempo, sucedieron muchas cosas interesantes.

Microsoft decidió que ya no iban a llegar tarde. Por lo tanto, en lugar de mirar lo que hará nVidia y copiar su desarrollo ya post-factum, Microsoft tomó una decisión sorprendente: ve y habla. Y se enamoraron, y obtuvieron una pequeña consola conjunta.

El ruidoso divorcio ocurrió más tarde, pero esta es una historia completamente diferente.

Para el mercado de PC, esto significó que GeForce 3 salió simultáneamente con D3D v8, y es fácil ver cómo GeForce 3 afectó a los sombreadores D3D v8. Los sombreadores de píxeles del Shader Model 1.0 eran muymuy afilado para equipos nVidia. No se ha hecho un solo intento para hacer algo para extraer nVidia del hierro. Shader Model 1.0 fue para lo que fue diseñada la GeForce 3.

Cuando ATI entró en la carrera de rendimiento gráfico con su Radeon 8500, había un problema. La tubería Radeon 8500 píxeles resultó ser más poderosa que la nVidia. Por lo tanto, Microsoft lanzó el Shader Model 1.1, que era básicamente para lo que era el 8500.

Suena como una derrota D3D, pero el éxito y el fracaso son términos relativos. De hecho, un fracaso épico esperaba a OpenGL.

NVidia era muy aficionado a OpenGL, por lo que después del lanzamiento de GeForce 3 lanzaron un montón de extensiones para OpenGL. Propietarioextensiones que solo funcionaban en nVidia. Naturalmente, cuando apareció la placa 8500, no podía usar ninguno de ellos.

Entonces, en D3D 8, al menos podría ejecutar sombreadores SM 1.0. Por supuesto, para usar toda la genialidad del 8500, tuve que escribir nuevos sombreadores, pero el código al menos funcionó .

Para obtener cualquier shaders de OpenGL en la Radeon 8500, ATI tuvo que desarrollar algunas extensiones de OpenGL. Extensiones de propiedad que solo funcionaban en ATI. Como resultado, para que los desarrolladores pudieran declarar que atornillaron los sombreadores a su motor, tuvieron que escribir un código separado para nVidia y un código separado para ATI.

Usted puede preguntar: "¿Y dónde estaba el comité ARB que debía apoyar OpenGL a flote?" Y fueron donde terminaron muchos comités: se sentaron y fueron estúpidos.

Tenga en cuenta que mencioné ARB_multitexture arriba porque esta extensión está profundamente involucrada en toda la situación. A un observador externo le pareció que ARB generalmente quiere evitar la idea de sombreadores. Decidieron que si inyectan suficiente capacidad de configuración en una tubería fija, entonces será igual en sus capacidades con una tubería de sombreador programable.

ARB lanzó extensiones una por una. Cada extensión con las palabras "texture_env" en el nombre fue un intento de reparar este diseño antiguo. Mire la lista de extensiones: se han lanzado ocho de tales extensionespiezas, y muchas de ellas se han traducido a la funcionalidad principal de OpenGL.

En ese momento, Microsoft era parte de ARB, y lo dejó solo para el lanzamiento de D3D 9, por lo que tal vez Microsoft saboteó OpenGL de alguna manera. Personalmente, dudo de esta teoría por dos razones. Primero, tendrían que asegurar el apoyo de otros miembros del Comité, porque cada miembro tiene un solo voto. En segundo lugar, y lo que es más importante, el Comité no necesitó la ayuda de Microsoft para arruinar todo, evidencia que veremos más adelante.

Como resultado, ARB, muy probablemente bajo presión de ATI y nVidia (ambos son participantes activos), finalmente despertó e introdujo sombreadores de ensamblador en el estándar.

¿Quieres una historia aún más loca?

Hardware T&L. Esto es lo que originalmente tenía OpenGL .. Para obtener el rendimiento de T&L de hardware más alto posible, debe almacenar datos de vértice en la GPU. Aún así, la GPU es el principal consumidor de datos de vértices.

En D3D v7, Microsoft introdujo el concepto de búferes de vértices, que asignan trozos de memoria en la GPU y colocan allí los datos de vértices.

¿Quiere saber cuándo apareció una funcionalidad equivalente en OpenGL? Sí, nVidia, como el mayor fanático de OpenGL, lanzó su extensión para almacenar matrices de vértices en la GPU en el momento del lanzamiento de GeForce 256. ¿Pero cuándo ARB introdujo tal funcionalidad?

Dos años despues. Fue despuesde cómo aprobó los sombreadores de vértices y fragmentos (píxeles en términos de D3D). ARB tardó mucho tiempo en desarrollar una solución multiplataforma para almacenar datos de vértices en la memoria de la GPU. Y eso es lo que el hardware T&L necesita para lograr el máximo rendimiento.

Un idioma para matarlos a todos

Entonces, OpenGL ha estado roto por algún tiempo. No había sombreadores multiplataforma y almacenamiento de vértices independiente del hardware en la GPU, mientras que los usuarios de D3D disfrutaron de ambos. ¿Podría empeorar?

Se podría decir que sí. Conoce: Laboratorios 3D .

Usted pregunta: ¿quiénes son ellos? Son una compañía muerta que considero el verdadero asesino de OpenGL. Por supuesto, el fracaso general del Comité hizo que OpenGL fuera vulnerable, mientras que se suponía que destrozaría D3D. Pero en mi opinión, 3D Labs es quizás la única razón de la posición actual en el mercado de OpenGL. ¿Qué han hecho por esto?

Desarrollaron un lenguaje de sombreador para OpenGL.

3D Labs era una empresa moribunda. Sus costosas GPU han sido expulsadas del mercado de estaciones de trabajo por la presión cada vez mayor de nVidia. Y a diferencia de nVidia, los laboratorios 3D no se introdujeron en el mercado de consumo; La victoria de nVidia significaría la muerte para 3D Labs.

Lo que finalmente sucedió.

En un esfuerzo por flotar en un mundo que no necesitaba sus productos, 3D Labs apareció en la Game Developer Conference con una presentación de lo que llamaron "OpenGL 2.0". Era una API OpenGL reescrita desde cero. Y eso tenía sentido, porque en esos días la API de OpenGL estaba llena de basura (que, sin embargo, permanece allí hasta el día de hoy). Mira al menos cómo esotéricamente se realiza la carga y unión de texturas.

Parte de su propuesta era el lenguaje shader. Sí lo es. Sin embargo, a diferencia de las extensiones multiplataforma existentes, su lenguaje de sombreador era de "alto nivel" (C es un nivel alto para el lenguaje de sombreador).

Al mismo tiempo, Microsoft estaba trabajando en su propio lenguaje de sombreador. Lo que ellos, incluyendo toda su imaginación colectiva, llamaron ... High Level Shader Language (HLSL). Pero su enfoque del lenguaje era fundamentalmente diferente.

El mayor problema con 3D Labs fue que era integrable. Microsoft determinó completamente su propio idioma. Lanzaron un compilador que generó un código de ensamblaje para los sombreadores SM 2.0 (o superior), que, a su vez, podrían alimentarse a D3D. En los días de D3D v9, HLSL nunca tocó D3D directamente. Era una buena pero opcional abstracción. El desarrollador siempre tuvo la oportunidad de tomar el escape del compilador y ajustarlo para obtener el máximo rendimiento.

3D Labs no tenía nada de esto. Le da al conductor un lenguaje tipo C, y crea un sombreador. Eso es todo Sin sombreador de ensamblador, nada que se pueda alimentar a otra cosa. Solo un objeto OpenGL que representa un sombreador.

Para los usuarios de OpenGL, esto significaba que eran propensos a los caprichos de los desarrolladores de OpenGL que acababan de aprender cómo compilar lenguajes similares a ensambladores. Los compiladores de lenguaje de sombreador OpenGL (GLSL) han estado furiosos por los errores. Para empeorar las cosas, si pudiste hacer que el sombreador se compilara correctamente en diferentes plataformas (lo que en sí mismo fue un gran logro), entonces todavía estaba sujeto a optimizadores de aquellos tiempos que no eran tan óptimos como podrían ser.

Este fue un gran pero no el único inconveniente de GLSL. Lejos de ser el único.

En D3D, como en los antiguos lenguajes ensambladores de OpenGL, puede mezclar y combinar sombreadores de vértices y fragmentos de todas las formas posibles. Puede usar cualquier sombreador de vértices con cualquier sombreador de fragmentos compatible si interactúan a través de la misma interfaz. Además, incluso se permitía cierta incompatibilidad: por ejemplo, el sombreador de vértices podía generar un valor que el sombreador de fragmentos no utilizaba.

No había nada de eso en GLSL. Los sombreadores de vértices y fragmentos se fusionaron, formando algo llamado "objeto de software" de 3D Labs. Por lo tanto, para el uso conjunto de varios sombreadores de vértices y fragmentos en varias combinaciones, fue necesario crear varios objetos de programa. Esto causó el segundo problema más grande.

3D Labs pensó que eran los más inteligentes. Tomaron C / C ++ como base para el modelo de compilación GLSL. Esto es cuando toma un archivo c y lo compila en un archivo de objeto, y luego toma varios archivos de objeto y los compone en un programa. Así es como se compila GLSL: primero se compila un vértice o fragmento de sombreador en un objeto de sombreador, luego se colocan estos objetos en un objeto de programa y se unen para finalmente formar un programa.

En teoría, esto permitió que aparecieran cosas interesantes como sombreadores de "biblioteca" que contienen código llamado por el sombreador principal. En la práctica, esto dio como resultado que los sombreadores se compilaran dos veces: Una vez en la etapa de compilación y una segunda vez en la etapa de compilación. En particular, el compilador de nVidia fue famoso por esto. No generó ningún código objeto intermedio; compiló al principio, tiró el resultado y compiló nuevamente en la etapa de compilación.

Por lo tanto, para unir el sombreador de vértices a dos sombreadores de fragmentos diferentes, fue necesario compilar mucho más que en D3D. Especialmente teniendo en cuenta que toda la compilación se realiza sin conexión , y no antes de que el programa se ejecute directamente.

GLSL tuvo otros problemas. Quizás sería un error culpar a todos de la falla en 3D Labs, porque al final ARB aprobó e incluyó el lenguaje de sombreadores en OpenGL (pero nada más de las sugerencias de 3DLabs). Sin embargo, la idea original todavía era para 3D Labs.

Y ahora lo más triste: 3D Labs tenían razón (en su mayoría). GLSL no es un lenguaje vectorial como HLSL en ese momento. Esto sucedió porque el hardware de 3D Labs era escalar (como el hardware moderno de nVidia), y tenían toda la razón al elegir la dirección que muchos fabricantes de equipos siguieron más tarde.

Tenían razón al elegir el modelo de compilación para el lenguaje de "alto nivel". Incluso D3D finalmente llegó a esto.

El problema es que 3D Labs tenían razón en el momento equivocado . Y en los intentos de llegar al futuro prematuramente, en los intentos de estar preparados para el futuro, dejan de lado el presente. Parece la funcionalidad T&L en OpenGL, que siempre ha estado en ella. Excepto que la tubería OpenGL T&L fue útily antes de la llegada del hardware T&L, GLSL era una carga antes de que el resto del mundo lo alcanzara.

GLSL es un buen lenguaje ahora . ¿Pero qué era en ese momento? El fue terrible. Y OpenGL sufrió de esto.

De camino a la apoteosis

Apoyo la opinión de que 3D Labs dio un golpe mortal a OpenGL, pero el último clavo en el ataúd fue anotado por el propio ARB.

Es posible que hayas escuchado esta historia. En los días de OpenGL 2.1, OpenGL tenía grandes problemas. Llevaba una gran carga de compatibilidad. La API ya no era fácil de usar. Una cosa podría hacerse de cinco maneras diferentes y no está claro cuál es más rápido. Podrías "aprender" OpenGL con tutoriales simples, pero no aprendiste el OpenGL que proporciona potencia y rendimiento gráfico real.

ARB decidió hacer otro intento de inventar OpenGL. Era como "OpenGL 2.0" de 3D Labs, pero mejor porque ARB estaba detrás de este intento. Lo llamaron "Longs Peak".

¿Qué tiene de malo pasar un poco de tiempo mejorando la API? La mala noticia es que Microsoft está en una posición bastante precaria. Este era el momento de actualizar a Vista.

En Vista, Microsoft decidió realizar cambios atrasados en los controladores de gráficos. Obligaron a los controladores a recurrir al sistema operativo para la virtualización de la memoria gráfica y muchos otros.

Puede discutir durante mucho tiempo sobre los méritos de este enfoque, y si fue posible, pero el hecho es que: Microsoft creó D3D 10 solo para Vista y superior. Incluso en un hardware compatible con D3D, era imposible ejecutar una aplicación D3D sin Vista.

Quizás recuerdes que Vista ... digamos que no funcionó muy bien. Entonces, teníamos un SO tranquilo, una nueva API que funcionaba solo en este SO y una nueva generación de hardware que necesitaba que esta API y SO hicieran más que simplemente superar el rendimiento de la generación anterior.

Sin embargo, los desarrolladores podrían usar la funcionalidad de nivel D3D 10 a través de OpenGL. Es decir, podrían si ARB no estuviera ocupado trabajando en Long Peaks.

ARB pasó uno y medio o dos años trabajando para mejorar la API. Para cuando se lanzó OpenGL 3.0, la transición a Vista había terminado, Windows 7 estaba en camino y los desarrolladores de juegos ya no se preocupaban por la funcionalidad de D3D 10. Al final, el equipo para D3D 10 funcionaba perfectamente con aplicaciones en D3D 9. Con el aumento en el ritmo de transferencia de PC a consola (o con la transición de los desarrolladores de PC al mercado de consolas), los desarrolladores necesitaban cada vez menos la funcionalidad de D3D 10.

Si los desarrolladores pudieran acceder a esta funcionalidad incluso en Windows XP, el desarrollo de OpenGL podría tener una carga vital de vida. Pero ARB perdió esta oportunidad. ¿Quieres saber qué es lo peor?

ARB fallóinventar la API desde cero a pesar de pasar dos preciosos años tratando de hacerlo. Por lo tanto, devolvieron el status quo, agregando solo un mecanismo para declarar obsoleta la funcionalidad.

Como resultado, ARB no solo perdió las oportunidades clave , sino que también falló en hacer el trabajo que los llevó a esta omisión. Fue un fracaso épico en todas las direcciones.

Esta es la historia de la confrontación entre OpenGL y Direct3D. La historia de las oportunidades perdidas, la mayor estupidez, la temeridad deliberada y los absurdos banales.