OpenGL - OpenGL

OpenGL

Les jeux vidéo sous-traitent les calculs de rendu en temps réel au GPU via OpenGL. Les résultats rendus ne sont pas renvoyés vers la mémoire principale, mais vers le framebuffer de la mémoire vidéo. Le contrôleur d'affichage enverra ensuite ces données au dispositif d'affichage.
Auteur(s) original(aux)	Graphiques en silicone
Développeur(s)	Groupe Khronos (anciennement ARB )
Première version	30 juin 1992 ; il y a 29 ans ( 1992-06-30 )
Version stable	4.6 / 31 juillet 2017 ; il y a 4 ans ( 2017-07-31 )
Écrit en	C
Taper	API graphique 3D
Licence	Licence open source pour l'utilisation du SI : Il s'agit d'une licence de logiciel libre B étroitement calquée sur les licences BSD, X et Mozilla. Licence de marque pour les nouveaux titulaires de licence qui souhaitent utiliser la marque et le logo OpenGL et revendiquer la conformité.
Site Internet	opengl .org

OpenGL ( Bibliothèque Open Graphics ) est une croix de langue , multi-plateforme interface de programmation d'application (API) pour le rendu 2D et 3D graphiques vectoriels . L'API est généralement utilisée pour interagir avec une unité de traitement graphique (GPU) afin d'obtenir un rendu accéléré par le matériel .

Silicon Graphics, Inc. (SGI) a commencé à développer OpenGL en 1991 et l'a publié le 30 juin 1992 ; les applications l'utilisent largement dans les domaines de la conception assistée par ordinateur (CAO), de la réalité virtuelle , de la visualisation scientifique , de la visualisation de l' information, de la simulation de vol et des jeux vidéo . Depuis 2006, OpenGL est géré par le consortium technologique à but non lucratif Khronos Group .

Concevoir

Une illustration du processus de pipeline graphique

La spécification OpenGL décrit une API abstraite pour dessiner des graphiques 2D et 3D. Bien qu'il soit possible que l'API soit entièrement implémentée dans le logiciel, elle est conçue pour être implémentée principalement ou entièrement dans le matériel .

L'API est définie comme un ensemble de fonctions pouvant être appelées par le programme client, à côté d'un ensemble de constantes entières nommées (par exemple, la constante GL_TEXTURE_2D, qui correspond au nombre décimal 3553). Bien que les définitions des fonctions soient superficiellement similaires à celles du langage de programmation C , elles sont indépendantes du langage. En tant que tel, OpenGL possède de nombreuses liaisons linguistiques , certaines des plus remarquables étant la liaison JavaScript WebGL (API, basée sur OpenGL ES 2.0 , pour le rendu 3D à partir d'un navigateur Web ) ; les liaisons C WGL , GLX et CGL ; la liaison C fournie par iOS ; et les liaisons Java et C fournies par Android .

En plus d'être indépendant de la langue, OpenGL est également multiplateforme. La spécification ne dit rien au sujet de l'obtention et de la gestion d'un contexte OpenGL, laissant cela comme un détail du système de fenêtrage sous-jacent . Pour la même raison, OpenGL est purement concerné par le rendu, ne fournissant aucune API liée à l'entrée, à l'audio ou au fenêtrage.

Développement

OpenGL est une API activement développée. De nouvelles versions des spécifications OpenGL sont régulièrement publiées par le groupe Khronos , chacune étendant l'API pour prendre en charge diverses nouvelles fonctionnalités. Les détails de chaque version sont décidés par consensus entre les membres du groupe, y compris les fabricants de cartes graphiques, les concepteurs de systèmes d'exploitation et les sociétés technologiques générales telles que Mozilla et Google .

En plus des fonctionnalités requises par l'API principale, les fournisseurs d' unités de traitement graphique (GPU) peuvent fournir des fonctionnalités supplémentaires sous la forme d' extensions . Les extensions peuvent introduire de nouvelles fonctions et de nouvelles constantes, et peuvent assouplir ou supprimer les restrictions sur les fonctions OpenGL existantes. Les fournisseurs peuvent utiliser des extensions pour exposer des API personnalisées sans avoir besoin de l'assistance d'autres fournisseurs ou du groupe Khronos dans son ensemble, ce qui augmente considérablement la flexibilité d'OpenGL. Toutes les extensions sont collectées et définies par le registre OpenGL.

Chaque extension est associée à un identifiant court, basé sur le nom de l'entreprise qui l'a développée. Par exemple, l'identifiant de Nvidia est NV, qui fait partie du nom d'extension GL_NV_half_float, de la constante GL_HALF_FLOAT_NVet de la fonction glVertex2hNV(). Si plusieurs fournisseurs conviennent d'implémenter la même fonctionnalité en utilisant la même API, une extension partagée peut être publiée, en utilisant l'identifiant EXT. Dans de tels cas, il peut également arriver que l'Architecture Review Board du groupe Khronos donne son approbation explicite à l'extension, auquel cas l'identifiant ARB est utilisé.

Les fonctionnalités introduites par chaque nouvelle version d'OpenGL sont généralement formées à partir des fonctionnalités combinées de plusieurs extensions largement implémentées, en particulier des extensions de type ARB ou EXT.

Documentation

L'OpenGL Architecture Review Board a publié une série de manuels ainsi que les spécifications qui ont été mis à jour pour suivre les changements dans l'API. Ceux-ci sont communément désignés par les couleurs de leurs couvertures :

Le livre rouge

Guide de programmation OpenGL, 9e édition. ISBN  978-0-134-49549-1

Le guide officiel d'apprentissage d'OpenGL, version 4.5 avec SPIR-V

Le livre orange

OpenGL Shading Language, 3e édition. ISBN  0-321-63763-1

Un tutoriel et un livre de référence pour GLSL .

Livres historiques (pré-OpenGL 2.0) :

Le livre vert

Programmation OpenGL pour le système X Window. ISBN  978-0-201-48359-8

Un livre sur l'interfaçage X11 et OpenGL Utility Toolkit (GLUT).

Le livre bleu

Manuel de référence OpenGL, 4e édition. ISBN  0-321-17383-X

Essentiellement une copie papier des pages de manuel Unix (man) pour OpenGL.

Comprend un diagramme dépliant de la taille d'une affiche montrant la structure d'une implémentation OpenGL idéalisée.

L'Alpha Book (couverture blanche)

Programmation OpenGL pour Windows 95 et Windows NT. ISBN  0-201-40709-4

Un livre sur l'interfaçage d'OpenGL avec Microsoft Windows.

La documentation d'OpenGL est également accessible via sa page Web officielle.

Bibliothèques associées

Les premières versions d'OpenGL ont été publiées avec une bibliothèque associée appelée OpenGL Utility Library (GLU). Il fournissait des fonctionnalités simples et utiles qui étaient peu susceptibles d'être prises en charge par le matériel contemporain, telles que la tessellation , et la génération de mipmaps et de formes primitives . La spécification GLU a été mise à jour pour la dernière fois en 1998 et dépend des fonctionnalités OpenGL qui sont maintenant obsolètes .

Boîtes à outils contextuelles et fenêtres

Étant donné que la création d'un contexte OpenGL est un processus assez complexe et qu'il varie selon les systèmes d'exploitation , la création automatique de contexte OpenGL est devenue une caractéristique commune de plusieurs bibliothèques de développement de jeux et d'interfaces utilisateur , notamment SDL , Allegro , SFML , FLTK , et Qt . Quelques bibliothèques ont été conçues uniquement pour produire une fenêtre compatible OpenGL. La première bibliothèque de ce type était OpenGL Utility Toolkit (GLUT), plus tard remplacée par freeglut . GLFW est une alternative plus récente.

• Ces boîtes à outils sont conçues pour créer et gérer des fenêtres OpenGL et gérer les entrées, mais peu au-delà.

• GLFW – Un gestionnaire de fenêtrage multiplateforme et de manette clavier-souris-joystick ; est plus axé sur le jeu
• freeglut – Un fenêtrage multiplateforme et un gestionnaire clavier-souris ; son API est un sur-ensemble de l'API GLUT, et elle est plus stable et à jour que GLUT
• OpenGL Utility Toolkit (GLUT) – Un ancien gestionnaire de fenêtrage, qui n'est plus maintenu.

• Plusieurs "bibliothèques multimédias" peuvent créer des fenêtres OpenGL, en plus des tâches d'entrée, de son et d'autres utiles pour les applications de type jeu.

• Allegro 5 – Une bibliothèque multimédia multiplateforme avec une API C axée sur le développement de jeux
• Simple DirectMedia Layer (SDL) – Une bibliothèque multimédia multiplateforme avec une API C
• SFML – Une bibliothèque multimédia multiplateforme avec une API C++ et plusieurs autres liaisons vers des langages tels que C#, Java, Haskell et Go

• Boîtes à outils de widgets

• FLTK – Une petite bibliothèque de widgets C++ multiplateforme
• Qt – Une boîte à outils de widgets C++ multiplateforme. Il fournit de nombreux objets d'assistance OpenGL, qui font même abstraction de la différence entre le bureau GL et OpenGL ES
• wxWidgets – Une boîte à outils de widgets C++ multiplateforme

Bibliothèques de chargement d'extensions

Compte tenu de la charge de travail élevée impliquée dans l'identification et le chargement des extensions OpenGL, quelques bibliothèques ont été conçues pour charger automatiquement toutes les extensions et fonctions disponibles. Les exemples incluent GLEE , GLEW et glbinding . Les extensions sont également chargées automatiquement par la plupart des liaisons de langage, telles que JOGL et PyOpenGL .

Implémentations

Mesa 3D est une implémentation open source d'OpenGL. Il peut effectuer un rendu purement logiciel et peut également utiliser l'accélération matérielle sur BSD , Linux et d'autres plates-formes en tirant parti de l' infrastructure de rendu direct . Depuis la version 20.0, il implémente la version 4.6 du standard OpenGL.

Histoire

Dans les années 1980, le développement de logiciels pouvant fonctionner avec une large gamme de matériel graphique était un véritable défi. Les développeurs de logiciels ont écrit des interfaces et des pilotes personnalisés pour chaque élément matériel. Cela coûtait cher et entraînait une multiplication des efforts.

Au début des années 1990, Silicon Graphics (SGI) était un leader des graphiques 3D pour les postes de travail. Leur API IRIS GL est devenue la norme de l'industrie, plus largement utilisée que les PHIGS basés sur des normes ouvertes . C'était parce qu'IRIS GL était considéré comme plus facile à utiliser et parce qu'il prenait en charge le rendu en mode immédiat . En revanche, PHIGS était considéré comme difficile à utiliser et obsolète dans ses fonctionnalités.

Les concurrents de SGI (dont Sun Microsystems , Hewlett-Packard et IBM ) ont également été en mesure de mettre sur le marché du matériel 3D pris en charge par des extensions apportées à la norme PHIGS, ce qui a poussé SGI à ouvrir une version d'IrisGL en tant que norme publique appelée OpenGL .

Cependant, SGI avait de nombreux clients pour lesquels le passage d'IrisGL à OpenGL exigerait des investissements importants. De plus, IrisGL avait des fonctions API qui n'étaient pas pertinentes pour les graphiques 3D. Par exemple, elle comprenait un fenêtrage, le clavier et la souris API, en partie parce qu'il a été développé avant que le système X Window et Sun NeWS . De plus, les bibliothèques IrisGL ne convenaient pas à l'ouverture en raison de problèmes de licence et de brevet. Ces facteurs ont obligé SGI à continuer à prendre en charge les API de programmation avancées et propriétaires d' Iris Inventor et Iris Performer pendant que le support du marché pour OpenGL arrivait à maturité.

L'une des restrictions d'IrisGL était qu'il ne donnait accès qu'aux fonctionnalités prises en charge par le matériel sous-jacent. Si le matériel graphique ne prenait pas en charge une fonctionnalité nativement, l'application ne pouvait pas l'utiliser. OpenGL a surmonté ce problème en fournissant des implémentations logicielles de fonctionnalités non prises en charge par le matériel, permettant aux applications d'utiliser des graphiques avancés sur des systèmes relativement peu gourmands en énergie. OpenGL a normalisé l'accès au matériel, a poussé la responsabilité du développement des programmes d'interface matérielle ( pilotes de périphérique ) aux fabricants de matériel et a délégué les fonctions de fenêtrage au système d'exploitation sous-jacent. Avec autant de types différents de matériel graphique, leur faire parler le même langage de cette manière a eu un impact remarquable en offrant aux développeurs de logiciels une plate-forme de niveau supérieur pour le développement de logiciels 3D.

En 1992, SGI a dirigé la création de l' OpenGL Architecture Review Board (OpenGL ARB), le groupe de sociétés qui maintiendrait et étendrait la spécification OpenGL à l'avenir.

En 1994, SGI a joué avec l'idée de sortir quelque chose appelé " OpenGL++ " qui incluait des éléments tels qu'une API de graphes de scènes (vraisemblablement basée sur leur technologie Performer ). La spécification a circulé parmi quelques parties intéressées - mais n'a jamais été transformée en un produit.

Microsoft a publié Direct3D en 1995, qui est finalement devenu le principal concurrent d'OpenGL. Plus de 50 développeurs de jeux ont signé une lettre ouverte à Microsoft, publiée le 12 juin 1997, appelant la société à soutenir activement Open GL. Le 17 décembre 1997, Microsoft et SGI ont lancé le projet Fahrenheit , un effort conjoint dans le but d'unifier les interfaces OpenGL et Direct3D (et d'ajouter également une API de graphe de scène). En 1998, Hewlett-Packard a rejoint le projet. Il a d'abord montré une certaine promesse de mettre de l'ordre dans le monde des API d'infographie 3D interactives, mais en raison de contraintes financières chez SGI, de raisons stratégiques chez Microsoft et d'un manque général de soutien de l'industrie, il a été abandonné en 1999.

En juillet 2006, l'OpenGL Architecture Review Board a voté pour transférer le contrôle de la norme API OpenGL au groupe Khronos.

Historique des versions

La première version d'OpenGL, la version 1.0, a été publiée le 30 juin 1992 par Mark Segal et Kurt Akeley . Depuis lors, OpenGL a parfois été étendu en publiant une nouvelle version de la spécification. De telles versions définissent un ensemble de fonctionnalités de base que toutes les cartes graphiques conformes doivent prendre en charge et contre lesquelles de nouvelles extensions peuvent plus facilement être écrites. Chaque nouvelle version d'OpenGL a tendance à incorporer plusieurs extensions qui sont largement supportées par les fournisseurs de cartes graphiques, bien que les détails de ces extensions puissent être modifiés.

OpenGL 2.0

Date de sortie : 7 septembre 2004

OpenGL 2.0 a été conçu à l'origine par 3Dlabs pour répondre aux préoccupations selon lesquelles OpenGL stagnait et manquait d'une direction forte. 3Dlabs a proposé un certain nombre d'ajouts majeurs à la norme. La plupart d'entre eux ont été, à l'époque, rejetés par l'ARB ou ne se sont jamais concrétisés sous la forme proposée par 3Dlabs. Cependant, leur proposition d'un langage d'ombrage de style C a finalement été achevée, ce qui a donné lieu à la formulation actuelle du langage d'ombrage OpenGL ( GLSL ou GLslang). Comme les langages d'ombrage de type assembleur qu'il remplaçait, il permettait de remplacer le vertex à fonction fixe et le tuyau de fragment par des shaders , bien qu'écrits cette fois dans un langage de haut niveau de type C.

La conception de GLSL était remarquable pour faire relativement peu de concessions aux limites du matériel alors disponible. Cela revenait à la tradition antérieure d'OpenGL qui fixait un objectif ambitieux et prospectif pour les accélérateurs 3D plutôt que de simplement suivre l'état du matériel actuellement disponible. La spécification finale d'OpenGL 2.0 inclut la prise en charge de GLSL.

Longs Peak et OpenGL 3.0

Avant la sortie d'OpenGL 3.0, la nouvelle révision portait le nom de code Longs Peak . Au moment de son annonce initiale, Longs Peak a été présenté comme la première révision majeure de l'API dans la vie d'OpenGL. Il s'agissait d'une refonte du fonctionnement d'OpenGL, appelant à des changements fondamentaux de l'API.

Le projet a introduit un changement dans la gestion des objets. Le modèle objet GL 2.1 a été construit sur la conception basée sur l'état d'OpenGL. C'est-à-dire que pour modifier un objet ou l'utiliser, il faut lier l'objet au système d'états, puis apporter des modifications à l'état ou effectuer des appels de fonction qui utilisent l'objet lié.

En raison de l'utilisation par OpenGL d'un système d'état, les objets doivent être modifiables. C'est-à-dire que la structure de base d'un objet peut changer à tout moment, même si le pipeline de rendu utilise cet objet de manière asynchrone. Un objet texture peut être redéfini de 2D à 3D. Cela nécessite que toutes les implémentations OpenGL ajoutent un degré de complexité à la gestion des objets internes.

Sous l'API Longs Peak, la création d'objet deviendrait atomique , en utilisant des modèles pour définir les propriétés d'un objet qui serait créé avec un seul appel de fonction. L'objet pourrait alors être utilisé immédiatement sur plusieurs threads. Les objets seraient également immuables ; cependant, leur contenu pourrait être modifié et mis à jour. Par exemple, une texture peut changer son image, mais sa taille et son format ne peuvent pas être modifiés.

Pour prendre en charge la rétrocompatibilité, l'ancienne API basée sur l'état serait toujours disponible, mais aucune nouvelle fonctionnalité ne serait exposée via l'ancienne API dans les versions ultérieures d'OpenGL. Cela aurait permis aux bases de code héritées, telles que la majorité des produits de CAO , de continuer à fonctionner tandis que d'autres logiciels pourraient être écrits ou portés vers la nouvelle API.

Longs Peak devait initialement être finalisé en septembre 2007 sous le nom d'OpenGL 3.0, mais le groupe Khronos a annoncé le 30 octobre qu'il avait rencontré plusieurs problèmes qu'il souhaitait résoudre avant de publier la spécification. En conséquence, la spécification a été retardée et le groupe Khronos est entré dans un black-out médiatique jusqu'à la publication de la spécification finale d'OpenGL 3.0.

La spécification finale s'est avérée beaucoup moins révolutionnaire que la proposition de Longs Peak. Au lieu de supprimer tout le mode immédiat et les fonctionnalités fixes (mode sans shader), la spécification les incluait en tant que fonctionnalités obsolètes. Le modèle d'objet proposé n'a pas été inclus et aucun plan n'a été annoncé pour l'inclure dans des révisions futures. En conséquence, l'API est restée en grande partie la même, quelques extensions existantes étant promues au cœur des fonctionnalités.

Parmi certains groupes de développeurs, cette décision a provoqué un tollé, de nombreux développeurs déclarant qu'ils passeraient à DirectX en signe de protestation. La plupart des plaintes concernaient le manque de communication de Khronos avec la communauté du développement et le rejet de plusieurs fonctionnalités qui étaient considérées favorablement par beaucoup. D'autres frustrations comprenaient l'exigence d'un matériel de niveau DirectX 10 pour utiliser OpenGL 3.0 et l'absence de shaders de géométrie et de rendu instancié comme fonctionnalités de base.

D'autres sources ont signalé que la réaction de la communauté n'était pas aussi sévère que celle présentée à l'origine, de nombreux fournisseurs montrant leur soutien à la mise à jour.

OpenGL 3.0

Date de sortie : 11 août 2008

OpenGL 3.0 a introduit un mécanisme de dépréciation pour simplifier les futures révisions de l'API. Certaines fonctionnalités, marquées comme obsolètes, pourraient être complètement désactivées en demandant un contexte de compatibilité ascendante au système de fenêtrage. Les fonctionnalités d'OpenGL 3.0 peuvent toujours être accessibles en plus de ces fonctionnalités obsolètes, cependant, en demandant un contexte complet .

Les fonctionnalités obsolètes incluent :

• Tout le traitement des sommets et des fragments à fonction fixe
• Rendu en mode direct, utilisant glBegin et glEnd
• Afficher les listes
• Cibles de rendu des couleurs indexées
• OpenGL Shading Language versions 1.10 et 1.20

OpenGL 3.1

Date de sortie : 24 mars 2009

OpenGL 3.1 a complètement supprimé toutes les fonctionnalités qui étaient dépréciées dans la version 3.0, à l'exception des lignes larges. À partir de cette version, il n'est plus possible d'accéder aux nouvelles fonctionnalités à l'aide d'un contexte complet ou d'accéder aux fonctionnalités obsolètes à l'aide d'un contexte à compatibilité ascendante . Une exception à la première règle est faite si l'implémentation prend en charge l' extension ARB_compatibility , mais cela n'est pas garanti.

Matériel : Mesa prend en charge ARM Panfrost avec la version 21.0.

OpenGL 3.2

Date de sortie : 3 août 2009

OpenGL 3.2 s'appuie sur les mécanismes de dépréciation introduits par OpenGL 3.0, en divisant la spécification en un profil de base et un profil de compatibilité . Les contextes de compatibilité incluent les API à fonction fixe précédemment supprimées, équivalentes à l'extension ARB_compatibility publiée avec OpenGL 3.1, contrairement aux contextes de base. OpenGL 3.2 incluait également une mise à niveau vers GLSL version 1.50.

OpenGL 3.3

Date de sortie : 11 mars 2010

Mesa prend en charge le logiciel Driver SWR, softpipe et pour les anciennes cartes Nvidia avec NV50. D3D12 est une nouvelle émulation pour l'extension Microsoft WSL permettant d'utiliser Direct 12.

OpenGL 4.0

Date de sortie : 11 mars 2010

OpenGL 4.0 a été publié avec la version 3.3. Il a été conçu pour du matériel capable de prendre en charge Direct3D 11.

Comme dans OpenGL 3.0, cette version d'OpenGL contient un grand nombre d'extensions assez insignifiantes, conçues pour exposer en profondeur les capacités du matériel de classe Direct3D 11. Seules les extensions les plus influentes sont répertoriées ci-dessous.

Prise en charge matérielle : Nvidia GeForce 400 et plus récent, AMD Radeon HD 5000 et plus récent (shaders FP64 implémentés par émulation sur certains GPU TeraScale), Intel HD Graphics dans les processeurs Intel Ivy Bridge et plus récents.

OpenGL 4.1

Date de sortie : 26 juillet 2010

Prise en charge matérielle : Nvidia GeForce 400 et plus récent, AMD Radeon HD 5000 et plus récent (shaders FP64 implémentés par émulation sur certains GPU TeraScale), Intel HD Graphics dans les processeurs Intel Ivy Bridge et plus récents.

• La « taille de texture maximale » minimale est de 16 384 × 16 384 pour la mise en œuvre de cette spécification par le GPU.

OpenGL 4.2

Date de sortie : 8 août 2011

• Prise en charge des shaders avec des compteurs atomiques et des opérations de lecture-modification-écriture de chargement-stockage-atomique à un niveau d'une texture
• Dessiner plusieurs instances de données capturées à partir du traitement des sommets GPU (y compris la tessellation), pour permettre le repositionnement et la réplication efficaces d'objets complexes
• Prise en charge de la modification d'un sous-ensemble arbitraire d'une texture compressée, sans avoir à retélécharger la totalité de la texture sur le GPU pour des améliorations significatives des performances

Prise en charge matérielle : Nvidia GeForce 400 et plus récent, AMD Radeon HD 5000 et plus récent (shaders FP64 implémentés par émulation sur certains GPU TeraScale) et Intel HD Graphics dans les processeurs Intel Haswell et plus récents. (Linux Mesa : Ivy Bridge et plus récent)

OpenGL 4.3

Date de sortie : 6 août 2012

• Nuanceurs de calcul tirant parti du parallélisme GPU dans le contexte du pipeline graphique
• Objets tampons de stockage de shaders, permettant aux shaders de lire et d'écrire des objets tampons comme le chargement/stockage d'images à partir de 4.2, mais via le langage plutôt que des appels de fonction.
• Requêtes de paramètres de format d'image
• Compression de texture ETC2/EAC en standard
• Compatibilité totale avec OpenGL ES 3.0 API
• Capacités de débogage pour recevoir des messages de débogage pendant le développement de l'application
• Vues de texture pour interpréter les textures de différentes manières sans réplication des données
• Sécurité mémoire accrue et robustesse multi-applications

Prise en charge matérielle : AMD Radeon HD 5000 Series et plus récent (shaders FP64 implémentés par émulation sur certains GPU TeraScale), Intel HD Graphics dans les processeurs Intel Haswell et plus récents. (Linux Mesa : Ivy Bridge sans texture au pochoir, Haswell et plus récent), Nvidia GeForce 400 et plus récent. L'émulation VIRGL pour machines virtuelles prend en charge 4.3+ avec Mesa 20.

OpenGL 4.4

Date de sortie : 22 juillet 2013

• Contrôles d'utilisation des objets tampons appliqués
• Requêtes asynchrones dans les objets tampons
• Expression de plus de contrôles de disposition des variables d'interface dans les shaders
• Liaison efficace de plusieurs objets simultanément

Prise en charge matérielle : AMD Radeon HD 5000 Series et plus récents (shaders FP64 implémentés par émulation sur certains GPU TeraScale), Intel HD Graphics dans les processeurs Intel Broadwell et plus récents (Linux Mesa : Haswell et plus récents), Nvidia GeForce 400 et plus récents, Tegra K1 .

OpenGL 4.5

Date de sortie : 11 août 2014

• Accès direct à l'état (DSA) - les accesseurs d'objet permettent d'interroger et de modifier l'état sans lier les objets aux contextes, pour une efficacité et une flexibilité accrues des applications et des middleware.
• Contrôle de vidage – les applications peuvent contrôler le vidage des commandes en attente avant le changement de contexte – permettant des applications multithread hautes performances ;
• Robustesse - fournir une plate-forme sécurisée pour les applications telles que les navigateurs WebGL, y compris empêcher une réinitialisation du GPU affectant toute autre application en cours d'exécution ;
• Compatibilité API OpenGL ES 3.1 et shader - pour faciliter le développement et l'exécution des dernières applications OpenGL ES sur les systèmes de bureau.

Prise en charge matérielle : AMD Radeon HD 5000 Series et plus récents (shaders FP64 implémentés par émulation sur certains GPU TeraScale), Intel HD Graphics dans les processeurs Intel Broadwell et plus récents (Linux Mesa : Haswell et plus récents), Nvidia GeForce 400 et plus récents, Tegra K1 , et Tegra X1.

OpenGL 4.6

Date de sortie : 31 juillet 2017

• traitement de la géométrie plus efficace, côté GPU
• exécution plus efficace des shaders ( AZDO )
• plus d'informations via les statistiques, les requêtes de débordement et les compteurs
• des performances supérieures grâce à l'absence de contextes de gestion des erreurs
• serrage de la fonction de décalage de polygone , résout un problème de rendu d'ombre
• SPIR-V shader
• Filtrage anisotrope amélioré

Support matériel : AMD Radeon HD 7000 Series et plus récent (shaders FP64 implémentés par émulation sur certains GPU TeraScale), Intel Haswell et plus récent, Nvidia GeForce 400 et plus récent.

Prise en charge des pilotes :

• Mesa 19.2 sur Linux prend en charge OpenGL 4.6 pour Intel Broadwell et plus récent. Mesa 20.0 prend en charge les GPU AMD Radeon, tandis que la prise en charge de Nvidia Kepler+ est en cours. Zink en tant que pilote d'émulation avec 21.1 et le pilote logiciel LLVMpipe sont également pris en charge avec Mesa 21.0.
• Pilote graphique AMD Adrenalin 18.4.1 sur Windows 7 SP1 , 10 version 1803 (mise à jour d'avril 2018) pour AMD Radeon™ HD 7700+, HD 8500+ et versions ultérieures. Sortie en avril 2018.
• Pilote graphique Intel 26.20.100.6861 sous Windows 10 . Sortie en mai 2019.
• Pilote graphique NVIDIA GeForce 397.31 sous Windows 7 , 8 , 10 x86-64 bits uniquement, pas de prise en charge 32 bits . Sortie en avril 2018

Implémentations alternatives

Apple a déprécié OpenGL dans iOS 12 et macOS 10.14 Mojave au profit de Metal , mais il est toujours disponible à partir de macOS 11 Big Sur (y compris les appareils en silicium Apple ). La dernière version prise en charge pour OpenGL est la 4.1 à partir de 2011. Une bibliothèque propriétaire de Molten – les auteurs de MoltenVK – appelée MoltenGL, peut traduire les appels OpenGL en Metal.

Il existe plusieurs projets qui tentent d'implémenter OpenGL sur Vulkan. Le backend Vulkan pour ANGLE de Google a atteint la conformité OpenGL ES 3.1 en juillet 2020. Le projet Mesa3D comprend également un tel pilote, appelé Zink .

L'avenir d'OpenGL

En juin 2018, Apple a déprécié les API OpenGL sur toutes ses plateformes ( iOS , macOS et tvOS ), encourageant fortement les développeurs à utiliser leur API propriétaire Metal , introduite en 2014.

Les systèmes d'exploitation Fuchsia et Stadia prennent en charge Vulkan uniquement

17 septembre 2021 Valve a retiré OpenGL de Dota 2

Tous les nouveaux jeux de 2016 basés sur le moteur de jeu ID Tech 6 utilisent Vulkan

Le moteur de jeu ID Tech 7 prend en charge Vulkan uniquement

Atypical Games, avec le soutien de Samsung, a pris en charge la mise en œuvre du support Vulkan dans leur moteur. En fin de compte, il est devenu clair que la mise en œuvre de Vulkan remplacera en fait OpenGL sur toutes les plates-formes autres qu'Apple.

Vulkan

Vulkan, anciennement nommé "Next Generation OpenGL Initiative" (glNext), est un effort de refonte de fond pour unifier OpenGL et OpenGL ES en une seule API commune qui ne sera pas rétrocompatible avec les versions OpenGL existantes.

La version initiale de l'API Vulkan a été publiée le 16 février 2016.

Voir également

• Langage d'assemblage ARB - Le langage d'ombrage de bas niveau hérité d'OpenGL
• Comparaison d'OpenGL et de Direct3D
• Direct3D – principal concurrent d'OpenGL
• Glide API – une API graphique autrefois utilisée sur les cartes 3dfx Voodoo
• Liste des applications OpenGL
• Metal (API) – une API graphique pour iOS, macOS, tvOS, watchOS
• OpenAL - bibliothèque audio multiplateforme, conçue pour ressembler à OpenGL
• OpenGL ES – OpenGL pour les systèmes embarqués
• OpenSL ES - API pour l'audio sur les systèmes embarqués, développée par le groupe Khronos
• OpenVG - API pour les graphiques 2D accélérés, développé par le groupe Khronos
• RenderMan Interface Specification (RISpec) - API ouverte de Pixar pour un rendu photoréaliste hors ligne
• VOGL – un débogueur pour OpenGL
• Vulkan – API graphique 2D et 3D multiplateforme à faible surcharge, « l'initiative OpenGL de nouvelle génération »
• Pipeline graphique
• WebGPU

Les références

Lectures complémentaires

• Shreiner, Dave ; Vendeurs, Graham ; et al. (30 mars 2013). Guide de programmation OpenGL : Le guide officiel d'apprentissage d'OpenGL . Version 4.3 (8e éd.). Addison-Wesley. ISBN 978-0-321-77303-6.
• Vendeurs, Graham ; Wright, Richard S.; Haemel, Nicholas (31 juillet 2013). OpenGL SuperBible : Tutoriel complet et référence (6e éd.). Addison-Wesley. ISBN 978-0-321-90294-8.
• Rost, Randi J. (30 juillet 2009). OpenGL Shading Language (3e éd.). Addison-Wesley. ISBN 978-0-321-63763-5.
• Lengyel, Éric (2003). Le guide des extensions OpenGL . Charles River Media. ISBN 1-58450-294-0.
• Conseil d'examen de l'architecture OpenGL ; Shreiner, Dave (2004). Manuel de référence OpenGL : Le document de référence officiel d'OpenGL . Version 1.4. Addison-Wesley. ISBN 0-321-17383-X.
• Conseil d'examen de l'architecture OpenGL ; Shreiner, Dave ; et al. (2006). Guide de programmation OpenGL : Le guide officiel d'apprentissage d'OpenGL . Version 2 (5e éd.). Addison-Wesley. ISBN 0-321-33573-2.

Liens externes

• Site officiel
• Présentation d'OpenGL et Wiki d' OpenGL.org avec plus d'informations sur les liaisons du langage OpenGL
• Le site Web OpenGL de SGI
• OpenGL chez Curlie
• Groupe Khronos, Inc.
• Angel, Edward & Shreiner, Dave (2013). "Une introduction à la programmation OpenGL" . YouTube . Université SIGGRAPH.