Freigeben über

Unterschiede im Bindungsmodell von Direct3D 11

  • Artikel

Eine der Standard Entwurfsentscheidungen hinter der DirectX12-Bindung besteht darin, sie von anderen Verwaltungsaufgaben zu trennen. Dies stellt einige Anforderungen an die App, um bestimmte potenzielle Gefahren zu verwalten.

Der Standard Vorteil des D3D12-Bindungsmodells besteht darin, dass Apps texturierte Bindungen häufig ändern können, ohne hohe CPU-Leistungskosten. Weitere Vorteile sind, dass Shader Zugriff auf eine sehr große Anzahl von Ressourcen haben, Shader im Voraus nicht wissen müssen, wie viele Ressourcen gebunden werden, und dass ein einheitliches Ressourcenbindungsmodell unabhängig von der Hardware oder dem Inhaltsfluss von Apps verwendet werden kann.

Um die Leistung zu verbessern, muss das System nicht nachverfolgen, welche Bindungen eine App von der GPU angefordert hat, und es gibt eine sauber Integration zwischen Bindungs- und Multithreadbefehlslisten.

In den folgenden Abschnitten werden einige Änderungen am Ressourcenbindungsmodell seit D3D11 aufgeführt.

Speicherresidenzverwaltung getrennt von Bindung

Anwendungen haben eine explizite Kontrolle darüber, welche Oberflächen sie für die direkte Verwendung der GPU verfügbar sein müssen (als "resident" bezeichnet). Umgekehrt können sie andere Zustände auf Ressourcen anwenden, z. B. dass sie explizit nicht resident sind, oder das Betriebssystem bestimmte Anwendungsklassen auswählen lassen, die einen minimalen Arbeitsspeicherbedarf erfordern. Wichtig dabei ist, dass die Verwaltung des Residenten durch die Anwendung vollständig von der Möglichkeit des Zugriffs auf Ressourcen für Shader entkoppelt ist.

Die Entkoppelung der Residenzverwaltung vom Mechanismus, um Shadern Zugriff auf Ressourcen zu gewähren, reduziert die System-/Hardwarekosten für das Rendern, da das Betriebssystem nicht ständig den lokalen Bindungsstatus überprüfen muss, um zu wissen, was resident sein soll. Darüber hinaus müssen Shader nicht mehr wissen, auf welche genauen Oberflächen sie möglicherweise verweisen müssen, solange der gesamte Satz von möglicherweise zugänglichen Ressourcen im Voraus eingerichtet wurde.

Objektlebensdauerverwaltung getrennt von Bindung

Im Gegensatz zu früheren APIs verfolgt das System keine Ressourcenbindungen mehr an die Pipeline nach. Dies wird verwendet, um es dem System zu ermöglichen, Ressourcen am Leben zu erhalten, die die Anwendung freigegeben hat, da sie weiterhin von hervorragender GPU-Arbeit referenziert werden.

Vor dem Freigeben einer Ressource, z. B. einer Textur, müssen Anwendungen jetzt sicherstellen, dass die GPU die Referenzierung abgeschlossen hat. Dies bedeutet, dass die GPU die Ausführung der Befehlsliste abgeschlossen haben muss, die auf die Ressource verweist, bevor eine Anwendung eine Ressource sicher freigeben kann.

Treiberressourcenstatusnachverfolgung getrennt von Bindung

Das System überprüft keine Ressourcenbindungen mehr, um zu verstehen, wann Ressourcenübergänge aufgetreten sind, die zusätzliche Treiber- oder GPU-Arbeit erfordern. Ein häufiges Beispiel für viele GPUs und Treiber ist es, zu wissen, wann eine Oberfläche von der Verwendung als Renderzielansicht (Render Target View, RTV) zu Shader Resource View (SRV) wechselt. Anwendungen selbst müssen jetzt erkennen, wann Ressourcenübergänge, die dem System wichtig sind, über dedizierte APIs erfolgen.

CPU-GPU zugeordnete Speichersynchronisierung getrennt von Bindung

Das System überprüft keine Ressourcenbindungen mehr, um zu ermitteln, ob das Rendering verzögert werden muss, da es von einer Ressource abhängt, die für den CPU-Zugriff zugeordnet wurde, aber noch nicht nicht zugeordnet wurde. Anwendungen sind jetzt für die Synchronisierung von CPU- und GPU-Speicherzugriffen verantwortlich. Um dies zu unterstützen, stellt das System Mechanismen bereit, mit denen die Anwendung den Ruhezustand eines CPU-Threads anfordern kann, bis die Arbeit abgeschlossen ist. Die Abfrage kann auch durchgeführt werden, kann aber weniger effizient sein.

Ressourcenbindung