Kachelzugriffseinschränkungen bei doppelten Zuordnungen

Es gibt Einschränkungen für den Kachelzugriff mit doppelten Zuordnungen, z. B. beim Kopieren von Streamingressourcen mit überlappender Quelle und Ziel oder beim Rendern auf Kacheln, die innerhalb des Renderbereichs freigegeben werden.

Kopieren von Streamingressourcen mit überlappender Quelle und Ziel

Wenn Kacheln im Quell- und Zielbereich eines Kopiervorgangs duplizierte Zuordnungen im Kopierbereich aufweisen, die sich auch dann überlappen würden, wenn beide Ressourcen keine Streamingressourcen wären und der Kopiervorgang überlappende Kopien unterstützt, verhält sich der Kopiervorgang* einwandfrei (so, als ob die Quelle an einen temporären Speicherort kopiert wird, bevor zum Ziel gewechselt wird). Wenn die Überlappung jedoch nicht offensichtlich ist (wie die Quell- und Zielressourcen unterschiedlich sind, aber Freigabezuordnungen oder Zuordnungen auf einer bestimmten Oberfläche dupliziert werden), sind die Ergebnisse des Kopiervorgangs auf den freigegebenen Kacheln undefiniert.

Kopieren in eine Streamingressource mit doppelten Kacheln im Zielbereich

Das Kopieren in eine Streamingressource mit doppelten Kacheln im Zielbereich führt zu undefinierten Ergebnissen in diesen Kacheln, es sei denn, die Daten selbst sind identisch. Verschiedene Kacheln schreiben die Kacheln möglicherweise in unterschiedlichen Reihenfolgen.

UAV-Zugriffe auf doppelte Kachelzuordnungen

Angenommen, eine ungeordnete Zugriffsansicht (UAV) für eine Streamingressource weist doppelte Kachelzuordnungen in ihrem Bereich oder mit anderen Ressourcen auf, die an die Pipeline gebunden sind. Die Reihenfolge der Zugriffe auf diese doppelten Kacheln ist nicht definiert, wenn sie von verschiedenen Threads ausgeführt wird, ebenso wie jede Reihenfolge des Speicherzugriffs auf UAVs im Allgemeinen ungeordnet ist.

Rendern nach Kachelzuordnungsänderungen oder Inhaltsupdates von externen Zuordnungen

Wenn sich die Kachelzuordnungen einer Streamingressource geändert haben oder der Inhalt in zugeordneten kachelnden Poolkacheln über die Zuordnungen einer anderen Streamingressource geändert wurde und die Streamingressource über die Renderzielansicht oder die Tiefenschablonenansicht gerendert wird, muss die Anwendung Die Kacheln löschen (mit der festen Funktion ApIs löschen) oder die Kacheln, die innerhalb des gerenderten Bereichs geändert wurden, vollständig mithilfe von Copy*/Update*-APIs kopieren.

Wenn eine Anwendung in diesen Fällen nicht gelöscht oder kopiert werden kann, führt dies dazu, dass die Hardwareoptimierungsstrukturen für die angegebene Renderzielansicht oder tiefenschablonenansicht veraltet sind und zu Garbage Rendering-Ergebnissen auf einigen Hardware- und Inkonsistenzen auf unterschiedlicher Hardware führen. Diese ausgeblendeten Optimierungsdatenstrukturen, die von Hardware verwendet werden, sind möglicherweise für einzelne Zuordnungen lokal und für andere Zuordnungen zum gleichen Speicher nicht sichtbar.

Wenn Sie eine Ressourcenansicht löschen (alle Elemente in einer Ressourcenansicht auf einen Wert festlegen), können Sie Renderzielansichten mit Rechtecken löschen. Für Hardware, die Streamingressourcen unterstützt, muss das Löschen einer Ressourcenansicht auch das Löschen von Tiefenschablonenansichten mit Rechtecken für Tiefenoberflächen (ohne Schablone) unterstützen. Dieser Vorgang ermöglicht es Anwendungen, nur den erforderlichen Bereich einer Oberfläche zu löschen.

Wenn eine Anwendung vorhandene Speicherinhalte von Bereichen in einer Streamingressource beibehalten muss, in denen sich Zuordnungen geändert haben, muss diese Anwendung die klare Anforderung umgehen. Die Anwendung kann diese Umgehung durchführen, indem sie zuerst den Inhalt speichert, an dem sich Kachelzuordnungen geändert haben (indem sie auf eine temporäre Oberfläche kopiert werden), den erforderlichen Clear-Befehl ausgibt und dann den Inhalt zurück kopiert. Dies würde zwar die Aufgabe erfüllen, Oberflächeninhalte für inkrementelles Rendering beizubehalten, der Nachteil ist jedoch, dass die nachfolgende Renderingleistung auf der Oberfläche beeinträchtigt werden kann, da Renderingoptimierungen möglicherweise verloren gehen.

Wenn eine Kachel mehreren Streamingressourcen gleichzeitig zugeordnet wird und Kachelinhalte mit irgendeinem Mittel (Rendern, Kopieren usw.) über eine der Streamingressourcen bearbeitet werden, muss die Kachel zuerst wie zuvor beschrieben gelöscht werden, wenn dieselbe Kachel über eine andere Streamingressource gerendert werden soll.

Rendern in Kacheln, die außerhalb des Renderbereichs gemeinsam genutzt werden

Angenommen, ein Bereich in einer Streamingressource wird in gerendert, und die Kachelpoolkacheln, auf die vom Renderbereich verwiesen wird, werden auch von außerhalb des Renderbereichs zugeordnet (auch über andere Streamingressourcen gleichzeitig oder nicht). Daten, die in diesen Kacheln gerendert werden, werden nicht ordnungsgemäß angezeigt, wenn sie über die anderen Zuordnungen angezeigt werden, obwohl das zugrunde liegende Speicherlayout kompatibel ist. Dies ist auf Optimierungsdatenstrukturen zurückzuführen, die teilweise hardwarebenutzt werden und für einzelne Zuordnungen für renderbare Oberflächen lokal sein können und für andere Zuordnungen zum gleichen Speicherort nicht sichtbar sind.

Sie können diese Einschränkung umgehen, indem Sie von der gerenderten Zuordnung in alle anderen Zuordnungen in denselben Speicher kopieren, auf den möglicherweise zugegriffen wird (oder diesen Speicher löschen oder andere Daten kopieren, wenn der alte Inhalt nicht mehr benötigt wird). Diese Umgehung scheint redundant zu sein, aber alle anderen Zuordnungen zum gleichen Arbeitsspeicher verstehen korrekt, wie sie auf den Inhalt zugreifen können, und zumindest die Speichereinsparungen, die durch nur eine einzige physische Speichersicherung erzielt werden, bleiben intakt.

Wenn Sie außerdem zwischen verschiedenen Streamingressourcen wechseln, die Zuordnungen gemeinsam nutzen (sofern nicht nur Lesevorgänge), müssen Sie zwischen den Switches eine Einschränkung für die Datenzugriffsreihenfolge (eine Barriere) zwischen mehreren kachelten Ressourcen angeben.

Rendern in Kacheln, die innerhalb des Renderbereichs gemeinsam genutzt werden

Wenn ein Bereich in einer Streamingressource in gerendert wird und innerhalb des Renderbereichs mehrere Kacheln demselben Kachelpoolspeicherort zugeordnet werden, sind die Renderingergebnisse für diese Kacheln nicht definiert.

Datenkompatibilität zwischen Streamingressourcenfreigabekacheln

Angenommen, mehrere Streamingressourcen verfügen über Zuordnungen zu denselben Kachelpoolspeicherorten, und jede Ressource wird für den Zugriff auf dieselben Daten verwendet. Dieses Szenario ist nur gültig, wenn die anderen Regeln zur Vermeidung von Problemen mit Hardwareoptimierungsstrukturen vermieden werden, geeignete Barrieren angegeben werden (wenn eine Einschränkung für die Reihenfolge des Datenzugriffs zwischen mehreren kachelnden Ressourcen angegeben wird) und die Streamingressourcen miteinander kompatibel sind.

Letzteres wird hier in Bezug darauf beschrieben, was es bedeutet, dass Streamingressourcen, die Kacheln gemeinsam nutzen, inkompatibel sind. Die Inkompatibilitätsbedingungen für den Zugriff auf dieselben Daten in doppelten Kachelzuordnungen sind die Verwendung verschiedener Oberflächendimensionen oder Formate oder Unterschiede beim Vorhandensein von Renderziel- oder Tiefenschablonenbindungsflags für die Ressourcen. Das Schreiben in den Arbeitsspeicher mit einem Zuordnungstyp führt zu undefinierten Ergebnissen, wenn Sie anschließend über eine Zuordnung aus einer inkompatiblen Ressource lesen oder rendern.

Wenn die anderen Ressourcenfreigabezuordnungen zuerst mit neuen Daten initialisiert werden (Wiederverwendung des Speichers für einen anderen Zweck), ist der nachfolgende Lese- oder Rendervorgang in Ordnung, da die Daten nicht über inkompatible Interpretationen hinweg bluten. Wenn Sie jedoch zwischen dem Zugriff auf inkompatible Zuordnungen wie diese wechseln, müssen Sie Barrieren angeben (wenn Sie eine Datenzugriffssortierungseinschränkung zwischen mehreren kachelten Ressourcen angeben).

Wenn das Renderziel- oder Tiefenschablonenbindungsflag für keine der Ressourcen festgelegt ist, die Zuordnungen miteinander teilen, gibt es weitaus weniger Einschränkungen. Solange das Format und die Oberflächentypen (z. B. Texture2D) identisch sind, können Kacheln freigegeben werden. Verschiedene Formate sind kompatibel, z. B. BC*-Oberflächen und die äquivalente größe unkomprimierte 32 Bit oder 16 Bit pro Komponentenformat, z. B. BC6H und R32G32B32A32. Viele 32-Bit-Formate pro Element können auch mit R32_* aliasiert werden (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*, B8G8R8X8_*, R16G16_*); Dieser Vorgang war immer für Nicht-Streaming-Ressourcen zulässig.

Die Gemeinsame Nutzung zwischen gepackten und nicht gepackten Kacheln ist in Ordnung, wenn die Formate kompatibel sind und die Kacheln mit Volltonfarbe gefüllt sind.

Wenn schließlich nichts über die Ressourcen gilt, die Kachelzuordnungen gemeinsam nutzen, außer dass keines über Renderziel- oder Tiefenschablonenbindungsflags verfügt, kann nur mit 0 gefüllter Arbeitsspeicher sicher freigegeben werden. Die Zuordnung wird als eine beliebige 0-Decodierung für die Definition des angegebenen Ressourcenformats angezeigt (in der Regel nur 0).

Verwandte Themen

Pipelinezugriff auf Streamingressourcen