Residenz

Ein Objekt wird als "resident" betrachtet, wenn es von der GPU zugänglich ist.

Budget für DieResidenz

GPUs unterstützen noch keine Seitenfehler, sodass Anwendungen Daten in den physischen Speicher ausführen müssen, während die GPU darauf zugreifen kann. Dieser Prozess wird als "Machen von etwas Residentem" bezeichnet und muss sowohl für den physischen Systemspeicher als auch für den physischen diskreten Videospeicher durchgeführt werden. In D3D12 kapseln die meisten API-Objekte eine gewisse Menge an GPU-zugänglichen Arbeitsspeicher. Dieser GPU-zugängliche Speicher wird während der Erstellung des API-Objekts als "resident" gespeichert und bei der Zerstörung von API-Objekten aus dem System eniert.

Die menge des für den Prozess verfügbaren physischen Speichers wird als Videospeicherbudget bezeichnet. Das Budget kann merklich schwanken, wenn der Hintergrundprozess reaktivieren und im Ruhezustand ist. und schwanken erheblich, 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 ab. Wenn eine Anwendung nicht innerhalb ihres Budgets bleibt, wird der Prozess zeitweilig eingefroren, damit andere Anwendungen ausgeführt werden können, und/oder die Erstellungs-APIs geben einen Fehler zurück. Die IDXGIAdapter3-Schnittstelle stellt die Methoden für diese Funktionalität bereit, insbesondere QueryVideoMemoryInfo und RegisterVideoMemoryBudgetChangeNotificationEvent.

Anwendungen wird empfohlen, eine Reservierung zu verwenden, um die Menge des Arbeitsspeichers zu bezeichnen, auf den sie nicht mehr gehen können. Im Idealfall sind die vom Benutzer angegebenen "niedrigen" Grafikeinstellungen oder etwas niedrigeres der richtige Wert für eine solche Reservierung. Durch das Festlegen einer Reservierung erhält eine Anwendung niemals ein höheres Budget, als sie normalerweise erhalten würde. Stattdessen helfen die Reservierungsinformationen dem Betriebssystemkernel, die Auswirkungen großer Arbeitsspeicherverluste schnell zu minimieren. Selbst die Reservierung ist nicht garantiert für die Anwendung verfügbar, wenn die Anwendung nicht die Vordergrundanwendung ist.

Heapressourcen

Viele API-Objekte kapseln zwar einen Teil des GPU-zugänglichen Speichers, heaps & Ressourcen werden jedoch als die wichtigste Art und Weise erwartet, wie Anwendungen physischen Speicher nutzen und verwalten. Ein Heap ist die niedrigste Einheit zum Verwalten des physischen Speichers, daher ist es gut, sich mit den Eigenschaften derResidenz vertraut zu machen.

  • Heaps können nicht teilweise als "resident" bezeichnet werden, es gibt jedoch Problemumgehungen bei reservierten Ressourcen.
  • Heaps sollten als Teil eines bestimmten Pools budgetiert werden. UMA-Adapter verfügen über einen Pool, diskrete Adapter über zwei Pools. Es ist zwar richtig, dass der Kernel einige Heaps auf diskreten Adaptern vom Videospeicher in den Systemspeicher verschieben kann, aber dies ist nur ein extrem letzter Ausweg. Anwendungen sollten sich nicht auf das Überbudgetverhalten des Kernels verlassen und sich stattdessen auf eine gute Budgetverwaltung konzentrieren.
  • Heaps können aus der Residency entfernt werden, wodurch ihre Inhalte auf den Datenträger ausgepaget werden können. Die Zerstörung von Heaps ist jedoch eine zuverlässigere Technik, um Residency für alle Adapterarchitekturen frei zu machen. Bei Adaptern, bei denen das FeldMaxGPUVirtualAddressBitsPerProcess von D3D12 _ FEATURE DATA GPU VIRTUAL ADDRESS _ _ _ _ _ SUPPORT nahezu der Budgetgröße entspricht, gibt Evict dieResidenz nicht zuverlässig zurück.
  • Die Heaperstellung kann langsam sein. es ist jedoch für die Threadverarbeitung im Hintergrund optimiert. Es wird empfohlen, Heaps auf Hintergrundthreads zu erstellen, um eine Störung des Renderthreads zu vermeiden. In D3D12 können mehrere Threads create-Routinen sicher gleichzeitig aufrufen.

D3D12 bietet mehr Flexibilität und Orthogonalität in sein Ressourcenmodell, um mehr Optionen für Anwendungen zu ermöglichen. In D3D12 gibt es drei arten von Ressourcen auf hoher Ebene: "Committed", "Placed" und "Reserved".

  • Für Ressourcen, für die ein Committed erstellt wurde, werden gleichzeitig eine Ressource und ein Heap erstellt. Der Heap ist implizit und kann nicht direkt aufgerufen werden. Der Heap ist entsprechend dimensioniert, um die gesamte Ressource im Heap zu finden.
  • Platzierte Ressourcen ermöglichen die Platzierung einer Ressource an einem Offset von nicht 0 (null) innerhalb eines Heaps. Offsets müssen in der Regel auf 64 KB ausgerichtet werden. es gibt jedoch einige Ausnahmen in beide Richtungen. MSAA-Ressourcen erfordern eine Offsetausrichtung von 4 MB, und für kleine Texturen ist eine Offsetausrichtung von 4 KB verfügbar. Platzierte Ressourcen können nicht direkt verschoben oder einem anderen Heap neu zugeordnet werden. sie ermöglichen jedoch eine einfache Verschiebung 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 Ressourcendatenspeicherort verwendet werden.
  • Reservierte Ressourcen sind nur verfügbar, wenn der Adapter gekachelte Ressourcen der Ebene 1 oder höher unterstützt. Wenn verfügbar, bieten sie die fortgeschrittensten verfügbaren Verfahren für die Verwaltung von Residencys. aber nicht alle Adapter unterstützen sie derzeit. Sie ermöglichen die Neuzuordnung einer Ressource, ohne dass eine Neuzuordnung von Ressourcendeskriptoren, teilweiser MIP-Levelresidenz und Szenarios mit Sparsetextur erforderlich ist usw. Nicht alle Ressourcentypen werden auch dann unterstützt, wenn reservierte Ressourcen verfügbar sind, sodass ein vollständig allgemeiner seitenbasierter Residency-Manager noch nicht möglich ist.

Prioritäten der Residency

Die Windows 10 Creators Update ermöglicht Entwicklern, zu beeinflussen, welche Heaps und Ressourcen bevorzugt bleiben sollen, wenn die Arbeitsspeicherbedruckung erfordert, dass einige ihrer Ressourcen zurückgestuft werden. Dies hilft Entwicklern, Anwendungen mit besserer Leistung zu erstellen, indem sie wissen, dass die Runtime nicht aus der API-Nutzung abgeleitet werden kann. Es wurde erwartet, dass Entwickler beim Übergang von der Verwendung von commitierten Ressourcen zu erneuten und gekachelten Ressourcen komfortabler und fähiger werden, Prioritäten anzugeben.

Die Anwendung dieser Prioritäten muss einfacher sein als die Verwaltung von zwei dynamischen Arbeitsspeicherbudgets, indem Ressourcen manuell heruntergestuft und höher gestuft werden, da Anwendungen dies bereits tun können. Daher ist der Entwurf der Api für DieResidenzpriorität natürlich mit angemessenen Standardprioritäten aufeinander abgestellt, die jedem Heap oder jeder Ressource bei derEntität zugewiesen werden. Weitere Informationen finden Sie unter ID3D12Device1::SetResidencyPriority und die Enumeration D3D12 _ RESIDENCY _ PRIORITY.

Mit Prioritäten wird von Entwicklern eine der beiden erwarteten:

  • Erhöhen Sie die Priorität von einigen ausnahmebewöhnten Heaps, um die auswirkungen dieser Heaps auf die Leistung besser zu verringern, die früher oder häufiger als ihre natürlichen Zugriffsmuster erfordern würden. Dieser Ansatz wird von Anwendungen genutzt, die von Grafik-APIs wie Direct3D 11 oder OpenGL portiert werden. Das Ressourcenverwaltungsmodell von Direct3D 12 ist deutlich anders.
  • Überschreiben Sie fast alle Heapprioritäten mit dem eigenen Bucketisierungsschema der Anwendung, entweder basierend auf den Kenntnissen des Programmierers über die Zugriffshäufigkeit oder dynamisch. Ein festes Schema ist einfacher zu verwalten als ein dynamisches Schema, kann jedoch weniger effektiv sein und eine Intevention durch Programmierer erfordern, da sich Verwendungsmuster im Laufe der Entwicklung ändern. Dieser Ansatz wird voraussichtlich von Anwendungen genutzt, die mit der Ressourcenverwaltung im 12-Stil von Direct3D erstellt wurden, z. B. von Anwendungen, die die Residency-Bibliothek (insbesondere dynamische Schemas) verwenden.

Standardprioritätsalgorithmus

Eine Anwendung kann keine nützlichen Prioritäten für einen Heap angeben, den sie verwalten soll, ohne zuerst den Standardprioritätsalgorithmus zu unterordnen. 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 um denselben Arbeitsspeicher konkurrieren.

Die zum Generieren von Standardprioritäten gewählte Strategie besteht in der Kategorisierung von Heaps in zwei Buckets, die Heaps bevorzugen (die eine höhere Priorität erhalten), die von der GPU häufig über Heaps geschrieben werden, die nicht sind.

Der Bucket mit hoher Priorität enthält Heaps und Ressourcen, die mit Flags erstellt werden, die sie als Renderziele, Tiefen-Schablonenpuffer oder ungeordnete Zugriffsansichten (Unordered Access Views, UAVs) identifizieren. Diesen werden Prioritätswerte im Bereich ab D3D12 _ RESIDENCY _ PRIORITY _ HIGH zugewiesen. Zur weiteren Priorisierung zwischen diesen Heaps und Ressourcen werden die niedrigsten 16 Bits der Priorität auf die Größe des Heaps oder der Ressource dividiert durch 10 MB festgelegt (bei extrem großen Heaps auf 0xFFFF verteilt). Diese zusätzliche Priorisierung bevorzugt größere Heaps und Ressourcen.

Der Bucket mit niedriger Priorität enthält alle anderen Heaps und Ressourcen, denen der Prioritätswert D3D12 _ RESIDENCY _ PRIORITY NORMAL zugewiesen _ ist. Es wird keine weitere Priorisierung zwischen diesen Heaps und Ressourcen versucht.

Programmieren der Verwaltung vonResidenz

Einfache Anwendungen können möglicherweise nur durch Erstellen von Ressourcen, für die ein Committed durchgeführt wurde, erhalten, bis nicht genügend Arbeitsspeicher verfügbar ist. Bei einem Fehler kann die Anwendung andere Ressourcen oder API-Objekte zerstören, für die ein Committed erstellt wurde, damit weitere Ressourcen erstellt werden können. Aber auch einfache Anwendungen werden dringend empfohlen, auf negative Budgetänderungen zu achten und nicht verwendete API-Objekte ungefähr einmal pro Frame zu zerstören.

Die Komplexität eines Residency Management-Entwurfs erhöht sich, wenn versucht wird, adapterarchitekturen zu optimieren oder Prioritäten für die Residency zu integrieren. Die diskrete Budgetierung und Verwaltung von zwei Pools mit diskretem Arbeitsspeicher ist komplexer als die Verwaltung von nur einem. Das Zuweisen fester Prioritäten in großem Umfang kann zu einer Verwaltungslast werden, wenn sich Verwendungsmuster entwickeln. Das Überlaufen von Texturen in den Systemspeicher erhöht die Komplexität, da die falsche Ressource im Systemspeicher die Framerate erheblich beeinflussen kann. Und es gibt keine einfache Funktionalität, um die Ressourcen zu identifizieren, die entweder von einer höheren GPU-Bandbreite profitieren oder eine niedrigere GPU-Bandbreite tolerieren würden.

Noch kompliziertere Entwürfe fragen die Features des aktuellen Adapters ab. Diese Informationen sind unter 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 ins Land kommen. Beispielsweise können einige große Texturen und selten genutzte Codepfade ressourcenverwaltete Ressourcen verwenden, während viele Texturen möglicherweise mit einer Streamingeigenschaft gekennzeichnet werden und eine allgemeine Technik für platzierte Ressourcen verwenden.

ID3D12Heap

Speicherverwaltung