Arbeitsspeicheraliasing und Datenvererbung

Platzierte und reservierte Ressourcen können einen Alias für physischen Speicher innerhalb eines Heaps setzen. Platzierte Ressourcen ermöglichen mehr Datenvererbungsszenarien als reservierte Ressourcen, wenn für den Heap das freigegebene Flag festgelegt ist oder wenn die Aliasressourcen über vollständig definierte Speicherlayouts verfügen.

Aliase

Zwischen der Verwendung von zwei Ressourcen, die denselben physischen Speicher gemeinsam nutzen, muss eine Aliasingbarriere ausgegeben werden, auch wenn keine Datenvererbung gewünscht ist. Einfache Verwendungsmodelle müssen zumindest die Zielressource bezeichnen, die an einem solchen Vorgang beteiligt ist. Weitere Informationen und erweiterte Nutzungsmodelle finden Sie unter CreatePlacedResource.

Nachdem auf eine Ressource zugegriffen wurde, werden alle Ressourcen, die physischen Speicher für diese Ressource freigeben, ungültig, es sei denn, die Datenvererbung ist zulässig. Lesefunktionen 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, es treten zwei Bedingungen auf:

  • Die Ressource verfügt weder über das D3D12 _ RESOURCE FLAG ALLOW RENDER TARGET noch über das _ _ _ _ D3D12 _ RESOURCE FLAG ALLOW DEPTH _ _ _ _ STENCIL.
  • Der Schreibvorgang ist ein Kopier- oder Clear-Vorgang für eine gesamte Unterressource oder Kachel. Die Kachelinitialisierung ist nur für Ressourcen mit 64 KB _ TILE _ UNDEFINED _ SWIZZLE und 64 KB _ TILE STANDARD _ _ SWIZZLE verfügbar.

Überlappende Invalidierungen werden auf kleinere Granularitäten reduziert, wenn Layouts Informationen zum Speicherort der Texeldaten bereitstellen und wenn sich Ressourcen in bestimmten Übergangsbarrierenzuständen befinden. Invalidierungen können jedoch nicht kleiner als die Granularität der Ressourcenausrichtung sein.

Eine Pufferausrichtungsgranularität beträgt 64 KB, und eine 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 64-KB-Bereich befinden können, ohne sich gegenseitig zu überlappen. Ein Pufferalias mit dem gleichen 64-KB-Bereich kann jedoch nicht in Verbindung mit einer dieser 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 wischen dürfen.

64 KB _ KACHEL _ UNDEFINED _ SWIZZLE, 64 KB _ 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-Renderzieltexturarray mit 2 Arrayslices, einer einzelnen Mipebene und dem 64-KB-LAYOUT _ TILE _ UNDEFINED _ SWIZZLE erstellen. Angenommen, die Anwendung versteht, dass jeder Arrayslice 100 64 KB Kacheln einnimmt. Die Anwendung kann auf die Verwendung von Arrayslice 0 verzichten und diesen Arbeitsspeicher entweder für einen Puffer mit ca. 6 MB, eine Textur von ca. 6 MB mit undefiniertem Layout usw. wiederverwenden. Gehen Sie weiter davon aus, dass die Anwendung die erste Kachel von Arrayslice 1 nicht mehr benötigt. Anschließend könnte die Anwendung dort auch einen Puffer mit 64 KB finden, bis das Rendering wieder die erste Kachel des Arrays Slice 1 erfordert. Die Anwendung müsste eine vollständige Kachel löschen oder kopieren, um die erste Kachel erneut mit dem Texturarray zu verwenden.

Selbst Texturen mit definierten Layouts weisen jedoch weiterhin problematische Fälle auf. Die Größe der Texturressourcen kann sich erheblich von dem unterscheiden, was die Anwendung selbst berechnen kann, da einige Adapterarchitekturen zusätzlichen Speicher für Texturen zuweisen, um die effektive Bandbreite in gängigen Renderingszenarien zu reduzieren. Alle Invalidierungen in diesem zusätzlichen Speicherbereich führen dazu, dass die gesamte Ressource ungültig wird. Weitere Informationen finden Sie unter GetResourceAllocationInfo.

Datenvererbung

Platzierte Ressourcen ermöglichen die größte Datenvererbung für Texturen, auch bei nicht definierten Speicherlayouts. Anwendungen können die Datenvererbungsfunktionen imitieren, die freigegebene Ressourcen mit Commit 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). Es kann jedoch sein, dass beide Ressourcen unterschiedliche Anfängliche Übergangsbarrierenzustände aufweisen.

Reservierte Ressourcen aktivieren die Datenvererbung pro Kachel. Es gibt jedoch häufig Einschränkungen für Barrierezustände für den Ressourcenübergang.

Um Daten zu erben, müssen sich beide Ressourcen in einem kompatiblen Barrierezustand für den Ressourcenübergang befinden:

  • Bei Puffern, Texturen für gleichzeitigen Zugriff und adapterübergreifenden Texturen 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 64 KB _ TILE _ UNDEFINED _ SWIZZLE oder 64 KB _ TILE STANDARD _ _ SWIZZLE muss sich der Barrierezustand des Ressourcenübergangs einschließlich der Kachel im allgemeinen Zustand befinden.
  • Für alle anderen Texturen, bei denen die Ressourcenbeschreibungen genau übereinstimmen, muss der Barrierezustand des Ressourcenübergangs für jedes entsprechende Paar von Unterressourcen:
    • Befinden Sie sich im allgemeinen Zustand.
    • Ist gleich, wenn der Zustand das gleiche GPU-Schreibflag enthält.

Wenn die GPU Standard-Swizzle unterstützt, können Puffer und Standardmäßige Swizzletexturen mit demselben Speicher aliasiert werden und Daten zwischen ihnen erben. Die Anwendung kann Texel aus der Pufferdarstellung bearbeiten, da das Standardmäßige Swizzle-Muster beschreibt, wie Texel im Arbeitsspeicher angeordnet werden. Das CPU-sichtbare Swizzlemuster entspricht dem GPU-sichtbaren Swizzlemuster, das in Puffern zu sehen ist.

Unterzuweisung innerhalb von Heaps