OpenGL ( Open Graphics Library [4] ) es una interfaz de programación de aplicaciones (API) multiplataforma y en varios idiomas para representar gráficos vectoriales 2D y 3D . La API se utiliza normalmente para interactuar con una unidad de procesamiento de gráficos (GPU) para lograr una renderización acelerada por hardware .
Silicon Graphics, Inc. (SGI) comenzó a desarrollar OpenGL en 1991 y lo lanzó el 30 de junio de 1992. [5] [6] Se utiliza para una variedad de aplicaciones, incluido el diseño asistido por computadora (CAD), videojuegos , ciencias. visualización , realidad virtual y simulación de vuelo . Desde 2006, OpenGL ha sido gestionado por el consorcio tecnológico sin fines de lucro Khronos Group . [7]
La especificación OpenGL describe una interfaz de programación de aplicaciones (API) abstracta para dibujar gráficos 2D y 3D. Está diseñado para implementarse en su mayor parte o en su totalidad utilizando aceleración de hardware como una GPU , aunque es posible que la API se implemente completamente en software que se ejecuta en una CPU .
La API se define como un conjunto de funciones que puede llamar el programa cliente, junto con un conjunto de constantes enteras con nombre (por ejemplo, la constante GL_TEXTURE_2D, que corresponde al número decimal 3553). Aunque las definiciones de funciones son superficialmente similares a las del lenguaje de programación C , son independientes del lenguaje. Como tal, OpenGL tiene muchos enlaces de lenguaje , algunos de los más notables son el enlace de JavaScript WebGL (API, basado en OpenGL ES 2.0 , para renderizado 3D desde un navegador web ); las uniones C WGL , GLX y CGL ; el enlace C proporcionado por iOS ; y los enlaces de Java y C proporcionados por Android .
Además de ser independiente del idioma, OpenGL también es multiplataforma. La especificación no dice nada sobre el tema de obtener y administrar un contexto OpenGL, dejando esto como un detalle del sistema de ventanas subyacente . Por la misma razón, OpenGL se ocupa exclusivamente del renderizado y no proporciona API relacionadas con la entrada, el audio o las ventanas.
OpenGL ya no está en desarrollo activo, mientras que entre 2001 y 2014, la especificación OpenGL se actualizó principalmente anualmente, con dos lanzamientos (3.1 y 3.2) en 2009 y tres (3.3, 4.0 y 4.1) en 2010, el último. La especificación OpenGL 4.6 se lanzó en 2017, después de una pausa de tres años, y se limitó a la inclusión de once extensiones ARB y EXT existentes en el perfil principal. [8]
El desarrollo activo de OpenGL se abandonó en favor de la API Vulkan , lanzada en 2016 y con el nombre en código glNext durante el desarrollo inicial. En 2017, Khronos Group anunció que OpenGL ES no tendría nuevas versiones [9] y desde entonces se ha concentrado en el desarrollo de Vulkan y otras tecnologías. [10] [11] Como resultado, ciertas capacidades ofrecidas por las GPU modernas, por ejemplo, el trazado de rayos , no son compatibles con el estándar OpenGL. Sin embargo, es posible que se proporcione soporte para funciones más nuevas a través de extensiones OpenGL específicas del proveedor. [12] [13]
Khronos Group lanza nuevas versiones de las especificaciones OpenGL, cada una de las cuales amplía la API para admitir varias funciones nuevas. Los detalles de cada versión se deciden por consenso entre los miembros del Grupo, incluidos fabricantes de tarjetas gráficas, diseñadores de sistemas operativos y empresas de tecnología en general como Mozilla y Google . [14]
Además de las funciones requeridas por la API principal, los proveedores de unidades de procesamiento de gráficos (GPU) pueden proporcionar funciones adicionales en forma de extensiones . Las extensiones pueden introducir nuevas funciones y nuevas constantes, y pueden relajar o eliminar restricciones en las funciones OpenGL existentes. Los proveedores pueden usar extensiones para exponer API personalizadas sin necesidad de soporte de otros proveedores o del Grupo Khronos en su conjunto, lo que aumenta enormemente la flexibilidad de OpenGL. Todas las extensiones se recopilan y definen en el Registro OpenGL. [15]
Cada extensión está asociada a un identificador corto, basado en el nombre de la empresa que la desarrolló. Por ejemplo, el identificador de Nvidia es NV, que forma parte del nombre de la extensión GL_NV_half_float
, la constante GL_HALF_FLOAT_NV
y la función glVertex2hNV()
. [16] Si varios proveedores acuerdan implementar la misma funcionalidad utilizando la misma API, se puede lanzar una extensión compartida utilizando el identificador EXT. En tales casos, también podría suceder que la Junta de Revisión de Arquitectura del Grupo Khronos dé su aprobación explícita a la extensión, en cuyo caso se utiliza el identificador ARB. [17]
Las características introducidas por cada nueva versión de OpenGL generalmente se forman a partir de las características combinadas de varias extensiones ampliamente implementadas, especialmente extensiones de tipo ARB o EXT.
La Junta de Revisión de Arquitectura OpenGL publicó una serie de manuales junto con la especificación que se actualizó para rastrear los cambios en la API. Comúnmente se les conoce por los colores de sus portadas:
Libros históricos (anteriores a OpenGL 2.0):
También se puede acceder a la documentación de OpenGL a través de su página web oficial. [18]
Las primeras versiones de OpenGL se lanzaron con una biblioteca complementaria llamada OpenGL Utility Library (GLU). Proporcionó características simples y útiles que probablemente no serían compatibles con el hardware contemporáneo, como teselación y generación de mapas MIP y formas primitivas . La especificación GLU se actualizó por última vez en 1998 y depende de características OpenGL que ahora están en desuso .
Dado que la creación de un contexto OpenGL es un proceso bastante complejo, y dado que varía entre sistemas operativos , la creación automática de contexto OpenGL se ha convertido en una característica común de varias bibliotecas de interfaz de usuario y desarrollo de juegos , incluidas SDL , Allegro , SFML , FLTK , y Qt . Algunas bibliotecas se han diseñado únicamente para producir una ventana compatible con OpenGL. La primera biblioteca de este tipo fue OpenGL Utility Toolkit (GLUT), posteriormente reemplazada por freeglut . GLFW es una alternativa más nueva. [19]
Dada la gran carga de trabajo que implica identificar y cargar extensiones OpenGL, se han diseñado algunas bibliotecas que cargan automáticamente todas las extensiones y funciones disponibles. Los ejemplos incluyen la biblioteca OpenGL Easy Extension (GLEE), la biblioteca OpenGL Extension Wrangler (GLEW) y glbinding . Las extensiones también se cargan automáticamente mediante la mayoría de los enlaces de idiomas, como JOGL y PyOpenGL.
Mesa 3D es una implementación de código abierto de OpenGL. Puede realizar renderizado de software puro y también puede utilizar aceleración de hardware en BSD , Linux y otras plataformas aprovechando la infraestructura de renderizado directo . A partir de la versión 20.0 implementa la versión 4.6 del estándar OpenGL.
En la década de 1980, desarrollar software que pudiera funcionar con una amplia gama de hardware gráfico era un verdadero desafío. Los desarrolladores de software escribieron interfaces y controladores personalizados para cada pieza de hardware. Esto fue costoso y resultó en una multiplicación de esfuerzos.
A principios de la década de 1990, Silicon Graphics (SGI) era líder en gráficos 3D para estaciones de trabajo. Su IRIS GL API [21] [22] se convirtió en el estándar de la industria, utilizado más ampliamente que el PHIGS basado en estándares abiertos . [ cita necesaria ] Esto se debió a que se consideraba que IRIS GL era más fácil de usar, [ ¿quién? ] y porque admitía la renderización en modo inmediato . Por el contrario, PHIGS se consideró difícil de usar y de funcionalidad obsoleta.
Los competidores de SGI (incluidos Sun Microsystems , Hewlett-Packard e IBM ) también pudieron llevar al mercado hardware 3D respaldado por extensiones realizadas al estándar PHIGS, lo que presionó a SGI para abrir una versión de IRIS GL como estándar público llamado OpenGL .
Sin embargo, SGI tenía muchos clientes para quienes el cambio de IRIS GL a OpenGL exigiría una inversión significativa. Además, IRIS GL tenía funciones API que eran irrelevantes para los gráficos 3D. Por ejemplo, incluía una API de ventanas, teclado y mouse, en parte porque fue desarrollado antes que X Window System y Sun's NeWS . Además, las bibliotecas IRIS GL no eran aptas para su apertura debido a problemas de licencias y patentes [ se necesita más explicación ] . Estos factores requirieron que SGI continuara brindando soporte a las API de programación avanzadas y patentadas Iris Inventor e Iris Performer mientras maduraba el soporte del mercado para OpenGL.
Una de las restricciones de IRIS GL era que solo proporcionaba acceso a funciones compatibles con el hardware subyacente. Si el hardware de gráficos no admitía una función de forma nativa, la aplicación no podría utilizarla. OpenGL superó este problema proporcionando implementaciones de software de funciones no compatibles con el hardware, lo que permite que las aplicaciones utilicen gráficos avanzados en sistemas de potencia relativamente baja. OpenGL estandarizó el acceso al hardware, impulsó la responsabilidad del desarrollo de programas de interfaz de hardware ( controladores de dispositivos ) a los fabricantes de hardware y delegó funciones de ventanas al sistema operativo subyacente. Con tantos tipos diferentes de hardware gráfico, lograr que todos hablaran el mismo idioma de esta manera tuvo un impacto notable al brindarles a los desarrolladores de software una plataforma de mayor nivel para el desarrollo de software 3D.
En 1992, [23] SGI lideró la creación de la Junta de Revisión de Arquitectura OpenGL (OpenGL ARB), el grupo de empresas que mantendrían y expandirían la especificación OpenGL en el futuro.
En 1994, SGI jugó con la idea de lanzar algo llamado " OpenGL++ " que incluía elementos tales como una API de gráficos de escenas (presumiblemente basada en su tecnología Performer ). La especificación circuló entre algunas partes interesadas, pero nunca se convirtió en un producto. [24]
En 1996, Microsoft lanzó Direct3D , que finalmente se convirtió en el principal competidor de OpenGL. Más de 50 desarrolladores de juegos firmaron una carta abierta a Microsoft, publicada el 12 de junio de 1997, pidiendo a la empresa que apoyara activamente OpenGL. [25] El 17 de diciembre de 1997, [26] Microsoft y SGI iniciaron el proyecto Fahrenheit , que fue un esfuerzo conjunto con el objetivo de unificar las interfaces OpenGL y Direct3D (y agregar también una API de gráficos de escenas). En 1998, Hewlett-Packard se unió al proyecto. [27] Inicialmente mostró cierta promesa de poner orden en el mundo de las API de gráficos por computadora interactivos en 3D, pero debido a limitaciones financieras en SGI, razones estratégicas en Microsoft y una falta general de apoyo de la industria, fue abandonado en 1999. [ 28]
En julio de 2006, la Junta de Revisión de Arquitectura OpenGL votó a favor de transferir el control del estándar API OpenGL al Grupo Khronos. [29] [30]
En junio de 2018, Apple dejó de usar las API OpenGL en todas sus plataformas ( iOS , macOS y tvOS ), alentando encarecidamente a los desarrolladores a utilizar su API Metal patentada , que se introdujo en 2014. [31]
id Software ha estado usando OpenGL en sus juegos comenzando con GLQuake (portación de Quake a OpenGL con algunas modificaciones) lanzado en 1997. [32] El primer motor con licencia de la compañía con soporte OpenGL fue el motor Quake II , también conocido como id Tech 2 . [33] En 2016, lanzaron una actualización para id Tech 6 que agregó soporte para Vulkan, un sucesor de OpenGL. ID Tech 7 eliminó la compatibilidad con OpenGL. [34]
En marzo de 2023, Valve eliminó la compatibilidad con OpenGL de Dota 2 . [35]
Khronos ha dejado de brindar soporte en OpenGL para una serie de tecnologías gráficas modernas, por ejemplo, Ray Tracing , decodificación de video en GPU , algoritmo anti-aliasing con aprendizaje profundo : AMD FidelityFX Super Resolución (FSR) [36] [37] y Nvidia DLSS. [38] [39]
Atype Games, con el apoyo de Samsung, actualizó su motor de juego para usar Vulkan, en lugar de OpenGL, en todas las plataformas que no sean Apple. [40]
El sistema operativo Fuchsia de Google utiliza Vulkan como API de gráficos nativos y requiere una GPU compatible con Vulkan. Fuchsia tiene la intención de admitir OpenGL sobre Vulkan mediante la capa de traducción ANGLE. [41]
La primera versión de OpenGL, la versión 1.0, fue lanzada el 30 de junio de 1992 por Mark Segal y Kurt Akeley . Desde entonces, OpenGL se ha ampliado ocasionalmente mediante el lanzamiento de una nueva versión de la especificación. Estas versiones definen un conjunto básico de características que todas las tarjetas gráficas compatibles deben admitir y sobre las cuales se pueden escribir nuevas extensiones más fácilmente. Cada nueva versión de OpenGL tiende a incorporar varias extensiones que cuentan con un amplio apoyo entre los proveedores de tarjetas gráficas, aunque los detalles de esas extensiones pueden cambiar.
Fecha de estreno : 7 de septiembre de 2004
OpenGL 2.0 fue concebido originalmente por 3Dlabs para abordar las preocupaciones de que OpenGL estaba estancado y carecía de una dirección sólida. [59] 3Dlabs propuso una serie de adiciones importantes al estándar. La mayoría de estos fueron, en su momento, rechazados por la ARB o nunca llegaron a concretarse en la forma propuesta por 3Dlabs. Sin embargo, su propuesta para un lenguaje de sombreado estilo C finalmente se completó, lo que resultó en la formulación actual del lenguaje de sombreado OpenGL ( GLSL o GLslang). Al igual que los lenguajes de sombreado tipo ensamblador que estaba reemplazando, permitía reemplazar el vértice de función fija y el tubo de fragmento con sombreadores , aunque esta vez escritos en un lenguaje de alto nivel tipo C.
El diseño de GLSL se destacó por hacer relativamente pocas concesiones a los límites del hardware disponible en ese momento. Esto se remonta a la tradición anterior de OpenGL que establecía un objetivo ambicioso y con visión de futuro para los aceleradores 3D en lugar de simplemente rastrear el estado del hardware disponible actualmente. La especificación final OpenGL 2.0 [60] incluye soporte para GLSL.
Antes del lanzamiento de OpenGL 3.0, la nueva revisión tenía el nombre en clave Longs Peak . En el momento de su anuncio original, Longs Peak se presentó como la primera revisión importante de API en la vida de OpenGL. Consistió en una revisión de la forma en que funciona OpenGL, lo que requirió cambios fundamentales en la API.
El borrador introdujo un cambio en la gestión de objetos. El modelo de objetos GL 2.1 se construyó sobre el diseño basado en estados de OpenGL. Es decir, para modificar un objeto o usarlo, es necesario vincular el objeto al sistema de estado y luego realizar modificaciones en el estado o realizar llamadas a funciones que utilicen el objeto vinculado.
Debido al uso de un sistema de estado por parte de OpenGL, los objetos deben ser mutables. Es decir, la estructura básica de un objeto puede cambiar en cualquier momento, incluso si la canalización de renderizado utiliza ese objeto de forma asincrónica. Un objeto de textura se puede redefinir de 2D a 3D. Esto requiere que cualquier implementación de OpenGL agregue un grado de complejidad a la gestión interna de objetos.
Bajo la API de Longs Peak, la creación de objetos se volvería atómica , utilizando plantillas para definir las propiedades de un objeto que se crearía con una llamada de función. Luego, el objeto podría usarse inmediatamente en varios subprocesos. Los objetos también serían inmutables; sin embargo, podrían modificar y actualizar su contenido. Por ejemplo, una textura podría cambiar su imagen, pero no se podría cambiar su tamaño y formato.
Para admitir la compatibilidad con versiones anteriores, la API basada en el estado anterior aún estaría disponible, pero no se expondría ninguna funcionalidad nueva a través de la API anterior en versiones posteriores de OpenGL. Esto habría permitido que las bases de código heredadas, como la mayoría de los productos CAD , siguieran ejecutándose mientras que otro software podría escribirse o migrarse a la nueva API.
Inicialmente, Longs Peak debía finalizarse en septiembre de 2007 con el nombre de OpenGL 3.0, pero el Grupo Khronos anunció el 30 de octubre que se había topado con varios problemas que deseaba abordar antes de publicar la especificación. [61] Como resultado, la especificación se retrasó y el Grupo Khronos entró en un apagón mediático hasta el lanzamiento de la especificación final OpenGL 3.0.
La especificación final resultó mucho menos revolucionaria que la propuesta de Longs Peak. En lugar de eliminar todo el modo inmediato y la funcionalidad fija (modo sin sombreador), la especificación los incluyó como características obsoletas. El modelo de objeto propuesto no se incluyó y no se han anunciado planes para incluirlo en revisiones futuras. Como resultado, la API se mantuvo prácticamente igual y algunas extensiones existentes se promovieron a la funcionalidad principal. Entre algunos grupos de desarrolladores, esta decisión causó cierto revuelo, [62] y muchos desarrolladores profesaron que cambiarían a DirectX en protesta. La mayoría de las quejas giraron en torno a la falta de comunicación de Khronos con la comunidad de desarrollo y el descarte de múltiples características que fueron vistas favorablemente por muchos. Otras frustraciones incluyeron el requisito de hardware de nivel DirectX 10 para usar OpenGL 3.0 y la ausencia de sombreadores de geometría y renderizado de instancias como características principales.
Otras fuentes informaron que la reacción de la comunidad no fue tan severa como se presentó originalmente, [63] y muchos proveedores mostraron su apoyo a la actualización. [64] [65]
Fecha de lanzamiento : 11 de agosto de 2008
OpenGL 3.0 introdujo un mecanismo de desaprobación para simplificar futuras revisiones de la API. Ciertas funciones, marcadas como obsoletas, podrían desactivarse por completo solicitando un contexto compatible con versiones posteriores al sistema de ventanas. Sin embargo, aún se puede acceder a las funciones de OpenGL 3.0 junto con estas funciones obsoletas, solicitando un contexto completo .
Las características obsoletas incluyen:
Fecha de lanzamiento : 24 de marzo de 2009
OpenGL 3.1 eliminó por completo todas las funciones que quedaron obsoletas en la versión 3.0, con la excepción de las líneas anchas. A partir de esta versión, no es posible acceder a nuevas funciones mediante un contexto completo ni a funciones obsoletas mediante un contexto compatible con versiones posteriores . Se hace una excepción a la regla anterior si la implementación admite la extensión ARB_compatibility, pero esto no está garantizado.
Soporte de hardware: Mesa es compatible con ARM Panfrost con la versión 21.0.
Fecha de lanzamiento : 3 de agosto de 2009
OpenGL 3.2 se basó en los mecanismos de obsolescencia introducidos por OpenGL 3.0, dividiendo la especificación en un perfil central y un perfil de compatibilidad . Los contextos de compatibilidad incluyen las API de función fija eliminadas anteriormente, equivalentes a la extensión ARB_compatibility lanzada junto con OpenGL 3.1, mientras que los contextos principales no. OpenGL 3.2 también incluyó una actualización a GLSL versión 1.50.
Fecha de lanzamiento: 11 de marzo de 2010
Mesa admite software Driver SWR, softpipe y tarjetas Nvidia más antiguas con NV50.
Fecha de lanzamiento : 11 de marzo de 2010
OpenGL 4.0 se lanzó junto con la versión 3.3. Fue diseñado para hardware capaz de soportar Direct3D 11.
Al igual que en OpenGL 3.0, esta versión de OpenGL contiene una gran cantidad de extensiones bastante intrascendentes, diseñadas para exponer completamente las capacidades del hardware de clase Direct3D 11. A continuación solo se enumeran las extensiones más influyentes.
Compatibilidad de hardware: serie Nvidia GeForce 400 y posteriores, AMD Radeon HD serie 5000 y posteriores (sombreadores FP64 implementados mediante emulación en algunas GPU TeraScale), gráficos Intel HD en procesadores Intel Ivy Bridge y posteriores. [66]
Fecha de estreno : 26 de julio de 2010
Compatibilidad de hardware: serie Nvidia GeForce 400 y posteriores, AMD Radeon HD serie 5000 y posteriores (sombreadores FP64 implementados mediante emulación en algunas GPU TeraScale), gráficos Intel HD en procesadores Intel Ivy Bridge y posteriores. [66]
Fecha de lanzamiento: 8 de agosto de 2011 [53]
Compatibilidad de hardware: serie Nvidia GeForce 400 y posteriores, AMD Radeon HD serie 5000 y posteriores (sombreadores FP64 implementados mediante emulación en algunas GPU TeraScale) y gráficos Intel HD en procesadores Intel Haswell y posteriores. [66] (Linux Mesa: Ivy Bridge y más reciente)
Fecha de lanzamiento: 6 de agosto de 2012 [54]
Soporte de hardware: AMD Radeon HD serie 5000 y posteriores (sombreadores FP64 implementados mediante emulación en algunas GPU TeraScale), gráficos Intel HD en procesadores Intel Haswell y posteriores. [66] (Linux Mesa: Ivy Bridge sin textura de plantilla, Haswell y más reciente), serie Nvidia GeForce 400 y más reciente. La emulación VIRGL para máquinas virtuales es compatible con 4.3+ con Mesa 20.
Fecha de lanzamiento: 22 de julio de 2013 [56]
Soporte de hardware: AMD Radeon HD serie 5000 y posteriores (sombreadores FP64 implementados mediante emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Broadwell y posteriores (Linux Mesa: Haswell y posteriores), [68] Nvidia GeForce serie 400 y posteriores, [69] Tegra K1 .
Fecha de lanzamiento: 11 de agosto de 2014 [15] [57]
Soporte de hardware: serie AMD Radeon HD 5000 y posteriores (sombreadores FP64 implementados mediante emulación en algunas GPU TeraScale), gráficos Intel HD en procesadores Intel Broadwell y posteriores (Linux Mesa: Haswell y posteriores), serie Nvidia GeForce 400 y posteriores, [69] Tegra K1 y Tegra X1. [71] [72]
Fecha de lanzamiento: 31 de julio de 2017 [15] [8] [58]
Soporte de hardware: AMD Radeon HD serie 7000 y posteriores (sombreadores FP64 implementados mediante emulación en algunas GPU TeraScale), Intel Haswell y posteriores, Nvidia GeForce serie 400 y posteriores. [69]
Soporte al conductor:
Apple desaprobó OpenGL en iOS 12 y macOS 10.14 Mojave en favor de Metal , pero todavía está disponible a partir de macOS 14 Sonoma (incluso en dispositivos Apple Silicon ). [80] La última versión compatible con OpenGL es 4.1 de 2011. [81] [82] Una biblioteca patentada de Molten, autores de MoltenVK , llamada MoltenGL, puede traducir llamadas OpenGL a Metal. [83]
Hay varios proyectos que intentan implementar OpenGL sobre Vulkan. El backend Vulkan para ANGLE de Google logró la conformidad con OpenGL ES 3.1 en julio de 2020. [84] El proyecto Mesa3D también incluye un controlador de este tipo, llamado Zink . [85]
Windows 11 en Arm de Microsoft agregó soporte para OpenGL 3.3 a través de GLon12, una implementación de OpenGL de código abierto sobre DirectX 12 a través de Mesa Gallium . [86] [87] [88]
Vulkan, anteriormente denominada "Iniciativa OpenGL de próxima generación" (glNext), [89] [90] es un esfuerzo de rediseño desde cero para unificar OpenGL y OpenGL ES en una API común que no será compatible con versiones anteriores de OpenGL. [91] [92] [93]
La versión inicial de Vulkan API se lanzó el 16 de febrero de 2016.