OpenGL - OpenGL

Nicht zu verwechseln mit OpenCL .

OpenGL
OpenGL-Logo (2D).svg
Linux-Kernel und OpenGL-Videospiele.svg
Videospiele lagern Echtzeit-Rendering-Berechnungen über OpenGL an die GPU aus . Die gerenderten Ergebnisse werden nicht an den Hauptspeicher zurückgesendet, sondern stattdessen an den Framebuffer des Videospeichers. Der Anzeigecontroller sendet diese Daten dann an das Anzeigegerät.
Originalautor(en) Silizium-Grafik
Entwickler Khronos-Gruppe
(ehemals ARB )
Erstveröffentlichung 30. Juni 1992 ; vor 29 Jahren ( 1992-06-30 )
Stabile Version
4.6 / 31. Juli 2017 ; vor 4 Jahren ( 2017-07-31 )
Geschrieben in C
Typ 3D-Grafik- API
Lizenz
  • Open-Source- Lizenz zur Nutzung der SI: Dies ist eine Freie Software-Lizenz B, die stark an BSD-, X- und Mozilla-Lizenzen angelehnt ist.
  • Markenlizenz für neue Lizenznehmer, die die OpenGL-Marke und das Logo verwenden und die Konformität beanspruchen möchten.
Webseite opengl .org

OpenGL ( Open Graphics Library ) ist eine sprach- und plattformübergreifende Anwendungsprogrammierschnittstelle (API) zum Rendern von 2D- und 3D- Vektorgrafiken . Die API wird normalerweise verwendet, um mit einer Grafikverarbeitungseinheit (GPU) zu interagieren , um ein hardwarebeschleunigtes Rendering zu erreichen .

Silicon Graphics, Inc. (SGI) begann 1991 mit der Entwicklung von OpenGL und veröffentlichte es am 30. Juni 1992; Anwendungen verwenden es umfassend in den Bereichen Computer-Aided Design (CAD), Virtual Reality , wissenschaftliche Visualisierung , Informationsvisualisierung, Flugsimulation und Videospiele . Seit 2006 hat OpenGL durch das verwaltete Non-Profit - Technologie Konsortium Khronos Group .

Entwurf

Eine Illustration des Grafik-Pipeline-Prozesses

Die OpenGL-Spezifikation beschreibt eine abstrakte API zum Zeichnen von 2D- und 3D-Grafiken. Obwohl es möglich ist, die API vollständig in Software zu implementieren, ist sie so konzipiert, dass sie größtenteils oder vollständig in Hardware implementiert wird .

Die API ist definiert als ein Satz von Funktionen, der vom Client-Programm aufgerufen werden kann, zusammen mit einem Satz benannter Integer-Konstanten (zum Beispiel die Konstante GL_TEXTURE_2D, die der Dezimalzahl 3553 entspricht). Obwohl die Funktionsdefinitionen denen der Programmiersprache C oberflächlich ähnlich sind, sind sie sprachunabhängig. Als solches hat OpenGL viele Sprachbindungen , von denen einige die bemerkenswertesten sind die JavaScript- Bindung WebGL (API, basierend auf OpenGL ES 2.0 , für 3D-Rendering aus einem Webbrowser heraus ); die C-Bindungen WGL , GLX und CGL ; die von iOS bereitgestellte C-Bindung ; und die von Android bereitgestellten Java- und C-Bindungen .

OpenGL ist nicht nur sprachunabhängig, sondern auch plattformübergreifend. Die Spezifikation sagt nichts zum Thema Erhalten und Verwalten eines OpenGL-Kontexts aus und belässt dies als Detail des zugrunde liegenden Fenstersystems . Aus dem gleichen Grund befasst sich OpenGL ausschließlich mit dem Rendern und bietet keine APIs für Eingabe, Audio oder Windowing.

Entwicklung

OpenGL ist eine aktiv entwickelte API. Von der Khronos Group werden regelmäßig neue Versionen der OpenGL-Spezifikationen veröffentlicht , die jeweils die API erweitern, um verschiedene neue Funktionen zu unterstützen. Die Details jeder Version werden im Konsens zwischen den Mitgliedern der Gruppe festgelegt, darunter Grafikkartenhersteller, Betriebssystemdesigner und allgemeine Technologieunternehmen wie Mozilla und Google .

Zusätzlich zu den von der Kern-API benötigten Funktionen können Anbieter von Grafikprozessoren (GPU) zusätzliche Funktionen in Form von Erweiterungen bereitstellen . Erweiterungen können neue Funktionen und neue Konstanten einführen und können Einschränkungen für bestehende OpenGL-Funktionen lockern oder entfernen. Anbieter können Erweiterungen verwenden, um benutzerdefinierte APIs bereitzustellen, ohne Unterstützung von anderen Anbietern oder der Khronos-Gruppe insgesamt zu benötigen, was die Flexibilität von OpenGL erheblich erhöht. Alle Erweiterungen werden in der OpenGL-Registrierung gesammelt und von ihr definiert.

Jede Erweiterung ist mit einer kurzen Kennung verbunden, die auf dem Namen des Unternehmens basiert, das sie entwickelt hat. Der Bezeichner von Nvidia ist beispielsweise NV, der Teil des Erweiterungsnamens GL_NV_half_float, der Konstante GL_HALF_FLOAT_NVund der Funktion ist glVertex2hNV(). Wenn mehrere Anbieter zustimmen, dieselbe Funktionalität unter Verwendung derselben API zu implementieren, kann eine gemeinsame Erweiterung unter Verwendung der Kennung EXT freigegeben werden. In solchen Fällen kann es auch vorkommen, dass das Architecture Review Board der Khronos Group der Erweiterung seine ausdrückliche Zustimmung erteilt, in welchem ​​Fall die Kennung ARB verwendet wird.

Die von jeder neuen Version von OpenGL eingeführten Funktionen werden typischerweise aus den kombinierten Funktionen mehrerer weit verbreiteter Erweiterungen gebildet, insbesondere Erweiterungen des Typs ARB oder EXT.

Dokumentation

Das OpenGL Architecture Review Board hat eine Reihe von Handbüchern zusammen mit der Spezifikation veröffentlicht, die aktualisiert wurden, um Änderungen in der API zu verfolgen. Diese werden im Allgemeinen durch die Farben ihrer Abdeckungen bezeichnet:

Das Rote Buch
OpenGL-Programmierhandbuch, 9. Auflage. ISBN  978-0-134-49549-1
Der offizielle Leitfaden zum Erlernen von OpenGL, Version 4.5 mit SPIR-V
Das orange Buch
OpenGL Shading Language, 3. Auflage. ISBN  0-321-63763-1
Ein Tutorial und Nachschlagewerk für GLSL .

Historische Bücher (vor OpenGL 2.0):

Das Grüne Buch
OpenGL-Programmierung für das X Window-System. ISBN  978-0-201-48359-8
Ein Buch über X11-Schnittstellen und OpenGL Utility Toolkit (GLUT).
Das blaue Buch
OpenGL-Referenzhandbuch, 4. Auflage. ISBN  0-321-17383-X
Im Wesentlichen ein gedruckter Ausdruck der Unix-Handbuchseiten (man-Seiten für OpenGL).
Enthält ein ausklappbares Diagramm in Postergröße, das die Struktur einer idealisierten OpenGL-Implementierung zeigt.
Das Alpha-Buch (weißer Umschlag)
OpenGL-Programmierung für Windows 95 und Windows NT. ISBN  0-201-40709-4
Ein Buch über die Anbindung von OpenGL an Microsoft Windows.

Die Dokumentation von OpenGL ist auch über die offizielle Webseite zugänglich.

Zugehörige Bibliotheken

Die frühesten Versionen von OpenGL wurden mit einer Begleitbibliothek namens OpenGL Utility Library (GLU) veröffentlicht. Es stellte einfache, nützliche Funktionen bereit, die von moderner Hardware wahrscheinlich nicht unterstützt würden, wie zum Beispiel Tessellation und das Generieren von Mipmaps und primitiven Formen . Die GLU-Spezifikation wurde zuletzt 1998 aktualisiert und hängt von OpenGL-Funktionen ab, die jetzt veraltet sind .

Kontext- und Fenster-Toolkits

Da einen OpenGL - Kontext zu schaffen ist ein ziemlich komplexer Prozess, und da sie variiert zwischen Betriebssystemen , automatischen OpenGL Kontext Schöpfung ein gemeinsames Merkmal von mehreren Spiel-Entwicklung und User-Interface wurde Bibliotheken , einschließlich SDL , Allegro , SFML , FLTK , und Qt . Einige Bibliotheken wurden ausschließlich entwickelt, um ein OpenGL-fähiges Fenster zu erzeugen. Die erste Bibliothek dieser Art war das OpenGL Utility Toolkit (GLUT), das später von freeglut abgelöst wurde . GLFW ist eine neuere Alternative.

  • Diese Toolkits wurden entwickelt, um OpenGL-Fenster zu erstellen und zu verwalten und Eingaben zu verwalten, aber wenig darüber hinaus.
  • GLFW – Ein plattformübergreifender Windowing- und Tastatur-Maus-Joystick-Handler; ist spielorientierter
  • freeglut – Ein plattformübergreifender Windowing- und Tastatur-Maus-Handler; seine API ist eine Obermenge der GLUT-API und ist stabiler und aktueller als GLUT
  • OpenGL Utility Toolkit (GLUT) – Ein alter Windowing-Handler, der nicht mehr gepflegt wird.
  • Mehrere "Multimedia-Bibliotheken" können OpenGL-Fenster erstellen, zusätzlich zu Eingabe-, Sound- und anderen Aufgaben, die für spielähnliche Anwendungen nützlich sind
  • Allegro 5 – Eine plattformübergreifende Multimedia-Bibliothek mit einer C-API, die sich auf die Spieleentwicklung konzentriert
  • Simple DirectMedia Layer (SDL) – Eine plattformübergreifende Multimediabibliothek mit einer C-API
  • SFML – Eine plattformübergreifende Multimediabibliothek mit einer C++-API und mehreren anderen Bindungen an Sprachen wie C#, Java, Haskell und Go
  • Widget-Toolkits
  • FLTK – Eine kleine plattformübergreifende C++-Widget-Bibliothek
  • Qt – Ein plattformübergreifendes C++-Widget-Toolkit. Es bietet viele OpenGL-Hilfsobjekte, die sogar den Unterschied zwischen Desktop-GL und OpenGL ES abstrahieren
  • wxWidgets – Ein plattformübergreifendes C++-Widget-Toolkit

Laden von Bibliotheken für Erweiterungen

Angesichts des hohen Arbeitsaufwands beim Identifizieren und Laden von OpenGL-Erweiterungen wurden einige Bibliotheken entwickelt, die alle verfügbaren Erweiterungen und Funktionen automatisch laden. Beispiele sind GLEE , GLEW und glbinding . Erweiterungen werden auch von den meisten Sprachbindungen wie JOGL und PyOpenGL automatisch geladen .

Implementierungen

Mesa 3D ist eine Open-Source- Implementierung von OpenGL. Es kann reines Software-Rendering durchführen und kann auch Hardwarebeschleunigung auf BSD , Linux und anderen Plattformen verwenden, indem es die Direct Rendering Infrastructure nutzt . Ab Version 20.0 implementiert es Version 4.6 des OpenGL-Standards.

Geschichte

In den 1980er Jahren war es eine echte Herausforderung, Software zu entwickeln, die mit einer Vielzahl von Grafikhardware funktioniert. Softwareentwickler schrieben benutzerdefinierte Schnittstellen und Treiber für jede Hardware. Dies war teuer und führte zu einer Vervielfachung des Aufwands.

In den frühen 1990er Jahren war Silicon Graphics (SGI) führend bei 3D-Grafiken für Workstations. Ihre IRIS GL API wurde zum Industriestandard und wird weiter verbreitet als das auf offenen Standards basierende PHIGS . Das lag daran , IRIS GL wurde leichter als zu bedienen, und weil es unterstützt unmittelbaren Modus Rendering. Im Gegensatz dazu galt PHIGS als schwierig zu bedienen und in seiner Funktionalität veraltet.

Die Konkurrenten von SGI (darunter Sun Microsystems , Hewlett-Packard und IBM ) waren ebenfalls in der Lage, 3D-Hardware auf den Markt zu bringen, die durch Erweiterungen des PHIGS-Standards unterstützt wird, was SGI dazu drängte, eine Version von IrisGL als öffentlichen Standard namens OpenGL zu öffnen .

SGI hatte jedoch viele Kunden, für die der Wechsel von IrisGL zu OpenGL erhebliche Investitionen erfordern würde. Darüber hinaus hatte IrisGL API-Funktionen, die für 3D-Grafiken irrelevant waren. Zum Beispiel enthielt es eine Fenster-, Tastatur- und Maus-API, teilweise weil es vor dem X Window System und Suns NeWS entwickelt wurde . Außerdem waren IrisGL-Bibliotheken aufgrund von Lizenz- und Patentproblemen nicht zum Öffnen geeignet. Diese Faktoren erforderten, dass SGI weiterhin die fortschrittlichen und proprietären Programmier-APIs Iris Inventor und Iris Performer unterstützte, während die Marktunterstützung für OpenGL ausgereift war.

Eine der Einschränkungen von IrisGL bestand darin, dass es nur Zugriff auf Funktionen bot, die von der zugrunde liegenden Hardware unterstützt wurden. Wenn die Grafikhardware eine Funktion nicht nativ unterstützt, kann die Anwendung sie nicht verwenden. OpenGL überwand dieses Problem, indem es Softwareimplementierungen von Funktionen bereitstellte, die von der Hardware nicht unterstützt werden, wodurch Anwendungen erweiterte Grafiken auf Systemen mit relativ geringer Leistung verwenden können. OpenGL standardisierte den Zugriff auf Hardware, verlagerte die Entwicklungsverantwortung für Hardware-Schnittstellenprogramme ( Gerätetreiber ) an Hardwarehersteller und delegierte Fensterfunktionen an das zugrunde liegende Betriebssystem. Bei so vielen verschiedenen Arten von Grafikhardware hatte es einen bemerkenswerten Einfluss, sie alle auf diese Weise dazu zu bringen, dieselbe Sprache zu sprechen, indem Softwareentwicklern eine übergeordnete Plattform für die 3D-Softwareentwicklung zur Verfügung gestellt wurde.

1992 leitete SGI die Gründung des OpenGL Architecture Review Board (OpenGL ARB), der Unternehmensgruppe, die die OpenGL-Spezifikation in Zukunft pflegen und erweitern sollte.

1994 spielte SGI mit der Idee, etwas namens " OpenGL++ " zu veröffentlichen, das Elemente wie eine Szenengraph-API (vermutlich basierend auf ihrer Performer- Technologie) enthielt . Die Spezifikation wurde unter einigen Interessenten zirkuliert – aber nie in ein Produkt umgesetzt.

1995 veröffentlichte Microsoft Direct3D , das schließlich zum Hauptkonkurrenten von OpenGL wurde. Über 50 Spieleentwickler unterzeichneten einen offenen Brief an Microsoft, der am 12. Juni 1997 veröffentlicht wurde und das Unternehmen aufforderte, Open GL aktiv zu unterstützen. Am 17. Dezember 1997 initiierten Microsoft und SGI das Fahrenheit- Projekt, das eine gemeinsame Anstrengung mit dem Ziel war, die OpenGL- und Direct3D-Schnittstellen zu vereinheitlichen (und auch eine Szenengraph-API hinzuzufügen). 1998 trat Hewlett-Packard dem Projekt bei. Es war zunächst vielversprechend, um Ordnung in die Welt der interaktiven 3D-Computergrafik-APIs zu bringen, aber aufgrund finanzieller Zwänge bei SGI, strategischer Gründe bei Microsoft und eines allgemeinen Mangels an Unterstützung durch die Industrie wurde es 1999 aufgegeben.

Im Juli 2006 stimmte das OpenGL Architecture Review Board dafür, die Kontrolle über den OpenGL API-Standard an die Khronos Group zu übertragen.

Versionsgeschichte

Die erste Version von OpenGL, Version 1.0, wurde am 30. Juni 1992 von Mark Segal und Kurt Akeley veröffentlicht . Seitdem wurde OpenGL gelegentlich durch die Veröffentlichung einer neuen Version der Spezifikation erweitert. Solche Releases definieren einen grundlegenden Satz von Funktionen, die alle konformen Grafikkarten unterstützen müssen und gegen die neue Erweiterungen leichter geschrieben werden können. Jede neue Version von OpenGL enthält in der Regel mehrere Erweiterungen, die von Grafikkartenherstellern weit verbreitet sind, obwohl die Details dieser Erweiterungen geändert werden können.

OpenGL-Versionsverlauf
Ausführung Veröffentlichungsdatum Merkmale
1.1 4. März 1997 Texturobjekte, Vertex-Arrays
1,2 16. März 1998 3D-Texturen, BGRA- und gepackte Pixelformate , Einführung des für Bildverarbeitungsanwendungen nützlichen Imaging- Subsets
1.2.1 14. Oktober 1998 Ein Konzept von ARB-Erweiterungen
1.3 14. August 2001 Multitexturing , Multisampling, Texturkompression
1,4 24. Juli 2002 Tiefentexturen, GLSlang
1,5 29. Juli 2003 Vertex Buffer Object (VBO), Okklusionsabfragen
2.0 7. September 2004 GLSL 1.1, MRT , Non-Power-of-Two-Texturen, Point Sprites, Zweiseitige Schablone
2.1 2. Juli 2006 GLSL 1.2, Pixel Buffer Object (PBO), sRGB-Texturen
3.0 11. August 2008 GLSL 1.3, Texturarrays, Bedingtes Rendering, Frame Buffer Object (FBO)
3.1 24. März 2009 GLSL 1.4, Instancing, Texture Buffer Object, Uniform Buffer Object, Primitive Restart
3.2 3. August 2009 GLSL 1.5, Geometry Shader, Multi-Sampled-Texturen
3.3 11. März 2010 GLSL 3.30, Backportiert so viele Funktionen wie möglich aus der OpenGL 4.0-Spezifikation
4.0 11. März 2010 GLSL 4.00, Tessellation auf GPU, Shader mit 64-Bit-Präzision
4.1 26. Juli 2010 GLSL 4.10, Entwicklerfreundliche Debug-Ausgaben, Kompatibilität mit OpenGL ES 2.0
4.2 8. August 2011 GLSL 4.20, Shader mit atomaren Zählern, instanziiertes Draw-Transform-Feedback, Shader-Packing, Leistungsverbesserungen
4.3 6. August 2012 GLSL 4.30, Compute-Shader, die GPU-Parallelität nutzen, Shader-Speicherpufferobjekte, hochwertige ETC2/EAC-Texturkomprimierung, erhöhte Speichersicherheit, eine Robustheitserweiterung für mehrere Anwendungen, Kompatibilität mit OpenGL ES 3.0
4.4 22. Juli 2013 GLSL 4.40, Pufferplatzierungssteuerung, Effiziente asynchrone Abfragen, Shader-Variablen-Layout, Effiziente Bindung mehrerer Objekte, Optimierte Portierung von Direct3D-Anwendungen, Bindless Texture Extension, Sparse Texture Extension
4.5 11. August 2014 GLSL 4.50, Direct State Access (DSA), Flush Control, Robustheit, OpenGL ES 3.1 API- und Shader-Kompatibilität, DX11-Emulationsfunktionen
4.6 31. Juli 2017 GLSL 4.60, Effizientere Geometrieverarbeitung und Shader-Ausführung, mehr Informationen, kein Fehlerkontext, Polygon-Offset-Klemme, SPIR-V, anisotrope Filterung

OpenGL 2.0

Erscheinungsdatum : 7. September 2004

OpenGL 2.0 wurde ursprünglich von 3Dlabs entwickelt , um Bedenken auszuräumen, dass OpenGL stagniert und keine starke Ausrichtung hat. 3Dlabs hat eine Reihe wichtiger Ergänzungen zum Standard vorgeschlagen. Die meisten davon wurden damals vom ARB abgelehnt oder kamen sonst nie in der von 3Dlabs vorgeschlagenen Form zum Tragen. Ihr Vorschlag für eine Shading-Sprache im C-Stil wurde jedoch schließlich abgeschlossen, was zur aktuellen Formulierung der OpenGL-Shading-Sprache ( GLSL oder GLslang) führte. Wie die Assembler-ähnlichen Shading-Sprachen, die es ersetzte, erlaubte es das Ersetzen des Vertex- und Fragment-Pipe mit fester Funktion durch Shader , obwohl diesmal in einer C-ähnlichen Hochsprache geschrieben.

Das Design von GLSL zeichnete sich dadurch aus, dass relativ wenige Zugeständnisse an die Grenzen der damals verfügbaren Hardware gemacht wurden. Dies knüpft an die frühere Tradition von OpenGL an, ein ehrgeiziges, zukunftsorientiertes Ziel für 3D-Beschleuniger zu setzen, anstatt nur den Zustand der derzeit verfügbaren Hardware zu verfolgen. Die endgültige OpenGL 2.0-Spezifikation beinhaltet Unterstützung für GLSL.

Longs Peak und OpenGL 3.0

Vor der Veröffentlichung von OpenGL 3.0 hatte die neue Revision den Codenamen Longs Peak . Zum Zeitpunkt seiner ursprünglichen Ankündigung wurde Longs Peak als erste große API-Revision in OpenGLs Lebenszeit vorgestellt. Es bestand aus einer Überarbeitung der Funktionsweise von OpenGL, die grundlegende Änderungen an der API erforderte.

Der Entwurf führte eine Änderung in der Objektverwaltung ein. Das GL 2.1-Objektmodell wurde auf dem zustandsbasierten Design von OpenGL aufgebaut. Das heißt, um ein Objekt zu modifizieren oder zu verwenden, muss man das Objekt an das Zustandssystem binden, dann Änderungen am Zustand vornehmen oder Funktionsaufrufe ausführen, die das gebundene Objekt verwenden.

Da OpenGL ein Zustandssystem verwendet, müssen Objekte änderbar sein. Das heißt, die Grundstruktur eines Objekts kann sich jederzeit ändern, selbst wenn die Renderingpipeline dieses Objekt asynchron verwendet. Ein Texturobjekt kann von 2D auf 3D umdefiniert werden. Dies erfordert, dass jede OpenGL-Implementierung ein gewisses Maß an Komplexität zur internen Objektverwaltung hinzufügt.

Unter der Longs Peak API würde die Objekterstellung atomar werden , indem Vorlagen verwendet werden, um die Eigenschaften eines Objekts zu definieren, das mit einem Funktionsaufruf erstellt würde. Das Objekt könnte dann sofort über mehrere Threads hinweg verwendet werden. Objekte wären auch unveränderlich; deren Inhalt kann jedoch geändert und aktualisiert werden. Zum Beispiel könnte eine Textur ihr Bild ändern, aber ihre Größe und ihr Format könnten nicht geändert werden.

Um die Abwärtskompatibilität zu unterstützen, wäre die alte zustandsbasierte API weiterhin verfügbar, aber in späteren Versionen von OpenGL würden keine neuen Funktionen über die alte API verfügbar gemacht. Dadurch hätten alte Codebasen, wie die meisten CAD- Produkte, weiterhin laufen können, während andere Software gegen die neue API geschrieben oder auf diese portiert werden könnte.

Longs Peak sollte ursprünglich im September 2007 unter dem Namen OpenGL 3.0 fertiggestellt werden, aber die Khronos Group gab am 30. Oktober bekannt, dass sie auf mehrere Probleme gestoßen sei, die sie vor der Veröffentlichung der Spezifikation ansprechen wollte. Infolgedessen verzögerte sich die Spezifikation und die Khronos Group geriet bis zur Veröffentlichung der endgültigen OpenGL 3.0-Spezifikation in einen Medien-Blackout .

Die endgültige Spezifikation erwies sich als weit weniger revolutionär als der Vorschlag von Longs Peak. Anstatt den gesamten Sofortmodus und alle festen Funktionen (Nicht-Shader-Modus) zu entfernen, wurden sie in die Spezifikation als veraltete Funktionen aufgenommen. Das vorgeschlagene Objektmodell wurde nicht aufgenommen, und es wurde nicht angekündigt, es in zukünftige Überarbeitungen aufzunehmen. Infolgedessen blieb die API weitgehend gleich, wobei einige vorhandene Erweiterungen zur Kernfunktionalität hochgestuft wurden.

Bei einigen Entwicklergruppen sorgte diese Entscheidung für Aufruhr, viele Entwickler kündigten an, aus Protest auf DirectX umzusteigen. Die meisten Beschwerden drehten sich um die mangelnde Kommunikation von Khronos mit der Entwickler-Community und die Verwerfung mehrerer Funktionen, die von vielen positiv bewertet wurden. Weitere Frustrationen waren die Anforderung von DirectX 10-Hardware zur Verwendung von OpenGL 3.0 und das Fehlen von Geometrie-Shadern und instanziiertem Rendering als Kernfunktionen.

Andere Quellen berichteten, dass die Reaktion der Community nicht ganz so heftig war wie ursprünglich dargestellt, und viele Anbieter zeigten Unterstützung für das Update.

OpenGL 3.0

Erscheinungsdatum : 11. August 2008

OpenGL 3.0 führte einen veralteten Mechanismus ein, um zukünftige Überarbeitungen der API zu vereinfachen. Bestimmte Funktionen, die als veraltet markiert sind, könnten vollständig deaktiviert werden, indem ein aufwärtskompatibler Kontext vom Fenstersystem angefordert wird. Auf OpenGL 3.0-Funktionen kann jedoch weiterhin neben diesen veralteten Funktionen zugegriffen werden, indem ein vollständiger Kontext angefordert wird .

Zu den veralteten Funktionen gehören:

  • Alle Vertex- und Fragmentverarbeitung mit fester Funktion
  • Direktmodus-Rendering mit glBegin und glEnd
  • Listen anzeigen
  • Indizierte Farbwiedergabeziele
  • OpenGL Shading Language- Versionen 1.10 und 1.20

OpenGL 3.1

Erscheinungsdatum : 24. März 2009

OpenGL 3.1 hat alle Funktionen, die in Version 3.0 veraltet waren, mit Ausnahme der breiten Linien, vollständig entfernt. Ab dieser Version ist es nicht mehr möglich, mit einem vollständigen Kontext auf neue Funktionen zuzugreifen oder mit einem aufwärtskompatiblen Kontext auf veraltete Funktionen zuzugreifen . Eine Ausnahme von der vorherigen Regel wird gemacht, wenn die Implementierung die Erweiterung ARB_compatibility unterstützt , dies ist jedoch nicht garantiert.

Hardware: Mesa unterstützt ARM Panfrost mit Version 21.0.

OpenGL 3.2

Erscheinungsdatum : 3. August 2009

OpenGL 3.2 baute weiter auf den von OpenGL 3.0 eingeführten Deprecation-Mechanismen auf, indem die Spezifikation in ein Kernprofil und ein Kompatibilitätsprofil unterteilt wurde . Kompatibilitätskontexte umfassen die zuvor entfernten APIs mit festen Funktionen, die der neben OpenGL 3.1 veröffentlichten ARB_compatibility-Erweiterung entsprechen, während Kernkontexte dies nicht tun. OpenGL 3.2 enthielt auch ein Upgrade auf die GLSL-Version 1.50.

OpenGL 3.3

Erscheinungsdatum: 11. März 2010

Mesa unterstützt Software-Treiber SWR, Softpipe und für ältere Nvidia-Karten mit NV50. D3D12 ist eine neue Emulation für die Microsoft WSL-Erweiterung zur Verwendung von Direct 12.

OpenGL 4.0

Erscheinungsdatum : 11. März 2010

OpenGL 4.0 wurde zusammen mit Version 3.3 veröffentlicht. Es wurde für Hardware entwickelt, die Direct3D 11 unterstützt.

Wie in OpenGL 3.0 enthält diese Version von OpenGL eine große Anzahl von ziemlich belanglosen Erweiterungen, die entwickelt wurden, um die Fähigkeiten der Direct3D-11-Klasse-Hardware umfassend aufzuzeigen. Im Folgenden sind nur die einflussreichsten Erweiterungen aufgeführt.

Hardware-Unterstützung: Nvidia GeForce 400-Serie und neuer, AMD Radeon HD 5000-Serie und neuer (FP64-Shader implementiert durch Emulation auf einigen TeraScale-GPUs), Intel HD Graphics in Intel Ivy Bridge- Prozessoren und neuer.

OpenGL 4.1

Erscheinungsdatum : 26. Juli 2010

Hardware-Unterstützung: Nvidia GeForce 400-Serie und neuer, AMD Radeon HD 5000-Serie und neuer (FP64-Shader implementiert durch Emulation auf einigen TeraScale-GPUs), Intel HD Graphics in Intel Ivy Bridge- Prozessoren und neuer.

  • Die minimale "maximale Texturgröße" beträgt 16.384 × 16.384 für GPUs, die diese Spezifikation implementieren.

OpenGL 4.2

Erscheinungsdatum: 8. August 2011

  • Unterstützung für Shader mit atomaren Zählern und Load-Store-Atomic Read-Modify-Write-Operationen auf einer Texturebene
  • Zeichnen mehrerer Instanzen von Daten, die aus der GPU-Vertex-Verarbeitung (einschließlich Tessellation) erfasst wurden, um komplexe Objekte effizient neu zu positionieren und zu replizieren
  • Unterstützung für das Ändern einer beliebigen Teilmenge einer komprimierten Textur, ohne die gesamte Textur erneut auf die GPU herunterladen zu müssen, um signifikante Leistungsverbesserungen zu erzielen

Hardwareunterstützung: Nvidia GeForce 400-Serie und neuer, AMD Radeon HD 5000-Serie und neuer (FP64-Shader implementiert durch Emulation auf einigen TeraScale-GPUs) und Intel HD Graphics in Intel Haswell- Prozessoren und neuer. (Linux Mesa: Ivy Bridge und neuer)

OpenGL 4.3

Erscheinungsdatum: 6. August 2012

  • Computing-Shader, die GPU-Parallelität im Kontext der Grafikpipeline nutzen
  • Shader-Speicherpufferobjekte, die es Shadern ermöglichen, Pufferobjekte wie das Laden/Speichern von Bildern aus 4.2 zu lesen und zu schreiben, jedoch über die Sprache und nicht über Funktionsaufrufe.
  • Abfragen von Bildformatparametern
  • ETC2/EAC- Texturkomprimierung als Standardfunktion
  • Volle Kompatibilität mit OpenGL ES 3.0- APIs
  • Debug-Fähigkeiten zum Empfangen von Debug-Nachrichten während der Anwendungsentwicklung
  • Texturansichten, um Texturen auf unterschiedliche Weise ohne Datenreplikation zu interpretieren
  • Erhöhte Speichersicherheit und Robustheit für mehrere Anwendungen

Hardwareunterstützung: AMD Radeon HD 5000 Series und neuer (FP64-Shader implementiert durch Emulation auf einigen TeraScale-GPUs), Intel HD Graphics in Intel Haswell- Prozessoren und neuer. (Linux Mesa: Ivy Bridge ohne Schablonentexturierung, Haswell und neuer), Nvidia GeForce 400-Serie und neuer. Die VIRGL-Emulation für virtuelle Maschinen unterstützt 4.3+ mit Mesa 20.

OpenGL 4.4

Erscheinungsdatum: 22. Juli 2013

  • Erzwungene Kontrollen zur Verwendung von Pufferobjekten
  • Asynchrone Abfragen in Pufferobjekte
  • Ausdruck von mehr Layout-Steuerelementen von Schnittstellenvariablen in Shadern
  • Effizientes Binden mehrerer Objekte gleichzeitig

Hardware-Unterstützung: AMD Radeon HD 5000-Serie und neuer (FP64-Shader implementiert durch Emulation auf einigen TeraScale-GPUs), Intel HD Graphics in Intel Broadwell- Prozessoren und neuer (Linux Mesa: Haswell und neuer), Nvidia GeForce 400-Serie und neuer, Tegra K1 .

OpenGL 4.5

Erscheinungsdatum: 11. August 2014

  • Direct State Access (DSA) – Objektzugriffsprogramme ermöglichen das Abfragen und Ändern des Zustands, ohne Objekte an Kontexte zu binden, um die Effizienz und Flexibilität von Anwendungen und Middleware zu erhöhen.
  • Flush Control – Anwendungen können das Flushing anstehender Befehle vor dem Kontextwechsel steuern – wodurch leistungsstarke Multithread-Anwendungen ermöglicht werden;
  • Robustheit – Bereitstellung einer sicheren Plattform für Anwendungen wie WebGL-Browser, einschließlich der Verhinderung eines GPU-Resets, das sich auf andere laufende Anwendungen auswirkt;
  • OpenGL ES 3.1 API- und Shader-Kompatibilität – um die einfache Entwicklung und Ausführung der neuesten OpenGL ES-Anwendungen auf Desktop-Systemen zu ermöglichen.

Hardwareunterstützung: AMD Radeon HD 5000 Serie und neuer (FP64 Shader implementiert durch Emulation auf einigen TeraScale GPUs), Intel HD Graphics in Intel Broadwell Prozessoren und neuer (Linux Mesa: Haswell und neuer), Nvidia GeForce 400 Serie und neuer, Tegra K1 , und Tegra X1.

OpenGL 4.6

Erscheinungsdatum: 31. Juli 2017

Hardware-Unterstützung: AMD Radeon HD 7000-Serie und neuer (FP64-Shader implementiert durch Emulation auf einigen TeraScale-GPUs), Intel Haswell und neuer, Nvidia GeForce 400-Serie und neuer.

Fahrerunterstützung:

  • Mesa 19.2 unter Linux unterstützt OpenGL 4.6 für Intel Broadwell und neuer. Mesa 20.0 unterstützt AMD Radeon GPUs, während die Unterstützung für Nvidia Kepler+ in Arbeit ist. Zink als Emulationstreiber mit 21.1 und Softwaretreiber LLVMpipe unterstützen auch mit Mesa 21.0.
  • AMD Adrenalin 18.4.1 Grafiktreiber unter Windows 7 SP1 , 10 Version 1803 (April 2018 Update) für AMD Radeon™ HD 7700+, HD 8500+ und neuer. Erschienen im April 2018.
  • Intel 26.20.100.6861 Grafiktreiber unter Windows 10 . Erschienen im Mai 2019.
  • NVIDIA GeForce 397.31 Grafiktreiber nur unter Windows 7 , 8 , 10 x86-64 Bit, keine 32-Bit- Unterstützung. Erschienen im April 2018

Alternative Implementierungen

Apple - veraltete OpenGL in iOS 12 und macOS 10.14 Mojave für Metall , aber es ist nach wie vor als die zur Verfügung stehenden macOS 11 Big Sur (einschließlich Apple - Silizium - Geräte). Die neueste für OpenGL unterstützte Version ist 4.1 von 2011. Eine proprietäre Bibliothek von Molten – den Autoren von MoltenVK – namens MoltenGL, kann OpenGL-Aufrufe in Metal übersetzen.

Es gibt mehrere Projekte, die versuchen, OpenGL auf Vulkan zu implementieren. Das Vulkan-Backend für Googles ANGLE hat im Juli 2020 die OpenGL ES 3.1-Konformität erreicht. Das Mesa3D- Projekt enthält auch einen solchen Treiber namens Zink .

Die Zukunft von OpenGL

Im Juni 2018 hat Apple OpenGL-APIs auf all seinen Plattformen ( iOS , macOS und tvOS ) eingestellt und Entwickler dringend dazu ermutigt, ihre proprietäre Metal API zu verwenden , die 2014 eingeführt wurde.

Die Betriebssysteme Fuchsia und Stadia unterstützen nur Vulkan

17. September 2021 Valve hat OpenGL aus Dota 2 entfernt

Alle neuen Spiele von 2016 basierend auf der ID Tech 6 Game Engine verwenden Vulkan

ID Tech 7 Game Engine unterstützt nur Vulkan

Atypical Games hat mit Unterstützung von Samsung die Aufgabe übernommen, Vulkan-Unterstützung in ihre Engine zu implementieren. Am Ende wurde klar, dass die Implementierung von Vulkan OpenGL tatsächlich auf allen Plattformen außer Apple ersetzen wird.

Vulkan

Hauptartikel: Vulkan (API)

Vulkan, früher als "Next Generation OpenGL Initiative" (glNext) bezeichnet, ist ein grundlegender Neuentwurf, um OpenGL und OpenGL ES in einer gemeinsamen API zu vereinen, die nicht abwärtskompatibel mit bestehenden OpenGL-Versionen ist.

Die erste Version der Vulkan API wurde am 16. Februar 2016 veröffentlicht.

Siehe auch

Verweise

Weiterlesen

Externe Links