OpenGL wird dieses Jahr komplett durch Vulkan ersetzt

[floorball]

hustbaer schrieb:

Na bin schon gespannt wie DX12 und Vulkan so performen. Was MS so über DX12 erzählt klingt ja sehr vielversprechend.

Ziemlich genau der gleiche Performancezuwachs wie mit Mantle.Hier ein Vergleich mit der Star Swarm Demo. Wobei DirectX12 noch beta-Status hat. Glaub allerdings nicht das sich da noch viel an Performance verändert, ist ja schon so schnell wie Mantle.

EDIT: so wirklich vielversprechend find ich das nicht, auch nur das was Mantle macht.

Kellerautomat schrieb:

Wo bleiben die Docs?

Zu Vulkan findet nur https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf. Und da liest man nur was von CommandBuffern wie man sie aus DirectX 11 kennt. Absolut revolutionär...
Ah und SPIR-V womit man seine Shader schon von vornherein kompilieren kann, was man von DirectX 9 (korrigiert mich falls ich falsch lieg, aber ich meine das war von Anfang an dabei) her kennt. Ist ja noch viel revolutionärer
Ah und eine API auf allen Geräten (PC, Handy) was so auch schon von DirectX 11 kennt (ok jetzt hör ich auf ) und (was so noch nicht kannte) Autos, 3D-Drucker (wtf??) Drohnen (noch mehr wtf, Hä? was soll das andere Beispiel hätten nun wirklich besser gepasst), etc...

Ok fairerweise sollte man wohl dazu sagen, dass Vulkan auch nicht wirklich revolutionär sein soll, sondern einfach nur Overhead reduzieren soll. Und das wird es wohl hinkriegen.

Naja, alles in allem ist das alles irgendwie längst überflüssig. Nur den Namen hätten sie nun wirklich nicht ändern müssen.

floorball

[hustbaer]

Ach watt, (EDIT: der Name) OGL Next ist doch doof, Vulkan ist viel kuhler

[rapso]

floorball schrieb:

hustbaer schrieb:

Na bin schon gespannt wie DX12 und Vulkan so performen. Was MS so über DX12 erzählt klingt ja sehr vielversprechend.

Ziemlich genau der gleiche Performancezuwachs wie mit Mantle.Hier ein Vergleich mit der Star Swarm Demo. Wobei DirectX12 noch beta-Status hat. Glaub allerdings nicht das sich da noch viel an Performance verändert, ist ja schon so schnell wie Mantle.

wobei StarSwarm sehr unoptimiert rendern wie hier zu lesen ist und mit den normalen optimierungen vermutlich auf beiden platformen noch schneller waere.

Kellerautomat schrieb:

Wo bleiben die Docs?

Zu Vulkan findet nur https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf. Und da liest man nur was von CommandBuffern wie man sie aus DirectX 11 kennt. Absolut revolutionär...

auch DX12 optimiert auf diese weise, ich denke das indiziert dass da doch ein unterschied sein muss

Ah und SPIR-V womit man seine Shader schon von vornherein kompilieren kann, was man von DirectX 9 (korrigiert mich falls ich falsch lieg, aber ich meine das war von Anfang an dabei) her kennt. Ist ja noch viel revolutionärer

wobei SPIR-V als intermediate language dient, das bedeutet, dass der schwerpunkt auf flexibilitaet und ausdrucksstaerke liegt. das directX binary ist auf der anderen seite schon stark optimierter opcode und die driver muessen manchmal viel magic machen um rauszufinden was gemacht wird und es geht manchmal schief. Es ist eher wie PTX von nvidia wuerde ich sagen.

Ah und eine API auf allen Geräten (PC, Handy) was so auch schon von DirectX 11 kennt (ok jetzt hör ich auf ) und (was so noch nicht kannte) Autos, 3D-Drucker (wtf??) Drohnen (noch mehr wtf, Hä? was soll das andere Beispiel hätten nun wirklich besser gepasst), etc...

gibt es von opengl ja auch schon ewig. wenn der driver das supportet kannst du auch auf dem handy opengl4.4 nutzen (z.B. auf den shield devices von nvidia).
ist glaube was die sagen wollen ist dass es einheitlicher wird. ich glaube du kannst bei DX11 auf handy z.b. nicht tesselation oder sowas nutzen.

Ok fairerweise sollte man wohl dazu sagen, dass Vulkan auch nicht wirklich revolutionär sein soll, sondern einfach nur Overhead reduzieren soll. Und das wird es wohl hinkriegen.

wobei das meiste nur CPU beschleunigen soll. auf PCs (gerade mit intel CPU) bringt das nicht viel da die meisten spiele GPU bound sind, einfach deswegen weil, wenn du noch performance uebrig hast, drehen die leute aufloesung, filterung, antialiasing, features auf bis es eben GPU limitiert ist. und wenn du am GPU limit bist, wird es kaum etwas bringen Mantle/Vulkan/DX12 zu nutzen... z.B. http://www.anandtech.com/show/8998/directx-12-star-swarm-intel-igpu-performance-preview

Naja, alles in allem ist das alles irgendwie längst überflüssig. Nur den Namen hätten sie nun wirklich nicht ändern müssen.

finde ich nicht. ich finde den NVidia ansatz mit ein paar nuetzlichen extensions besser. damit bekommst du die ganze moegliche performance und mit minimalem investment.

[floorball]

rapso schrieb:

auch DX12 optimiert auf diese weise, ich denke das indiziert dass da doch ein unterschied sein muss

Aus Sicht des Programmierers auf jeden Fall schon mal nicht .
Auch ansonsten dürfte meiner Meinung nach kaum ein Unterschied sein, na gut in Zukunft werden wohl auch Intel und AMD Command Lists Treiberseitig unterstützen aber das macht NVidia ja auch schon länger.
DX12 unterteilt außerdem nochmal zwischen Command Lists und Bundels damit die Treiber wissen was sie cachen sollten und was nicht.

rapso schrieb:

finde ich nicht. ich finde den NVidia ansatz mit ein paar nuetzlichen extensions besser. damit bekommst du die ganze moegliche performance und mit minimalem investment.

Ich glaube OpenGL fährt in Zukunft auch zweigleisig, d.h. Es wird wohl OpenGL 5 und Vulkan geben und bei DX wird es wohl DX11.3 und DX12 geben. So gesehen ist nichts verloren.

floorball

[Marthog]

rapso schrieb:

Naja, alles in allem ist das alles irgendwie längst überflüssig. Nur den Namen hätten sie nun wirklich nicht ändern müssen.

finde ich nicht. ich finde den NVidia ansatz mit ein paar nuetzlichen extensions besser. damit bekommst du die ganze moegliche performance und mit minimalem investment.

Das Problem ist, dass OpenGL 20 Jahre ballast mit sich rumschleppt. Von frueher hat man noch solche Funktionen, um die translation und rotation einzeln zu setzen und Punkte einzeln zu rendern.
Heutzutage wuerde man so eine API gar nicht mehr bereitstellen, sondern maximal noch fertige Matrix setzen, index- und vertexlist rendern, wenn man nicht gleich das buffer vertex object rendert.
Frueher hatte man noch einzelne features, wie alpha-blending, die man einzeln aktivieren konnte. Heutzutage sind Grafikkarten frei programmierbar. Vulkan arbeitet statt mit einzelner Textur- und Objektdaten direkt auf dem Speicher der Graka.
Dieser ganze Kram ist zum einen fuerchterlich unuebersichtlich zum lernen und zum anderen ist es sehr schwer, ausreichend vollstaendige Implementierungen zur Verfuegung zu stellen. Es gibt auch in den offiziellen Implementierungen der Grafikkartenfirmen viele Features, die kaum getestet sind und Mesa haengt noch bei OpenGL 3.3.

Wenn man ein modernes Programm mit OpenGL schreibt, muss man erstmal jede Menge Extensions aktivieren und aufpassen, dass man die herstellerspezifischen optional macht.

rapso schrieb:

Ah und eine API auf allen Geräten (PC, Handy) was so auch schon von DirectX 11 kennt (ok jetzt hör ich auf ) und (was so noch nicht kannte) Autos, 3D-Drucker (wtf??) Drohnen (noch mehr wtf, Hä? was soll das andere Beispiel hätten nun wirklich besser gepasst), etc...

gibt es von opengl ja auch schon ewig. wenn der driver das supportet kannst du auch auf dem handy opengl4.4 nutzen (z.B. auf den shield devices von nvidia).
ist glaube was die sagen wollen ist dass es einheitlicher wird. ich glaube du kannst bei DX11 auf handy z.b. nicht tesselation oder sowas nutzen.

Ich denke, mit dem einheitlichen meinen sie, dass damit OpenGL und OpenGL ES zusammengefasst wird und beim Design auch WebGL Anbindung mit bedacht wurde.

[rapso]

floorball schrieb:

rapso schrieb:

auch DX12 optimiert auf diese weise, ich denke das indiziert dass da doch ein unterschied sein muss

Aus Sicht des Programmierers auf jeden Fall schon mal nicht .

gerade aus sicht des programmierers. niemand anderes wird einen unterschied sehen

Auch ansonsten dürfte meiner Meinung nach kaum ein Unterschied sein, na gut in Zukunft werden wohl auch Intel und AMD Command Lists Treiberseitig unterstützen aber das macht NVidia ja auch schon länger.

es hat mehr mit DX2 commandbuffern zu tun als mit DX11

DX12 unterteilt außerdem nochmal zwischen Command Lists und Bundels damit die Treiber wissen was sie cachen sollten und was nicht.

primaerer grund von bundles ist dass treiber sie compilieren koennen. quasi sowas wie renderlist compilieren bei opengl.

[rapso]

Marthog schrieb:

Das Problem ist, dass OpenGL 20 Jahre ballast mit sich rumschleppt.

nein, nicht wirklich, sowohl bei openGL ES wie auch opengl (ich glaube) 3.3 sind veraltete funktionen nicht mehr supportet. der balast ist also schlimmstenfalls ein paar jahre alt (vielleicht DX10 zeit).

Von frueher hat man noch solche Funktionen, um die translation und rotation einzeln zu setzen und Punkte einzeln zu rendern.
Heutzutage wuerde man so eine API gar nicht mehr bereitstellen, sondern maximal noch fertige Matrix setzen, index- und vertexlist rendern, wenn man nicht gleich das buffer vertex object rendert.

das aktuelle opengl hat das nicht.
du kannst natuerlich die alte API aufgreifen, aber du kannst wohl auch noch directX 5 initialisieren.

Frueher hatte man noch einzelne features, wie alpha-blending, die man einzeln aktivieren konnte. Heutzutage sind Grafikkarten frei programmierbar. Vulkan arbeitet statt mit einzelner Textur- und Objektdaten direkt auf dem Speicher der Graka.

es arbeitet weiterhin mit textur und objektdaten. auch mantle macht es so, obwohl du gewisse kontrolle ueber den speicher hast, es ist weit von dem entfernt was du z.b. in C unter "kontrolle" verstehst.

Dieser ganze Kram ist zum einen fuerchterlich unuebersichtlich zum lernen und zum anderen ist es sehr schwer, ausreichend vollstaendige Implementierungen zur Verfuegung zu stellen.

mit Vulkan bzw DX12 wird es fuer die hersteller einfacher. viele dinge die der treiber gemacht hat sind dann auf deiner seite. Vom eigentlichen treiber bleibt nur noch der unterste layer der wirklich nur daten ein wenig aufbereitet und zur GPU schiebt. synchronisierung, etc. liegt dann alles bei dir. zwar nicht so schoen und frei wie auf konsolen, aber dennoch weit mehr in deiner hand als opengl.

wenn es nach mir ginge, waere es noch ein bisschen lower level. so wie es jetzt ist, ist es relativ abstrakt, sodass du eigentlich alles an kontrolle hast, aber du weisst nicht 100% was passiert, weil es relativ platformuebergreifend sein muss. es muss auf NVidia, ATI, Intel, PowerVR, Qualcom etc. laufen. unter windows, android, linux, osx. Es muss funzen wenn sich windows in hybernation legt und wenn android dir den halben speicher wegnehmen will. etc etc.

Wenn man ein modernes Programm mit OpenGL schreibt, muss man erstmal jede Menge Extensions aktivieren und aufpassen, dass man die herstellerspezifischen optional macht.

muss man eigentlich nicht, mit latest opengl hast du echt viele moeglichkeiten, eigentlich soviel wie mit DX11 und damit werden schliesslich die allermeisten spiele gemacht.

rapso schrieb:

Ah und eine API auf allen Geräten (PC, Handy) was so auch schon von DirectX 11 kennt (ok jetzt hör ich auf ) und (was so noch nicht kannte) Autos, 3D-Drucker (wtf??) Drohnen (noch mehr wtf, Hä? was soll das andere Beispiel hätten nun wirklich besser gepasst), etc...

gibt es von opengl ja auch schon ewig. wenn der driver das supportet kannst du auch auf dem handy opengl4.4 nutzen (z.B. auf den shield devices von nvidia).
ist glaube was die sagen wollen ist dass es einheitlicher wird. ich glaube du kannst bei DX11 auf handy z.b. nicht tesselation oder sowas nutzen.

Ich denke, mit dem einheitlichen meinen sie, dass damit OpenGL und OpenGL ES zusammengefasst wird und beim Design auch WebGL Anbindung mit bedacht wurde.[/quote]das hoffe ich auch. feature maessig sollten die GPUs alle gleich sein. sollte keinen grund geben APIs fuer mobile extra zu machen, Vulkan soll ja vor allme CPU seitig sparen und das ist die schwachstelle von mobile bisher.

[floorball]

rapso schrieb:

floorball schrieb:

rapso schrieb:

auch DX12 optimiert auf diese weise, ich denke das indiziert dass da doch ein unterschied sein muss

Aus Sicht des Programmierers auf jeden Fall schon mal nicht .

gerade aus sicht des programmierers. niemand anderes wird einen unterschied sehen

DX11 Command Lists:

ID3D11DeviceContext* d3d11DefferedContext;
d3d11Device->CreateDefferedContext(... , &d3d11DefferedContext); //Erstellen

d3d11DefferedContext->BlaBlaBla(...); // Kommandos Speichern
ID3D11CommandList* commandList;
d3d11DefferedContext->FinishCommandList(... , &pd3dCommandList); //Schließen

d3d11DeviceContext->ExecuteCommandList(commandList, ...); //Abspielen

Wo ist der Unterschied (für den Programmierer) zu z.B. DX12 Bundels, die in etwa so aussehen werden:

pDevice->CreateCommandList(D3D12_COMMAND_LIST_TYPE_BUNDLE, pBundleAllocator, pPSO, pDescriptorHeap, &pBundle); //Erstellen 
pBundle->BlaBlaBla(...); //Kommandos Speichern
pBundle->Close(); //Schließen
//Nichts konkretes dazu gefunden wie bundles abgespielt werden, vermutlich aber von CommandLists aus
pCommandList->ExecuteBundle(pBundle, ...); //Abspielen

Auch ansonsten kann (und soll(te)) man DX11 Command Lists benutzen wie DX12 Bundles.
Wieso sollte auch gerade für den Programmierer ein Unterschied zu sehen sein

rapso schrieb:

es hat mehr mit DX2 commandbuffern zu tun als mit DX11

Und unter NVidia werden DX11 Command Lists als Command Buffer realisiert. Unter AMD und Intel nicht. Oder versteh ich hier was falsch?

floorball

[rapso]

floorball schrieb:

Wo ist der Unterschied (für den Programmierer)

bei dem einen rufst du den treiber auf der dann drawcalls in den von dir gewuenschten buffer hinterlegt, bei dem anderen schreibst du selbst commands in einen commandbuffer.
bei dem einen ist es jacke wie hose ob du das in 1 oder 10 buffer fuellst, bei dem anderen kannst du die 10 commandbuffer zur gleichen zeit ausfuehren als ob du 10 devices haettest. bei dem einen hast du im commandbuffer alles an synchronisierung und daten updates eingebacken und der treiber wird das alles durchgehen und analysieren und dafuer sorgen dass es richtig ablaeuft. bei dem anderen nimmt die GPU einfach was du reinschreibst und notfalls zerlegt es deine scene, aber das ist niemandens schuld/verantwortung ausser deiner....

Auch ansonsten kann (und soll(te)) man DX11 Command Lists benutzen wie DX12 Bundles.
Wieso sollte auch gerade für den Programmierer ein Unterschied zu sehen sein

weil in dem einen fall jemand fuer dich kocht und du sagst nur dass du suppe, pizza, wurst etc. willst und entsprechend passiert es automatisch und du hast keine ahnung welches gift drinnen ist. bei dem anderen musst du selbst kochen.

auch wenn es bei aussenstehenden wie "nahrungsversorgung" aussieht, sind es fuer dich koch..emm.. programmierer zwei welten.

rapso schrieb:

es hat mehr mit DX2 commandbuffern zu tun als mit DX11

Und unter NVidia werden DX11 Command Lists als Command Buffer realisiert. Unter AMD und Intel nicht. Oder versteh ich hier was falsch?

keine implementierung ist wirklich gut, weil keine implementierung im voraus wissen kann was du damit eigentlich anstellen willst. dabei muss jede implementierung dir alles moegliche garantieren. was passiert wenn du 10 commandlists hast und in den 10 denselben buffer updaten willst?.... bei schnellen APIs sagt die API dir "I dont care" und deswegen ist es eine schnelle API.

oder aus welchem grund benutzt fast niemand commandlists von DX11 aber jeder hebt sie zum heiligen gral bei DX12,Vulkan,Mantle,Consoles?

[DX4Trash]

Mal im ernst, wenn Vulkan draußen ist wen interessiert denn dann noch DirectX? Es geht doch eh weg von Microsoft, wenn auch langsam. Denkt nicht nur immer an diesen Blockbuster-Schund. Aber selbst da werden immer mehr Engines portiert.

[Marthog]

DX4Trash schrieb:

Mal im ernst, wenn Vulkan draußen ist wen interessiert denn dann noch DirectX? Es geht doch eh weg von Microsoft, wenn auch langsam. Denkt nicht nur immer an diesen Blockbuster-Schund. Aber selbst da werden immer mehr Engines portiert.

Erstmal wissen wir noch gar nicht, wie Vulkan ueberhaupt wird. Vielleicht hat es ja fuerchterliche design-flaws oder ist fuer den Ottonormalentwickler viel zu schwer.
Dann ist DirectX ein Buzz-wort, bei dem der Spieler sofort an superschnelle Grafik denkt, waehrend er bei OpenGL keine Ahnung hat oder vielleicht sogar mal Bugs deswegen hatte. Zudem hatte OpenGL schon oft die Nase vorne. Insbesondere in der Phase, als DirectX 11 schon da war, aber es noch viele XP-Rechner gab, sind die Spieleentwickler weiterhin bei DirectX 9 geblieben, obwohl OpenGL plattformunabhaengigkeit und effizientes Ausnutzen der Hardware geboten hat.
Das Problem sind nicht die Big Player. Unreal- und CryEngine unterstuetzen bereits OpenGL. Dice war an der Mantle Entwicklung beteiligt, Unity hat zusammen mit Valve Vulkans Entwicklung ueberhaupt erst angestossen und letztere haben ein grosses Interesse daran, fuer ihre Steam machines auch Spiele anzubieten.
Ich habe den Eindruck, dass die mittelgrossen Spielefirmen oft kein Interesse an etwas anderem als Windows- und Konsolenmakt haben, waehrend die ganz Grossen alles einbauen und die Indies sowieso nur OpenGL nehmen.

[floorball]

@DX4Trash: Wenn du einen OpenGL vs DirectX Flamewar starten willst mach doch bitte deinen eigenen Thread dafür auf, aber andere Threads dazu zu missbrauchen um hier eine Trollerei loszutreten ist einfach nur widerlich.

@rapso: Du meinst, das in Zukunft der Programmierer dafür zuständig ist das alle Ressourcen zur richtigen Zeit am richtigen Ort sind? Da muss ich dir natürlich zustimmen*, diesen Punkt habe natürlich komplett übersehen.

*genau genommen bin ich von Anfang davon ausgegangen dass du recht behalten wirst, da du in diesem Bereich 100x mehr Wissen und Erfahrung mitbringst als ich, alles andere hätte mich sehr überrascht

[Kellerautomat]

https://www.youtube.com/watch?v=EUNMrU8uU5M
Die Qualitaet ist leider... bescheiden.

[rapso]

floorball schrieb:

@rapso: Du meinst, das in Zukunft der Programmierer dafür zuständig ist das alle Ressourcen zur richtigen Zeit am richtigen Ort sind? Da muss ich dir natürlich zustimmen*, diesen Punkt habe natürlich komplett übersehen.

ja, das ist teil davon. z.B. eine sehr simple sache: UI ausgabe.

Du hast deine paar tausend UI elemente (sagen wir sowas wie ein level editor mit buttons, texten, icons ueber 3d objekten, texture viewer, property, scenegraph blabla...

Du koenntest einen kleinen Vertex-/IndexBuffer haben den du pro drawcall befuellst. Dafuer erstellst du ihn mit einem flag dass der API hinted es ist ein dynamischer buffer. Du lockst/mapst sie vor dem drawcall, fuellst sie, unlockst/-mapst, zeichnest.
Ist das schnell?

DX11:
Du bist treiber programmierer. Du hast einen 'case' wo die VBs/IBs dynamic sind, hmm, legst du sie jetzt einfach als doublebuffer an? damit kann die GPU async zum befuellen arbeiten koennen. naja, vielleicht quad buffered, die pipeline ist ein wenig lang. Naja, eigentlich kann es sein dass der OS layer (e.g. DirectX) bzw das OS selbst den commandbuffer lange recorded und dann fuer paar hundert drawcalls abschickt, du willst das OS nicht forcieren, dass es flusht wenn jemand wie oben beschrieben UI zeichnet. aber 100x-buffern waere eine ziemliche verschwendung. naja, du koenntest die updates in den commandbuffer mit ablegen, lock/map liefert dann einen pointer dahin, aber wenn jemand immer wieder einen 1MB buffer mappen/unmappen wuerde um 32byte weiter zu schreiben, dann wuerde der CMDBuffer explodieren in wenigen updates. Na gut, dann waere ein pool von VB/IB gut. du koenntest einen nach groesse anlegen, vielleicht jeden dieser subpools mit round-robin ablaufen..hmm... aber was wenn eine Applikation auf die idee kommt aus performance gruenden manche dinge nur alle x-frames neu zu befuellen obwohl es 'dynamic' ist. 'half dynamic' gibt es gerade nicht als flag. dann brauchen wir einen pool der wie ein heap von VBs/IBs arbeitet. hmmm, aber was wenn eine app auf die lustige idee kommt z.b. einen streaming thread und einen rendering thread zu haben? (e.g. deferredcontext in DX11 oder shared context in GL) dann vielleicht "thread-local size differentiated heap-managed pools".. aber was wenn ein context garnicht daten updated und einer einzig und allein daten updated?

DX12:
du:
ah, einfach zwei 1MB VB/IB, wenn einer voll ist, sync point dran in den commandbuffer und pointer swappen.
das ist nicht super optimal, aber du weisst ganz genau dass es schnell genug sein wird, weil dich die UI nicht viel kuemmert solange sie die framerate nicht halbiert, weil du dich auf die performance vom spiel konzentrieren solltest (nicht vom editor).

Ich denke das ist der grund weshalb wir consolen lieben, es ist nicht so sehr die performance der low level APIs, sondern die kontrolle. Du hast eine art Quality of Service, weil du verantwortlich bist und wenn du das magst, dann kannst du eine gute quality abliefern (was z.b. nicht bedeutet hohe framerates, sondern stabile framerates, spiel ohne explizites level loading, asynchrones game saving etc.). wenn da driver+os dabei sind, dann wirst du, wenn du glueck hast, 100 mails mit den driver und os entwicklern austauschen um euch auf ein verhalten zu einigen und wenn du glueck hast laeuft es auf 90% der systeme wie erwartet. wenn du pech hast, dann musst du dein spiel mit der annahme von worst case entwickeln und damit leben dass es ruckelt weil du z.b. mal eine textur mehr updatest als der pool im driver antizipiert hat.

aber sowas verkaufst du nicht marketingmaessig.
-ist das jetzt 20% performance boost?
-wieviel besser wird meine framerate?
-sehen dann meine spiele besser aus?
-ist die AI damit schlauer weil sie mehr zeit hat?
-spart es akku auf meinem handy?
nein? es wird nur..emm.. besser?

es ist wie responsivness von z.b. websites durch asynchron calls, jeder merkt wenn es besser ist, aber im voraus kann man das niemandem erklaeren.

[rapso]

Kellerautomat schrieb:

https://www.youtube.com/watch?v=EUNMrU8uU5M
Die Qualitaet ist leider... bescheiden.

THX for sharing.
hab ich mir im hintergrund reingezogen, cool zu sehen, dass fast alle was lauffaehiges haben von den GPU herstellern.