OpenGL wird dieses Jahr komplett durch Vulkan ersetzt
-
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.
-
@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
-
https://www.youtube.com/watch?v=EUNMrU8uU5M
Die Qualitaet ist leider... bescheiden.
-
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.
-
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.