ZFX + Developia

Moin.

Ich habe ein Framework. Das ist >20 Jahre alt, wird immer noch aktiv gepflegt, ich mag es. Ich weigere mich, die Sinnlosigkeit meines Handelns einzusehen, und will weiter meine Grafik selbst programmieren.

Das Problem: der Grafikteil des Frameworks basiert auf DirectX9. Langsam sterben die Tools dafür aus: NSight verweigert seit einigen Jahren die Zusammenarbeit, PIX hab ich noch ne Uralt-Install, weil es das offiziell nicht mehr gibt. Und mir fehlen halt alle coolen Sachen, die moderne GPUs so können. Ich hätte die ganzen Bindless-Geschichten gut gebrauchen können, hätte Verwendung für GeometryShader oder gar MeshShader - das ist mir aber noch zu jung und nicht omnipräsent genug - und ich könnte Compute Shader gut gebrauchen. Asynchrone Transfers wären ein Gewinn, DX9 hackt und ruckt gerne mal, wenn man dynamisch streamen will, egal was man an Flags und Tricks zaubert. Also muss ich jetzt irgendwann mal in den sauren Apfel beissen und auf eine andere 3D-API umschreiben. Aber auf welche?

Mein Ursprungsplan war Vulkan: schnell, direkt, ziemlich gesunde Baseline-Funktionalität, alle spannenden Plattformen abgedeckt: Windows, Linux, Android. Einzig die dämlichen RenderPasses brauchen ne Extension, aber soweit ich das verstehe, ist das nur API-Design und demzufolge ne Selbstverständlichkeit und nicht an irgendwelche Hardware-Generationen gebunden.

Aber mit der Direktheit kommt halt eine massive Verantwortung und Komplexität, und ich bin nicht sicher, ob ich das in meiner Freizeit hinkriege. Kein IOS/OSX ist dagegen zwar schade, aber dem Drecksverein wünsche ich eh die Pest und auf IOS muss man sowieso irgendne API benutzen, die's nirgends sonst gibt, also ist das jetzt erstmal kein Problem. Meine Sorge bleibt die heftige Asynchronizität mit Vorhalten von Transfers, Barriers und Semaphores, Nachhalten von gelöschten Ressourcen usw. Und ist Vulkan wirklich schon überall verfügbar? Oder renne ich z.b. mit dem Wurmspiel, was ja reichlich casual ist, dann in tausendundein Treiber-Probleme?

Außerdem kenne ich genau eine Person, die Vulkan macht, und die macht nur aller Monate mal ein bissl Fortschritt, so dass ich jetzt *echte* Angst vor der Arbeitsmenge habe, die anscheinend für Selbstverständlichkeiten notwendig ist.

Dann gibt's da DirectX12, aber das schließe ich aus, weil's quasi wie Vulkan ist, aber mich zusätzlich auf einer Plattform einsperren würde. Ok, zwei, wenn man XBoxOne einberechnet, und irgendwann will ich ja mal auf die Konsolen. Aber das ist so ferne Zukunftsmusik, die hört man eh nur bei günstigem Wind, das ist kein Argument für die nächsten zehn Jahre.

Der Kumpel aus dem gleichen Kaff DirectX11 ist da schon ein anderes Kaliber. Ich könnte damit (fast) alles machen, was auf meiner Liste steht, und die API ist grundsätzlich noch wie DX9 und kümmert sich um Allocations und Synchronisation selbst. Dafür könnte ich die Einschränkung auf Windows eventuell in Kauf nehmen - Linux krieg ich ja mit Valves Bemühungen dann irgendwie dazu, schade um Android, fick Apple, Konsolen brauchen eh Custom-Liebe. Aber wenn ich dann doch für ne Linux-Version einen Layer einziehen muss, würde ich das mit...

...OpenGL machen. Mit OpenGL krieg ich auch alles, was ich mit DX11 kriege, und wahrscheinlich mit irgendnem wüsten Gewitter aus Extensions auch asynchrone Transfers. Aber OpenGL ist halt ne KATASTROPHE, so als API. Tausend kleine Inseln aus API-Methoden, teilweise überlappende Zuständigkeiten und unsichtbare Konflikte im Hintergrund, der Shader-Compiler ist eine treiberabhängige Sauerei aus dem dritten Kreis der Maintenance-Hölle, und jederzeit könnte Dir an irgendner Stelle ein DrawCall aus jedem zweiten Frame rausflackern und Du hättest keine verdammte Ahnung, wo Du überhaupt suchen sollst. OpenGL ist der Wartungshass in Tüten, und ich spreche da aus zugegebenermaßen >5 Jahre alten Erfahrungen.

Was also nehme ich? Habt ihr Erfahrungen, die ihr mit mir teilen könnt? Sollte ich meinen GameDev.net-Account mal reaktivieren und dort fragen?

Mir fehlt in deinem Text die Stelle wo du uns sagst was dein Ziel ist.

Ich habe früher auch viel selber entwickelt. Heute greifen ich auf eines der tollen 3D Engins zurück um meine Ideen zu verwirklichen. Ich selber sehe mich als Künstler und die 3D Engine ist das Werkzeug mit dem ich mein Kunstwerk erschaffe.

Als was siehst du dich? Im Grunde hast du dann deine Frage beantwortet (bzw. ist in deinem Text enthalten).

Der neue hotte Shit ist wohl WebGPU, welches auch native Support für C/C++ hat

xq hat geschrieben: ↑29.03.2022, 20:52 Der neue hotte Shit ist wohl WebGPU, welches auch native Support für C/C++ hat

Oh, fancy. Nachdem xq im IRC ein paar Sachen aufgeklärte, die ich missverstanden hatte, sieht das echt schick aus. Quasi ein Wrapper um einer der LowLevel-3D-APIs, portabel und nimmt ein paar der schmerzhaften Kanten weg. Hm. Lecker. Ich bookmarke mir das mal für wenn ich dazu kommen sollte.

gombolo hat geschrieben: ↑29.03.2022, 20:32 Mir fehlt in deinem Text die Stelle wo du uns sagst was dein Ziel ist.

Es ist freundlich, dass Du mir helfen magst, aber hier geht's nicht um "ich möchte ein Spiel machen, wie fange ich an". Die technischen Aspekte der 3D-APIs hängen jetzt wenig davon ab, was ich damit tun möchte.

Das Framework soll am Ende im Wurmspiel, im Shoot'm'Up meines ehemaligen Zwillingsbruders, im GridBased-Dungeon- / Surface-ProcGen-Experiment, in meinen Steam-Spielen wie z.B. Splatter, im fernen VoxelSurvival-Spiel und in kleinen Nebenbasteleien wie dem Halloween-GameJam-Beitrag verwendet werden.

Ich befand mich vor knapp zwei Jahren in der selben Situation und wollte von dem alten DIrectX9 weg.
Vulkan und DirectX12 habe ich ebenfalls auf Grund der Komplexität schnell verworfen.
OpenGL kam mir noch nie in die Tüte, keine Lust auf das Extension-Gehampel und die ganzen globalen States. Wobei das ja seit OGL3 mal besser geworden sein sollte. Das habe ich mir aber in der Tat nie genauer angesehen.

Also geworden ist es dann letztendlich DirectX11, wobei das ja auch schon >10 Jahre alt ist mittlerweile und ich ehrlich gesagt da etwas Schiss habe auf ein altes Pferd aufgesprungen zu sein. Andererseits wird es immer noch im professionellen Bereich stark genutzt, von daher passt alles.

Sehr angenehm fand ich die Umstellung von DX9 auf DX11. Die Konzepte sind fast die selben und man muss nur hier und da ein paar Dinge neu lernen.
Ich weiß nicht wie sehr du D3DX nutzt, aber das ist definitiv dann auch hinfällig und muss ersetzt werden.

Ich wünschte es gäbe eine modernere Highlevel-API als DX11, aber vermutlich ist das schlicht nicht nötig, da DX11 seinen Zweck noch vollkommen erfüllt. Für den Hobbybereich würde ich es jedem empfehlen, der nicht mehr die Freizeit aufbringen kann, die ein Schüler oder Student noch hat.

Specialist hat geschrieben: ↑30.03.2022, 02:14Sehr angenehm fand ich die Umstellung von DX9 auf DX11. Die Konzepte sind fast die selben und man muss nur hier und da ein paar Dinge neu lernen.
Ich weiß nicht wie sehr du D3DX nutzt, aber das ist definitiv dann auch hinfällig und muss ersetzt werden.

Microsoft hat übrigens einen Layer, durch den man D3D 9 1:1 mit D3D 12 nutzen kann. So kannst du z. B. die GUI in D3D 9 programmieren, aber die In-Game-Partikeleffekte in D3D 12 – auf dem selben Device. Das heißt D3D9On12, ist Open Source, und du musst es selber kompilieren weil der offizielle Download Telemetrie von deinen Spielern sammelt (wirklich!).

Der Nachfolger von D3DX ist übrigens DirectXMath.

Willst du nur Windows beliefern? DirectX ist halt nicht Multiplattform. WINE kommt mit DX 9 inzwischen gut zurecht. Aber mit allem höher hat es immer noch Probleme. Und Mac hat OpenGL deprecated, die sind jetzt auf Metal. Da bleibt für Multiplattform nicht mehr viel über. Und das ist halt der Vorteil der fertigen Engines. Im Idealfall One Button deploy für alle Plattformen.

Für eine technische Begründung fehlt mir grad die Zeit deshalb einfach eine subjektive Empfehlung von mir ;)

Nachdem du ja auch so ein Kandidat wie ich bist der Spass an Grafikspielereien hat:
Nimm eine Moderne API also Vulkan oder DirectX12
Ich bin mir ziemlich sicher dass du Aufgrund der Flexibilität damit trotz der anfänglichen Komplexitat ( wen man mal die für einen passende Abstraktionsebene gefunden hat geht's eigentlich) auf dauer glücklicher wirst also mit den alten APIs.

Für splatter und das wurmdings mag das zwar eine Verzögerungen sein, bei deinem Surface Generator oder den Voxel spieleereien bist dann aber wieder deutlich im Plus was die Möglichkeiten angeht ;)

Gute Punkte, danke euch. Also hab ich entweder DX11 als "eigentlich will ich nicht umdenken, sondern nur ein paar Kirschen obendrauf"-Option oder Vulkan als "jetzt mal neu und richtig, und ja das wird schmerzen"-Option. Und da glaube ich nehme ich WebGPU, diesen Wrapper auf Vulkan/DX12/Metal. Der entgratet evtl. ein paar der harten Kanten und gibt mir ansonsten alle Möglichkeiten der modernen GPU-Programmierung, und das auch noch plattformübergreifend. Mit DX12 kriegt man ja sogar XBoxOne, PS5 und Switch kriegt man da sicher irgendwie reingedengelt. Also in wirklich ferner Zukunft dann.

Nuja, ich schaue bei Gelegenheit mal rein, ob ich das zum Bauen bekomme. Auf Win/Linux wäre Vulkan erstmal meine Wahl, und die API kommt ja mit ihrem eigenen Set an Hass daher, um das ich erstmal drumrum schiffen muss.

Also je nachdem was du brauchst, kann es sich auch lohnen einfach gegen ANGLE (https://github.com/google/angle) zu entwickeln.
Also EGL 1.5 und OpenGL ES 3.x, und die Library macht die Übersetzung nach Direct3D/OpenGL/Vulkan.

WebGPU ist ähnlich, hätte aber die Chance das die API besser/moderner ist.
Gleichzeitig könnte es aber auch sein, dass die Implementierungen noch nicht so wirklich standardisiert bzw. komplett sind.
Wäre super wenn du da über deine Erfahrungen berichten würdest :-)

Schrompf hat geschrieben: ↑29.03.2022, 18:03
Mein Ursprungsplan war Vulkan: schnell, direkt, ziemlich gesunde Baseline-Funktionalität, alle spannenden Plattformen abgedeckt: Windows, Linux, Android. Einzig die dämlichen RenderPasses brauchen ne Extension, aber soweit ich das verstehe, ist das nur API-Design und demzufolge ne Selbstverständlichkeit und nicht an irgendwelche Hardware-Generationen gebunden.

Aber mit der Direktheit kommt halt eine massive Verantwortung und Komplexität, und ich bin nicht sicher, ob ich das in meiner Freizeit hinkriege. Kein IOS/OSX ist dagegen zwar schade, aber dem Drecksverein wünsche ich eh die Pest und auf IOS muss man sowieso irgendne API benutzen, die's nirgends sonst gibt, also ist das jetzt erstmal kein Problem.

Mit MoltenVK bekommt man Vulkan auf iOS, MacOS und iPadOS zum Laufen.

Schrompf hat geschrieben: ↑29.03.2022, 18:03 Was also nehme ich?

Nicht so viel meckern und OpenGL nutzen, wenn du keinen Bock auf Vulkan hast. Oder nach einem Vulkan API-Wrapper Ausschau halten, oder zumindest eine Bibliothek nutzen, die die Arbeit etwas erleichtert (bspw. den Vulkan Memory Allocator von AMD) und damit abfinden, dass die Dinge sind, wie sie sind - dass also die Zukunft in Richtung Vulkan(-ähnliche APIs) geht.

Specialist hat geschrieben: ↑30.03.2022, 02:14 OpenGL kam mir noch nie in die Tüte, keine Lust auf das Extension-Gehampel und die ganzen globalen States. Wobei das ja seit OGL3 mal besser geworden sein sollte. Das habe ich mir aber in der Tat nie genauer angesehen.

Also für OpenGL gibt es ja diverse Extension-Loader, ich hab einen genommen der im Wesentlichen aus 2 Dateien besteht die du in dein Projekt schmeißt und dann hast du einen Header der dir dein 4.6 Interface gibt. Ich glaube man muss auch ganz am Anfang noch eine Funktion aufrufen damit die Funktionszeiger entsprechend geladen werden. Dauert mit raussuchen und allem vlt. 1-2 Stunden und danach hat man eigentlich Ruhe. Gefühlt ist alles was man benutzen will im letzten Standard enthalten, ich habe jedenfalls noch nie eine Extension explizit geladen. Und je nach Loader kannst du halt auch die Mindest-Version angeben und da die letzte Version ja auch schon einige Jahre alt ist, ist die dann auch eigentlich überall verfügbar. Sprich: Der Extension-Mechanismus existiert zwar theoretisch, ist aber eigentlich Bedeutungslos.

Was den globalen State angeht: Ja, ist halt ne dreckige alte C-API. Du musst ja auch bei diversen Aufrufen den Typ explizit angeben und manchmal sind Dinge nicht so nett dokumentiert wie man es gerne hätte und dann hat man alle Daten theoretisch im richtigen Format vorliegen, braucht aber trotzdem einen ganzen Tag bis der API Call auch korrekt ist und es tatsächlich rendert (ist mir passiert als ich Instancing eingebaut habe, war nicht lustig). Gefühlt hätte man das Problem mit einem vernünftigen Interface komplett umgehen könnten. Aber naja.

Persönlich benutze ich eigentlich OpenGL auch nur, weil ich das halt irgendwie schon immer so gemacht habe und nicht alles umschreiben will. Ich bin aber schon auch echt neidisch auf all die netten Dinge die mit Vulkan gehen und dann viel effizienter sind, was mich von Schrompfs Situation unterscheidet ist aber glaube ich die Bereitschaft jetzt tatsächlich nochmal viel neu zu bauen. Oh well...

Also wenn du tatsächlich mit Vulkan direkt anfängst empfehle ich gleich von Anfang an folgende Libs mit in Betracht zu ziehen:

Volk um den blöden Default loader zu umgehen und außerdem alle extension gleich geladen zu haben
https://github.com/zeux/volk

VkBootstrap um den ganzen bloat für device selection und Erzeugung komfortabel wegzubekommen
https://github.com/charles-lunarg/vk-bootstrap
VulkanMemoryAllocator um Device-Memory allocations komfortabler zu machen. Außerdem abstrahiert die lib das Problem weg dass die Anzahl maximaler physischer allokationen auf der GPU recht gering ist (256 auf vielen Karten)
https://github.com/GPUOpen-LibrariesAnd ... yAllocator

Mit dieser Kombination hab ich gute Erfahrungen gemacht, aber es hilft gerade bei VkBoostrap und dem VMA enorm das gleich von Anfang an zu nutzen.

Außerdem sollte man nicht den Fehler machen OGL oder DX < 11 Konzepte versuchen 1:1 zu übertragen.
Das ist oft schwieriger und mehr Aufwand als gleich eine moderne Renderarchitektur zu bauen.

Feine Liste, Danke. volk hab ich aufm Schirm, schon weil mir der offizielle Loader mit seinen systemweiten Dependencies doch mächtig am Nervenkostüm zerrt. Den Bloat am Anfang hab ich schon irgendwo rumhängen, aber ich guck mir's mal an. Und nen Allocator werde ich sicher brauchen, mal schauen, was der so alles kann. Wenn der irgendwie das "Mem freigeben, aber erst in drei Frames wiederverwenden, wenn die GPU auch damit fertig ist"-Problem irgendwie behandelt, wäre er enorm wertvoll für mich.

Vulkan eignet sich vor allem, wenn du eine eigene Grafikschnittstelle wie OpenGL, aber speziell für dein Projekt maßgeschneidert bauen willst. Solo-Entwicklern mit großen Projektideen, würde ich immer von Vulkan abraten, da der Zeitaufwand sich nicht rentiert, und es bei größeren Render Pipelines sehr kompliziert wird. Wenn du nicht bereits jahrelang Erfahrung mit Vulkan hast, dann musst du dich drauf einstellen, anstatt deine Idee umzusetzen, erstmal rund um die Uhr nur stumpfen Grafikschnittstellen Code runter zu schreiben.

Es kommt vor allem darauf an, wie komplex deine Projekte sind, und ob es sich für dich wirklich rentieren würde, Schnittstellen wie OpenGL den Performance Kampf anzusagen. OpenGL ist für das meiste in Ordnung, läuft ziemlich flott, und gerät erst bei größeren Render Pipelines ins taumeln.

Hauptvorteil an Vulkan und D3D12 ist allerdings der Zugriff auf Features wie Hardware beschleunigtes Ray Tracing, Mesh Shader etc. Wenn du sowas für dein Projekt brauchst, dann führt an den low-level APIs kein Weg vorbei.

Mit WebGPU hab ich sehr gute Erfahrung gemacht, ist ein grober Mix aus Vulkan und Metal/OpenGL, allerdings sehr sauber designed mit einer Menge Kontrolle. Von der "Preis-Leistung" ist WebGPU definitiv die API, auf die ich in Zukunft für meine eigenen Projekte setzen werde, macht Spaß und man kommt schnell voran.

Einziges Manko an WebGPU ist die Shadersprache WGSL, ist erstmal gewöhnungsbedürftig und auch noch nicht ganz ausgereift. Eigentlich sollte WebGPU SPIR-V einsetzen, Apple hat dann aber Nö gesagt wegen einem IP Beef mit Khronos. Immerhin gibt es manuelle SPIR-V zu WGSL Compiler von Google und Mozilla, falls man bei GLSL bleiben will.

Oder du nimmst doch DirectX 11 weil angenehmer, und arbeitest für das Multiplattform mit nem Vulkan Wrapper.

https://www.lunarg.com/news-insights/ca ... or-vulkan/

Tiles hat geschrieben: ↑03.04.2022, 08:16 Oder du nimmst doch DirectX 11 weil angenehmer, und arbeitest für das Multiplattform mit nem Vulkan Wrapper.

https://www.lunarg.com/news-insights/ca ... or-vulkan/

Was es nicht alles für abenteuerliche Dinge gibt...

Ich hab nochmal über das Komplexitätsargument bei den LowLevelAPIs nachgedacht und bin zu dem Entschluss gekommen dass es eigenltich sch... egal ist was man nimmt.

Ja es dauert mit Vulkan/DX12 deutlich länger bis man überhaupt was auf auf den Bildschrim kommt. Aber ich kann x1m4 nicht zustimmen das Vulkan bei größeren Pipelines zu komplex wird. Ich sehe hier eher das Gegenteil.
OGL die Globale State Verwaltung, bähhh...
Dx9-12 und ogl mit ein paar 10000 Objekten in der scene
Was hat man da für Verrenkungen gemacht weil es kein sinnvolles multithreaded Rendering gibt und die Drawcalls schweinelangsam sind.
Debugging ein Graus, vor allem wenn der eine Teiber deinen Fehler akzeptiert und der andere einfach Abschmiert. Vulkan Validation Layer sind hier doch 10x angenehmer ;)

Ich könnt noch ein wenig weitermachen
Aber am Ende des Tages macht heutzutage OGL/DX11 nur für kleinere Projekte Sinn, je größer das Projekt bzw die darzustellenden Scenen desto mehr rentiert sich der Aufwand für Vulkan/Metal/DX12.


Zu WebGPU kann ich ned viel sagen klingt aber für den Hobbybereich ganz vielversprechend.

Ich gebe zu die ersten Monate waren hart, und vor allem währen dem Wegabstrahieren von dem Sync zeugs hab ich mich gefragt ob eine LowLevel API die richtige Entscheidung war. Aber jetzt möchte ich nicht mehr zurück. Man spart sich einfach so viele Grausamkeiten und weiß vor allem was passiert weil der Treiber nix mehr versteckt...
Also ja, anfangs durchaus ein steiniger Weg der sich aber lohnt wenn man seinen Renderer selbst implementieren will. Alle anderen sollten eh eine fertige Engine nehmen...
Ich scheitere halt jetzt an Dingen die ich ohne Vulkan gar nicht versuchen könnte weils die API nicht hergibt..
Aber vielleicht bin ich auch einfach seltsam ;)

Ok, Danke nochmal für die Erfahrungsberichte. WebGPU hab ich mir gestern mal geklont, aber auf die Schnelle nicht zum Bauen bekommen. Ich werde mir sicher nicht den ganzen Dependency-Scheiß eintreten, die benutzen ja sogar ihr eigenes Build-System. Meine Güte. Aber das geht sicher schlichter, meistens braucht man ja nur ein paar Defines und Include-Verzeichnisse und dann baut das.

Matthias Gubisch hat geschrieben: ↑03.04.2022, 09:08
Aber am Ende des Tages macht heutzutage OGL/DX11 nur für kleinere Projekte Sinn, je größer das Projekt bzw die darzustellenden Scenen desto mehr rentiert sich der Aufwand für Vulkan/Metal/DX12.

Ja der Aufwand eine low-level API zu benutzen rentiert sich am Ende immer, die Frage ist hald, ob sich das hauptsächlich vom Zeitaspekt für seine eigenen Hobby Projekte überhaupt lohnt. Für eigenen Kram würde immer mehr Gewichtung auf die Umsetzung der Idee, anstatt der technischen Perfektion legen. Ich hab bei mir selbst beobachtet, dass ich ewig lost mit Grafikschnittstellen Code bin (weil es muss ja perfekt sein), anstatt einfach meine Idee umzusetzen.

Matthias Gubisch hat geschrieben: ↑03.04.2022, 09:08 Zu WebGPU kann ich ned viel sagen klingt aber für den Hobbybereich ganz vielversprechend.

Ist echt ne nette Schnittstelle, hat auch so Zeug wie Command Buffer, Fences und Compute/Render Pipelines. Von der Syntax her ist WebGPU eben das, was bei rauskommt wenn man mehrere low-level Grafikschnittstellen vereinen will. Fun Fact, als ich NVIDIA's Grafik API auf der Switch gesehen hab, dachte ich erst, das ist WebGPU Syntax.

WebGPU gibt's auch für Nativ und man kann relativ einfach, eigene Extensions zu der Schnittstelle hinzufügen. Hier z.B. WebGPU mit Hardware Ray Tracing (über VK_KHR_ray_tracing und DXR)