Unterschiede im Bindungsmodell von Direct3D 11
Eine der wichtigsten Entwurfsentscheidungen hinter der DirectX12-Bindung besteht darin, sie von anderen Verwaltungsaufgaben zu trennen. Dies stellt einige Anforderungen an die App, um bestimmte potenzielle Risiken zu bewältigen.
Der Hauptvorteil des D3D12-Bindungsmodells besteht darin, dass Es Apps ermöglicht, Texturbindungen häufig ohne hohe CPU-Leistungskosten zu ändern. Andere Vorteile sind, dass Shader Zugriff auf eine sehr große Anzahl von Ressourcen haben, Shader nicht im Voraus wissen müssen, wie viele Ressourcen gebunden werden, und dass ein einheitliches Ressourcenbindungsmodell unabhängig vom Hardware- oder App-Inhaltsfluss verwendet werden kann.
Um die Leistung zu verbessern, erfordert das Bindungsmodell nicht, dass das System nachverfolgt, welche Bindungen eine App von der GPU angefordert hat, und es gibt eine saubere Integration zwischen Bindungs- und Multithreadbefehlslisten.
In den folgenden Abschnitten werden einige änderungen am Ressourcenbindungsmodell seit D3D11 aufgeführt.
- Speicherresidenzverwaltung getrennt von Bindung
- Objektlebensdauerverwaltung getrennt von Bindung
- Nachverfolgung des Treiberressourcenstatus getrennt von der Bindung
- CPU GPU Mapped Memory Synchronization Separated From Binding
- Zugehörige Themen
Speicherresidenzverwaltung getrennt von Bindung
Anwendungen haben explizite Kontrolle darüber, welche Oberflächen für die direkte Verwendung durch die GPU verfügbar sein müssen (als "resident" bezeichnet). Im Gegensatz dazu können sie andere Zustände auf Ressourcen anwenden, z. B. sie explizit nicht als "resident" festlegen oder das Betriebssystem für bestimmte Klassen von Anwendungen auswählen lassen, die einen minimalen Speicherbedarf erfordern. Der wichtige Punkt hier ist, dass die Verwaltung des Gebietsansässigen durch die Anwendung vollständig von der Art und Weise entkoppelt ist, wie sie Shadern Zugriff auf Ressourcen gewährt.
Die Entkopplung der Residencyverwaltung vom Mechanismus für den Zugriff von Shadern auf Ressourcen reduziert die System-/Hardwarekosten für das Rendering, da das Betriebssystem nicht ständig den lokalen Bindungszustand überprüfen muss, um zu wissen, was als resident gelten 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 als "resident" festgelegt wurde.
Objektlebensdauerverwaltung getrennt von Bindung
Im Gegensatz zu vorherigen APIs verfolgt das System keine Bindungen von Ressourcen an die Pipeline mehr nach. Dies wird verwendet, um dem System das Beibehalten von Ressourcen zu ermöglichen, die von der Anwendung freigegeben wurden, da auf sie weiterhin durch ausstehende GPU-Arbeit verwiesen wird.
Vor dem Freigeben einer Ressource, z. B. einer Textur, müssen Anwendungen jetzt sicherstellen, dass die GPU den Verweis darauf abgeschlossen hat. Das bedeutet, bevor eine Anwendung eine Ressource sicher freigeben kann, muss die GPU die Ausführung der Befehlsliste abgeschlossen haben, die auf die Ressource verweist.
Nachverfolgung des Treiberressourcenstatus getrennt von der Bindung
Das System überprüft ressourcenbindungen nicht 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, dass sie wissen müssen, wann eine Oberfläche von der Verwendung als Renderzielansicht (RTV) zu Shader Ressourcenansicht (SRV) wechselt. Anwendungen selbst müssen jetzt über dedizierte APIs ermitteln, wann Ressourcenübergänge stattfinden, die dem System möglicherweise wichtig sind.
CPU GPU Mapped Memory Synchronization Separated From Binding
Das System überprüft ressourcenbindungen nicht mehr, um zu verstehen, ob das Rendering verzögert werden muss, da es von einer Ressource abhängt, die für den CPU-Zugriff zugeordnet, aber noch nicht zugeordnet wurde. Anwendungen sind jetzt dafür verantwortlich, CPU- und GPU-Arbeitsspeicherzugriffe zu synchronisieren. Um dies zu unterstützen, stellt das System Mechanismen bereit, mit denen die Anwendung den Ruhemodus eines CPU-Threads anfordern kann, bis die Arbeit abgeschlossen ist. Der Abruf kann auch durchgeführt werden, kann aber weniger effizient sein.