Freigeben über

Residenz

  • Artikel

Ein Objekt gilt als residenten, wenn es von der GPU zugänglich ist.

Residency-Budget

GPUs unterstützen die Seitenfehler noch nicht, sodass Anwendungen Daten in physischen Arbeitsspeicher übernehmen müssen, während die GPU darauf zugreifen kann. Dieser Prozess wird als "Gebietsansässigmachen" bezeichnet und muss sowohl für den physischen Systemspeicher als auch für den physischen separaten Videospeicher erfolgen. In D3D12 kapseln die meisten API-Objekte eine Menge gpuzugriffsfähiger Speicher. Dieser GPU-barrierefreiheitsspeicher wird während der Erstellung des API-Objekts resident und wird bei der ZERSTÖRUNG von API-Objekten vertrieben.

Die Menge des für den Prozess verfügbaren physischen Arbeitsspeichers wird als Videospeicherbudget bezeichnet. Das Budget kann merklich schwanken, da Hintergrundprozesse aufwachen und schlafen; und schwanken dramatisch, wenn der Benutzer zu einer anderen Anwendung wechselt. Die Anwendung kann benachrichtigt werden, wenn sich das Budget ändert und sowohl das aktuelle Budget als auch die aktuell verbrauchte Arbeitsspeichermenge abruft. Wenn eine Anwendung nicht innerhalb ihres Budgets verbleibt, wird der Prozess zeitweise fixiert, damit andere Anwendungen ausgeführt werden können und/oder die Erstellungs-APIs einen Fehler zurückgeben. Die IDXGIAdapter3 Schnittstelle stellt die Methoden für diese Funktionalität bereit, insbesondere QueryVideoMemoryInfo und RegisterVideoMemoryBudgetChangeNotificationEvent.

Anwendungen werden empfohlen, eine Reservierung zu verwenden, um die Menge an Arbeitsspeicher zu kennzeichnen, ohne die sie nicht gehen können. Im Idealfall ist der vom Benutzer angegebene "niedrige" Grafikeinstellungen oder etwas noch niedriger der richtige Wert für eine solche Reservierung. Das Festlegen einer Reservierung gibt einer Anwendung niemals ein höheres Budget, als es normalerweise erhalten würde. Stattdessen helfen die Reservierungsinformationen dem Betriebssystem-Kernel, die Auswirkungen großer Speicherdrucksituationen schnell zu minimieren. Auch die Reservierung ist nicht garantiert für die Anwendung verfügbar, wenn die Anwendung nicht die Vordergrundanwendung ist.

Heap-Ressourcen

Während viele API-Objekte einen gpufähigen Speicher kapseln, werden Heaps & Ressourcen voraussichtlich am wichtigsten sein, wie Anwendungen physischen Speicher verbrauchen und verwalten. Ein Heap ist die niedrigste Einheit zum Verwalten des physischen Speichers, daher ist es gut, sich mit ihren Residency-Eigenschaften vertraut zu machen.

  • Heaps können nicht teilweise resident werden, aber Problemumgehungen sind mit reservierten Ressourcen vorhanden.
  • Heaps sollten als Teil eines bestimmten Pools budgetiert werden. UMA-Adapter verfügen über einen Pool, während diskrete Adapter über zwei Pools verfügen. Der Kernel kann zwar einige Heaps auf einzelnen Adaptern vom Videospeicher in den Systemspeicher verschieben, dies ist jedoch nur eine extreme letzte Möglichkeit. Anwendungen sollten sich nicht auf das Überbudgetverhalten des Kernels verlassen und sollten sich stattdessen auf ein gutes Budgetmanagement konzentrieren.
  • Heaps können aus der Residency entfernt werden, sodass ihre Inhalte auf den Datenträger ausgelagert werden können. Aber die Zerstörung von Heaps ist eine zuverlässigere Technik, um Residency in allen Adapterarchitekturen freizugeben. Auf Adaptern, bei denen maxGPUVirtualAddressBitsPerProcess Feld der D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT in der Nähe der Budgetgröße liegt, Evict nicht zuverlässig die Residency zurückgewinnt.
  • Heap-Erstellung kann langsam sein; sie ist jedoch für die Hintergrundthreadverarbeitung optimiert. Es wird empfohlen, Heaps für Hintergrundthreads zu erstellen, um zu vermeiden, dass der Renderthread glitching. In D3D12 können mehrere Threads gleichzeitig Routinen erstellen.

D3D12 führt mehr Flexibilität und Orthogonalität in das Ressourcenmodell ein, um mehr Optionen für Anwendungen zu ermöglichen. Es gibt drei allgemeine Ressourcentypen in D3D12: Zugesichert, platziert und reserviert.

  • Zugesicherte Ressourcen erstellen gleichzeitig eine Ressource und einen Heap. Der Heap ist implizit und kann nicht direkt aufgerufen werden. Der Heap ist entsprechend angepasst, um die gesamte Ressource innerhalb des Heaps zu finden.
  • Platzierte Ressourcen ermöglichen die Platzierung einer Ressource in einem Nicht-Null-Offset innerhalb eines Heaps. Offsets müssen in der Regel auf 64 KB ausgerichtet werden; einige Ausnahmen sind jedoch in beide Richtungen vorhanden. MSAA-Ressourcen erfordern 4 MB Offsetausrichtung, und die 4 KB-Offsetausrichtung ist für kleine Texturen verfügbar. Platzierte Ressourcen können nicht direkt an einen anderen Heap verschoben oder neu zugeordnet werden. sie ermöglichen jedoch eine einfache Verlagerung der Ressourcendaten zwischen Heaps. Nachdem Sie eine neue platzierte Ressource in einem anderen Heap erstellt und die Ressourcendaten kopiert haben, müssen neue Ressourcendeskriptoren für den neuen Speicherort der Ressourcendaten verwendet werden.
  • Reservierte Ressourcen sind nur verfügbar, wenn der Adapter nebeneinander angeordnete Ressourcen der Ebene 1 oder höher unterstützt. Wenn verfügbar, bieten sie die fortschrittlichsten Residency Management-Techniken verfügbar; aber nicht alle Adapter unterstützen sie derzeit. Sie ermöglichen das Neumapping einer Ressource, ohne dass eine Regeneration von Ressourcendeskriptoren, partiellem Mip-Level-Residency und geringen Texturszenarien usw. erforderlich ist. Nicht alle Ressourcentypen werden unterstützt, auch wenn reservierte Ressourcen verfügbar sind, sodass ein vollständig allgemeiner seitenbasierter Residency-Manager noch nicht machbar ist.

Residency-Prioritäten

Mit dem Windows 10 Creators Update können Entwickler beeinflussen, welche Heaps und Ressourcen bevorzugt werden, wenn der Arbeitsspeicherdruck erfordert, dass einige ihrer Ressourcen herabgestuft werden. Dies hilft Entwicklern, anwendungen besser zu erstellen, indem sie Wissen nutzen, dass die Laufzeit nicht von der API-Verwendung abgeleitet werden kann. Es wird erwartet, dass Entwickler bequemer und fähiger werden, Prioritäten anzugeben, während sie von der Verwendung von zugesicherten Ressourcen zu erneuten und nebeneinander angeordneten Ressourcen wechseln.

Die Anwendung dieser Prioritäten muss einfacher sein als das Verwalten von zwei dynamischen Speicherbudgets, das manuelle Herabstufen und Fördern von Ressourcen, da Anwendungen dies bereits tun können. Daher wird der Entwurf der Residency-Prioritäts-API natürlich mit angemessenen Standardprioritäten abgestimmt, die jedem Heap oder jeder Ressource zugewiesen sind, wie er erstellt wird. Weitere Informationen finden Sie unter ID3D12Device1::SetResidencyPriority und der D3D12_RESIDENCY_PRIORITY Enumeration.

Bei Prioritäten werden Entwickler entweder wie folgt erwartet:

  • Erhöhen Sie die Priorität einiger außergewöhnlicher Heaps, um die erfahrenen Leistungseinbußen dieser Heaps zu verringern, die früher oder häufiger herabgestuft werden, als ihre natürlichen Zugriffsmuster erfordern würden. Dieser Ansatz wird voraussichtlich von Anwendungen genutzt, die von Grafik-APIs wie Direct3D 11 oder OpenGL portiert werden, die das Ressourcenverwaltungsmodell von Direct3D 12 erheblich unterscheidet.
  • Überschreiben Sie nahezu alle Heapprioritäten mit dem eigenen Bucketisierungsschema der Anwendung, entweder fest, basierend auf dem Wissen des Programmierers über die Zugriffshäufigkeit oder dynamisch; Ein festes Schema ist einfacher zu verwalten als ein dynamisches Schema, kann aber weniger effektiv sein und erfordert programmierintevention, da sich die Verwendungsmuster während der Entwicklung ändern. Dieser Ansatz wird voraussichtlich von Anwendungen genutzt, die mit Direct3D 12-Ressourcenverwaltung erstellt werden, z. B. von Anwendungen, die die Residency-Bibliothek (insbesondere dynamische Schemas) verwenden.

Standardprioritätsalgorithmus

Eine Anwendung kann keine nützlichen Prioritäten für alle Heaps angeben, die verwaltet werden sollen, ohne zuerst den Standardprioritätsalgorithmus zu unterschreiten. Dies liegt daran, dass der Wert der Zuweisung einer bestimmten Priorität zu einem Heap von seiner relativen Priorität zu anderen priorisierten Heaps abgeleitet wird, die für denselben Speicher konkurrieren.

Die strategie, die zum Generieren von Standardprioritäten ausgewählt wurde, besteht darin, Heaps in zwei Buckets zu kategorisieren, wobei Heaps bevorzugt werden (die höhere Priorität haben), die von der GPU häufig über Heaps geschrieben werden, die nicht.

Der Bucket mit hoher Priorität enthält Heaps und Ressourcen, die mit Flags erstellt werden, die sie als Renderziele, Tiefenschablonenpuffer oder ungeordnete Zugriffsansichten (Unordered Access Views, UAVs) identifizieren. Diese werden prioritätswerten im Bereich beginnend bei D3D12_RESIDENCY_PRIORITY_HIGHzugewiesen; um zwischen diesen Heaps und Ressourcen weiter zu priorisieren, werden die niedrigsten 16 Bit der Priorität auf die Größe des Heaps oder der Ressource festgelegt, die durch 10 MB geteilt ist (Sättigung auf 0xFFFF für extrem große Heaps). Diese zusätzliche Priorisierung bevorzugt größere Heaps und Ressourcen.

Der Bucket mit niedriger Priorität enthält alle anderen Heaps und Ressourcen, denen ein Prioritätswert von D3D12_RESIDENCY_PRIORITY_NORMALzugewiesen wird. Es wird keine weitere Priorisierung dieser Heaps und Ressourcen versucht.

Programmier-Residency-Management

Einfache Anwendungen können möglicherweise nur durch erstellen zugesicherte Ressourcen abgerufen werden, bis fehler beim Ausfall des Arbeitsspeichers auftreten. Wenn ein Fehler auftritt, kann die Anwendung andere zugesicherte Ressourcen oder API-Objekte zerstören, um weitere Ressourcenerstellungen zu ermöglichen. Aber auch einfache Anwendungen werden dringend empfohlen, auf negative Budgetänderungen zu achten und nicht verwendete API-Objekte ungefähr einmal einen Frame zu zerstören.

Die Komplexität eines Residency Management-Designs wird steigen, wenn sie versuchen, für Adapterarchitekturen zu optimieren oder Residency-Prioritäten zu integrieren. Das diskrete Budgetieren und Verwalten von zwei Pools mit diskretem Speicher ist komplexer als die Verwaltung nur eines, und das Zuweisen von festen Prioritäten in einem breiten Maßstab kann zu einer Erhaltungslast werden, wenn sich Die Verwendungsmuster entwickeln. Das Überlaufen von Texturen in den Systemspeicher erhöht die Komplexität, da die falsche Ressource im Systemspeicher die Framerate stark beeinträchtigen kann. Und es gibt keine einfache Funktionalität, um die Ressourcen zu identifizieren, die entweder von einer höheren GPU-Bandbreite profitieren oder eine geringere GPU-Bandbreite tolerieren würden.

Noch kompliziertere Designs fragen die Features des aktuellen Adapters ab. Diese Informationen sind in D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT, D3D12_FEATURE_DATA_ARCHITECTURE, D3D12_TILED_RESOURCES_TIERund D3D12_RESOURCE_HEAP_TIERverfügbar.

Mehrere Teile einer Anwendung werden wahrscheinlich mit unterschiedlichen Techniken aufgewindet. Beispielsweise können einige große Texturen und selten ausgeübte Codepfade zugesicherte Ressourcen verwenden, während viele Texturen mit einer Streamingeigenschaft festgelegt und eine allgemeine Methode für platzierte Ressourcen verwendet werden.

ID3D12Heap-

Speicherverwaltung