spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Danke für den Link! Zu Tobiking und Spiele Programmierers Antwort sei noch hinzugefügt:

Zitat von »Julién«

Kann mir bitte jmnd. erklären warum die neuen API-Architekturen/Varianten schneller sind? Was ist überhaupt mit "Overhead" gemeint bzw. was bedeutet das eig.?

Vereinfacht ausgedrückt läuft die Kommunikation von Anwendung und Grafikkarte asynchron, über einen (sog) Commandbuffer. Die Anwendung erzeugt eine Sequenz von Kommandos (z.B. Setze Rendertargets, binde Shader, binde Ressources [Texturen, Index/Vertexpuffer, ...] und zeichne mir ein Mesh mit den Parametern XYZ). Diese Kommandos werden nicht direkt von der GPU ausgeführt, sondern erstmal in einem Puffer gemerkt. Irgendwann später wird der Puffer zum verarbeiten an die GPU weitergegeben und die GPU verarbeitet alle Kommandos, der Reihe nach, bis der Commandbuffer leer ist. In der Zwischenzeit kann die CPU schon weitere Puffer zusammenstellen. Das heißt quasi, die GPU kann durchaus mehrere Frames hinter der CPU laufen.

Das Zusammenstellen der Kommandos im Commandbuffer benötigt natürlich CPU-Leistung. Im Idealfall ist der CPU Part so klein, das die Anwendung der GPU genug Futter liefert um nicht zu verhungern, neben allen anderen Aufgaben, die die CPU noch zu erledigen hat. Wenn die CPU allerdings zu wenig Arbeit bereitstellen kann, dann sitzt die GPU nur rum und tut nichts (starve). In dem Fall redet man auch davon, dass eine Anwendung CPU-Bound ist, weil die CPU Seite den Flaschenhals darstellt.

Damit kommt man zu einem der Probleme aktueller APIs und deren Treiber. Diese wollten, vom Design her, nämlich immer möglichst "Foolproof" für Anwendungen sein. Bei DX9 wird nahezu alles kompensiert was du dir vorstellen kannst. Selbst Meshdaten die nicht zu einem Shader passen werden bis zu einem gewissen Grad gepatched. Mit DX10 und DX11 hat sich Microsoft schon ein paar Schritte davon entfernt. Die APIs verzeihen deutlich weniger und haben sehr viel weniger "Schickschnack" integriert (u.A. auch validierung zur Runtime usw...). Der Overhead ist trotzallem noch viel höher als eigentlich notwendig, weil die Treiber immer noch versuchen viele Fehlerfälle abzufangen in die eine Anwendung treten kann.

Beispielsweise vermittelt das Immediate-Device der Anwendung, das GPU und CPU vollkommen synchron laufen und Kommandos sofort verarbeitet werden. Das im Hintergrund immer noch Commandbuffer aufgezeichnet und verzögert Abgearbeitet werden ist für die Anwendung komplett transparent. Das heißt, Anwendungen müssen sich nicht darum kümmern zu prüfen ob Ressourcen ggf noch an einem Puffer gebunden sind, der noch gar nicht von der GPU abgearbeitet wurde. Wenn solche Ressourcen nämlich gelöscht/überschrieben werden, dann steht die GPU auf einmal mit einem Puffer voller 'Danglingpointer' da und greift auf nicht vorhandenen oder geänderten Speicher zu. Das und viele andere Dinge wird vom Treiber automatisch verwaltet. Da der Treiber aber nicht weiss was eine Anwendung genau tun möcht, muss die Logik so allgemein wie möglich funktionieren, was schlussendlich zu einem unnötig hohen CPU Overhead führt.

Ein weiteres Problem, das schon seit langem bemängelt wurde, ist, dass APIs für den PC (GL, DX) moderne Hardware nicht besonders gut abbilden. Viele Konzepte sind noch Relikte aus vergangenen Zeiten und im API Design hängen geblieben. APIs die auf Konsolen verwendet werden machen das seit jeher viel besser und erlauben den Entwicklern ein "hardwarenäheres" programmieren. Der o.g. CPU Overhead existiert dort (meistens) nicht und die Anwendungen können sehr viel mehr aus der Grafikkarte holen als auf dem PC.

DirectX12 und Vulkan wollen jetzt etwas ähnliches erreichen. Nämlich den CPU Overhead weitgehend aus dem Treiber entfernen und an die Anwendung übergeben. D.h. die Anwendungen müssen wissen wie die GPU tickt und alle Fallen selbst entschärfen. Dafür können Applikationsspezifische Lösungen verwendet werden und ggf massiv CPU-Last eingespart werden. Also ein ganz ähnliches Arbeiten, wie es von den Konsolen bekannt war. Das führ uns dann auch unweigerlich zu...

Zitat von »Julién«

Wieso funktioniert multithread rendering überhaupt? Man hat soch trotzdem nur ein GPU Kern, der alles berechnet. Wieso ist das dann schneller?

Alte APIs waren von Design her für Singlethreaded Anwendungen gedacht. Es gibt durchaus Möglichkeiten auch damit Multithreaded zu entwickeln (DX9-Style-MT) aber einen richtigen Support dafür gabs noch nie. Mit DX11 wollte Microsoft das mit dem Deferred-Context-Konzept ändern. Von der Idee her war das zwar gut, aber die Umsetzung ist i.A. so schlecht, das es kaum bis keinen Vorteil gibt Deferred Kontexte zu verwenden. DX12 und Vulkan sind inhärent für multithraded Applikationen gedacht. Dabei geht es nicht darum einzelne Drawcalls von verschiedenen GPUs verarbeiten zu lassen (Multi-GPU/Async Compute Lösungen sind ein anderer Part) sondern es geht darum auf der CPU einen Frame auf mehreren Kernen zusammenbauen zu lassen, also ganz konkret: Mehrere Commandbuffer werden auf verschiedenen GPUs aufgebaut und dann seriell in eine Queue (an die GPU) dispatched.

Durch diese ganze Lastenverteilung und veringerter CPU Overhead bleibt deutlich mehr Leistung übrig für andere Tasks, oder ermöglicht es Anwendungen auf mobiler Hardware energiesparend zu laufen, oder natürlich die Anzahl der Drawcalls massiv zu erhöhen.

Zitat von »Nimelrian«

Wusste gar nicht, dass wir hier einen GDev an Bord haben

Wir haben sogar mehrere, soweit ich weiß.

Zitat von »Nimelrian«

Sollte GPUs hier nicht CPUs heißen?

Ja, du hast absolut recht!

Intel hat einen neuen Artikel veröffentlicht, in dem die neuen Resourcebinding-Konzepte von DirectX12 erläutert werden: Link