Comparación entre Direct3D y OpenGL

La primera versión de Direct3D suscitó críticas generalizadas porque las operaciones más simples, tales como cambios de estado, requerían la creación de objetos llamados "buffers ejecutables". En contraste, la mayoría de los cambios de estado de OpenGL se podían realizar con solo llamar a una función. Por su parte el modelo de Direct3D para esto frustro a muchos programadores. Una queja muy famosa fue realizada probablemente por el alto perfil de desarrollador de juegos John D. Carmack en el archivo.plan en el cual incitó a Microsoft a abandonar Direct3D y unirse a la idea de OpenGL.[4] Chris Hecker hizo una petición similar en una "Carta Abierta a Microsoft "en el período abril-mayo de 1997 en la revista Game Developer.[5]

La Versión 5 (la segunda versión, llamada a reflejar su lanzamiento como parte de DirectX 5) sustituye los "buffers ejecutables" por la nueva API DrawPrimitive, pero todavía era considerado engorroso. En otra "Carta abierta a Microsoft" Chris Hecker se refería a DrawPrimitive como "un clon inmaduro y mal diseñado de OpenGL al que le faltan algunas de las decisiones arquitectónicas que hacen rápido a OpenGL".[5]

A pesar de la controversia, Microsoft siguió evolucionando el API. Una historia detallada de las versiones y las características agregadas se da en las páginas web de Microsoft Direct3D.

Algunos críticos anteriores de Direct3D reconocen que ahora es tan bueno o mejor que OpenGL en términos de capacidades y facilidad de uso. En enero de 2007, John Carmack dijo que "[...] DirectX9 ha alcanzado realmente un buen nivel como API, incluso en la concepción de Direct3D de las cosas, donde sé que tienen una larga historia de gente que piensa que soy antagónico en contra. Microsoft ha hecho un muy, muy buen trabajo de sensatez que evoluciona a cada paso, no está preocupado por no romper la compatibilidad hacia atrás y es una API bastante limpia. Me gusta especialmente el trabajo que estoy haciendo en el 360, y es probablemente la mejor API gráfica en la que he trabajado".[6]

Algunas de las características de diseño de Direct3D se han mantenido sin cambios desde la versión uno, más notablemente su dependencia del COM (acrónimo del inglés: Component Object Model) de Microsoft. Una ventaja de usar COM es que la API se puede utilizar en cualquier lenguaje COM, sobre todo Delphi y Microsoft Visual C++, C# y Visual Basic NET.

OpenGL esta específicamente implementado en el lenguaje C, aunque se puede usar en otros lenguajes de programación. Se basa en el concepto de una máquina de estados o autómatas, aunque las versiones más recientes de OpenGL han transformado en mucho más que un sistema basado en objetos. Como toda API, OpenGL no depende de ninguna característica de lenguaje particular, y puede llamarse desde casi cualquier lenguaje de programación con los enlaces apropiados. Estos enlaces existen para Ada, BASIC (BlitzMax (a menudo utilizado para programar juegos), 'PureBasic, Visual Basic), C#, Delphi, Fortran, Haskell, Java, Lisp, Lua, Pascal, Perl, Python y Ruby por nombrar algunos.

En general, Direct3D está diseñado para virtualizar interfaces 3D de hardware. Direct3D libera al programador de juegos de acomodar el hardware de gráficos. OpenGL, por otro lado, está diseñado para ser un sistema de representación de aceleración 3D por hardware que puede ser emulado en software. Estos dos APIs están orientadas fundamentalmente bajo dos modos diferentes de pensamiento.

Como tal, existen diferencias funcionales en la forma de trabajo de las dos APIs. Direct3D espera por la aplicación para gestionar los recursos de hardware, OpenGL hace que la implementación se encargue de esto. Este equilibrio para OpenGL disminuye la dificultad en el desarrollo de la API, mientras que al mismo tiempo aumenta la complejidad en la creación de una aplicación (o controlador) que se comporte de manera correcta. Con Direct3D, el programador debe gestionar los recursos de hardware de forma independiente. Sin embargo, la implementación es más sencilla, y los desarrolladores tienen flexibilidad para asignar recursos de la manera más eficiente posible para su aplicación.

Hasta alrededor del 2005, otra diferencia funcional entre estas dos API, era la forma en que manejaron la representación de las texturas. El método de Direct3D (SetRenderTarget ()) es conveniente, mientras que las versiones anteriores de OpenGL requieren la manipulación de buffers de píxel (P-buffers). Esto era complicado y arriesgado: si el código base del programador era diferente del previsto por el fabricante del controlador, el código estaría de nuevo ante un problema en la representación del software, causando una caída de rendimiento considerable.

Aparte de estas pocas diferencias funcionales que, en su mayoría han sido abordados a través de los años, las dos APIs proporcionan casi el mismo nivel de funcionamiento. Los fabricantes de hardware y software en general responden rápidamente a los cambios en DirectX, por ejemplo, el procesador de pixel shader y los requerimientos de shader en DirectX 9 o los procesadores de flujo en DirectX 10, mientras que las nuevas funciones de OpenGL se realizan principalmente por primera vez por los vendedores y después se aplican con carácter retroactivo a los estándares.

DOS es un software empresarial, como AutoCAD y los juegos de DOS tales como Doom, distribuido por la empresa id-Software, originalmente tenían que ser optimizados para funcionar en muchos chipsets gráficos diferentes. Cuando los fabricantes de hardware como 3Dlabs (miembro del OpenGL Architecture Review Board) hicieron aceleradores de gráficos OpenGL compatibles (por ejemplo, el GLint chip ), los desarrolladores como John Carmack de id-Software optimizaron sus productos para OpenGL. En entornos multitarea, como Microsoft Windows en el PC y el sistema X Window (X11) en sistemas tipo Unix-Like llegó a ser un factor dominante, por lo que la relevancia de este hardware se desvaneció.

Microsoft había comercializado Direct3D rápidamente sobre la base de comparaciones de rendimiento interno entre estas dos bibliotecas de software. El déficit de rendimiento se atribuyó a la especificación rigurosa. Esta percepción fue modificada en 1996 en la conferencia del Grupo de Interés Especial de gráficos y Técnicas Interactivas (SIGGRAPH). En ese momento, SGI desafió a Microsoft con su propia implementación optimizada de OpenGLn para Windows llamado CosmoGL que en varias demostraciones igualó o superó el rendimiento de Direct3D. Para SGI, este fue un hito fundamental, ya que demostró que el pobre rendimiento de OpenGL renderizado por software se debió a las referencias de Microsoft en la implementación de OpenGL, y no debido a fallas de diseño supuestas en el propio OpenGL.

Por otra parte, la representación de software usando API 3D fue en gran medida irrelevante para aplicaciones Direct3D y OpenGL. No muchas aplicaciones de DirectX utilizan software Direct3D para representar, y prefieren realizar su propio software de representación utilizando las instalaciones de DirectDraw para acceder al hardware de la pantalla. En cuanto a las aplicaciones de OpenGL, el compatibilidad con hardware que se esperaba, y el hardware, era mucho más rápido que el software de reserva de la aplicación OpenGL esto constituyó una desagradable sorpresa para el desarrollador de OpenGL.

En cualquier caso, por el momento SGI ha demostrado que el software OpenGL tiene un rendimiento de representación que puede ser competitivo con el de Direct3D, la representación del software se está convirtiendo en irrelevante debido a la amplia disponibilidad de hardware baratos para gráficos 3D. En 1998, incluso el acelerador de gráficos S3 ViRGE fue considerablemente más rápido que el más rápido Pentium II funcionando con el rasterizador MMX de Direct3D.

Una diferencia de rendimiento más sustantiva y moderna surge debido a la estructura de los controladores de hardware proporcionados por los desarrolladores de hardware. Por detrás de DirectX trabajan los controladores IHV que son, en cierto modo, controladores instalados en el sistema operativo. La parte de modo de usuario de la API es manejada por el runtime de DirectX que proporciona Microsoft. En OpenGL sin embargo, el controlador IHV se divide en dos partes: una parte en modo de usuario que implementa la API OpenGL, y un controlador de modo kernel que se llama por la parte de modo de usuario.

Esto es un problema porque llamar a las operaciones en modo kernel de modo de usuario requiere la realización de una llamada al sistema (es decir, hacer el cambio de CPU al modo kernel). Esta es una operación lenta donde el tiempo de demora en completarse se encuentra en el orden de los microsegundos.[7] Durante este tiempo, la CPU no puede realizar ninguna operación. Como tal, si se minimiza el número de veces que esta operación de conmutación se realiza se optimizaria el rendimiento. Por ejemplo, si el buffer de la GPU de mando está lleno de datos para la representación, la API podría simplemente almacenar el pedido solicitado en un buffer temporal y, cuando el búffer de comandos está cerca de ser vacío, se puede realizar un cambio de modo de kernel y agregar una serie de comandos almacenados todos a la vez. Esto se conoce como marchaling.

Debido a que los controladores de Direct3D IHV están en modo de kernel y el código en modo usuario está fuera del control del IHV, no hay ninguna posibilidad de que se produzcan tales optimizaciones. Debido al runtime de Direct3D, la parte de modo de usuario que implementa la API no puede tener conocimiento explícito del funcionamiento interno del conductor, por lo que el proceso de marchaling no puede ser apoyado con eficacia. Esto significa que en cada llamada Direct3D envía comandos para el hardware el cual debe realizar una conmutación en modo de kernel que a su vez, tarda un tiempo en el orden de los microsegundos en completarse. Esto ha conducido a un número de dudas con respecto al uso de Direct3D, siendo la más importante la necesidad de presentar grandes lotes de triángulos en una llamada de función. [8]

Dado que los controladores IHV de OpenGL tienen un componente de modo de usuario en ellos, IHVs posee la capacidad de implementar el marchaling mejorando así el rendimiento. Todavía es necesaria la conmutación en modo de kernel pero el número máximo teórico de veces en los que es realizado en la mayoría de las implementaciones de OpenGL es simplemente igual al comportamiento estándar de Direct3D.

Direct3D 10, la versión incluida en Windows Vista,[8] permite que porciones de los controladores funcionen en modo de usuario, por lo que es posible para IHV implementar el marshalling, por lo que las dos partes equilibran su rendimiento relativo. El OpenGL para el sistema Mac OS X es muy similar, IHV implementa una versión más simple de la API OpenGL (con ambos usuarios y los componentes de modo kernel), y las adiciones de Apple al runtime proporcionan la interfaz directa para el código de usuario, y algunas tareas básica para hacer el trabajo de IHV más fácil.

OpenGL siempre ha visto un uso más profesional en el mercado de gráficos que DirectX, DirectX por su parte se utiliza principalmente para juegos de ordenador. (El término profesional se utiliza aquí para referirse a la producción profesional y visualización de gráficos, tales como en películas de animación por ordenador y la visualización científica, no en los juegos donde los gráficos obtenidos son para uso personal, en lugar de profesional, del usuario final.) actualmente, tanto OpenGL y DirectX tienen un solapamiento suficientemente grande en la funcionalidad que bien puede utilizarse para la mayoría de propósitos comunes, con el sistema operativo en sí mismo a menudo siendo el que dicta el criterio principal que se utiliza, con DirectX la opción común es Windows, mientras que OpenGL se utiliza en casi todo lo demás.

En los primeros días de los juegos acelerados en 3D, el rendimiento y la fiabilidad eran los puntos de referencia clave y varias tarjetas aceleradoras 3D competían entre sí por el dominio. El software fue escrito específicamente para una determinada marca de tarjeta gráfica. Sin embargo, con los años, OpenGL y Direct3D han construido varias capas de software por encima del hardware, principalmente debido al apoyo de la industria para una biblioteca cruzada para hardware de gráficos.

OpenGL para sistemas integrados (también conocido como OpenGL ES) es un subconjunto de la API OpenGL para gráficos 3D diseñado para dispositivos integrados. Varias versiones de sistemas operativos de teléfonos inteligentes son compatibles con OpenGL ES, como Android, iOS (iPad, iPhone, iPod Touch), Maemo (Nokia N900), y Symbian.

OpenGL ES está disponible en 3 variantes, OpenGL ES 1.0, 1.1, y 2.0. Comenzando con el lanzamiento de la 2.0, la compatibilidad hacia atrás con las anteriores variantes fue eliminada, debido a la extensa gama de funciones programables disponibles en GL ES 2.0.

Direct3D Mobile es un derivado de Direct3D compatible con Windows CE. [9] En la actualidad todos los dispositivos Windows Phone 7 utiliza una interfaz de usuario. NET Framework.