Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: So Apr 18, 2021 12:35

Foren-Übersicht » DGL » News
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 4 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Sa Nov 18, 2006 14:55 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2025
Programmiersprache: C++
  • Transitions
    Obwohl ARB aufgehört hat zu existieren und die Arbeit zu Khronos gewandert ist, wird der Begriff ARB noch weiter existieren. Erweiterungen der Khronosgruppe werden den Zusatz ARB tragen.
    An der Arbeit an sich ändert sich nicht viel. Ein grosser Vorteil der Überführung ist die einfache Zusammenarbeit mit der OpenGL ES Arbeitsgruppe, was vorher nicht so einfach möglich war.

    Die Hauptaufgabe der ARB ist es 2007 2 neue OpenGL Releases anzuliefern. Der erste mit dem Codename OpenGL "Longs Peak" soll im Sommer 2007 veröffentlich werden. Der zweite mit dem Codename OpenGL "Mt. Evans" soll dann im Oktober 2007 veröffentlicht werden.
    Wieso Codenamen? Man wollte der ARB Marketinggruppe eine Chance geben, darüber was der richtige Name für einen Release wäre. Zu viele Vorschläge wurden schon gemacht, darunter OpenGL 2.2, OpenGL 3.0, OpenGL 3.1 und sogar OpenGL 4.0. Aktuell ist noch nicht die richtige Zeit um die Versionsnummer festzulegen und deshalb werden Codenamen benutzt.

    OpenGL Longs Peak wird ein signifikanter Aufbruch werden. Während immer noch die Rückwärstkompatibilität der API gegeben ist, wird das neue "Lean and Mean" Profil, und eine substantielle Überarbeitung zu dem neuen Objektmodell, in vielen Wegen ein ganz neues API Design. Dies ist eine anspruchsvolle Aufgabe und benötigt ein hohes Grad an Einstatz von den ARB Mitgliedern. Man sieht aktuell schon einen willkommenden Einsatz von Khronosmitgliedern, welche nicht Mitglieder des alten ARBs waren, und hoffen noch mehr zu sehen.

    Während OpenGL Longs Peak auf aktuelle und letzte Generation Hardware implementierbar sein wird, wird OpenGL Mt. Evans nur für die neuste Hardware implementierbar sein. Der OpenGL Mt. Evans Release wird eine Weiterführung des OpenGL Longs Peak sein, mit einer Menge an neuen Funktionalitäten. Ein paar der Highlights sind:
    Geometry Shading, eine mehr zentrale Rolle der Buffer Objekte und eine Integer Pipeline die über die OpenGL Shading Lanugange zugänglich ist.

    Zuletzt noch ein paar Informationen über Struktur der ARB Arbeitsgruppe. Die ARB WG enthät eine top-level SteuerGruppe (SG) und eine Anzahl von "technischen Subgruppen" oder TSGs. Jede TSG fokusiert sich auf ein spezielles Gebit und hat einen eigenen Vorsitzenden. Aktuell enthalten die Verantwortlichen und Strukten des ARB WG:
    • OpenGL ARB Steering Group (Vorsitzender: Barthold Lichtenbelt, NVIDIA)
      Das top-level SG wird in Verbindung mit der OpenGL ES Arbeitsgruppe die allgemeine OpenGL Strategie und Zeitplan definieren, entwickelte Konformitätstest und arbeitet andere grösseren Funktionen aus, die keiner TSGs zugewiesen sind.
    • Ecosystem TSG (Vorsitzender: Benj Lipchak, AMD)
      Das Ecosystem TSG entwickelt das OpenGL SDK, entwickelt Namenkonventionen, definiert die Aufteilung zwischen dem Kern des OpenGL Longs Peak "Lean and Mean" profile und dem Kompatibilitätslayout für OpenGL 1.x/2.x, führt Marketing Funktionen wie diesen Newsletter aus.
    • Object Model TSG (Vorsitzender: Barthold Lichtenbelt, NVIDIA)
      Das Object Model TSG entwickelt ein neues Object Model, findet heraus, wie man die existierenden OpenGL Funktionalitäten wie FBOs, Programmobjekte, Textureobjekte, etc. in das neue Model übertragen werden, und definiert kleine Teile von ganz neuen Funktionen wie Sync Objekten. Hier geschieht der grösste Teil der Arbeit für OpenGL Longs Peak.
    • Platform TSG (Vorsitzender: Jon Leech)
      Das Platform TSG definiert das GLX und WGL APIs und GLX Stream Protokol, arbeitet mit der Khronos OpenKODE Steering Gruppe zusammen um die Vorraussetzungen für die EGL API (plattform neutral, analog zu GLX und WGL) zu erstellen, und bearbeitet Themen mit Bezug zur OS Integration wie Application Binary Interfaces, Device Driver Interfaces oder reference source code für link libraries und shim layers.
    • Shading Language TSG (Vorsitzender: Bill Licea-Kane, AMD)
      Die The Shading Language TSG kümmert sich um alle Aspekte der OpenGL Shading Language, darunter auch die neuen Funktion benötigt in dem Longs Peak und Mt. Evans Releasen. Diese TSG koopieriert auch mit der Khronos OpenGL ES Working Group.
    • Next Gen TSG (Vorsitzender: Jeremy Sandmel, Apple)
      Die Next Gen TSG ist verantwortlich für alle Aspekte des Mt. Evans API Design.
  • One SDK to Rule Them All
    Die Ecosystem TSG hat das letzte Vierteljahr nur an einem Ziel gearbeitet: Ein OpenGL SDK abzuliefern. Das SDK soll als One-Stop-Shopping für die Tools und Referenzmaterialien dienen, welche Entwickler wünschen. Nein, es geht um das Verlangen mit der OpenGL API effizient umzugehen [Anm: Bitte die Originalzeile anschauen, der Inhalt un der Wortwitz können total falsch übersetzt sein.]
    Folgende Komponenten sollen im SDK enthalten sein:
    • Dokumentation
      Referenzdokumentation zu allen OpenGL 2.1 Core Punkten soll in allen möglichen Formaten wie HTML und PDF verfügbar sein. Mit der Zeit soll das Referenzmaterial auch die ARB-Erweiterungen enthalten.

      Neben dem relativ trockenen Referenzdokumentationen bringt das SDK auch eine Anzahl von Tutorials, welche einen durch die verschiedenen OpenGL API Fähigkeiten führen soll, von den ersten OpenGL Programm bis zu dem aktuellsten und grossartigsten fortgeschrittenen Rendertechniken. Diese Tutorials werden von den meist respektierten OpenGL Tutorialseiten aus dem Internet beigesteuert.
    • Beispiele
      Was ist ein besserer Weg um ein OpenGL Projekt zu starten als Beispielcode von irgendjemanden anderen zu benutzen? Und was ist ein besserer Weg die Vorstellungskraft anzuheizen und zu sehen was mit OpenGL alles möglich ist als ein paar innovative Demos auf dem eigenen System laufen zu lassen? Diese Kategorie wird Beispiele (mit Quellcode) und Demos (ohne Quellcode) enthalten.
    • Bibliotheken
      Niemand muss das Rad nochmal erfinden. Andere haben schon systemspezifische Fehler, die Initialisierung von Extensions, das Laden von Bildern etc. abstraktiert. Das Benutzen dieser Bibliotheken wird das Leben einfacher machen und erlaubt es einem mehr Zeit zur Entwickelung neuer Sachen in OpenGL zu verwenden.
    • Tools
      Es gibt erstaunliche Tools und Utilities die das Leben einfacher machen, wenn man OpenGL entwickelt. Falls man einen Debugger, einen Performance Profiler oder nur einen Bildkomprimierer benötigt, wird man diese in dieser Kategorie finden. Manche dieser Tools sind kommerziell verfügbar, andere sind frei.
    • Konformitätstest
      Der Erfolg von OpenGL hängt davon ab, dass alle Implementationen in der selben Art reagieren. Wenn man eine Anwendung auf einem Computer schreibt will man, dass es auf anderen genauso flüssig läuft. Das benötigt, dass die Grafiktreiber von verschiedenen Herstellern alle einer einzigen Menge von Regeln folgen: Den OpenGL Spezifikationen. Eine Menge von Test werden entwickelt, damit die Kompatibilität sichergestellt ist und Entwickler nicht den Grossteil ihrer Zeit damit verschwenden herstellerabhängigen Code zu schreiben um Inkompatibilitäten zu umgehen.
    Sieht es so aus, als ob das ARB den Mund zu voll genommen hat? Absolut. Deshalb arbeitet man mit führenden OpenGL Firmen, Open Source Projekten udn individuellen Professionellen zusammen. Das SDK wird die Sammelstelle für Beiträge aus den obigen Kategorien. Die ARB wird denoch Referenzdokumentation, Konformitätstests und other Komponenten bereitstellen, doch wo immer es möglich ist, wird man sich auf den Rest der Community stützen um das SDK auszuarbeiten.
  • The New Object Model
    Es wird aktuell an einem konsequenten Weg gearbeitet um Objektmodelle zu erstellen, bearbeiten, teilen und zu benutzen.
    Das aktuelle ObjektModell wurde über die Zeit entwickelt und hat kein gleichmässiges Design. Es hat angefangen mit den Displaylisten in OpenGL 1.0 und dann das Hinzufügen der Textureobjekte in OpenGL 1.1. Unglücklicherweise wurden diese nicht optimal implimentiert. Die Kombination von glBindTexture und glActiveTexture macht es zum Beispiel schwer den Code zu folgen oder zu debuggen. Textureobjekte können unvollständig sein und noch schlimmer: Ihr Format und Grösse können durch einen Aufruf von glTexImage neu definiert werden.
    Nach den Texturobjekten wurden neue Objekttypen hinzugefügt mit teilweise inkonsistenter Semantik. Ausserdem ist das existierende Objektmodel optimiert für die Objekterstellung und nicht für die Laufzeitgeschwindigkeit. Meiste Anwendung erstellen Objekte nur einmal, benutzen sie aber öfter. Daher macht es mehr Sinn das die Benutzung der Objekte zum Rendern nicht teuer ist. Dies ist aktuell nicht der Fall.

    Die Ziele des neuen Objektmodells sind:
    • maximale Laufzeitgeschwindigkeit
    • keine unvollständigen Objekte
    • Möglichkeit der gemeinsamen Benutzung von einzelnen Objekten über mehrere Kontexte
    • (teilweise) Eliminierung des aktuellen Bind-Semantik.

    Die maximale Laufzeitgeschwindigkeit hängt von mehreren Faktoren ab, einschliesslich der Möglichkeit der Anwendung die unterliegende Hardware so effizient wie möglich zu benutzen. In dem Kontext des neuen Objektmodells meint es, dass maximale Laufzeitperformance nur erreicht werden kann wenn der Overhead in dem OpenGL Treiber minimiert wird [Anm: Vgl. DirectX 9 mit DirectX 10]. Das neue Objektmodell reduziert den Treiberoverhead in verschiedenen Wegen:
    • Die Menge der Validierungen der OpenGL Implementation, welche beim Zeichnen anfällt, wird reduziert. Im aktuellen OpenGL kann und geschieht noch eine Menge von Validation während der Zeichenzeit, was das Rendern verlangsamt.
    • Weniger Zustandänderungen werden in dem neuen Objektmodell notwendig sein, was wieder die Laufzeitgeschwindigkeit verbessert. Als Beispiel wird die Anzahl der Bind-Operationen reduziert.
    • Das neue Objektmodell wird die Zeit reduzieren, die vom OpenGL Treiber benötigt wird um Objekt Handles nachzuschauen.

    Die Tatsache das unvollständige Objekte existieren können fügt Flexibilität in OpenGL hinzu, aber ohne einem klaren Vorteil. Sie machen es für die OpenGL Implementation schwerer intelligent Speicher für die Objekte zu reservieren, was wiederum in mehr Validation während der Renderzeit resultiert und es kann Entwickler verwirren, falls das Rendern nicht das erwartete Ergebnis produziert. Als Beispiel: Bei Textur Objekten wird immer nur ein MipMaplevel hinzugefügt. Die OpenGL Implementation hat keine Idee wieviele weitere MipMaps kommen und wieviel Speicher es noch braucht. Und wenn die Anwendung kein komplettes Set von MipMapleveln bereitstellen kann während MipMap aktiviert ist, wird die unvollständige Textur nie während des Rendern benutzt. Eine Falle die schwierig ist zu debuggen.

    Der Austauch von Objekten über Kontexte ist heutzutage ein "Alles oder Nichts" Schalter. Gefährliche Zustände können zum Beispiel entstehen falls ein Kontext ein Objekt benutzt während ein anderer Kontext die Objektgrösse ändert. Nicht zu erwähnen was passiert wenn ein Objekt in den einem Kontext gelöscht wird, während es in einem anderen benutzt wird. Dieser Fall führt aktuell zu verschiedenen Verhalten auf verschiedenen Implementationen wegen der Zweideutigkeiten in den existierenden Spezifikationen.

    Die existierende Objektmodels "bind to edit" und "bind to use" Semantik kann komplexe Seiteneffekte haben und ist im generellen verwirrend. Da ist kein guter Grund um ein Objekt an dem aktuellen Renderstatus zu binden wenn es nur editiert werden muss. Binding sollte nur auftretten, wenn das Objekt zum Rendern benötigt wird.

    Das neue Objektmodell ist entwickelt worden um die Fehler des alten zu beseitigen. Hier sind ein paar Highlights:
    • Die Objekterstellung ist atomar [Anm: Kleinste mögliche Einheit]. Alle Attribute, die zur Erstellung eines Objektes benötigt werden, werden zur Erstellungszeit übergeben. Nach der Erstellung gibt die OpenGL Implementation einen Handle auf das neue Objekt zurück.
    • Ein Objekthandle wird als ein Parameter in einem OpenGL Befehl übergeben um mit dem Objekt zu arbeiten. Die Bind Semantic zum Editieren eines Objektes ist somit Geschichte.
    • Ein Attribut kann bei der Objekterstellung angegeben werden, welches anzeigt ob das Objekt über Kontexte geteilt werden darf. Die Erstellung wird fehlschlagen falls der Typ des Objektes nicht geteilt werden kann. Kontainerobjekte wie FBOs können nicht über verschiedene Kontexte geteilt werden um zugehörige Fehlermöglichkeiten zu beseitigen. Kontainerobjekte sind billig, daher ist das Kopieren in einen anderen Kontext keine schwere Last.
    • Alle Attribute die bei der Erstellung von Objekten übergeben werden sind unveränderlich. Das meint das diese Eigenschaften von Objekten nicht später verändert werden können. Stattdessen würde von der Anwendung ein neues Objekt erstellt mit veränderten Attributen. Als Beispiel muss ein Texturobjekt seine Grösse und Dimension zum Erstellungszeitpunkt schon kennen. Nach der Erstellung kann man diese nicht mehr ändern. Die Daten im den Texturobjekt können aber noch immer verändert werden. Im alten Modell kann man die Grösse und den Inhalt mit einen Aufruf von glTexImage ändern.
      Die Trennung der Objektform und der Grösse seiner Daten hat schöne Nebeneffekte. Es entfernt das Rätselraten der OpenGL Implemenation über das Aussehen des Objektes, sodass es eine intelligente Auswahl darüber machen wieviel Speicher es benötigt. Auch macht es das Teilen von Kontexten mehr effizienter, da es gefährliche Zustande im Bezug auf Form und Grösse entfernt.
    • Es ist für die OpenGL Implementation mehr Effizient die Objekte zur Renderzeit zur validieren, was in mehr Renderperformance resultiert.
    • Das neue Objektmodell ist einfach für Entwickler zu benutzen.
    • Es werden neue Datentypen in der Form eines per-object class typedef geben, was stärkere Typenüberprüfung zur Compilerzeit erzwingt. Das soll eine nette Hilfe sein und falls eine Compilerwarnung oder -Fehler auftritt ist dies ein früher Indikator für Codingfehler. [Anm: :mrgreen: ]
    • Ein Objecthandle wird die Grösse eines Pointertypen haben auf dem die OpenGL Implementation läuft. Dies erlaubt es, aber erzwingt nicht, der OpenGL Implementation den Pointer in eine interne Datenstruktur des Handles zu speichern. This meint, dass die OpenGL Implementation sehr schnell den übergebenen Handle auflösen kann, was in eine höhere Geschwindigkeit resultiert. Natürlich kann dies auch in mögliche Crashe der Anwendung resultieren. Ein Debuglayer kann helfen diese Art von Bugs während der Entwicklung eines Titels zu finden.
    Ein Grossteil der Objekttypen wurde schon ausgearbeitet und man ist in dem Prozess des Schreibens einer Spezifikation. Sobald alle Objekttypen ausgearbeitet wurden, werden diese veröffentlicht.
  • Platform TSG Update
    Das Platform TSG ist eine spezialisierte Untergruppe des neuen ARBs was sich mit dem Problemen durch die verschiedenen Plattformimplementationen (GLX, WGL) kümmert. Auch achten sie auf generelle Betriebsystem- und Treiberintegrationsprobleme wie Platform ABIs, Treiberschnittstellen und Referenzbibliotheken.
    Als Beispiel dieses Arbeit wurde das Linux ABI im Linux Standards Base Projekt verbessert.
    Aktuell arbeiten sie an dem GLX Protokol, damit dieses VBOs unterstützt. Dies basierd auf der Arbeit von Ian Romanick von IBM welche in Mesa eingeflossen ist. Daraus soll in der relativ nahen Zukunft eine verbesserte GLX Protokol Spezifikation entstehen.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Nov 19, 2006 10:36 
Offline
Fels i.d. Brandung
Benutzeravatar

Registriert: Sa Mai 04, 2002 19:48
Beiträge: 3812
Wohnort: Tespe (nahe Hamburg)
Erst einmal ein ganz großes Dankeschön an Dich für die Übersetzung. Ich bin mir fast sicher, dass ich den englischen Text nur kurz überflogen hätte, so musste ich mir einfach die Zeit nehmen es einmal in Ruhe durch zu gehen. Bevor ich in größere Euphorie umschwenke, werde ich lieber auf Long Peak warten um zu sehen, ob die Entwickungen auch wirklich wie geplant realisiert werden konnten. Veränderungen an der API blicke ich mich gemischten Gefühlen entgegen. Müssen wir OpenGLer nun doch einmal wieder etwas neues Lernen, anstatt nur kleinere Funktionalität hinzulernen? Ich denke, wenn man sich anschaut, wie alt unsere Graphic API nun geworden ist, so wäre ein solcher Wechsel durchaus verkraftbar - sofern wir dies nun nicht im gleichen Rhythmus durchleben wie die D3Dler. Begrüßenswert finde ich, dass im Vorstand nun scheinbar nicht nur Karteileichen sitzen, sondern wirklich jene Gruppen, die auch Marktführer in dem Gebiet sind. Nichts gegen die alten Mitglieder des ARB, aber wie man Microsoft über Jahre lang mitführte, obwohl diese eigene Ziele verfolgten und was zur Hölle HP dort zu suchen hatte, die bereits Jahre zuvor feierliche Ihre Graphic Workstations verbrannt haben ... dazu die Mutter SGI, die kurz vor der Insolvenzgrenze eher in der Defensive war, anstatt neue Innovationen einbringen zu können... da macht die aktuelle Konstellation durchaus einen besseren Eindruck, vor allem wenn signalisiert wird, dass man mit anderen offenen Projekten zusammenarbeiten will.

Fazit: Ich bleibe skeptisch, glaube aber das die Richtung zumindest grob zu stimmen scheint... warten wir auf Ergebnisse ;)

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Nov 19, 2006 16:31 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Okt 04, 2006 15:42
Beiträge: 78
Wohnort: Bonn
Programmiersprache: Python, C++, Delphi
Ich bin auch mal gespannt, was dabei so rumkommt.
Auf jeden Fall gibt das einen Haufen Arbeit für DGL. Header neuschreiben 8)
Würde ja ungern von FPC/Delphi auf *würg* C++ umsteigen.

Ich hoffe nur, dass durch die ganze Vista-Problematik ATi nicht komplett den
OpenGL-Boden verliert. Wäre schade drum, wenn nVidia auf dem Gebiet konkurrenzlos
würde. (Quasi)Monopole sind eben prinzipiell schlecht (ATi wird im ARB durch AMD vertreten,
denke ich mal).


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Nov 19, 2006 17:42 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Das nenne ich mal eine OpenGL News-Meldung :D

Mich persönlich überzeugen aber erst fertige Produkte und nicht ihre Ankündigungen. Also mal sehen wie gut die das hinbekommen.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 4 Beiträge ] 
Foren-Übersicht » DGL » News


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.032s | 17 Queries | GZIP : On ]