Anfang der Woche hat Khronos die finale Specs für OpenGL 4.4 veröffentlicht, und wir haben unseren Header entsprechend aktualisiert. Ihr findet ihn wie gewohnt auf der entsprechenden Wiki-Seite,

Unterstützt werden wie gewohnt Free Pascal (Windows, Linux, MacOSX) und Delphi (Windows, k.a. wie es hier mit MacOSX aussieht da dort ja FM genutzt wird).

Folgende Extensions sind neu in OpenGL 4.4. :

• GL_ARB_buffer_storage
• GL_ARB_clear_texture
• GL_ARB_enhanced_layouts
• GL_ARB_multi_bind
• GL_ARB_query_buffer_object
• GL_ARB_texture_mirror_clamp_to_edge
• GL_ARB_texture_stencil8
• GL_ARB_vertex_type_10f_11f_11f_rev

Ausserdem wurden noch ein paar Hinweise aus der Community berücksichtigt :

• Neue Funktion zum Auslesen der Extensions für GL 3.0+ (Dank an Frenk)
• Fehlende Funktionen für GL_EXT_direct_state_access hinzugefügt (Dank an Frenk)
• cdecl für glXGetVisualFromFBConfig (Dank an Traude)

Wer also eine neue GPU bestitzt die vom Hersteller schon mit GL 4.4-Treibern versehen wurde (afaik bisher nur NVIDIA) kann ab jetzt also GL4.4 nutzen.

Feedback ist wie immer gerne gesehen, v.a. da Khronos im Vergleich zu GL 4.3 in ihren eigenen Headern einiges verändert hat und es dadurch diesmal beim Updaten etwas schwieriger war. Im Diff-Betrachter sieht dass zwischen 4.3 und 4.4. fast ganz rot aus

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Dann hol ich mir mal gleich neue Treiber und lad nen neuen Report hoch

EDIT:

Wäre mal schön, wenn glCaps zwei Grakas handeln könnte...

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Zwei verschiedene? Das geht afaik nicht so ohne weiteres via OpenGL, da müsste man was übers OS coden.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Meine Erfahrung (zm. wenig Jahre, aber egal ):

Linux hat damit generell Probleme... (Ubuntu kriegt man damit überhaupt nicht zum Laufen, ohne eine Abzustellen, dazu gehören auch [*Füge Alphabet ein*]Ubuntu Distris)

Mac hab ich nicht (wäre schön wenn du mal meine Header, falls du Zeit hast, auf einem Mac Rechner testen könntest )

bleibt ja nur noch eines über...

Ist halt zm. nervig sich durch X Untermenüs klicken zu müssen um für ein Programm eine Ausnahme hinzuzufügen...

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Mhh, ich hab ne OnChip graka und eine gf490 und weder Fedora noch Win7 hat probleme bei mir.
Um Grakas direkt an zu sprechen, guck einfach mal in folgendem Link.
http://www.opengl.org/discussion_boards/showthread.php/173030-How-to-use-OpenGL-with-a-device-chosen-by-you?p=1212623&viewfull=1#post1212623
Ich benutzte EnumDisplayDevices um die Grakas aus zu lesen und mach das noch zusätzlich mit SMBIOS.

Wenn ich das letzte Woche richtig gelesen hab, dann ist die NV extension, zum erhalten und nutzten der VRAM pointer, eines beliebigen Objektes, nun ARB. Die 2. große Neuerung ist das nutzen von Texturen ohne diese auf ein Texturslot binden zu müssen, was Theoretisch gesehen soviele Texturen zu lässt wie man Speicher hat.
Letzlich ist die Wichtigkeit von Features für jeden anders, je nach dem was er so macht.
So werden für einige auch ganz andere Neuerungen wichtig sein.

Allderings muss ich sagen, dass DX11.2 mit tiled resource OpenGL aktuell vorraus ist.
Kann man hoffen, dass OpenGL 4.5 oder 5.0 recht zügig kommt und es enthält.
http://www.youtube.com/watch?v=QB0VKmk5bmI
Das ist aktuell DX11.2 ihr größtes Feature und auf Win8.1 und DX11.2 Fähigen Grakas limitiert.
Ein weiteres Feature ist das neue Swap-Chain, was ich auch in OpenGL gerne sehen würde.
Swap-Chain erlaubt mehrere Renderbuffer mit unterschiedlichen Auflösungen zu mergen, skalieren, unterschiedlichen Frameraten zu aktualisieren und einiges mehr.
Das macht Sinn, wenn man UI mit Nativer Auflösung laufen lassen will und das Spiel selber in einer anderen Auflösung laufen lässt. Swap-Chain erlaubt dies ohne weitere FBO, Shader, GPU-Zeit, da das alles in der Hardware gegossen ist und nicht von den Shader Units gemacht wird.

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

Projekte: https://github.com/tak2004

Gibt es keine einzigste neue Core-Funktion?

Klingt so als wäre hier alles für ARB und Extensions, höchstens die Funktion zur ABFRAGE nach Extension scheint hier Core zu sein.


... Oder hab ich hier doch noch was übersehen?

Das sind alles Core-Funktionen. Keine der Funktionsdeklarationen besitzt eine abehängtes ARB.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wenn ich SDL benutze, dann initialisiere ich OpenGL so:

InitOpenGL;
ReadExtensions;
ReadImplementationProperties;

und sage dem SDL_OpenGL_Context dann so:


SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);

Welche Version er haben soll. Das Problem was ich jetzt hab:

Ich würde gerne den DGL-Funktionen per Parameter sagen können welche Funktionen geladen werden sollen:

InitOpenGL(3,0);

Sodass dann nur die Funktionen ab v. 3,0 geladen werden. Könnte das vllt. in der nächsten Version implementiert werden? (hab leider momentan nicht genug Zeit das selbst zu tun...)

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Kann unser Header schon seit einiger Zeit :

Damit gibts einen Vorwärtskompatiblen 4.2 Renderkontext.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Aber das funktioniert meines Wissens nicht mit SDL, da es ja einen eigenen Context erstellt.

Ich muss ja nur die Funktionen laden.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Was genau willst du denn machen? Nur Funktionszeiger ab Version x.y laden, oder (was die obige Funktion macht) einen vorwärtskompatiblen Kontext erstellen? Ersteres kann unser Header nicht.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

G-Truc hat ne Review über die neue OGL Version gemacht http://www.g-truc.net/post-0586.html

Da schreibt er, dass es eine Alternative zu tiled resource in OGL4.4 gibt.
Man kann 16k*16k Texturen Virtuell in den Speicher legen und werden OnDemand vom Speicher geladen(nvidia hat ne shadowmap demo mit gemacht).

Des weiterem gibt es ein Texturlademechanik, welche mehrere Texturen laden, binden und auch sauber per Hardware filtert.
Dies ist praktisch, wenn man auf PTex setzen will, was der Trend der kommenden Generation sein soll.
Hier ne AMD demo die noch die vorige Extension verwendet.

Interessant finde ich auch das neue Texturformat welches 10R 11G 11B aufgebaut ist und für HDR bzw. genauere Normalmap verwendet werden kann.

Interessant ist auch im Forcast, wo er glaubt, dass VBO, FBO und co mit der nächsten Version raus können, da man nun ressourcen direkt im shader zugreifen kann und kein binding mehr notwendig ist.

Update: Ich sehe gerade, dass man das alles ab GF400 verwenden kann.
Schön, dass die die Karten so generisch designed haben, dass man nicht mehr die neuste Karte braucht ^^
Mit dem alten T&L basierten Karten wäre das ein Ding der unmöglichkeit gewesen.

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

Projekte: https://github.com/tak2004

Bin ja mal gespannt wann ATI nachziehen. NVidia haben ja nen passenden Treiber, und ATI haben jetzt (!) ne Beta vom 13.8er rausgebracht der 4.3 komplett (!) unterstützt :/

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ersteres bräuchte ich tatsächlich.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Warum genau? Willst du die exe klein halten? Das wäre nämlich eine recht umfangreiche Änderung am Header, und dafür hab ich momentan nicht wirklich die Zeit.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)