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 von Kacheln, die innerhalb des Renderbereichs freigegeben wurden.

Kopieren von Streamingressourcen mit überlappender Quelle und Ziel

Wenn Kacheln im Quell- und Zielbereich eines Copy*-Vorgangs duplizierte Zuordnungen im Kopierbereich haben, die sich überlappen würden, auch wenn beide Ressourcen keine Streamingressourcen waren und der Copy*-Vorgang überlappende Kopien unterstützt, verhält sich der Copy*-Vorgang einwandfrei (als ob die Quelle an einen temporären Speicherort kopiert wird, bevor Sie zum Ziel wechseln). Wenn die Überlappung jedoch nicht offensichtlich ist (z. B. die Quell- und Zielressourcen unterscheiden sich, aber Zuordnungen oder Zuordnungen über eine bestimmte Oberfläche dupliziert werden), werden die Ergebnisse des Kopiervorgangs auf den freigegebenen Kacheln nicht definiert.

Kopieren in Streamingressource mit duplizierten Kacheln im Zielbereich

Das Kopieren in eine Streamingressource mit duplizierten Kacheln im Zielbereich führt zu nicht definierten Ergebnissen in diesen Kacheln, es sei denn, die Daten selbst sind identisch. unterschiedliche Kacheln können die Kacheln in unterschiedlichen Reihenfolgen schreiben.

UAV greift auf doppelte Kachelzuordnungen zu

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

Rendern nach Änderungen der Kachelzuordnung oder Inhaltsaktualisierungen von externen Zuordnungen

Wenn sich die Kachelzuordnungen einer Streamingressource geändert haben oder Inhalte in zugeordneten Kacheln in nebeneinander angeordneten Poolkacheln über die Zuordnungen einer anderen Streamingressource geändert wurden und die Streamingressource über die Renderzielansicht oder tiefenschablonenansicht gerendert werden soll, muss die Anwendung löschen (mit der festen Funktion Clear APIs) oder vollständig mit Copy*/Update*-APIs die Kacheln kopieren, die sich innerhalb des gerenderten Bereichs geändert haben (zugeordnet oder nicht).

Wenn eine Anwendung in diesen Fällen nicht gelöscht oder kopiert werden soll, führt dies zu Hardwareoptimierungsstrukturen für die angegebene Renderzielansicht oder tiefen Schablonenansicht, die veraltet ist, und führt zu Garbage Rendering-Ergebnissen für einige Hardware und Inkonsistenzen auf unterschiedlicher Hardware. Diese ausgeblendeten Optimierungsdatenstrukturen, die von der Hardware verwendet werden, sind möglicherweise lokal für einzelne Zuordnungen und nicht für andere Zuordnungen im selben Speicher sichtbar.

Wenn Sie eine Ressourcenansicht löschen (wenn Sie alle Elemente in einer Ressourcenansicht auf einen Wert festlegen), können Sie Renderzielansichten mit Rechtecke löschen. Für Hardware, die Streamingressourcen unterstützt, muss das Löschen einer Ressourcenansicht auch das Löschen von Tiefenschablonenansichten mit Rechtecke unterstützen, für Tiefenoberflächen (ohne Schablone). Mit diesem Vorgang können Anwendungen nur die erforderliche Fläche einer Oberfläche löschen.

Wenn eine Anwendung vorhandene Speicherinhalte von Bereichen in einer Streamingressource beibehalten muss, bei denen sich Zuordnungen geändert haben, muss diese Anwendung die klare Anforderung umgehen. Die Anwendung kann dieses Problem umgehen, indem sie zuerst den Inhalt speichern, in dem sich Kachelzuordnungen geändert haben (durch Kopieren auf eine temporäre Oberfläche), das Ausstellen des erforderlichen clear-Befehls und anschließendes Erneutes Kopieren des Inhalts. Dies würde zwar die Aufgabe erfüllen, Oberflächeninhalte für das inkrementelle Rendering beizubehalten, doch liegt der Nachteil darin, dass nachfolgende Renderingleistung auf der Oberfläche möglicherweise beeinträchtigt wird, da Renderingoptimierungen möglicherweise verloren gegangen sind.

Wenn eine Kachel gleichzeitig mehreren Streamingressourcen zugeordnet ist und Kachelinhalte auf irgendeine Weise (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 freigegeben wurden

Angenommen, ein Bereich in einer Streamingressource wird gerendert, und die Kachelpoolkacheln, auf die vom Renderbereich verwiesen wird, werden ebenfalls von außerhalb des Renderbereichs zugeordnet (einschließlich über andere Streamingressourcen gleichzeitig oder nicht). Daten, die auf diesen Kacheln gerendert werden, werden nicht garantiert ordnungsgemäß angezeigt, wenn sie über die anderen Zuordnungen angezeigt werden, auch wenn das zugrunde liegende Speicherlayout kompatibel ist. Diese Tatsache liegt daran, dass Optimierungsdatenstrukturen einige Hardwarenutzungen verwenden, die lokal für einzelne Zuordnungen für renderbare Oberflächen sein können und für andere Zuordnungen am gleichen Speicherort nicht sichtbar sind.

Sie können diese Einschränkung umgehen, indem Sie aus der gerenderten Zuordnung zu allen 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). Obwohl diese Umgehung redundant erscheint, werden alle anderen Zuordnungen mit demselben Speicher richtig verstanden, wie auf ihre Inhalte zugegriffen werden kann, und zumindest die Speichereinsparungen bei der Sicherung eines einzigen physischen Speichers bleiben intakt.

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

Rendern in Im Renderbereich freigegebenen Kacheln

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

Datenkompatibilität über Streamingressourcen hinweg, die Kacheln freigeben

Angenommen, mehrere Streamingressourcen weisen Zuordnungen zu den gleichen Kachelpoolspeicherorten auf, und jede Ressource wird verwendet, um auf dieselben Daten zuzugreifen. Dieses Szenario ist nur gültig, wenn die anderen Regeln zum Vermeiden von Problemen mit Hardwareoptimierungsstrukturen vermieden werden, entsprechende Barrieren angegeben werden (angeben einer Einschränkung der Datenzugriffsbestellung zwischen mehreren nebeneinander angeordneten Ressourcen), und die Streamingressourcen sind miteinander kompatibel.

Letzteres wird hier in Bezug auf das, was es bedeutet, dass Streamingressourcen Kacheln teilen, nicht kompatibel sind. Die Inkompatibilitätsbedingungen für den Zugriff auf dieselben Daten über doppelte Kachelzuordnungen hinweg sind die Verwendung verschiedener Oberflächenabmessungen oder -formate oder Unterschiede beim Vorhandensein von Renderziel- oder Tiefenschablonenbindungskennzeichnungen für die Ressourcen. Das Schreiben in den Speicher mit einem Zuordnungstyp erzeugt nicht definierte Ergebnisse, wenn Sie anschließend eine Zuordnung aus einer inkompatiblen Ressource lesen oder rendern.

Wenn die anderen Ressourcenfreigabezuordnungen zuerst mit neuen Daten initialisiert werden (den Speicher für einen anderen Zweck wiederverwerten), ist der nachfolgende Lese- oder Rendervorgang in Ordnung, da Daten nicht inkompatible Interpretationen ausbluten. Wenn Sie jedoch zwischen dem Zugriff auf inkompatible Zuordnungen wie diesem wechseln, müssen Sie Barrieren angeben (angeben einer Einschränkung für die Datenzugriffsreihenfolge zwischen mehreren nebeneinander angeordneten Ressourcen).

Wenn das Bindungsflaggen für das Renderziel oder die Tiefenschablonenbindung für alle Ressourcen, die Zuordnungen miteinander teilen, nicht festgelegt ist, gibt es wesentlich weniger Einschränkungen. Solange das Format und die Oberflächentypen (z. B. Texture2D) identisch sind, können Kacheln freigegeben werden. Unterschiedliche Kompatible Formate sind Fälle wie BC*-Oberflächen und die entsprechende größe unkomprimierte 32-Bit- oder 16-Bit pro Komponentenformat wie BC6H und R32G32B32A32. Viele 32-Bit-Formate pro Element können auch mit R32_* aliast werden (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*,B8G8R8X8_*,R16G16_*); Dieser Vorgang ist für Nicht-Streamingressourcen immer zulässig.

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

Wenn nichts über die Ressourcenfreigabe-Kachelzuordnungen verbreitet ist, außer dass keine Renderziel- oder Tiefenschablonenbindungskennzeichnungen aufweisen, können nur Speicher, der mit 0 gefüllt ist, sicher freigegeben werden; die Zuordnung wird als beliebiges Decodierungszeichen für die Definition des angegebenen Ressourcenformats (in der Regel nur 0) angezeigt.

Verwandte Themen

Pipelinezugriff auf Streamingressourcen