OpenGL (Open Graphics Library; deutsch Offene Grafikbibliothek) ist eine Spezifikation einer plattform- und programmiersprachenübergreifenden Programmierschnittstelle (API) zur Entwicklung von 2D- und 3D-Computergrafikanwendungen. Der OpenGL-Standard beschreibt etwa 250 Befehle, die die Darstellung komplexer 3D-Szenen in Echtzeit erlauben. Zudem können andere Organisationen (zumeist Hersteller von Grafikkarten) proprietäre Erweiterungen definieren.
Die Implementierung des OpenGL-API erfolgt in der Regel durch Systembibliotheken, auf einigen Betriebssystemen auch als Teil der Grafikkarten-Treiber. Diese führen entsprechend Befehle der Grafikkarte aus, insbesondere müssen auf der Grafikkarte nicht vorhandene Funktionen durch die CPU emuliert werden.
Der Nachfolger von OpenGL ist Vulkan.
Das Programmiermodell mini|500px|Diagramm der Grafikpipeline von OpenGL
Viele Parameter können die Darstellung von gerenderten Objekten beeinflussen, beispielsweise können sie texturiert und beleuchtet sein, gestreckt, verschoben, transparent oder undurchsichtig, sie können eine raue oder glatte Oberfläche haben und so weiter.
OpenGL wurde als Zustandsautomat entworfen, der nicht bei jedem Funktionsaufruf alle benötigten Parameter erhält, sondern so lange dieselben Werte verwendet, bis die entsprechenden Zustände geändert werden. Auf diese Weise braucht man zum Beispiel nicht für jeden Vertex OpenGL die gewünschte Farbe mitzuteilen, sondern setzt einmalig eine Farbe, woraufhin alle folgenden Vertices in dieser Farbe dargestellt werden. Auf dieselbe Weise kann man global Lichtquellen an- oder ausschalten und viele weitere Zustände setzen.
Der Grund für dieses Design ist, dass fast jede Änderung des Zeichenmodus aufwendige Reorganisationen der Grafikpipeline nach sich zieht, daher vermeidet man diese lieber, so lange es sinnvoll möglich ist. Auch wäre es für den Programmierer ermüdend, dutzende Parameter immer wieder neu anzugeben. Oft können viele tausend Vertices bearbeitet werden, bevor wieder ein Zustand geändert werden muss, während manche Zustände sogar nie geändert werden. Beispielsweise bleiben die Lichtquellen meistens für alle Objekte einer Szene die gleichen. Viele Zustände werden zumindest für die Dauer des Renderns eines kompletten Objekts beibehalten, zum Beispiel wird ein Auto als Ganzes um einen bestimmten Vektor verschoben und nicht in seine Einzelteile zerlegt und diese einzeln verschoben. Auch in Direct3D verfolgt man dieses zustandsbasierte Konzept.
Erweiterungen Eine wichtige Eigenschaft von OpenGL ist dessen Erweiterbarkeit. Einzelne Anbieter (typischerweise Grafikkartenhersteller) können die Zustandsmaschine von OpenGL um weitere Zustände erweitern. Dabei wird eine vierstufige Vorgehensweise verfolgt:
Wenn ein Hersteller eine Erweiterung realisieren möchte, so liefert er eine C-Headerdatei aus, in der er die Erweiterung mit den nötigen Konstanten und evtl. Funktionsprototypen definiert. Die Funktionsnamen und Konstanten erhalten ein herstellerspezifisches Suffix (z. B. NV für Nvidia oder ATI für ATI). Einigen sich dann mehrere Hersteller darauf, die gleiche Erweiterung anzubieten, bekommen die Funktionsnamen und Konstanten das Suffix EXT. Einigt sich schließlich das ARB (Architecture Review Board) darauf, die Erweiterung zu standardisieren, erhalten alle Namen das Suffix ARB. Die meisten vom ARB standardisierten Erweiterungen werden in der folgenden OpenGL-Spezifikation dann „core“, das heißt, sie werden Bestandteil von OpenGL selbst und haben dann kein Suffix mehr.
Historische Entwicklung OpenGL entstand ursprünglich aus dem von Silicon Graphics (SGI) entwickelten IRIS GL. Die Version OpenGL 1.0 wurde von Mark Segal und Kurt Akeley verfasst. Im sogenannten Fahrenheit-Projekt versuchten Microsoft und SGI ihre 3D-Standards zu vereinheitlichen, das Projekt wurde jedoch wegen finanzieller Schwierigkeiten auf Seiten von SGI abgebrochen.
Der OpenGL-Standard wird vom OpenGL ARB (Architecture Review Board) festgelegt. Das ARB existiert seit 1992 und besteht aus einer Reihe von Firmen. Stimmberechtigte Mitglieder sind die Firmen 3DLabs, Apple, AMD/ATI, Dell, IBM, Intel, Nvidia, SGI und Sun (Stand Nov. 2004). Weiter mitwirkende Firmen sind Evans & Sutherland, Imagination Technologies, Matrox, Quantum3D, S3 Graphics, Spinor GmbH, Tungsten Graphics und Xi Graphics. Microsoft, eines der Gründungsmitglieder, hat das ARB im März 2003 verlassen.
Neue Funktionen in OpenGL werden meist zuerst als herstellerspezifische Erweiterungen eingeführt und gehen dann den Weg über herstellerübergreifende Erweiterungen und ARB-Erweiterungen zu Kernfunktionalität. Dies erlaubt es, neueste Möglichkeiten der Grafikhardware zu nutzen und dennoch OpenGL abstrakt genug zu halten.
Seit dem 31. Juli 2006 liegt die Weiterentwicklung der OpenGL-API in der Hand der Khronos Group.
Versionsgeschichte
Version Veröffentlichung Beschreibung / Änderungen Januar 1992 erste Veröffentlichung Januar 1997 Vertex Arrays Texture Objects Polygon Offset 16. März 1998 3D-Texturen neue Pixelformate (BGRA, Packed) Level-Of-Detail-Texturen 14. Oktober 1998 ARB Extensions eingeführt ARB Multitexture 14. August 2001 komprimierte Texturen Cube-Maps Multitexturing 24. Juli 2002 Tiefentexturen (für Shadow-Mapping) automatische Mip-Map-Erzeugung Nebelkoordinaten 29. Juli 2003 Pufferobjekte (Vorhalten von Daten im Grafikspeicher) Occlusion Queries 7. September 2004 Shaderprogramme: OpenGL Shading Language Multiple Render Targets Texturen beliebiger Größe (nicht mehr 2n für Höhe und Breite) 2. August 2006 Pixel Buffer Objects OpenGL Shading Language 1.20 sRGB-Texturen 11. August 2008 [ursprünglich geplante Ziele, nur teilweise umgesetzt] Codebasis aufgeräumt OpenGL Shading Language 1.30 Entfernen von Altlasten (glBegin / glEnd, Fixed-Function-Pipeline, T&L etc.) die Architektur insgesamt (Schichtmodell) nähert sich an DirectX an erstmals weitestgehender Verzicht auf explizite Abwärtskompatibilität 24. März 2009OpenGL 3.1 Spezifikationen (PDF; 2,2 MB) weiteres Entfernen von Altlasten (z. B. Fixed-Function-Optionen, Direct-Mode und Color-Index-Mode), diese sind nur noch über die optionale „compatibility extension“ verfügbar OpenGL Shading Language 1.40 Uniform Buffer Objects Vertex Shader Programme erlauben mindestens 16 Texture-lookups Primitive Restart Instancing CopyBuffer API in Zusammenarbeit mit OpenCL. 3. August 2009opengl.org (PDF; 2,4 MB) OpenGL Core Specification with changes marked höhere Ausführungsgeschwindigkeit verbesserte Darstellungsqualität beschleunigtes Geometry Processing vereinfachte Portierung von Direct3D-Anwendungen OpenGL Shading Language 1.50 Geometry-Shader werden bei Programmierung von Grafikpipelines jetzt auch direkt im OpenGL-Kern unterstützt fünf ARB-Erweiterungen 11. März 2010opengl.org Einbindung von OpenCL OpenGL Shading Language 3.30 11. März 2010 Einbindung von OpenCL Tessellation OpenGL Shading Language 4.00 26. Juli 2010 Laden von binären Shader-Programmen, um Zeit zu sparen 64-Bit Floating-Point-Komponenten bei Vertex-Shader-Eingabe für höhere Präzision Mehrere Viewports für ein Render Surface OpenGL Shading Language 4.10 8. August 2011 OpenGL Shading Language 4.20 6. August 2012 Compute Shader-Programme für universelle Berechnungen OpenGL Shading Language 4.30 Plattformübergreifende Texturkompression nach ETC2/EAC Mehr Stabilität zwischen den OpenGL-Anwendungen 22. Juli 2013 Mehr Kontrolle über die Platzierung der „buffer“ im Speicher OpenGL Shading Language 4.40 Mehrere OpenGL-Objekte gleichzeitig an den Context binden Compute Shader mit variabler Work-Group-Größe 11. August 2014 Direct State Access (DSA) Flush Control Robustheit OpenGL ES 3.1 API und Shader-Kompatibilität DX11 Emulations Features 31. Juli 2017 Unterstützung von SPIR-V
Der große Sprung von OpenGL 1.5 auf 2.0 erklärt sich mit der Einführung der „OpenGL Shading Language“. Dies stellt eine so große Änderung und Erweiterung dar, dass sich das ARB zu diesem Schritt entschieden hat. Die Khronos Group hat die Spezifikation für OpenGL 3.0 am 11. August zur Siggraph 2008 bekanntgegeben. Die API wurde (weg von der Fixed-Function-Pipeline – hin zu den Shadern bzw. Programs, weg von der State Machine – hin zu einem objektbasierten System) umfassend überarbeitet. Dabei ist OpenGL zwar weiterhin abwärtskompatibel, doch es gibt keine neuen Funktionalitäten für die alte API mehr. Das neue OpenGL hat erstmals mächtige Geometry-Shader des 3.0-Modells.
Mit der raschen Veröffentlichung von OpenGL 4.0 und dessen Feature-Set – insbesondere der Einführung der Tesselation – konnte die Khronos Group seit längerer Zeit wieder gleichziehen und ist erneut mit DirectX (11) in Konkurrenz getreten.
Unter den Titeln OpenGL 2015 und OpenGL 2016 hat NVIDIA einige neue ARBs eingebracht. Ein Teil davon wurde mit OpenGL 4.6 zum Standard. 2017 und 2018 wurden für Pascal und Turing weitere Erweiterungen besonders für VR und Raytracing zur Verfügung gestellt.on-demand.gputechconf.com (PDF; 7,1 MB)khronos.org (PDF; 1,2 MB)khronos.org (PDF; 5,4 MB)on-demand.gputechconf.com
Longs Peak und die Kontroverse zu OpenGL 3.0 Vor der Freigabe der Version OpenGL 3.0 am 11. August 2008 war diese Revision der API unter dem Codenamen „Longs Peak“ bekannt. Zum Zeitpunkt der ursprünglichen Ankündigung wurde Longs Peak als allererste umfangreiche und tiefgreifende Überarbeitung der API-Schnittstelle in der Geschichte von OpenGL präsentiert. Diese bestand aus einer grundsätzlichen Überarbeitung der Art und Weise, wie OpenGL arbeitet, was fundamentale Veränderungen an der API zur Folge haben sollte. Um trotz der angekündigten umfangreichen Veränderungen und revolutionären Neuerungen die Abwärtskompatibilität mit älterer Software zu gewährleisten, sollten ältere Versionen der API weiterhin verfügbar sein, jedoch keine neuen Funktionen mehr dort einfließen. Dies hätte es erlaubt, alten Programmcode, wie z. B. in der Mehrzahl der CAD-Anwendungen vorhanden – welche ihre Codebasis seit Jahrzehnten nahezu unverändert nutzen – weiterhin mit älteren Versionen der OpenGL-API auszuführen, während andere Programme allmählich auf die neue Schnittstelle hin umgeschrieben oder portiert worden wären.
Longs Peak sollte ursprünglich bereits im September 2007 unter dem Namen OpenGL 3.0 freigegeben werden. Dann jedoch gab die Khronos-Gruppe am 30. Oktober 2007 bekannt, dass sie auf verschiedene Problempunkte gestoßen sei, die sie gelöst haben wollte, bevor sie die Spezifikationen veröffentlichte.
Als Resultat verschob sich die Veröffentlichung, und die Informationsquellen verstummten vollständig. Die Khronos-Gruppe war zur Koordination der Weiterentwicklung eingesetzt worden, da sich Neuerungen und Ideen durch die zahlreichen Mitglieder nur schwierig und sehr zeitaufwendig umsetzen ließen. Nach der Aufnahme ihrer Tätigkeiten strebte sie einen klaren und engen Zeitplan mit klar definierten Zielen an und verschrieb sich einer offeneren Kommunikation.
Die letztendlich verabschiedeten Spezifikationen erwiesen sich als weitaus weniger spektakulär als angekündigt. Weite Teile des Codes wurden doch beibehalten, und der vorgestellte Objektmodus war nicht integriert. Auch sind keine Pläne bekannt, diesen in zukünftigen Versionen nachzureichen. Im Endeffekt ist die API weitgehend die gleiche geblieben, mit ein paar wenigen Erweiterungen an der Kernfunktionalität.