OpenGL

OpenGL (Open Graphics Library) es una interfaz de programación de aplicaciones (API) multiplataforma y multilenguaje para renderizar gráficos vectoriales 2D y 3D. La API generalmente se usa para interactuar con una unidad de procesamiento de gráficos (GPU), para lograr una representación acelerada por hardware.

Silicon Graphics, Inc. (SGI) comenzó a desarrollar OpenGL en 1991 y lo lanzó el 30 de junio de 1992; las aplicaciones lo utilizan ampliamente en los campos de diseño asistido por computadora (CAD), realidad virtual, visualización científica, visualización de información, simulación de vuelo y videojuegos. Desde 2006, OpenGL ha sido administrado por el consorcio de tecnología sin fines de lucro Khronos Group.

Diseño

Una ilustración del proceso de tuberías gráficas

La especificación OpenGL describe una API abstracta para dibujar gráficos 2D y 3D. Aunque es posible que la API se implemente completamente en software, está diseñada para implementarse en su mayor parte o en su totalidad en hardware.

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 la representación 3D desde un navegador web); el C se une a WGL, GLX y CGL; el enlace C proporcionado por iOS; y los enlaces 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 únicamente de la representación, sin proporcionar API relacionadas con la entrada, el audio o las ventanas.

Desarrollo

OpenGL ya no está en desarrollo activo: mientras que entre 2001 y 2014, la especificación de OpenGL se actualizó principalmente cada año, con dos versiones (3.1 y 3.2) en 2009 y tres (3.3, 4.0 y 4.1) en 2010, la última 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.

El desarrollo activo de OpenGL se abandonó en favor de la API de 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á nuevas versiones y desde entonces se ha concentrado en el desarrollo de Vulkan y otras tecnologías. Como resultado, ciertas capacidades que ofrecen las GPU modernas, p. trazado de rayos, no son compatibles con OpenGL.

Khronos Group lanza nuevas versiones de las especificaciones de 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 los fabricantes de tarjetas gráficas, los diseñadores de sistemas operativos y las empresas de tecnología en general, como Mozilla y Google.

Además de las funciones requeridas por la API central, 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 las restricciones de 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 en gran medida la flexibilidad de OpenGL. Todas las extensiones se recopilan y definen en el registro de OpenGL.

Cada extensión está asociada con un identificador breve, 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(). Si varios proveedores acuerdan implementar la misma funcionalidad usando la misma API, se puede lanzar una extensión compartida, usando el identificador EXT. En tales casos, también podría suceder que la Junta de Revisión de Arquitectura de Khronos Group dé a la extensión su aprobación explícita, en cuyo caso se utiliza el identificador ARB.

Las funciones introducidas por cada nueva versión de OpenGL generalmente se forman a partir de las funciones combinadas de varias extensiones ampliamente implementadas, especialmente extensiones de tipo ARB o EXT.

Documentación

La Junta de revisión de la arquitectura de OpenGL publicó una serie de manuales junto con la especificación que se actualizó para realizar un seguimiento de los cambios en la API. Estos se conocen comúnmente por los colores de sus cubiertas:

El Libro Rojo

OpenGL Guía de programación, 9a edición. ISBN 978-0-134-49549-1

La Guía Oficial de Aprendizaje OpenGL, versión 4.5 con SPIR-V

El libro Orange

OpenGL Shading Language, 3a edición. ISBN 0-321-63763-1

Un tutorial y un libro de referencia para GLSL.

Libros históricos (anteriores a OpenGL 2.0):

El Libro Verde

Programación OpenGL para el sistema X Window. ISBN 978-0-201-48359-8

Un libro sobre X11 interfacing y OpenGL Utility Toolkit (GLUT).

El Libro Azul

Manual de referencia OpenGL, 4a edición. ISBN 0-321-17383-X

Esencialmente una impresión de copia dura de las páginas manual Unix para OpenGL.

Incluye un diagrama plegable de tamaño póster que muestra la estructura de una implementación de OpenGL idealizada.

El Libro Alfa (cubrimiento blanco)

Programación OpenGL para Windows 95 y Windows NT. ISBN 0-201-40709-4

Un libro sobre interfacing OpenGL con Microsoft Windows.

También se puede acceder a la documentación de OpenGL a través de su página web oficial.

Bibliotecas asociadas

Las primeras versiones de OpenGL se lanzaron con una biblioteca complementaria llamada OpenGL Utility Library (GLU). Proporcionó características simples y útiles que era poco probable que fueran compatibles con el hardware contemporáneo, como teselado y generación de mipmaps y formas primitivas. La especificación GLU se actualizó por última vez en 1998 y depende de las características de OpenGL que ahora están obsoletas.

Conjuntos de herramientas de ventana y contexto

Dado que la creación de un contexto OpenGL es un proceso bastante complejo y que varía entre los sistemas operativos, la creación automática de contextos 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 han sido diseñadas únicamente para producir una ventana compatible con OpenGL. La primera biblioteca de este tipo fue OpenGL Utility Toolkit (GLUT), más tarde reemplazada por freeglut. GLFW es una alternativa más nueva.

• Estos kits de herramientas están diseñados para crear y gestionar ventanas OpenGL, y gestionar la entrada, pero poco más allá de eso.

• GLFW – Una ventana multiplataforma y un manipulador de teclado-joystick-mouse; está más orientado al juego
• freeglut – Una ventana multiplataforma y un controlador de teclado-mouse; su API es un superset de la API GLUT, y es más estable y hasta la fecha que GLUT
• OpenGL Utility Toolkit (GLUT) – Un viejo manejador de ventana, ya no se mantiene.

• Varias "libros multitimedia" pueden crear Ventanas OpenGL, además de tareas de entrada, sonido y otras útiles para aplicaciones tipo juego

• Allegro 5 – Una biblioteca multimedia multiplataforma con una API de C centrada en el desarrollo del juego
• Simple DirectMedia Layer (SDL) – Una biblioteca multimedia multiplataforma con una API de C
• SFML – Una biblioteca multimedia multiplataforma con una API C++ y múltiples otras ligaciones a idiomas como C#, Java, Haskell y Go

• Widget toolkits

• FLTK – Una pequeña biblioteca multiplataforma C++
• Qt – Un kit de herramientas multiplataforma C++. Proporciona muchos objetos de ayuda OpenGL, que incluso abstraer la diferencia entre el escritorio GL y OpenGL ES
• wxWidgets – Un widget multiplataforma C++

Bibliotecas de carga de extensiones

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), OpenGL Extension Wrangler Library (GLEW) y glbinding. La mayoría de los enlaces de idiomas también cargan automáticamente las extensiones, como JOGL y PyOpenGL.

Implementaciones

Captura de Pantalla glxinfo, mostrando información sobre la implementación de Mesa de OpenGL en un sistema

Mesa 3D es una implementación de código abierto de OpenGL. Puede hacer renderizado de software puro y también puede usar 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.

Historia

En la década de 1980, desarrollar software que pudiera funcionar con una amplia gama de hardware de gráficos 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 la multiplicación del esfuerzo.

A principios de la década de 1990, Silicon Graphics (SGI) era líder en gráficos 3D para estaciones de trabajo. Su API IRIS GL se convirtió en el estándar de la industria y se usó más ampliamente que los PHIGS basados en estándares abiertos. Esto se debió a que IRIS GL se consideró más fácil de usar y porque admitía el modo de renderizado inmediato. Por el contrario, PHIGS se consideró difícil de usar y obsoleto en su funcionalidad.

Los competidores de SGI (incluidos Sun Microsystems, Hewlett-Packard e IBM) también pudieron comercializar hardware 3D respaldado por extensiones hechas al estándar PHIGS, lo que presionó a SGI para abrir una versión de código abierto de IRIS GL como un estándar público llamado OpenGL.

Sin embargo, SGI tenía muchos clientes para quienes el cambio de IRIS GL a OpenGL demandarí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 se desarrolló antes que X Window System y Sun's NeWS. Además, las bibliotecas IRIS GL no eran adecuadas para abrir debido a problemas de licencias y patentes. Estos factores requirieron que SGI continuara brindando soporte a las API de programación avanzadas y propietarias Iris Inventor e Iris Performer mientras maduraba el soporte de 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 usarla. OpenGL superó este problema al proporcionar implementaciones de software de características no compatibles con el hardware, lo que permitió que las aplicaciones usaran gráficos avanzados en sistemas de energía relativamente baja. OpenGL estandarizó el acceso al hardware, empujó la responsabilidad de desarrollo de los programas de interfaz de hardware (controladores de dispositivos) a los fabricantes de hardware y delegó las funciones de ventanas al sistema operativo subyacente. Con tantos tipos diferentes de hardware de gráficos, hacer que todos hablaran el mismo idioma de esta manera tuvo un impacto notable al brindarles a los desarrolladores de software una plataforma de alto nivel para el desarrollo de software 3D.

En 1992, SGI lideró la creación de OpenGL Architecture Review Board (OpenGL ARB), el grupo de empresas que mantendría y expandiría la especificación OpenGL en el futuro.

En 1994, SGI jugó con la idea de lanzar algo llamado "OpenGL++" que incluía elementos como una API de gráfico de escena (presumiblemente basada en su tecnología Performer). La especificación se distribuyó entre algunas partes interesadas, pero nunca se convirtió en un producto.

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, en la que pedían a la empresa que apoyara activamente a OpenGL. El 17 de diciembre de 1997, Microsoft y SGI iniciaron el proyecto Fahrenheit, que fue un esfuerzo conjunto con el objetivo de unificar las interfaces de OpenGL y Direct3D (y agregar una API de gráficos de escena también). En 1998, Hewlett-Packard se unió al proyecto. Inicialmente mostró cierta promesa de poner orden en el mundo de las API de gráficos por computadora en 3D interactivos, pero debido a las limitaciones financieras en SGI, razones estratégicas en Microsoft y una falta general de apoyo de la industria, se abandonó en 1999.

En julio de 2006, la Junta de revisión de la arquitectura de OpenGL votó a favor de transferir el control del estándar API de OpenGL al Grupo Khronos.

Historial de versiones

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. Dichos lanzamientos definen un conjunto básico de características que todas las tarjetas gráficas compatibles deben admitir y con las que 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 soporte entre los proveedores de tarjetas gráficas, aunque los detalles de esas extensiones pueden cambiar.

OpenGL 2.0

Fecha de lanzamiento: 7 de septiembre de 2004

OpenGL 2.0 fue concebido originalmente por 3Dlabs para abordar las preocupaciones de que OpenGL se estaba estancando y carecía de una dirección sólida. 3Dlabs propuso una serie de adiciones importantes al estándar. La mayoría de estos fueron, en ese momento, rechazados por la ARB o nunca llegaron a buen término en la forma propuesta por 3Dlabs. Sin embargo, su propuesta para un lenguaje de sombreado de 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 similares a ensambladores que estaba reemplazando, permitía reemplazar el vértice de función fija y la tubería de fragmentos con sombreadores, aunque esta vez escrito en un lenguaje de alto nivel similar a 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 establece un objetivo ambicioso y con visión de futuro para los aceleradores 3D en lugar de simplemente rastrear el estado del hardware actualmente disponible. La especificación final de OpenGL 2.0 incluye soporte para GLSL.

Longs Peak y OpenGL 3.0

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 la API en la vida de OpenGL. Consistía en una revisión de la forma en que funciona OpenGL, que requería 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 el estado de OpenGL. Es decir, para modificar un objeto o utilizarlo, 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 OpenGL de un sistema de estado, 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 representación usa ese objeto de forma asíncrona. Un objeto de textura se puede redefinir de 2D a 3D. Esto requiere cualquier implementación de OpenGL para agregar un grado de complejidad a la gestión de objetos internos.

Bajo la API de Longs Peak, la creación de objetos serí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 cambiar y actualizar su contenido. Por ejemplo, una textura podría cambiar su imagen, pero su tamaño y formato no se podrían cambiar.

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, continuaran 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 Khronos Group anunció el 30 de octubre que se había encontrado con varios problemas que deseaba abordar antes de publicar la especificación. Como resultado, la especificación se retrasó y el Grupo Khronos entró en un apagón de medios hasta el lanzamiento de la especificación final de 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 con algunas extensiones existentes que se promovieron a la funcionalidad principal.

Entre algunos grupos de desarrolladores, esta decisión causó algo de revuelo, y muchos desarrolladores afirmaron que cambiarían a DirectX como 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 muchos vieron favorablemente. 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 representación instanciada como características principales.

Otras fuentes informaron que la reacción de la comunidad no fue tan severa como se presentó originalmente, y muchos proveedores mostraron su apoyo a la actualización.

OpenGL 3.0

Fecha de lanzamiento: 11 de agosto de 2008

OpenGL 3.0 introdujo un mecanismo de obsolescencia para simplificar futuras revisiones de la API. Ciertas funciones, marcadas como obsoletas, podrían deshabilitarse por completo solicitando un contexto compatible con versiones anteriores del 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:

• Todo el vértice de funcionamiento fijo y procesamiento de fragmentos
• renderizado directo, utilizando glBegin y glEnd
• Listas de visualización
• Objetivos de renderización de color
• OpenGL Shading Idioma versiones 1.10 y 1.20

OpenGL 3.1

Fecha de lanzamiento: 24 de marzo de 2009

OpenGL 3.1 eliminó por completo todas las características 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 funciones nuevas mediante un contexto completo ni acceder a funciones obsoletas mediante un contexto compatible con versiones anteriores. Se hace una excepción a la regla anterior si la implementación admite la extensión ARB_compatibility, pero esto no está garantizado.

Hardware: Mesa es compatible con ARM Panfrost con la versión 21.0.

OpenGL 3.2

Fecha de lanzamiento: 3 de agosto de 2009

OpenGL 3.2 se basó aún más en los mecanismos de desaprobación introducidos por OpenGL 3.0, al dividir la especificación en un perfil principal 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.

OpenGL 3.3

Fecha de lanzamiento: 11 de marzo de 2010

Mesa es compatible con el controlador de software SWR, softpipe y para tarjetas Nvidia más antiguas con NV50.

OpenGL 4.0

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 compatible con 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. Solo las extensiones más influyentes se enumeran a continuación.

Compatibilidad con hardware: Nvidia GeForce serie 400 y posteriores, AMD Radeon HD 5000 series y posteriores (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Ivy Bridge y posteriores.

OpenGL 4.1

Fecha de lanzamiento: 26 de julio de 2010

Compatibilidad con hardware: Nvidia GeForce serie 400 y posteriores, AMD Radeon HD 5000 series y posteriores (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Ivy Bridge y posteriores.

• Mínimo "tamaño máximo de textura" es 16,384 × 16,384 para la implementación de esta especificación de GPU.

OpenGL 4.2

Fecha de lanzamiento: 8 de agosto de 2011

• Soporte para sombreadores con contadores atómicos y operaciones de lectura-modificar-escritura atómico de carga a un nivel de textura
• Dibujo múltiples casos de datos capturados del procesamiento del vértice de GPU (incluyendo la tessellación), para permitir que los objetos complejos sean reposicionados y replicados eficientemente
• Soporte para modificar un subconjunto arbitrario de una textura comprimida, sin tener que volver a cargar toda la textura a la GPU para mejoras significativas de rendimiento

Compatibilidad con hardware: Nvidia GeForce serie 400 y posteriores, AMD Radeon HD 5000 series y posteriores (sombreadores FP64 implementados por emulación en algunas GPU TeraScale) e Intel HD Graphics en procesadores Intel Haswell y posteriores. (Linux Mesa: Ivy Bridge y posteriores)

OpenGL 4.3

Fecha de lanzamiento: 6 de agosto de 2012

• Los sombreadores computarizados que aprovechan el paralelismo GPU en el contexto de la tubería gráfica
• Objetos de amortiguación de almacenamiento, permitiendo a los sombreadores leer y escribir objetos de amortiguación como carga de imagen / tienda de 4.2, pero a través del lenguaje en lugar de llamadas de función.
• Consultas de parámetros de formato de imagen
• compresión de textura ETC2/EAC como característica estándar
• Compatibilidad completa con OpenGL ES 3.0 APIs
• Debug habilidades para recibir mensajes depuradores durante el desarrollo de aplicaciones
• Vistas de textura para interpretar texturas de diferentes maneras sin replicación de datos
• Mayor seguridad de la memoria y robustez de aplicación múltiple

Compatibilidad con hardware: AMD Radeon HD 5000 Series y posteriores (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Haswell y posteriores. (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.

OpenGL 4.4

Fecha de lanzamiento: 22 de julio de 2013

• Controles de uso de objetos de amortiguación reforzados
• Consultas asincrónicas en objetos de amortiguación
• Expresión de más controles de diseño de variables de interfaz en sombreadores
• Armadura eficiente de múltiples objetos simultáneamente

Compatibilidad con hardware: AMD Radeon HD serie 5000 y posteriores (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Broadwell y posteriores (Linux Mesa: Haswell y posteriores), Nvidia GeForce serie 400 y posteriores, Tegra K1.

OpenGL 4.5

Fecha de lanzamiento: 11 de agosto de 2014

• Acceso directo al Estado (DSA) – los accesorios de objetos permiten que el estado sea consultado y modificado sin objetos vinculantes a contextos, para aumentar la eficiencia y flexibilidad de la aplicación y el middleware.
• Control de Flush – las aplicaciones pueden controlar el despilfarro de comandos pendientes antes de cambiar el contexto – permitiendo aplicaciones multitesis de alto rendimiento;
• Robustness – proporcionar una plataforma segura para aplicaciones como los navegadores WebGL, incluyendo la prevención de un restablecimiento de GPU que afecte a cualquier otra aplicación en ejecución;
• OpenGL ES 3.1 API y compatibilidad con sombreadores – para permitir el fácil desarrollo y ejecución de las últimas aplicaciones OpenGL ES en sistemas de escritorio.

Compatibilidad con hardware: AMD Radeon HD serie 5000 y posteriores (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Broadwell y posteriores (Linux Mesa: Haswell y posteriores), Nvidia GeForce serie 400 y posteriores, Tegra K1 y Tegra X1.

OpenGL 4.6

Fecha de lanzamiento: 31 de julio de 2017

• más eficiente, procesamiento de geometría lado GPU
• más eficiente ejecución de la sombra (AZDO)
• más información a través de estadísticas, consultas de desbordamiento y contadores
• mayor rendimiento sin contextos de manejo de errores
• fijación de la función offset de polígono, resuelve un problema de renderización de sombras
• Sombreros SPIR-V
• Filtro anisotrópico mejorado

Compatibilidad con hardware: AMD Radeon HD 7000 Series y posteriores (FP64 shaders implementados por emulación en algunas GPU TeraScale), Intel Haswell y posteriores, Nvidia GeForce 400 series y posteriores.

Compatibilidad con el controlador:

• Mesa 19.2 en Linux soporta OpenGL 4.6 para Intel Broadwell y más reciente. Mesa 20.0 admite GPUs AMD Radeon, mientras que el apoyo a Nvidia Kepler+ está en marcha. Zink como controlador de emulación con 21.1 y controlador de software LLVMpipe también admite con Mesa 21.0.
• AMD Adrenalin 18.4.1 Graphics Driver en Windows 7 SP1, 10 versión 1803 (actualización de abril de 2018) para AMD RadeonTM HD 7700+, HD 8500+ y más reciente. Publicado abril de 2018.
• Intel 26.20.100.6861 controlador de gráficos en Windows 10. Publicado mayo 2019.
• NVIDIA GeForce 397.31 Graphics Driver on Windows 7, 8, 10 x86-64 bit only, no 32-bit support. Publicado abril 2018

Implementaciones alternativas

Apple dejó de usar OpenGL en iOS 12 y macOS 10.14 Mojave a favor de Metal, pero todavía está disponible a partir de macOS 13 Ventura (incluidos los dispositivos de silicio de Apple). La última versión admitida para OpenGL es 4.1 de 2011. Una biblioteca patentada de Molten, autores de MoltenVK, llamada MoltenGL, puede traducir llamadas OpenGL a Metal.

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. El proyecto Mesa3D también incluye un controlador de este tipo, llamado Zink.

El futuro de OpenGL

En junio de 2018, Apple dejó de utilizar las API de OpenGL en todas sus plataformas (iOS, macOS y tvOS), lo que alentó enfáticamente a los desarrolladores a usar su API Metal patentada, que se presentó en 2014.

Stadia y el sistema operativo de Google Fuchsia solo son compatibles con Vulkan.

En 2016, id Software lanzó una actualización para el motor de juegos id Tech 6 que agregó compatibilidad con Vulkan, pero mantuvo la compatibilidad con OpenGL. ID Tech 7 eliminó el soporte para OpenGL.

El 17 de septiembre de 2021, Valve anunció que eliminaría OpenGL de Dota 2 en una actualización futura.

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 son de Apple.

OpenGL no es compatible con Ray Tracing, API para decodificación de video en GPU en comparación con Vulkan.

Sombreadores de malla compatibles con GPU nVidia y AMD.

OpenGL no es compatible con el algoritmo anti-aliasing con aprendizaje profundo: AMD FidelityFX Super Resolution (FSR) y Nvidia DLSS.

Vulcano

Vulkan, anteriormente denominada "Iniciativa OpenGL de próxima generación" (glNext), es un esfuerzo de rediseño desde cero para unificar OpenGL y OpenGL ES en una API común que no será compatible con las versiones anteriores de OpenGL.

La versión inicial de Vulkan API se lanzó el 16 de febrero de 2016.