Unsere OpenGL Header wurden um einige kürzlich neu veröffentlichten OpenGL-Extensions erweitert :

- GL_ARB_ES3_2_compatibility
- GL_ARB_fragment_shader_interlock
- GL_ARB_gpu_shader_int64
- GL_ARB_parallel_shader_compile
- GL_ARB_post_depth_coverage
- GL_ARB_sample_locations
- GL_ARB_shader_atomic_counter_ops
- GL_ARB_shader_ballot
- GL_ARB_shader_clock
- GL_ARB_shader_viewport_layer_array
- GL_ARB_sparse_texture2
- GL_ARB_sparse_texture_clamp
- GL_ARB_texture_filter_minmax
- GL_INTEL_framebuffer_CMAA
- GL_KHR_no_error
- GL_NV_conservative_raster_dilate
- GL_OVR_multiview
- GL_OVR_multiview2

Getaggtes Release
GitHub Repository

Wer also eine aktuelle Grafikkarte mit neuen Treiber besitzt darf jetzt auch die neusten OpenGL Funktionen mit Pascal/Delphi verwenden. Zumindest NVidia haben bereits Treiber veröffentlicht die z.B. das parallele Kompilieren von Shadern unterstützen (GL_ARB_parallel_shader_compile).

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

Hmm, ich hab die woche gelesen, dass NV GPUs garnicht für Parallele Arbeit von Rendering und Compute ausgelegt sind und einige andere Sachen(parallel Shader bauen) nicht gleichzeitig sauber funktionieren(massive performance einbrüche, wegen Context wechsel).
http://www.heise.de/newsticker/meldung/Async-Shaders-Fehlende-DirectX-12-Funktion-auf-Nvidia-Grafikkarten-ein-vollkommenes-Desaster-2801497.html

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

Projekte: https://github.com/tak2004

Ja, das stimmt zumindest teilweise. Maxwell hat wohl Probleme mit Async Compute, da muss man schauen dass man unter 1ms beim Wechsel bleib. Wohl weil Compute und Graphics nicht gleichzeitig geht. NVidia will das wohl im Treiber nachbessern, was dann aber natüriich wieder CPU ist und da dann Cycles kostet. Mal schaune, bisher war AMD ja besonders bei vielen DrawCalls CPU-gebunden, hoffentlich passiert bei NV nicht das selbe. Problem sind halt die Konsolen die alle mit GPUs auf GCN-Basis laufen bei denen ASync Compute dann problemlos funktioniert. Da werden die Engines also entsprechend angepasst, das könnten als auf aktuellen NV-GPUs kritisch werden.

Was das parallele Kompilieren von Shadern angeht : Auf meiner GTX980 ist das Limit bei 2, also nicht wirklich hoch. Müsste mal ausgiebig testen obs was bringt. Rein technisch sollte das ASync Compute Problem ja keine Auswirkungen auf das Kompilieren und Linken der Shader haben.

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

So wie ich das verstanden habe, ist das Problem mehrschichtig.
Es fehlt zum einen Schaltkreise auf der GPU und zum anderen ist der Treiber nicht auf Context switches ausgelegt.
Das zweite ist wohl das Problem wieso diverse andere OGL 4.5/DX12 Sachen Performancetechnisch in den Keller gehen.

Laut Artikel hat NV auch Benchmark hersteller/Tester gebeten die entsprechenden Test aus dem Benchmarks und Artikeln raus zu lassen.
Oxide(hat stark mit AMD und Mantle gearbeitet) hat diesen versuch öffentlich gemacht und darauf kamen wohl noch einige andere Firmen(was dann NV in einen schlechten Licht darstehen lässt).
Der Betrug mit den 3,5GB Ram schnell Anbindung statt 4GB oder das verbauen von weniger Processing Units als in den Specs steht hat NV schon nicht gut verkraftet.
Bei den geht es wohl einiges nicht mehr so richtig rund innerhalb der Firma.


Sind in der XBox One und PS4 sind doch AMD CPU/GPU.


Ich hab bisher noch nie nen Punkt erreicht wo die Drawcalls auf mein AMD Systemen groß Einfluss auf die CPU hatte.
Das höchste aller Gefühle in ein Game was ich an Drawcalls hatte war 5k aber um die 3k sind eher normal und das auch nur weil wir nie über OGL2 raus sind.


Ich kann ja mal auf meiner Fury X testen, wenn ich Zuhause bin, auf Arbeit hab ich ne 980.

Mich interessiert ASync Compute so sehr, weil die GPUs mitlerweile so schnell sind und es beim Rendern Engpässe gibt, dass in diesen man Prima Compute Shader quetschen könnte.
Wenn man von einem Pass zum nächsten geht, hat man in der Regel noch einiges auf der CPU zu tun(sortieren, raus filtern, updates,..., sync point) während dessen kann man z.B. kleine Jobs laufen lassen z.B. Texturen verarbeiten, GPU-Based Partikel simulieren oder Global Ilumination(kleine Anzahl an Rays schiessen).
Bzw. wenn man OIT verwendet, kann man dann die Listen sortieren, damit beim nächsten durchlauf caches besser greifen.
Die letzte Engine mit der ich gearbeitet hab war eine OGL2 Engine mit 3/4 Extensions und im Profile war die GPU vor Swap auf hochtour und danach bis zum nächsten Swap ziemliche flaute.
Was an ein zu einfachen Gameloop lag und die hab ich schon zig mal in Unity Games gesehen.

Wenn die CPU 5ms braucht um die ersten 3 Punkte ab zu arbeiten, dann kann im besten Fall noch 200FPS raus kommen, weil nur in "Renderer"(bei älteren OpenGL durch Sync stark ausgebremst) und "Swap" die GPU läuft.
Das schlimmere, was die Designer bei der Loop nicht sehen ist, dass Physik und Sound oft Synchron/Deterministisch arbeiten, also alle Schritte nachholen, wenn sie zu spät dran sind.
Wenn also 15ms in den Updates verbracht wird, dann 20ms im Rendering hat man 35ms, also ~28FPS, sollte man die Physik und Sound auf 60FPS getaktet haben, holen die im kommenden Update erstmal 1 Update nach und damit wird das ganze Update langsamer und das System schaukelt sich zusätzlich ein bisschen hoch.

Es hilft also nicht, tolle Bindless APIs, parallel Shader zu kompilieren und laufen zu lassen, wenn das Design schon hinkt.

Hätte wesentlich mehr Zeit gesparrt, als alle OGL Optimierungen zusammen.

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

Projekte: https://github.com/tak2004

Schade, GL_MAX_SHADER_COMPILER_THREADS_ARB lässt sich auf aktuellen NVidia-Treibern nicht auslesen, obwohl die Extension dafür vorhanden ist. Gibt mir immer ein "Invalid Enum" zurück.

Eigentlich wollt ich dazu heut ne Demo basteln un den OpenGL CapsViewer erweitern :/

Außer AMD unterstützt die Extension wohl momentan eh kein anderer IHV...

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