Welche API

[Raven280438]

Hi,

nach einiger Zeit möchte ich mich wieder etwa mit der Spieleprogrammierung beschäftigen.
Ich hab mich bisher hauptsächlich mit OpenGL beschäftigt (nur kurz mit DX11).

Meine Frage: Welche API macht im Moment und in Zukunft mehr Sinn zu lernen?
DX12 und Vulkan sind ja angekündigt. Ist der Umstieg von DX11 zu DX12, oder von OpenGL zu Vulkan einfacher? Ich möchte ungern alles Neu lernen müssen.


Gruß

[dot]

Schwer zu sagen, da es zu beiden APIs noch keine wirklichen Informationen gibt. Ich würde erwarten, dass der Umstieg in beiden Fällen von ähnlicher Schwierigkeit ist. In Zukunft werden sicher beide APIs von Bedeutung sein, die Frage, welche von beiden mehr Sinn macht, wird sich morgen genausowenig allgemein beantworten lassen, wie schon heute...

[David_pb]

Hi,

sowohl DX12 als auch Vulkan sind APIs die gewollt nicht einfach Verwendbar sind. Ziel beider APIs ist eine möglichst dünne Abstraktion zwischen Anwendung und Hardware zu sein. Der Großteil des internen Managements fliegt raus, dadurch wird der CPU Overhead drastisch verringert. Dinge wie Ressourcenverwaltung, Hazard-Tracking, CPU/GPU Synchronisation etc... muss die Anwendung damit selbst übernehmen. Eben alles was frühere DX Versionen bzw OpenGL intern dem Entwickler abgenommen haben. Die Menge an potentiellen Fehlern, die eine Anwendung machen kann, steigt dadurch natürlich.

Als Beispiel: Du zeichnest ein Mesh mit einer beliebigen Textur. Irgendwann entscheidest du, dass die Textur ausgetauscht werden soll und erzeugst eine neue Textur. Die alte Textur wird fachmänisch zerstört (um wertvollen Speicher zu sparen) und das Grafikdevice resettet sich (oder du bekommst einen Bluescreen, oder, oder...). Warum? Weil du vergessen hast zu warten bis die GPU den/die Frame/s abgeschlossen hat in der die alte Textur referenziert wurden.

Derlei Dinge (und vieles mehr) liegen mit Vulkan und DX12 in der Hand der Entwickler. Beide APIs sind außerdem auf Multithreading ausgelegt. Anwendungen profitieren vor allem dann, wenn Commandbuffer parallel aufgebaut werden. Eine Engine muss darauf natürlich ausgelegt sein.

Ein Umstieg von DX11 oder OpenGL auf DX12 bzw Vulkan wird sich sicherlich nicht zu einfach gestalten. Schon weil es kein wirkliches 1:1 Mapping von den Konzepten gibt. Die APIs machen eben einen Schritt zurück, zur Hardware hin. Einsteiger sollten vermutlich eher bei den alten APIs bleiben. Außerdem, wirklich profitieren von den APIs wirst du vor allem dann, wenn deine Anwendung schon "CPU bound" ist.

Intel hat eine sehr gute Übersicht über einige der neuen Konzepte von DirectX 12 veröffentlicht:
https://software.intel.com/en-us/blogs/ ... -the-metal
https://software.intel.com/en-us/blogs/ ... ate-object
https://software.intel.com/en-us/blogs/ ... ce-binding
https://software.intel.com/en-us/blogs/ ... and-tables
https://software.intel.com/en-us/blogs/ ... -5-bundles
https://software.intel.com/en-us/blogs/ ... mand-lists
https://software.intel.com/en-us/blogs/ ... amic-heaps
https://software.intel.com/en-us/blogs/ ... arallelism

[mnemonix]

Danke David_pb für die Links. ;) Die werde ich mir bei Gelegenheit auch mal reinziehen um einen Überblick über die Konzepte zu bekommen (Vulkan wird das ja wahrscheinlich recht ähnlich handhaben).

Ansonsten sehe ich das recht ähnlich wie dot. Aber das kommt auch auf deinen Anwendungsfall drauf an. Wenn du hauptsächlich nur für Windows programmieren möchtest, dann lerne Direct3D 12. Wenn du jedoch Grafik-Entwicklung auf unterschiedlichen Betriebssystemen oder Geräten anstrebst, dann solltest du eher in Richtung Vulkan hin arbeiten. Jetzt ist aber erstmal abwarten und Tee trinken angesagt, is ja noch was hin.

P.S.: Zusammengefasst ist der ganze Shit :D auch nochmal auf Channel 9.

[David_pb]

Hier auch noch der aktuelle Talk von der GDC Advanced DirectX 12 Graphics and Performance

[Jonathan]

Meh, das hört sich ja so an, als würde in Zukunft der durchschnittlicher Hobbyprogrammierer erstmal sein eigenes OpenGL mit Vulkan nachbauen :D
Ich habe das Gefühl, eh schon zu viel Zeit in die Implementierung gelöster Probleme zu verschwenden. Auf absehbare Zeit werde ich also glaube ich doch beim aktuellen OpenGL bleiben, einfach um vielleicht auch irgendwann mal was fertig zu bekommen...
Aber interessant sind die ganzen neuen Konzepte ja schon.

[antisteo]

Das Gefühl habe ich auch. Die modernen OpenGLs sind alle effizient und tolles Design für massive Datenverarbeitung. Aber den Hobbyspieleprogrammierer bedienen sie nicht mehr. Zu viel Aufwand, ein minimales Projekt aufzusetzen. WebGL genau dasselbe. Ich hoffe ja, dass sich irgendwann DAS Linux der Game Engines durchsetzt.

[Spiele Programmierer]

Also ich freue mich sehr darauf. :D
Erstmal was anständiges zusammenbauen zu müssen, hatte man ja bis jetzt auch schon.
OpenGL in C++ ohne einen Wrapper zu nutzen macht schließlich auch keinen Spaß. Nur hat man dann den ganzen Ärger mit den Kontext, wie die Bind-Nervigkeiten, 1000 Funktionen die alle das Gleiche machen und nur anders aussehen. Für Texturen zum Beispiel muss man zum Beispiel je nach Treiberfähigkeiten OpenGL 3.3, EXT_direct_state_access, ARB_texture_storage(OpenGL 4.2), ARB_texture_storage(OpenGL 4.2) + EXT_direct_state_access oder ARB_direct_state_access(OpenGL 4.5) verwenden. Und eigentlich ist es mit vielen Funktionen. So viele Möglichkeiten, das selbe zu tun, hauptsächlich abhänig von Treiberfeature Level. Und am Ende ist dann immer noch alles Thread Local und man hat überall Sync Points die keiner braucht und man ist die Hälfte der Zeit damit beschäftigt, zu planen, ob man lieber einzelne Uniforms, ein UBO, ein TBO oder ein SSBO nimmt, wie man die teuren States Changes reduzieren kann und wie man die Daten auf die GPU bekommt. Und Draw Calls darf man momentan ja auch kaum machen - man verschwendet also seine Zeit damit, wie man unterschiedliche Dinge in die selben Buffer oder States bekommt.
In Vulkan sehe ich die Chance auf eine Plattform, mit der das alles einfacher wird.(sollte sie in einem angemessenen Zeitraum von einer einigermaßen akzeptablen Menge Hardware unterstützt werden) Scheinbar wollen sie mit der gleichen API ja auch mobile Geräte erreichen - was momentan anscheinend ein weitere API ist, die ähnlich ist aber nicht gleich und damit für viel Ärger sorgen kann.

Außerdem werden in Zukunft bestimmt Bibliotheken erscheinen, die das Verwenden von Vulkan vereinfachen.
Auch das ist in OpenGL nicht anders. Fast jeder wird einen OpenGL Loader, eine OpenGL Context Library und einen Image Loader einbinden. OpenGL zu laden und einen Kontext aufzubekommen ist ja so kompliziert, dass man am Besten eigene Bibliotheken verwendet. Es gibt ja kein einfaches "vkCreateDevice" oder so.

Ich glaube, die neuen APIs werden nicht viel komplizierter als sie jetzt sind, sie sind nur an die aktuelle Hardware angepasst. Und bei OpenGL kommt dann noch ein allgemeines Aufräumen hinzu, was die Sache erst recht lohnenswert zu verwenden macht.

[David_pb]

Und am Ende ist dann immer noch alles Thread Local und man hat überall Sync Points die keiner braucht und man ist die Hälfte der Zeit damit beschäftigt, zu planen, ob man lieber einzelne Uniforms, ein UBO, ein TBO oder ein SSBO nimmt, wie man die teuren States Changes reduzieren kann und wie man die Daten auf die GPU bekommt. Und Draw Calls darf man momentan ja auch kaum machen - man verschwendet also seine Zeit damit, wie man unterschiedliche Dinge in die selben Buffer oder States bekommt.

Das wird sich mit Vulkan/DX12 auch nicht einfach so ändern. Klar wird konzeptionell das Zeug geboten um mit "Zero CPU-Overhead" zu arbeiten. Leider stimmt das nur so lange, wie die Anwendung das ordentlich ausnutzt. Der CPU-Overhead aus GL und DX11 ist ja nicht weg, sondern wird auf die Anwendungen "abgeschoben". Das kann durchaus sehr gut sein, da die Anwendung sehr problemorientierte Lösungen verwenden kann. Andersrum kann das aber, bei falscher Anwendung, auch komplett in die Hose gehen. Du wirst z.B. mit einem naiven Port eines GL oder DX11 Renderer vermutlich keinen Gewinn feststellen, oder sogar massive Performanzprobleme bekommen.

Ich glaube, die neuen APIs werden nicht viel komplizierter als sie jetzt sind, sie sind nur an die aktuelle Hardware angepasst. Und bei OpenGL kommt dann noch ein allgemeines Aufräumen hinzu, was die Sache erst recht lohnenswert zu verwenden macht.

DX12 und Vulkan wollen explizit nicht einfach bedienbare APIs sein und zielen eher auf professionellen Einsatz ab. Um die APIs zu verwenden ist es zwangsläufig notwendig ein gutes Vorwissen darüber zu haben wie die CPU/GPU Kommunikation abläuft und was für Fallstricke damit verbunden sind. Ansonsten wird man erstmal eine sehr schwere Zeit mit Vulkan/DX12 haben und über viele Kleinigkeiten stolpern die einem bisher implizit von den APIs abgenommen wurden. Außerdem ist es auch notwendig die neuen Konzepte sinnvoll einzusetzen. Das sollte vor allem in den ersten Jahren interessant werden, weil noch keine "best practices" existieren. Wenns das allerdings so läuft wie bei DX11 seh ich da allerdings eher schwarz, da gibts (öffentlich) wenig, das über die Standard Sample-Anwendungen hinaus geht. Engines sollten exzessive multithreaded sein (da haben sicher die meißten reinen PC Engines noch starke Defizite), außerdem muss geklärt werden wie Descriptor(tables) möglichst effizient einsetzbar sind, usw...

Ich denke das Anfänger mit DX12 und Vulkan nicht gut bedient werden und lieber den Einstieg mit DX11 versuchen sollten, zumal viele Hobbyprojekte vermutlich kaum CPU bound sind und im Zweifel gar keine Vorteile von DX12/Vulkan haben (abgesehen natürlich von neuen Renderfeatures).

Auch sehr interessant, Promit's post zu diesem Thema: Link

[Spiele Programmierer]

Vielleicht geht es ja nur mir so, aber ich habe nicht den Eindruck das es öffentlich wirklich viele hilfreiche Best Practices existieren. Wenn ich im Internet auf der Suche nach der Entscheidung gehe, das so oder so umsetzen, ist meistens die einzige Antwort die ich finde, wenn überhaupt eine, dass man es ausprobieren muss. Und das hilft mir nicht wirklich weiter.
Häufig ist es nämlich so, dass der eine oder die andere Methode mehr oder weniger das selbe zu erreichen, auf den einigen Treibern auf einmal drastisch schlechter abschneidet. Ich sehe die Hoffnung, dass die neuen APIs dort hilfreich sind.

Vulkan schreibt selbst, "Vulkan is not “low level” – just a better abstraction of modern hardware". Und auch wenn ich glaube, dass es in gewisser Weise schon etwas mehr Low Level sein wird als bisher, glaube ich nicht, dass es für den Nutzer etwas schlechtes ist.
Und ich spreche nicht von Anfängern. Ich würde mich auch nicht mehr als Anfänger bezeichnen. Und ihr euch wahrscheinlich auch nicht.

Der Link ist interessant, bestätigt im Prinzip aber sogar meine Ansichtsweise. Ich möchte eben nicht gegen tausende Zeilen Logik in den ganzen Simpelfunktionen ankämpfen, sondern einfach das machen können, was auf der GPU intuitiv am effizientesten ist. Ohne den Dreck dazwischen. Für meine Spiele sehe ich nämlich wenig Chancen, dass sich ein Treiberentwickler bei einer anderen Firma hinsetzt und ihn auf mein Spiel optimiert.

An DirectX 12 bin ich persönlich kaum interessiert. Wenn das nämlich tatsächlich nur auf Windows 10 läuft, wird es wohl wirklich nur für sehr wenige Entwickler in Frage kommen.

[David_pb]

AMD hat nun die Mantle Dokumentation veröffentlicht. Ist vermutlich auch ein ganz guter 'Sneak Peek' in Vulkan, und ohnehin sehr interessant! :)

Zum Thema passend fand ich auch das folgende Zitat:

Mantle is designed for those graphics developers who are willing to accept this new level of
responsibility.

und

Due to its lower level control of memory and synchronization features, the Mantle API is targeted
at sophisticated developers

[Krishty]

Leicht abweichend, aus der Dokumentation:

Index reset is a rarely used DirectX® 11 feature that does not provide significant Performance benefits. Applications should use indexed primitive lists to emulate index strips with reset.

Wie soll ich mir Index Reset vorstellen? NaNs in Vertices schreiben? Finde hier gerade nichts dazu …

[Schrompf]

Nee, ich glaube, Du konntest aus dem VertexShader einen Reset-Bool zurückgeben. Der hat dafür gesorgt, dass das aktuelle Primitive beendet und ein neues angefangen wird.

[Artificial Mind]

Ich hatte das bei meinem Praktikum vor ein paar Jahren genutzt um Blitze zu rendern.
Ein Blitz war ein LineStrip (n+1 Vertices für n Kanten). Damit ich alle Blitze auf einmal rendern kann, habe ich nach jedem Blitz ein Primitive Reset Index eingefügt und konnte die damit in einem Buffer haben (ohne von jedem Blitz zu jedem anderen eine Verbindungskante zu haben).

[Krishty]

Danke schonmal!

Nee, ich glaube, Du konntest aus dem VertexShader einen Reset-Bool zurückgeben. Der hat dafür gesorgt, dass das aktuelle Primitive beendet und ein neues angefangen wird.

Welche SV_* wäre das dann?

Ich hatte das bei meinem Praktikum vor ein paar Jahren genutzt um Blitze zu rendern.
Ein Blitz war ein LineStrip (n+1 Vertices für n Kanten). Damit ich alle Blitze auf einmal rendern kann, habe ich nach jedem Blitz ein Primitive Reset Index eingefügt […]

Wie heißt die entsprechende Konstante? Oder soll sie einfach out-of-range sein?

Ich möchte das in der Dokumentation finden …

[Artificial Mind]

Sorry falls ich jetzt was durcheinandergebracht/verwechselt habe, aber ich hatte OpenGL genutzt und dort ist das https://www.opengl.org/sdk/docs/man3/xh ... tIndex.xml

[mnemonix]

Hm, suchst du das hier.

Generating Multiple Strips

You can generate multiple strips through strip cutting. You can perform a strip cut by explicitly calling the RestartStrip HLSL function, or by inserting a special index value into the index buffer. This value is –1, which is 0xffffffff for 32-bit indices or 0xffff for 16-bit indices. An index of –1 indicates an explicit 'cut' or 'restart' of the current strip. The previous index completes the previous primitive or strip and the next index starts a new primitive or strip. For more info about generating multiple strips, see Geometry-Shader Stage.
Note You need feature level 10.0 or higher hardware because not all 10level9 hardware implements this functionality.

[dot]

Wie heißt die entsprechende Konstante?

-1 ;)

Edit: too late...

[Krishty]

Erste Sahne; danke! Und entschuldigt bitte das Hijacking.