Climbing OpenGL Longs Peak – An OpenGL ARB Progress Update
Wie man schon weiss plant ARB viel für 2007. So arbeiten sie nicht an einer, sondern an zwei OpenGL Spezifikationen mit den Codenamen "OpenGL Longs Peak" und "OpenGL Mount Evans" (Mehr dazu hier). OpenGL Longs Peak bringt ein neues Objektmodel, welches in gewissen Details schon im letzten Newsletter beschrieben wurde. Seit dem letzten Update gab es ein paar wichtige Entscheidungen die hier erwähnt sein sollten:

• Objekterstellung ist asynchron
  Das heisst das der Aufruf zur Objekterstellung schon einen Handle zurückgeben kann, bevor das Objekt in der OpenGL Implementation überhaupt erstellt wurde. Das schöne daran ist, dass dieser Handle ein gültiger Handle ist, er kann direkt weiterbenutzt werden. Dies ermöglicht der Anwendung sowie der OpenGL Implementation die Arbeit zu überlappen, was die Parallelverarbeitung verbessert. Als Beispiel dafür sei eine Anwendung, welche eine neue Textur für einen neuen Charakter benötigt. Während der aktuelle Charakter gerendert wird, kann man die Erstellung der Textur starten und einen gültigen Handle bekommen. Wenn die Anwendung fertig ist um den nächsten Charakter zu rendern hat die OpenGL Implementation diese Textur schon geladen und es gibt keine Verzögerung beim Rendern.
• Mehrere Programmobjekte können zusammengefasst werden
  In OpenGL 2.1 kann nur ein Programmobjekt zum Rendern benutzt werden. Wenn eine Anwendung die Vertex- und Fragmentstufe der Renderpipeline mit ihren eigenen Shadern ersetzen will, so müssen alle Shader in ein Programmobjekt vereinigt werden. Dies ist ein gutes Modell, wenn es 2 programmierbare Stufen gibt, aber es wird schlechter je höher man die Zahl der Stufen setzt. In OpenGL Longs Peak wird es möglich sein mehrere Programmobjekte fürs Rendern zusammenzufassen. Jedes Programmobjekt braucht nur die Shader einer einzelnen Stufe beinhalten, entweder die Vertex-, Geometrie- oder Fragmentstufe. Denoch ist es natürlich noch möglich Programmobjekte zu erzeugen, welche mehrere Stufen beinhalten.
• Der Unterschied zwischen unformatierten/transparenten Bufferobjekten und formatierten/undurchsichtigen Texturobjekten beginnt zu verschwinden
  OpenGL Longs Peak beinhaltet die Notation der Bildbuffer (image buffer). Ein Bildbuffer hält den Datenteil (Texel) einer Textur. Ein Bildbuffer ist nicht mehr als ein Bufferobjekt, welches wir aus OpenGL 2.1 kennen, verbunden mit einem Format welches die Daten beschreibt. In anderen Worten: Ein Bildbuffer ist ein formatiertes Bufferobjekt und wird als eine Unterklasse eines Bufferobjektes behandelt.
• Ein Shaderschreiber kann eine Menge von uniform Variablen in einen gemeinsamen Block gruppieren
  Der Speicher für die Variablen in einem gemeinsamen Block wird von einem Bufferobjekt bereitgestellt. Die Anwendung muss das Bufferobjekt an ein Programmobjekt binden, um den Platz zu bieten. Dies bietet mehrere Vorteile. Erstens: Der mögliche Speicherplatz für uniform Variablen wird erhöht. Zweitens gibt es eine Möglichkeit eine Gruppe von Variablen mit einem Api-Aufruf zu übergeben. Drittens erlaubt es die Verwendung der Variablen in mehreren Programmobjekten indem man dasselbe Bufferobjekt an die verschiedenen Programmobjekte bindet. Dies wird auch als "enviroment uniforms" bezeichnet, etwas was in OpenGL 2.1 und GLSL 1.2 nur möglich ist, wenn man diese Werte in eingebaute Variablen wie gl_ModelViewMatrix einbaut.

Aktuell wird diskutiert wie man Interoperabilität zwischen OpenGL 2.1 und OpenGL Longs Peak sicher stellt. Die aktuellen Gedanken sind die folgenden: Es wird einen neuen Kontexterstellungsaufruf geben welcher anzeigt ob man einen OpenGL 2.1 oder einen OpenGL Longs Peak Kontext haben will. Auch wird es erlaubt sein, beide Kontexte gleichzeitig zu benutzen, auch auf derselben Zeichenfläche. Dies ist ein Schlüsselfeature und erlaubt es OpenGL 2.1 (und früher) Anwendungen einen Longs Peak Kontext zu öffnen und diesen Kontext benutzen um Effekte zu zeichnen, die nur in Longs Peak möglich sind. Auch soll es eine Erweiterung für OpenGL 2.1 geben, welche es erlaubt ein Bildobjekt eines Long Peak Kontextes an ein Texturobjekt aus einem OpenGL 2.1 Kontext zu heften. Auch wollen sie an dieser Stelle Feedback und fragen ob dies ein vernünftiger Weg für aktuelle Anwendungen ist.

Polygons In Your Pocket: Introducing OpenGL ES
OpenGL ES ist grossteils eine reine Untermenge von OpenGL. Bei der Erzeugung von OpenGL ES wurde versucht Altlasten von OpenGL sowie unnötige Möglichkeiten zu entfernen. Aktuell hat OpenGL ES die meisten proprietären 3D APIs ersetzt und ist z.B. auch auf der Playstation 3 zu finden. In zukünftigen Versionen des Newsletter will man weitere Details zu OpenGL ES veröffentlichen.

A First Glimpse at the OpenGL SDK
Das OpenGL SDK wurde veröffentlicht: http://www.opengl.org/sdk/

Using the Longs Peak Object Model
Die folgenden Beispiele basierend auf der aktuellen API welche zu einem grossen Teil schon stabil ist.

Template and Objects
Im traditionellen OpenGL werden Objekte erstellt und deren Parameter (oder Attribute in unserer neuen Terminologie) werden nach der Erstellung gesetzt.
In dem neuen Objektmodell sind viele Typen von Objekte unveränderbar, sodass ihre Attribute bei der Erstellung definiert sein müssen.

Ein Template ist ein Clientobjekt welches exakt die Attribute enthält welche benötigt werden um ein "richtiges" Objekt auf dem Server zu erstellen. Jeder Typ von Objekt (Buffer, Bild, Programm, Shader, Syncs, Vertex Arrays und so weiter) hat ein entsprechendes Template. Wenn ein Template erstellt wird enthält es die Standardattribute für diesen Objekttyp, welche dann verändert werden können. Die Erstellung eines "richtigen" Objektes auf dem Server geschieht bei der Übergabe des Templates an eine Erstellungsfunktion, welche ein Handle zu dem neuen Objekt zurückgibt. Um Pipelineprobleme zu vermeiden verursachen Objekterstellungen keinen round-trip auf dem Server. Stattdessen gibt der Client einen spekulierten Handle zurück, welcher in zukünftigen API-Aufrufen benutzt werden kann. (Falls die Erstellung fehlgeschlagen ist wird die weitere Benutzung des Handles zu einem neuen Fehlertyp erzeugen: GL_INVALID_OBJECT.)

API Design Concerns
Diese Design sieht langatming und nicht sehr objektorientiert aus. Dies stimmt auch, nur kann man zum Glück Templates wiederverwenden und muss nicht für jedes Objekt ein neues Template erstellen. Auch wird erwartet, dass bald Wrapperfunktion entstehen, die das Problem reduzieren. Auch sollen ein Teil dieser Wrapper in eine GLU-ähnliche Bibliothek wandern.
Die Objektorientierung ist nicht möglich, da die Treiber zum grossteil in nicht OO-Sprachen programmiert sind. Desweiteren will man sich nicht auf eine spezifische OO-Sprache festlegen. Dafür sind die Befehle so gewählt, dass man ohne Probleme eine OO-Sprachbindung für OpenGL erstellen kann, sowie sie jetzt schon existieren.

ARB Next Gen TSG Update
Die folgenden Sektionen bieten eine kleine Übersicht über die Features welche vom der Next Gen TSG für OpenGL Mount Evans entwickelt werden:

• Geometry Shading ist eine neue mächtige programmierbare Stufe der OpenGL Pipeline welche nach dem Vertex Shading, aber vor der Rasterisierung stattfindet. Geometrie Shaders, welche genauso wie Vertex- und Pixelshader mit GLSL beschrieben werden, operieren auf post-transformierten Vertices und haben Informationen über die aktuellen Primitiven sowie deren Nachbarvertices. Seitdem man mit Geometrie Shadern neue Vertices und Primitive erstellen kann, bieten diese sich für die Implementation von hochaufgelösten Oberflächen und anderen Techniken welche von einem "ein Input, viel Output"-Modell profitieren an.
• Instanced Rendering bietet einen Mechanismus zum wiederholten effizienten Rendern derselben Art von Vertices mit verschiedenen "Instancen" an. Der Vertex Shader kann einen Instancenidentizifierer lesen und damit Vertextransformationen im Bezug zu diesem Identizifierer ausführen.
• Integer Pipeline Support wurde hinzugefügt um zu erlauben, dass Integerzahlen durch die OpenGL Pipeline fliessen ohne Clamping-Operationen sowie Normalisierungsschritte durchzuführen. Neue nicht normalisierende Integerpixelformate für Renderbuffer und Texturen wurden hinzugefügt und GLSL hat ein paar "integer-aware" Operatoren und eingebaute Funktionen bekommen damit Shader Integerdaten manipulieren können.
• Texture "Lookup Table" Samplers sind spezialisierte Typen von Texturesamplern die es einem Shader erlauben indexbasierende, nicht filternde Lookips in sehr grossen eindimensionalen Datenarrays durchzuführen. Diese können grösser als die maximal unterstützte 1D Textur sein.
• New Uses for Buffer Objects wurden definiert um der Anwendung zu erlauben, dass sie Bufferobjekte benutzt um Shader Uniforms, Texturen und den Output von Vertex- und Geometryshadern zu speichern. In Bufferobjekt gespeicherte Uniformvariablen erlauben das effiziente Wechseln zwischen verschiedenen Gruppen von Uniforms ohne dem wiederholten senden des geänderten Status zwischen Client und Server. Das Speichern von Texturen in Bufferobjekten bietet eine sehr effiziente Möglichkeit grosse Datenarrays in Shadern durchzuschauen. Das Fangen der Ausgabe von Vertex- oder Geometryshadern in ein Bufferobjekt bietet einen unglaublich mächtigen Mechanismus um Daten in der GPU auszuführen zu lassen, ohne den Overhead und Probleme der Rasterisation.
• Texture Arrays bieten eine effiziente Möglichkeit um aus und in eine Sammlung von Bildbuffern zu rendern ohne die grosse Zahl an Overhead durch Status-Änderungen beim Auswählen eines speziellen Bildes aus der Sammlung.

Während die oberen Elemente ein "must have" Feature für OpenGL Mount Evans sind, sind die folgenden eine Gruppe von "nice to have" Features:

• New Pixel and Texture Formats wurden definiert um den sRGB-Farbraum, shared-exponent und packed floating point, ein oder zwei Komponentenkompressionsformate sowie floating-point Depthbuffer zu unterstützen.
• Improved Blending Support for DrawBuffers würde es der Anwendung erlauben seperate Blendingzustände sowie Color-Write-Masken für jeden Zeichenbuffer zu spezifieren.
• Performance Improvements for glMapBuffer erlaubt es Anwendungen die Synchronisierung zwischen OpenGL und der Anwendung effizienter zu kontrollieren, wenn man Buffer Objects für Zugriffe von der HostCPU mappt.

OpenGL and Windows Vista™
Vista bietet über 4 verschiedene Möglichkeiten Unterstützung für OpenGL an:

• Microsoft's Software OpenGL 1.1 Implementation (Rendererstring: GDI Generic)
• Microsoft's limitierter D3D Wrapper (Rendererstring: Direct3D)
• Microsoft's besserer D3D Wrapper (Rendererstring: OpenGL-D3D Translator)
• Grafikkartenherstellertreiber

Ansonsten muss ein OpenGL-Entwickler noch sich zwischen zwei Dingen entscheiden:

• Keine Aero-Oberfläche während das Programm läuft.
• Keine Benutzung von GDI.

Quelle

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Das ist meiner Meinung nach eine der besten Neuerungen. Wenn man mehrere verschiedene Lichter benötigt, hatte man bislang das Problem, dass man entweder die entsprechenden Shaderkombinationen alle generieren mußte oder sich auf ein Licht pro Pass beschränkt. Bei D3D gab es mal den Fragment Linker. Der war aber nicht optimal, da er nur das zusammenfügen übernommen hat und man den Shader dann nochmal explizit erstellen mußte. Da ist es natürlich sinnvoller und vielleicht auch schneller, das direkt vom Treiber machen zu lassen. Schließlich muss der OpenGL Treiber für die feste Pipeline auch eine große Menge von Shaderkombinationen verwalten. D3D10 hat leider keine solche Funktionalität und daher wäre das ein Vorteil für OpenGL. Wenn man sich die Beiträge bei gamedev.net ansieht, sind die Shaderkombinationen wirklich ein grundlegendes Problem.

Habe das leider falsch verstanden. Das einzige was wegfällt ist, dass man die Vertex und Fragment Shader nicht mehr zusammenlinken muss. Mehrere Vertex oder Fragment(oder Geometrie) Shader sind leider doch nicht möglich. Sehr schade.

Hmm, ich hatte es aber auch verstanden, dass man mehrere Shader zusammenfassen kann

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Leider nicht. Das wurde im Forum klargestellt:

There are two classes of linkage which occur with programs:

http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=015074