Arbeitsspeicheraliasing und Datenvererbung
Platzierte und reservierte Ressource kann physischen Speicher innerhalb eines Heaps aliasieren. Platzierte Ressourcen ermöglichen mehr Datenvererbungsszenarien als reservierte Ressourcen, wenn der Heap das freigegebene Flag festgelegt hat oder wenn die aliasierten Ressourcen vollständig definierte Speicherlayouts aufweisen.
Aliasing
Eine Aliasingbarriere muss zwischen der Verwendung von zwei Ressourcen ausgegeben werden, die denselben physischen Speicher gemeinsam nutzen, auch wenn die Datenvererbung nicht gewünscht ist. Einfache Verwendungsmodelle müssen zumindest die Zielressource, die an einem solchen Vorgang beteiligt ist, kennzeichnen. Weitere Details und erweiterte Verwendungsmodelle finden Sie unter CreatePlacedResource.
Nachdem auf eine Ressource zugegriffen wurde, werden alle Ressourcen, die physischen Arbeitsspeicher für diese Ressource freigeben, ungültig, es sei denn, die Datenvererbung ist zulässig. Lesevorgänge ungültiger Ressourcen führen zu nicht definierten Ressourceninhalten. Schreibvorgänge in ungültige Ressourcen führen auch zu nicht definierten Ressourceninhalten, es sei denn, zwei Bedingungen treten auf:
- Die Ressource verfügt weder über das D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET noch über D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL.
- Bei dem Schreibvorgang handelt es sich um einen Kopier- oder Löschvorgang in eine gesamte Unterressource oder Kachel. Die Kachelinitialisierung ist nur für Ressourcen mit 64KB_TILE_UNDEFINED_SWIZZLE und 64KB_TILE_STANDARD_SWIZZLE verfügbar.
Überlappende Ungültigkeiten sind auf kleinere Granularitäten festgelegt, wenn Layouts Informationen zum Speicherort der Texel-Daten bereitstellen und Ressourcen in bestimmten Übergangsbarrierenzuständen vorhanden sind. Ungültige Vorgänge können jedoch nicht kleiner als die Granularitäten der Ressourcenausrichtung sein.
Eine Granularität der Pufferausrichtung beträgt 64 KB, und größere Ausrichtungsgranularität hat Vorrang. Dies ist wichtig, wenn Sie 4 KB-Texturen in Betracht ziehen, da sich mehrere 4 KB-Texturen in einem Bereich von 64 KB befinden können, ohne sich gegenseitig überlappen zu müssen. Ein Pufferaliasing desselben 64 KB-Bereichs kann jedoch nicht in Verbindung mit diesen 4 KB-Texturen verwendet werden. Die Anwendung kann den Zugriff auf den Puffer nicht zuverlässig daran hindern, die 4 KB-Texturen zu überschneiden, da GPUs 4 KB Texturdaten innerhalb des 64 KB-Bereichs in einem nicht definierten Muster schwenken dürfen.
64KB_TILE_UNDEFINED_SWIZZLE, 64KB_TILE_STANDARD_SWIZZLE und ROW_MAJOR Texturlayouts informieren die Anwendung darüber, welche überlappenden Ausrichtungsgranularitäten ungültig wurden. Beispiel: Eine Anwendung kann ein 2D-Render-Zieltextur-Array mit 2 Arraysegmenten, einer einzelnen Mip-Ebene und dem 64KB_TILE_UNDEFINED_SWIZZLE Layout erstellen. Angenommen, die Anwendung versteht, dass jedes Arraysegment 100 64 KB Kacheln belegt. Die Anwendung kann auf Arraysegment 0 verzichten und diesen Speicher für einen ~6MB-Puffer, eine ~6MB-Textur mit nicht definiertem Layout usw. wiederverwenden. Nehmen wir weiter an, dass die Anwendung die erste Kachel des Arraysegments 1 nicht mehr benötigt. Anschließend konnte die Anwendung dort auch einen 64 KB-Puffer finden, bis das Rendern erneut die erste Kachel des Arraysegments 1 erfordert. Die Anwendung müsste eine vollständige Kachel löschen oder kopieren, um die erste Kachel erneut mit dem Texturarray zu verwenden.
Aber auch Texturen mit definierten Layouts weisen weiterhin problematische Fälle auf. Texturressourcengrößen können sich erheblich davon unterscheiden, was die Anwendung selbst berechnen kann, da einige Adapterarchitekturen zusätzlichen Arbeitsspeicher für Texturen zuweisen, um die effektive Bandbreite während gängiger Rendering-Szenarien zu reduzieren. Alle Ungültigkeitserklärungen in diesem zusätzlichen Speicherbereich führen dazu, dass die gesamte Ressource für ungültig erklärt wird. Weitere Informationen finden Sie unter GetResourceAllocationInfo.
Datenvererbung
Platzierte Ressourcen ermöglichen die meisten Datenvererbung für Texturen, auch bei nicht definierten Speicherlayouts. Anwendungen können die Datenvererbungsfunktionen nachahmen, die freigegebene zugesicherte Ressourcen ermöglichen, indem sie zwei Texturen mit identischen Ressourceneigenschaften am gleichen Offset in einem freigegebenen Heap suchen. Die gesamte Ressourcenbeschreibung muss identisch sein, einschließlich des optimierten eindeutigen Werts und des Typs der Ressourcenerstellungsmethode (platziert oder reserviert). Beide Ressourcen hatten jedoch möglicherweise unterschiedliche anfängliche Übergangsbarrierenzustände.
Reservierte Ressourcen ermöglichen die Vererbung von Daten pro Kachel; es gibt jedoch häufig Einschränkungen für Barrierezustände für Ressourcenübergangsbarrieren.
Um Daten zu erben, müssen sich beide Ressourcen in einem kompatiblen Zustand der Ressourcenübergangsbarriere befinden:
- Für Puffer, gleichzeitige Zugriffstexturen und Adaptertexturen ist der Ressourcenübergangszustand nicht wichtig, und alle Zustände sind „kompatibel”.
- Für reservierte Texturen ohne die vorherigen Eigenschaften oder andere Datenvererbung pro Kachel über 64KB_TILE_UNDEFINED_SWIZZLE oder 64KB_TILE_STANDARD_SWIZZLE muss sich der Zustand der Ressourcenübergangsbarriere einschließlich der Kachel im allgemeinen Zustand befinden.
- Für alle anderen Texturen, bei denen die Ressourcenbeschreibungen exakt übereinstimmen, muss der Zustand der Ressourcenübergangsbarriere für jedes entsprechende Paar von Unterressourcen folgendes sein:
- Im gemeinsamen Zustand sein.
- Achten Sie darauf, wenn der Zustand über das gleiche GPU-Schreib-Flag verfügt.
Wenn die GPU Standard-Swizzle unterstützt, können Puffer und Standard-Swizzle-Texturen demselben Speicher zugeordnet werden und Daten untereinander vererben. Die Anwendung kann Texel aus der Pufferdarstellung bearbeiten, da das Standard-Swizzle-Muster beschreibt, wie Texel im Arbeitsspeicher angeordnet werden. Das CPU-sichtbare Swizzle-Muster entspricht dem GPU-sichtbaren Swizzle-Muster, das in Puffern zu sehen ist.
Zugehörige Themen