Loading AI tools
Direct3D y OpenGL son interfaces para la programación de aplicaciones (API acrónimo del inglés Application Programing Interfaces) competitivas que pueden ser usadas en aplicaciones para representar gráficos por computadora (o también llamado computación gráfica) en 2D y 3D, tomando como ventaja de la aceleración por hardware cuando se dispone de esta. Las unidades de procesamiento gráfico (GPU acrónimo del inglés Graphics Processing Unit) modernas, pueden implementar una versión particular de una o ambas de estas interfaces.
Direct3D está desarrollada con el objetivo de ser utilizada sobre plataformas de Microsoft Windows. OpenGL, por su parte, es una API estándar de uso libre, cuyas implementaciones existen para una amplia variedad de plataformas.
| Plataforma de Apoyo | Sistema Integrado que lo Soporta | Licencia | |
|---|---|---|---|
| OpenGL | Distintas plataformas | Distintas plataformas a través de OpenGL ES | Libre (algunas características patentadas) |
| Direct3D | Windows | Windows CE a través de Direct3D Mobile | Privativa |
Para más detalle, las dos APIs de computación gráfica puden resumirse como:
- Direct3D: es una API privativa (o puede ser llamada también de forma errónea propietaria por una traducción textual del término en inglés) que proporciona funciones para representar gráficos en tres dimensiones, y utiliza la aceleración de hardware si esta se encuentra disponible en la tarjeta gráfica. Fue diseñado por Microsoft Corporation para su uso en la plataforma Windows. También puede ser utilizado en otros sistemas operativos a través de un software especial, como el Wine, aunque el subconjunto de funciones que ofrece no es tan completa como la implementación de original.
- OpenGL: es una API estándar de uso libre (también llamado estándar abierto) que ofrece una serie de funciones para representar gráficos en 2D y 3D, y está disponible en los sistemas operativos más modernos, pero no limitado solo a Windows, Mac OS X y Linux.
Tenga en cuenta que muchas extensiones de OpenGL y algunos métodos esenciales, aunque está documentados, se encuentran en realidad patentados, lo que impone serios problemas legales para su implementación (ver problemas con Mesa[1]).
OpenGL y Direct3D están los dos implementados sobre el controlador de pantalla. A continuación se comparan los dos APIs, estructurado el análisis en torno a diversas consideraciones en su mayoría relacionados con el desarrollo de juegos.
Direct3D esta oficialmente implementado sólo en la familia de sistemas operativos de Microsoft Windows, incluyendo las versiones integradas utilizadas en la familia de videoconsolas Xbox de Microsoft Corporation y Dreamcast de Sega. Varios puertos en su mayoría funcionales de las API de Direct3D son construidos por Wine, un proyecto para lograr APIs de Windows con puerto común en sistemas operativos de tipo Unix-Like, y Cedega, pero esto se ve obstaculizado debido a la interdependencia de DirectX en muchos otros componentes de Windows.
OpenGL tiene implementaciones disponibles en muchas plataformas, incluyendo Microsoft Windows y sistemas Unix como Mac OS X, GNU / Linux. Es un error pensar que las variantes de OpenGL se utilizan en Nintendo y las plataformas de Sony, ya que han desarrollado sus propias bibliotecas. La consola de juegos PlayStation 3 tiene una implementación de OpenGL, pero sigue sin ser utilizado por la mayoría de los desarrolladores debido a problemas de rendimiento. Un subconjunto de OpenGL fue elegido como biblioteca principal de gráficos para Android, BlackBerry, iOS y Symbian en la versión llamada OpenGLES.
El controlador de Microsoft OpenGL ofrece aceleración de hardware en Windows Vista, el soporte fue eliminado de Windows XP, no mucho después de que no pudo salir al mercado el soporte Fahrenheit de bajo nivel para una fusión OpenGL / DirectX a finales de 1990. La aceleración por hardware de OpenGL en Windows está disponible desde la primera vez que son instalados por los usuarios los controladores instalables del cliente (CIC) desarrollados por los fabricantes de GPU.[2] Estos CIC, en casi todos los casos, son incluidos en el paquete de controlador estándar del proveedor de hardware (IHV), por lo que instalar los últimos controladores de gráficos es suficiente para proporcionar compatibilidad con hardware OpenGL.[3]
Direct3D
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
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.
Comparación
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.
Poco después del establecimiento de las dos APIs, Direct3D y OpenGL como librerías gráficas viables (cerca de 1995), Microsoft y SGI (del acrónimo en inglés Silicon Graphics Inc) se dedican a lo que se ha denominado la «Guerra de las API». Gran parte de la discusión giró en torno a cual ofrece un rendimiento superior. Esta pregunta es pertinente debido al alto costo que tenían los aceleradores de gráficos durante este tiempo, lo que significa que el mercado de los consumidores estaba usando renderizadores de software implementados por Microsoft, tanto para Direct3D como para OpenGL.
Debate inicial
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.
Modo de conmutación (en Microsoft Windows)
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, originalmente diseñado para estaciones de trabajo SGI entonces poderosas, incluye una serie de características, como la representación de música y el "subconjunto de imágenes", que se consideraron en general de poca utilidad para los juegos, aunque han despertado mayor interés a partir del 2011 con los juegos estereoscópicos. La API en su conjunto contiene alrededor de 250 llamadas, pero solo un subconjunto de quizás 100 son útiles para el desarrollo de juegos. Sin embargo, ningún subgrupo específico para juegos oficiales se definió alguna vez. MiniGL, publicado por 3Dfx como una medida temporal para apoyar GlQuake, podría haber servido como punto de partida, pero las características adicionales como la plantilla fueron adoptadas luego por los juegos, y el apoyo continuo para todo el estándar OpenGL. Hoy en día, las estaciones de trabajo y las máquinas de los consumidores utilizan las mismas arquitecturas y sistemas operativos, y encarnaciones modernas del estándar de OpenGL todavía incluyen estas características, aunque sólo algunas estaciones de trabajo con tarjetas de video especiales lo aceleran.
El mecanismo de extensión OpenGL es probablemente la diferencia más fuertemente disputada entre los dos APIs. OpenGL incluye un mecanismo en el que cualquier conductor puede conocer sus propias extensiones a la API, lo que introduce nuevas funciones como modos de mezcla, nuevas formas de transferir datos a GPUs o diferentes parámetros de envoltura de textura. Esto permite que las funciones exponer nuevas rápidamente, pero puede provocar confusión si diferentes proveedores implementan extensiones similares con diferentes APIs. Muchas de estas extensiones son periódicamente estandarizadas por el OpenGL Architecture Review Board (ARB), y algunos se hacen una parte fundamental de las futuras revisiones de OpenGL.
Por otro lado, Direct3D es especificado por un proveedor único (Microsoft), lo cual asegura una API más consistente, pero sin embargo deniegan el acceso a las características específicas del proveedor. La tecnología NVIDIA UltraShadow, por ejemplo, no está disponible en el API Direct3D en tiempo de escritura. Cabe señalar que Direct3D hace de soporte para extensiones de formato de textura (por FourCC). Estas fueron una vez poco conocido y utilizado en raras ocasiones, pero ahora se utilizan para Compresión de texturas S3.
Cuando las tarjetas gráficas han añadido soporte para pixel shaders (conocidos en OpenGL como "Fragment Shader"), Direct3D ha proporcionado un estándar "de Pixel Shader 1.1" (PS1.1) con la que la GeForce 3 o superior, y Radeon 8500 o superior, son totalmente compatibles. Bajo las mismas funciones OpenGL se accede a través de una variedad de extensiones personalizadas.
En teoría, el enfoque de Microsoft permite una ruta de código para apoyar a las marcas de tarjeta, mientras que en OpenGL, los programadores deben escribir dos sistemas separados. En realidad a causa de los límites de los píxeles de las tarjetas iniciales, Pixel Shader 1.1 no era más que una versión en pseudo-montaje de las extensiones específicas de NVIDIA OpenGL. En su mayor parte, las únicas tarjetas PS 1,1 que permiten esta funcionalidad son las NVIDIA, y eso se debe a que fueron construidas para ello de forma nativa. Cuando la Radeon 8500 fue lanzado, Microsoft publicó una actualización de Direct3D que incluye Pixel Shader 1.4, que no era más que una versión en pseudo-montaje de las extensiones específicas de ATI OpenGL.
Esta situación sólo existió durante un corto tiempo bajo ambos APIs. La segunda generación de tarjetas de sombreado de píxeles funcionó mucho más similar, con cada arquitectura evolucionando hacia el mismo tipo de conclusión de píxeles de procesamiento. Como tal Shader, Pixel 2.0 permite una ruta de código unificado bajo Direct3D. Por la misma época OpenGL introdujo sus propias extensiones de sombreado de vértices y píxeles aprobados por la ARB (GL ARB Vertex Program y GL ARB Fragment Program), y los dos conjuntos de tarjetas apoyaron esta norma también.
Gráficos Profesionales
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.
Jugabilidad
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.
Teléfonos móviles y otros dispositivos integrados
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.
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
