OpenGL - OpenGL

No confundir con OpenCL .

OpenGL
Logotipo de OpenGL (2D) .svg
Kernel de Linux y videojuegos OpenGL.svg
Los videojuegos subcontratan los cálculos de renderizado en tiempo real a la GPU a través de OpenGL. Los resultados renderizados no se envían de vuelta a la memoria principal, sino al framebuffer de la memoria de video. El controlador de pantalla enviará estos datos al dispositivo de pantalla.
Autor (es) original (es) Gráficos de silicio
Desarrollador (es) Grupo Khronos
(anteriormente ARB )
Versión inicial 30 de junio de 1992 ; Hace 29 años (1992-06-30)
Lanzamiento estable
4.6 / 31 de julio de 2017 ; Hace 4 años (2017-07-31)
Escrito en C
Escribe API de gráficos 3D
Licencia
  • Licencia de código abierto para el uso de SI: esta es una licencia de software libre B que se basa en las licencias BSD, X y Mozilla.
  • Licencia de marca comercial para nuevos licenciatarios que deseen utilizar la marca comercial y el logotipo de OpenGL y reclamar conformidad.
Sitio web opengl .org

OpenGL ( Abra Graphics Library ) es una entre lenguajes , multi-plataforma de interfaz de programación de aplicaciones (API) para la representación en 2D y 3D de gráficos vectoriales . La API se usa generalmente 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 del 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 tecnológico sin fines de lucro Khronos Group .

Diseño

Una ilustración del proceso de canalización de gráficos

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

La API se define como un conjunto de funciones que pueden ser invocadas por 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 idioma , algunos de los más notables son el enlace de JavaScript WebGL (API, basado en OpenGL ES 2.0 , para renderizado 3D desde dentro de un navegador web ); los enlaces C 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 la obtención y gestión de un contexto OpenGL, dejando esto como un detalle del sistema de ventanas subyacente . Por la misma razón, OpenGL se ocupa exclusivamente de la renderización y no proporciona API relacionadas con la entrada, el audio o las ventanas.

Desarrollo

OpenGL es una API desarrollada activamente. Khronos Group lanza regularmente 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, diseñadores de sistemas operativos y empresas de tecnología en general como Mozilla y Google .

Además de las características requeridas por la API central, los proveedores de unidades de procesamiento de gráficos (GPU) pueden proporcionar funcionalidad adicional en forma de extensiones . Las extensiones pueden introducir nuevas funciones y nuevas constantes, y pueden relajar o eliminar restricciones en las funciones de 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.

Cada extensión está asociada con un identificador corto, basado en el nombre de la empresa que la desarrolló. Por ejemplo, el identificador de Nvidia es NV, que es parte del nombre de la extensión GL_NV_half_float, la constante GL_HALF_FLOAT_NVy la función glVertex2hNV(). Si varios proveedores aceptan implementar la misma funcionalidad usando la misma API, se puede liberar una extensión compartida, usando el identificador EXT. En tales casos, también podría suceder que la Junta de Revisión de Arquitectura del Grupo Khronos otorgue a la extensión su aprobación explícita, en cuyo caso se utiliza el identificador ARB.

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.

Documentación

La Junta de Revisión de Arquitectura OpenGL publicó una serie de manuales junto con la especificación que se han actualizado para realizar un seguimiento de los cambios en la API. Estos se denominan comúnmente por los colores de sus cubiertas:

El libro rojo
Guía de programación de OpenGL, novena edición. ISBN  978-0-134-49549-1
La guía oficial para aprender OpenGL, versión 4.5 con SPIR-V
El libro naranja
Lenguaje de sombreado OpenGL, tercera 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 la interfaz X11 y OpenGL Utility Toolkit (GLUT).
El libro azul
Manual de referencia de OpenGL, cuarta edición. ISBN  0-321-17383-X
Esencialmente una copia impresa de las páginas del manual (man) de Unix para OpenGL.
Incluye un diagrama desplegable del tamaño de un póster que muestra la estructura de una implementación OpenGL idealizada.
The Alpha Book (tapa blanca)
Programación OpenGL para Windows 95 y Windows NT. ISBN  0-201-40709-4
Un libro sobre la interfaz de OpenGL con Microsoft Windows.

La documentación de OpenGL también es accesible 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, útiles que eran poco probable que se admiten en hardware contemporánea, tales como tessellating , y la 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 en desuso .

Conjuntos de herramientas de contexto y ventana

Dado que crear 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 desarrollo de juegos e interfaces de usuario , 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), luego reemplazada por freeglut . GLFW es una alternativa más nueva.

  • Estos kits de herramientas están diseñados para crear y administrar ventanas OpenGL y administrar entradas, pero poco más allá de eso.
  • GLFW : un controlador de ventanas multiplataforma y de teclado, mouse y joystick; está más orientado al juego
  • freeglut : una ventana multiplataforma y un controlador de teclado y mouse; su API es un superconjunto de la API GLUT, y es más estable y actualizada que GLUT
  • OpenGL Utility Toolkit (GLUT): un antiguo controlador de ventanas que ya no se mantiene.
  • Varias "bibliotecas multimedia" pueden crear ventanas OpenGL, además de entrada, sonido y otras tareas útiles para aplicaciones similares a juegos.
  • Allegro 5 : una biblioteca multimedia multiplataforma con una API C centrada en el desarrollo de juegos
  • Simple DirectMedia Layer (SDL): una biblioteca multimedia multiplataforma con una API C
  • SFML : una biblioteca multimedia multiplataforma con una API de C ++ y muchos otros enlaces a lenguajes como C #, Java, Haskell y Go
  • Kits de herramientas de widgets
  • FLTK : una pequeña biblioteca de widgets C ++ multiplataforma
  • Qt : un conjunto de herramientas de widgets C ++ multiplataforma. Proporciona muchos objetos auxiliares de OpenGL, que incluso abstraen la diferencia entre GL de escritorio y OpenGL ES
  • wxWidgets : un kit de herramientas de widgets de C ++ multiplataforma

Bibliotecas de carga de extensiones

Dada la alta carga de trabajo involucrada en la identificación y carga de extensiones OpenGL, se han diseñado algunas bibliotecas que cargan todas las extensiones y funciones disponibles automáticamente. Los ejemplos incluyen GLEE , GLEW y glbinding . Las extensiones también se cargan automáticamente mediante la mayoría de los enlaces de idiomas, como JOGL y PyOpenGL .

Implementaciones

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.

Historia

En la década de 1980, el desarrollo de software que pudiera funcionar con una amplia gama de hardware gráfico fue 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 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 se consideró que IRIS GL era más fácil de usar y porque admitía el renderizado en modo inmediato . Por el contrario, PHIGS se consideró difícil de usar y obsoleta en funcionalidad.

Los competidores de SGI (incluidos Sun Microsystems , Hewlett-Packard e IBM ) también pudieron llevar al mercado hardware 3D compatible con extensiones realizadas al estándar PHIGS, lo que presionó a SGI para que abriera una versión de IrisGL como estándar público llamado OpenGL .

Sin embargo, SGI tenía muchos clientes para quienes el cambio de IrisGL a OpenGL exigiría una inversión significativa. Además, IrisGL 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 el sistema X Window y Sun's NeWS . Además, las bibliotecas IrisGL no eran adecuadas para la apertura debido a problemas de licencias y patentes. Estos factores requerían que SGI continuara respaldando las API de programación avanzadas y patentadas Iris Inventor e Iris Performer mientras maduraba el soporte de mercado para OpenGL.

Una de las restricciones de IrisGL era que solo brindaba 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 proporcionando implementaciones de software de características no compatibles con hardware, lo que permite que las aplicaciones utilicen gráficos avanzados en sistemas de relativamente baja potencia. OpenGL estandarizó el acceso al hardware, trasladó la responsabilidad del 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 gráfico, lograr que todos hablen el mismo idioma de esta manera tuvo un impacto notable al brindar a los desarrolladores de software una plataforma de nivel superior para el desarrollo de software en 3D.

En 1992, SGI lideró la creación del 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áficos 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.

Microsoft lanzó Direct3D en 1995, que finalmente se convirtió en el principal competidor de OpenGL. Más de 50 desarrolladores de juegos firmaron una carta abierta a Microsoft, lanzada el 12 de junio de 1997, pidiendo a la compañía que apoye activamente a Open GL. 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 OpenGL y Direct3D (y también agregar una API de gráficos de escena). 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 interactivos en 3D, 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 Arquitectura OpenGL votó a favor de transferir el control del estándar API 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. Dichas versiones definen un conjunto básico de características que deben admitir todas las tarjetas gráficas conformes y contra las cuales se pueden escribir nuevas extensiones más fácilmente. Cada nueva versión de OpenGL tiende a incorporar varias extensiones que tienen un soporte generalizado entre los proveedores de tarjetas gráficas, aunque los detalles de esas extensiones pueden cambiar.

Historial de versiones de OpenGL
Versión Fecha de lanzamiento Características
1.1 4 de marzo de 1997 Objetos de textura, matrices de vértices
1.2 16 de marzo de 1998 Texturas 3D, BGRA y formatos de píxeles empaquetados , introducción del subconjunto de imágenes útil para aplicaciones de procesamiento de imágenes
1.2.1 14 de octubre de 1998 Un concepto de extensiones ARB
1.3 14 de agosto de 2001 Multitextura , multimuestreo, compresión de texturas
1.4 24 de julio de 2002 Texturas de profundidad, GLSlang
1,5 29 de julio de 2003 Vertex Buffer Object (VBO), consultas de oclusión
2.0 7 de septiembre de 2004 GLSL 1.1, MRT , Sin poder de dos texturas, Point Sprites, Plantilla de dos caras
2.1 2 de julio de 2006 GLSL 1.2, Objeto de búfer de píxeles (PBO), Texturas sRGB
3,0 11 de agosto de 2008 GLSL 1.3, Matrices de texturas, Representación condicional, Objeto de búfer de cuadros (FBO)
3.1 24 de marzo de 2009 GLSL 1.4, instancia, objeto de búfer de textura, objeto de búfer uniforme, reinicio primitivo
3.2 3 de agosto de 2009 GLSL 1.5, Geometry Shader, texturas multimuestreadas
3.3 11 de marzo de 2010 GLSL 3.30, Backports tantas funciones como sea posible de la especificación OpenGL 4.0
4.0 11 de marzo de 2010 GLSL 4.00, teselación en GPU, sombreadores con precisión de 64 bits
4.1 26 de julio de 2010 GLSL 4.10, salidas de depuración amigables para desarrolladores, compatibilidad con OpenGL ES 2.0
4.2 8 de agosto de 2011 GLSL 4.20, Shaders con contadores atómicos, instancia de retroalimentación de transformación de extracción, empaquetado de sombreadores, mejoras de rendimiento
4.3 6 de agosto de 2012 GLSL 4.30, sombreadores informáticos que aprovechan el paralelismo de la GPU, objetos de búfer de almacenamiento de sombreadores, compresión de textura ETC2 / EAC de alta calidad, mayor seguridad de la memoria, una extensión de robustez de múltiples aplicaciones, compatibilidad con OpenGL ES 3.0
4.4 22 de julio de 2013 GLSL 4.40, control de ubicación de búfer, consultas asincrónicas eficientes, diseño variable de sombreado, enlace de múltiples objetos eficiente, portabilidad optimizada de aplicaciones Direct3D, extensión de textura sin encuadernación, extensión de textura dispersa
4.5 11 de agosto de 2014 GLSL 4.50, Direct State Access (DSA), Flush Control, Robustez, OpenGL ES 3.1 API y compatibilidad con sombreadores, funciones de emulación DX11
4.6 31 de julio de 2017 GLSL 4.60, procesamiento de geometría y ejecución de sombreado más eficientes, más información, sin contexto de error, abrazadera de desplazamiento de polígono, SPIR-V, filtrado anisotrópico

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 se materializaron en la forma propuesta por 3Dlabs. Sin embargo, su propuesta de 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 de tipo ensamblador 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 que OpenGL estableciera 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 API en la vida de OpenGL. Consistió en una revisión de la forma en que funciona OpenGL, requiriendo 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, luego hacer modificaciones al estado o realizar llamadas a funciones que usan 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 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 administración de objetos internos.

Bajo la API de Longs Peak, la creación de objetos se volvería atómica , usando plantillas para definir las propiedades de un objeto que se crearía con una llamada de función. A continuación, el objeto podría utilizarse inmediatamente en varios subprocesos. Los objetos también serían inmutables; sin embargo, podrían modificar y actualizar su contenido. Por ejemplo, una textura puede cambiar su imagen, pero su tamaño y formato no se pueden cambiar.

Para admitir la compatibilidad con versiones anteriores, la API basada en el estado anterior todavía 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 trasladarse a la nueva API.

Inicialmente, Longs Peak debía finalizar en septiembre de 2007 bajo el nombre de OpenGL 3.0, pero el Grupo Khronos 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 Khronos Group 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 sombreado), 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 futuras revisiones. Como resultado, la API se mantuvo prácticamente igual con algunas extensiones existentes que se promocionaron a la funcionalidad principal.

Entre algunos grupos de desarrolladores, esta decisión causó algo de alboroto, y muchos desarrolladores afirmaron que se 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 al 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 instanciado 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 desactivarse por completo solicitando un contexto compatible con versiones posteriores del sistema de ventanas. Sin embargo, aún se puede acceder a las características de OpenGL 3.0 junto con estas características en desuso, solicitando un contexto completo .

Las características obsoletas incluyen:

  • Todo el procesamiento de vértices y fragmentos de función fija
  • Renderizado en modo directo, usando glBegin y glEnd
  • Mostrar listas
  • Objetivos de reproducción de colores indexados
  • OpenGL Shading Language 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 funciones que estaban en desuso 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 utilizando un contexto completo ni acceder a funciones obsoletas utilizando 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.

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ó en los mecanismos de obsolescencia introducidos por OpenGL 3.0, al dividir 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 centrales no. OpenGL 3.2 también incluyó una actualización a la versión 1.50 de GLSL.

OpenGL 3.3

Fecha de lanzamiento: 11 de marzo de 2010

Mesa es compatible con el controlador de software SWR, softpipe y tarjetas Nvidia más antiguas con NV50. D3D12 es una nueva emulación para la extensión Microsoft WSL para usar Direct 12.

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.

Como 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.

Soporte de hardware: Nvidia GeForce serie 400 y más reciente, AMD Radeon HD 5000 Series y más reciente (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Ivy Bridge y más nuevos.

OpenGL 4.1

Fecha de lanzamiento : 26 de julio de 2010

Soporte de hardware: Nvidia GeForce serie 400 y más reciente, AMD Radeon HD 5000 Series y más reciente (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Ivy Bridge y más nuevos.

  • El "tamaño máximo de textura" mínimo es 16.384 × 16.384 para las GPU que implementan esta especificación.

OpenGL 4.2

Fecha de lanzamiento: 8 de agosto de 2011

  • Compatibilidad con sombreadores con contadores atómicos y operaciones de carga, almacenamiento, lectura, modificación y escritura atómicas en un nivel de una textura.
  • Dibujar múltiples instancias de datos capturados del procesamiento de vértices de la GPU (incluida la teselación), para permitir que los objetos complejos se reposicionen y repliquen de manera eficiente
  • Soporte para modificar un subconjunto arbitrario de una textura comprimida, sin tener que volver a descargar toda la textura a la GPU para obtener mejoras de rendimiento significativas.

Soporte de 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 más reciente)

OpenGL 4.3

Fecha de lanzamiento: 6 de agosto de 2012

  • Compute shaders que aprovechan el paralelismo de la GPU dentro del contexto de la canalización de gráficos
  • Objetos de búfer de almacenamiento de sombreadores, lo que permite a los sombreadores leer y escribir objetos de búfer como carga / almacenamiento de imágenes desde 4.2, pero a través del lenguaje en lugar de llamadas a funciones.
  • Consultas de parámetros de formato de imagen
  • Compresión de textura ETC2 / EAC como característica estándar
  • Total compatibilidad con las API de OpenGL ES 3.0
  • Capacidad de depuración para recibir mensajes de depuración durante el desarrollo de la aplicación
  • Vistas de texturas para interpretar texturas de diferentes formas sin replicación de datos
  • Mayor seguridad de la memoria y solidez de múltiples aplicaciones

Soporte de hardware: AMD Radeon HD 5000 Series y más reciente (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Haswell y más nuevos. (Linux Mesa: Ivy Bridge sin texturizado 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 búfer reforzados
  • Consultas asincrónicas en objetos de búfer
  • Expresión de más controles de diseño de variables de interfaz en sombreadores
  • Enlace eficiente de varios objetos simultáneamente

Soporte de hardware: AMD Radeon HD 5000 Series y más reciente (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Broadwell y más nuevos (Linux Mesa: Haswell y más nuevos), Nvidia GeForce 400 series y más nuevos, Tegra K1 .

OpenGL 4.5

Fecha de lanzamiento: 11 de agosto de 2014

  • Acceso directo al estado (DSA): los accesadores de objetos permiten consultar y modificar el estado sin vincular objetos a contextos, para una mayor eficiencia y flexibilidad de aplicaciones y middleware.
  • Flush Control: las aplicaciones pueden controlar el vaciado de los comandos pendientes antes del cambio de contexto, lo que permite aplicaciones multiproceso de alto rendimiento;
  • Robustez: proporciona una plataforma segura para aplicaciones como los navegadores WebGL, incluida la prevención de que el reinicio de la GPU afecte a otras aplicaciones en ejecución;
  • Compatibilidad con la API y el sombreador de OpenGL ES 3.1: para permitir el desarrollo y la ejecución sencillos de las últimas aplicaciones de OpenGL ES en sistemas de escritorio.

Soporte de hardware: AMD Radeon HD 5000 Series y más reciente (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel HD Graphics en procesadores Intel Broadwell y más nuevos (Linux Mesa: Haswell y más nuevos), Nvidia GeForce 400 series y más nuevos, Tegra K1 , y Tegra X1.

OpenGL 4.6

Fecha de lanzamiento: 31 de julio de 2017

Soporte de hardware: AMD Radeon HD 7000 Series y más reciente (sombreadores FP64 implementados por emulación en algunas GPU TeraScale), Intel Haswell y más reciente, Nvidia GeForce 400 series y más reciente.

Soporte al conductor:

  • Mesa 19.2 en Linux es compatible con OpenGL 4.6 para Intel Broadwell y versiones posteriores. Mesa 20.0 es compatible con las GPU AMD Radeon, mientras que la compatibilidad con Nvidia Kepler + está en curso. Zink como controlador de emulación con 21.1 y el controlador de software LLVMpipe también son compatibles con Mesa 21.0.
  • Controlador de gráficos AMD Adrenalin 18.4.1 en Windows 7 SP1 , 10 versión 1803 (actualización de abril de 2018) para AMD Radeon ™ HD 7700+, HD 8500+ y posteriores. Publicado en abril de 2018.
  • Controlador de gráficos Intel 26.20.100.6861 en Windows 10 . Publicado en mayo de 2019.
  • Controlador de gráficos NVIDIA GeForce 397.31 en Windows 7 , 8 , 10 x86-64 bits solamente, no es compatible con 32 bits . Publicado en abril de 2018

Implementaciones alternativas

Apple desaprobó OpenGL en iOS 12 y macOS 10.14 Mojave a favor de Metal , pero todavía está disponible a partir de macOS 11 Big Sur (incluidos los dispositivos de silicona de Apple ). La última versión compatible con OpenGL es 4.1 de 2011. Una biblioteca patentada de Molten, autores de MoltenVK , llamada MoltenGL, puede traducir las 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 desaprobó las API de OpenGL en todas sus plataformas ( iOS , macOS y tvOS ), lo que alienta encarecidamente a los desarrolladores a utilizar su API de Metal patentada , que se introdujo en 2014.

Operation Systems Fuchsia y Stadia solo son compatibles con Vulkan

17 de septiembre de 2021 Valve eliminó OpenGL de Dota 2

Todos los juegos nuevos de 2016 basados ​​en el motor de juego ID Tech 6 utilizan Vulkan

El motor de juego ID Tech 7 solo es compatible con Vulkan

Atypical Games, con el apoyo de Samsung, asumió la tarea de implementar el soporte de Vulkan en su motor. Al final, quedó claro que la implementación de Vulkan reemplazará a OpenGL en todas las plataformas excepto Apple.

Vulkan

Artículo principal: Vulkan (API)

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

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

Ver también

Referencias

Otras lecturas

enlaces externos