OpenGL 4.5 ist da und es hat einige Freunde zum spielen mit gebracht.
Ich hab mich noch nicht durch die ~800 Seiten durch gearbeitet aber bisher liesst es sich normal(bis Seite 300).
Die interessantesten Features für mich sind GL_ARB_cull_distance und GL_ARB_conditional_render_inverted.
Beide sind für Optimierung, die erste Extension ist für weiteres Cullen von Primitiven innerhalb der Render Pipeline und die zweite ist eine erweiterung für conditional rendering.
Üblicherweise prüft man mit einem Frustum auf ein Spatial System und wirft dann die Daten der Render API vor die Füße.
Mit cull_distance kann man in der Shader Pipeline noch weitere dinge raus werfen, die trotz innerhalb des Frustums raus sollen, wie z.B. kleine Assets die die Performance verbessern könnten. Ich muss mir das noch genauer an gucken um das ganze Potenzial zu sehen aber bisher liest es sich interessant.
Conditional rendering ist praktisch, wenn man GPU seitige Render Befehle hat, wie z.B. Partikelsysteme oder Grass.
Man kann dann z.B. ein Query Objekt führen, welches die Frametime tracked, zerlegt sein Partikelsystem in 2 Drawcalls und abhängig von der Frametime wird der 2. Drawcall einfach weg gelassen und man bekommt ein nicht ganz so voluminöses Parktikel system aber es ist load balanced die FPS ohne zu tun.

Hier gibt es den Beta Treiber von NV für OpenGL 4.5 .

edit:
Eines der größeren neueren Features ist die glCreate... Syntax.
Üblicherweise erzeugt man sich ein Objekt mit glGenBuffers oder glGenVertexArrays und dann ruft man ein glBindBuffer oder glBindVertexArray auf.
glCreate macht beides in einer Funktion, also erzeugt ein neues objekt und initialisiert es auch sofort, statt erst beim ersten glBindBuffer auf der generierte Objekt.
Das ganze läuft unter den Punkt "Direct State Access (DSA)" und wir können uns so von einer menge Funktionen verabschieden, denn alle glBind... gibt es nicht mehr und alle Funktionen werden durch neue ersetzt. Denn die DSA API erwartet nun immer die Objekte als Parameter, statt sie zu binden.
Ich bin wie gesagt noch am angucken ab folgendes sollte wohl nun der übliche Weg sein.
Neue Variante.


Alte Variante.

Hier findet man mehr dazu.
Das VAO ist eigentlich von der Zeilen Anzahl gleich geblieben allerdings kann das nun auch einfach mal wieder verwendet werden für andere meshes mit gleicher Struktur.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Für mich ist DSA ganz klar der Gewinner
Ich bin mir sicher, dass die anderen auch ganz toll sind aber ich habe mich mit dem was die anstellen/erweitern noch nie so richtig auseinander gesetzt.

Direct State Access ist ne super Sache und ich freu mich schon darauf meine Libraries darauf umzuschreiben …
Aber von den glBind… Funktionen werden wir uns noch nicht verabschieden können. Ich kann jedenfals auf die Schnelle keine neuen Funktionen zum Übergeben von Texturen oder Buffern an Shader finden.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

joa DSA ist schon extrem cool. Aber ich hätte mir hier einfach gewünscht das wir hier einen ordentlichen Prefix bekommen statt diese komischen Namen. Also zum Beispiel: glNamedTexParameter statt glTextureParameter für glTexParameter. Sonst kann ich schon vorraussagen das hier einige Alt und Neu mischen werden.

_________________
Meine Homepage

Man hinterlegt den Pointer auf ein Texturslot, das gab es vorher schon aber man muss die Textur vorher nicht mehr binden aber ja die Funktion dafür hat ein Bind in Namen allerdings ist es keine bind Funktion.

Ich hab gestern Bindless Meshes, Bindless Uniform Buffer Object und Shader eingebaut.
Bei den Shadern hab ich erst auf shared Shader und Program Objects gesetzt aber mich dann nur für Program Object entschieden.

Man kann Shader Objekte wieder verwenden, also kompiliert sie einmal und verwendet sie zum linken von Programmen immer wieder. Man muss dann auch noch Referenzcounting für Shader Objekte machen und sich drum kümmern, dass diese auch von Programmen, die diese Attached wurden auch wieder Detached werden, sonnst hilft ein glDeleteShader garnix.

Das Bindless UBO ist ein C++ struct welches ich lustig drin rum schreibe und dann jeden Frame eine Änderung signalisiere.
Da ist die Projektions und Kamera matrix drin und der Shader kann dann über UBO Slots auf diese Daten zu greifen.
Also kein Uniform binden pro Shader pro durchlauf wie früher, sondern einmal generell binden und nur noch Änderungen Signalisieren.
Ein Shader kann dann es über die std140 und locator Shader Syntax anbinden oder auch nicht.

Ich hab ein Bug in meiner Matrix, den ich heute erstmal fixen muss, dann will ich mal MultiDrawIndirect ausprobieren.

Es gibt schon ein OpenGL 5.0 sneak peek, man plant ein kompletten API wipe.
Der Masterplan ist ein mittelweg zwischen Mantle/Metal und OpenGL 4.5 DSA.
Einige Größen von Khronos würde gerne den Weg von Mantle/Metal gehen aber das Konsortium ist so groß und muss so viele Interessen beachten, dass man ein Mittelweg gehen will.
Ganz oben auf der Liste steht auch eine neue Shader Language, welche Vorkompilierbar ist.
Erste Vermutungen sind das es auf was OpenCL ähnliches hinaus laufen wird, denn das benutzt bereits eine VM Bytecode made by Khronos.
Der Grund dafür ist, dass viele Firmen klagen das man ihre Shader klaut, denn die liegen immer als klartext vor.
In OpenGL 4.1 gibt es binary shader aber die sind nicht Cross Platform, man kann den Kompilierten Shader halt bauen und dann als Cache auf der Platte speichern und beim nächsten mal gleich das Binary nehmen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

DSA ist definitiv DAS FEATURE für mich in OpenGL 4.5. Ich nutze schon seit einiger Zeit "EXT_direct_state_access". Der Rest ist, naja, halt ganz normale neue Features wie bisher auch.

Im Moment ist das Bindless-Zeug halt noch nicht im Kern. Das wäre garantiert fantastisch und vielleicht dann in OpenGL 5 zu finden. Ich würde mir eigentlich sogar wünschen das Bindless der einzige Weg sein wird. Ein kompletter Neuanfang wäre wirklich eine sehr sehr gute Idee. Die API ist unglaublich chaotisch und es gab ohnehin bereits sehr viele Funktionen mehrfach, jetzt mit DSA nochmal verdoppelt.

Da ich keine Ahnung habe wie Mantle/Metal intern funktioniert kann ich nicht sagen ob ein Mittelweg gut sein könnte oder eher nicht.

Ich mache mir auf jeden Fall sorgen ob es was wird. Es ist auf jeden Fall gut das man außer ein paar nette Features mal ein paar Grundprobleme anpacken will, allerdings, wie du schon schreibst, gibt es wieder unterschiedliche Interessen und ich befürchte das die Aufräumaktion wieder nicht vollständig gelingt, ähnlich wie schon bei Longs Peak.

Außerdem sehe ich ein großes Problem damit dass die Neuheiten auch eingesetzt werden. Bis man die neue API wirklich zuverlässig verwenden kann werden wahrscheinlich mindestens nochmal 5 Jahre vergehen. Ich bin überzeugt das Nvidia bald funktionsfähige Treiber liefert und mit etwas Glück in "absehbarer Zeit" vielleicht sogar AMD. Aber bis Intel oder gar die freien Treiber das unterstützen, fürchte ich wird noch einige Zeit ins Land gehen. Und die nächste Sache ist, dass es auch aktiv eingesetzt wird. Bei OpenGL 3 ist das auch noch immer kaum der Fall obwohl die Unterstützung langsam akzeptabel für einige Anwendungsfälle wird. Das führt sonst zusammen mit dem geringeren Interesse und den womöglich wieder redundanten Funktionen in OpenGL von einigen Herstellern zu katastrophaler Treiberqualität und Bugs ohne Ende. Erschreckend viele verwenden immer noch OpenGL < 3 und Core Profiles so gut wie überhaupt keiner. Ich weiß von keiner Anwendung die das tut. (Außer meinen eigenen ) Ich hoffe OpenGL 5 etabliert sich besser.

Eine Shader-Zwischensprache würde ich auch sehr begrüßen. Hauptsächlich um die Zuverlässigkeit zwischen verschiedenen Herstellern zu erhöhen. Das Argument mit dem Shader-Klau verstehe ich ehrlich gesagt nicht. In der Regel sind die Techniken kein doch kein riesen Geheimnis. Außerdem sind Shader allein so gut wie nutzlos. Schließlich müssen die Shader eng mit der Engine zusammenarbeiten und könnten nicht wirklich mit Arbeitsersparnis ausgetauscht werden weil die Shader und die Engine entsprechend zusammenarbeiten müssen. Außerdem, wenn man die Shader automatisiert von Kommentaren bereinigt und alle Variablen/Methodennamen umbenennt, sind sie wohl kaum wesentlich informationsreicher als eine theoretische Shaderzwischensprache.

Mit 4.5 ist es Teil des Kerns und keine ARB, was auch Intel bereits kann.
DSA war eine gemeinsame Initiative von Intel, NV und AMD, welche auf der GDC2014 als Zero Overhead Driver gemacht wurde.
Intel hat recht gut aufgeholt und ist DX11.2 fähig und entsprechend auch bei den OpenGL Treibern OpenGL 4.5 fähig aber haben noch kein 4.5 Treiber und das gilt auch für AMD.
Der NV Treiber ist schon als Beta erhältlich und hatte ich im ersten Post gelinkt.
Ich arbeite wie schon erwähnt auf einem OpenGL 4.5 Core Context und hatte dies bzgl auch aus der neuen gl.xml mein OpenGL Code generiert.
Aktuell haben wir 699 Funktionen im Core Profile und ~930 mit Back compatible Profile in den 4.5 Specs aber es gibt nochmal einige hundert Extensions(die generiere ich nicht mit raus von daher kenne ich die Zahl nicht genau).


Unreal Engine 4 und alle damit in Produktion befindlichen Titel sind OpenGL 4.5 Fähig.
Die letzte Tech Demo läuft bereits mit MDI, DSA mit weniger als 5% Performance unterschied auf Shield und OpenGL 4.5 fähigen Android Tablets.
Es gibt ein 1h Talk von NV und Epic wie die Transition von statten lief.
Ich find leider den blöden Talk in meiner Chronik nicht, vieleicht hab ich den Zuhause an geguckt.
Einige der Erweiterungen wurden deswegen in OpenGL 4.5 gemacht, z.B. die clip Extension für UV flipping, wenn man von DX11 zu OpenGL portiert.
UE4 Tegra Showreel
Epic hat erklärt, dass die meisten Platformen auf die man abzielt kein DX können(UE4 läuft mit Editor z.B. unter Mac OSX und bald auch Linux) und man eine große Latte an Features bei DX an das Betriebssystem gebunden hat, statt Graka.
Obwohl eine Graka Shader Model5 fähig ist kann man es nicht auf Windows XP mit DX11.2 nutzen, weil MS keine Integration anbietet aber bei OpenGL es geht.

Valve hat diese Woche ihr neues Toolkit für Dota2 raus gebracht, die Neuerung ist, dass es nur als 64Bit Build und mit DX11 mindest Anforderung kommt.
Das setzt schon Zeichen wo es hin geht.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Bei Intel fehlt es halt an den Treibern. Bist du sicher das Bindless schon Teil des Kernes ist? Ich kann keine Informationen dazu finden. In "ARB_direct_state_access" ist zum Beispiel die Funktion "BindTextureUnit" spezifiziert, das würde dann irgendwie keinen Sinn machen...
Allerdings sehe ich gerade auch keine Funktion um die neuen VAOs zu binden, das verwirrt mich irgendwie gerade.

Ich glaube auch das Microsoft sich mit der Limitierung von Dx auf neuere Systeme ziemlich geschadet hat. Wenn Dx 12 wieder nur mehr auf Windows 8 laufen wird, steigt das Potential von OpenGL noch etwas...

Ich glaube hier wurden 'Bindless' und 'Direct State Access' etwas durcheinander gebracht.

Bei 'Bindless' handelt es sich um eine andere Art (ohne Binds, mit Handles) Resources an Shader zu übergeben. siehe https://www.opengl.org/registry/specs/A ... exture.txt
Das ist auch bei OpenGL 4.5 noch nicht im Core (die Extension wird auch nicht von meiner GTX560 unterstützt, also kann sie nicht in den 4.x Core).

'Direct State Access' ist eine andere Art den State von Resources zu verändern. Zwar fallen hier auch Binds weg, es ist aber etwas anderes. Zum Beispiel werden Texturen immer noch auf die alte Art an Shader übergeben (über die texture units) wodurch das limit der texture units weiterhin besteht.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Ich hab mit Bindless eigentlich DSA verstanden, weil man dort keine Binding Befehle mehr hat aber ja Bindless Texture ist eine andere Geschichte und die ist wirklich nicht im Kern

Ich hab nochmal in meine Chronik Zuhause geguckt und siehe da ich hab die UE4 OpenGL Präsi gefunden.
Die war von der GDC2014 aber leider kein Vault, von daher kann ich kein Video zu liefern.
Slides
Das Video gibt es als sponsored und Buisness Eintrag, leider bekomme ich das nicht verlinkt also einfach mal auf gdc vault in die Suche "Bringing Unreal Engine 4 to OpenGL" und da gibt es dann auch die Slides und das Video.

Was mich noch sehr interessiert sind Sparse Texture, hat da mal wer mit gespielt ?
Ich hab einige Videos bei youtube gesehen und die Tiled Resource Demo von DX11.2.
In Kombination mit Compute shader kann man da bestimmte tolle Heightmaps für Planeten basteln
edit:Oder sowas sparse shadow map

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also ich beschäftige mich zur Zeit mit Terrainrendering und kam zu der Erkenntnis, dass es eigentlich nicht all zu viele Vorteile bringt das Terrain als Texture vorliegen zu haben. Ich habe lange darüber nachgedacht aber im wesentlichen bietet es keine Nachteile das Terrain einfach in einen Vertex Buffer zu stecken. Das ist vermutlich schonender für die GPU und bietet kaum Nachteile. LOD wäre mit Tesselation vielleicht ein wenig einfacher, ist aber auch keine große Sache.

Auf Arbeit haben wir nur Old School OpenGL 1.5 mit ein paar Extensions für die Render Pipeline und liefern Heightmaps aus einem Atlas und bauen on the fly ein VBO draus. In den VBO ist dann noch die Differenz zwischen den aktuellen Punkt und dem Schnittpunkt auf Y-Achse zur nächsten LOD Stufe.
Der Shader tut dann über Kamera zu Vertex Distanz diese Informationen mit drauf addieren und somit haben wir keine Löscher und ein morphing Lod.
Ich hab letzte Woche gelesen, dass die aktuelle Frostbite Engine und der letzte Battlefield Teil es aus so machen aber noch viel mehr Maps für Texturen verwenden und noch eine Destruction Map mit liefern, welche die Höhe noch zusätzlich modifiziert.
Diese Map wird verwendet, damit die Artists nachträglich noch Gelände Einebnen können, Straßen, Flüsse den Untergrund korrigieren können und Größere Explosionen das Terrain zur Laufzeit modifizierbar macht.
Die Heightmaps kommen aus World Machine 2 und deren Destruction Maps aus den eigenen Editor.
Auf den Geräten wo Tesselation verfügbar ist wird es verwendet, sonnst einfach per CPU mehr Triangles erzeugt und per Shader, Normal Map displaced.

Das ganze gefällt mir ned, weil World Machine 2 echt blöd zu nutzen ist.
Das wird nur von ein Hobbyisten entwickelt und das läuft auf CPU :\
Okey man kann sich die Nodes per Plugins selber nach bauen und auf OpenCL/Cuda laufen lassen aber das ist ein bisschen Aufwand.
Wir haben recht lange gebraucht um unser custom Exporter Plugin für zu schreiben.

Ich hatte mir überlegt Sparse Textures aus zu probieren und es mit Compute Shader zu paaren.
Wenn ein Tile angefordert wird, dann lade ich die Nodes, die für den Tile notwendig sind aus einer File und jage Stück für Stück die Compute Shader über den gleichen Buffer und bekomme die Heightmap und Splat Map für das Tile.
Tesselation, normal generierung und Geometry lasse ich per Geometry und Tesselation Shader bauen.
Sollte mir das nicht schnell genug sein, kann ich die Tiles dann auf die Platte raus speichern und die künftig nehmen ^^
Ich hab schon Hydraulic erosion Systeme für GPU gesehen, die in Echtzeit funktionieren und das sind Schritte, die ich nur einmal wesentlich gröber machen will.
World Machine 2 braucht auf mein 4 Kern System 30min für eine recht komplexe Heightmap von 256k*128k Ausmaß.
Durch die sparse texture erhoffe ich mir die Arbeit über die Zeit aufteilen zu können und mit Compute Shader es stark zu beschleunigen.
Mal sehen, was die Realität mir bereit hält ^^

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Da dürfte für dich auch GL_ARB_sparse_buffer interessant sein (hab ich grad erst entdeckt).
Damit könntest du alle heightmap Daten in ein sparse VBO schmeißen und so die Verwendung von multi-draw-indirect vereinfachen. Vor allem kannst du die tiles dann auch gleich auf der GPU cullen (in einem call) und in einen DRAW_INDIRECT buffer schreiben.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Ja ich wollte mit den Sparse Buffer rum hantieren, ich hab noch nicht in den Workflow geguckt aber ich werde die Woche wohl dazu kommen.
Ich hab gestern die Quaternion Kamera fertig gemacht und die läuft nun über ein UBO, was mir das ganze uniform binden erspart.
Dann hab ich eine PlanetRendererBehaviour Klasse angelegt und einer Entity zugewiesen, so dass ich nun mit dem Planeten rendering anfangen kann.
Ich will erstmal versuchen über bezier tesselation aus einem cube ne sphere zu machen und dann heightmaps ein zu pflegen.
Die Heightmap will ich über sparse texture machen, jedes mal ,wenn die gpu ein Tile anfordert, dann will ich eine Reihe von ComputeShadern über den Tile jagen(erstmal simples perlin noise, dann erosion und dann realistischere Ansätze durch voronoi).
Da will ich hin arbeiten.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Nicht topic aber die Notification betraf diesen Thread, speziell Shaijan's Post.
Die E-Mail Notification hat mein Exchange Server geschluckt, weil in der Mail Shaijan stand und das Wort/Name auf irgendeiner der größeren Blacklisten steht.
Die Notification durch sein Post, von Freitag, wurde aber noch durch gewunken.
Hatte schon mal wer Probleme bzgl. der Usernamen und Blacklists ?
Ich guck eigentlic nie in meinen Spamfilter, ausser heute, weil ich die Notification Mail vermisst hab.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also diese neue variante die API anzusprechen (die Puffer als parameter zu übergeben) ist so logisch und klar, dass man sich fragt, wieso man das nicht schon ewig so gemacht hat.
Vermutlich bestand die Angst, dass man früher sowas programmiert hätte (und massives Rebinding im Treiber verursacht hätte):

doWithBufferX(buffer1, param1, param2);
doWithBufferX(buffer2, param1, param2);
doWithBufferY(buffer1, param1, param2);
doWithBufferY(buffer2, param1, param2);

_________________
Blog: kevin-fleischer.de und fbaingermany.com