Kachelzugriffseinschränkungen bei doppelten Zuordnungen

In diesem Abschnitt werden Die Zugriffsbeschränkungen für Kacheln mit doppelten Zuordnungen beschrieben.

Kopieren gekachelter Ressourcen mit überlappender Quelle und Ziel

Wenn Kacheln im Quell- und Zielbereich eines Copy*-Vorgangs duplizierte Zuordnungen im Kopierbereich aufweisen, die sich auch dann überlappen würden, wenn beide Ressourcen nicht gekachelte Ressourcen waren und der Copy*-Vorgang überlappende Kopien unterstützt, verhält sich der Kopiervorgang* ordnungsgemäß (als ob die Quelle an einen temporären Speicherort kopiert wird, bevor sie zum Ziel gelangen). Wenn die Überlappung jedoch nicht offensichtlich ist (wie die Quell- und Zielressourcen unterschiedlich sind, aber Freigabezuordnungen oder Zuordnungen über eine bestimmte Oberfläche dupliziert werden), sind die Ergebnisse des Kopiervorgangs auf den freigegebenen Kacheln nicht definiert.

Kopieren in gekachelte Ressource mit duplizierten Kacheln im Zielbereich

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

UAV-Zugriffe auf doppelte Kachelzuordnungen

Angenommen, eine ungeordnete Zugriffssicht (UAV) für eine gekachelte Ressource 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, genauso wie jede Reihenfolge des Speicherzugriffs auf UAVs im Allgemeinen ungeordnet ist.

Rendering nach Kachelzuordnungsänderungen oder Inhaltsupdates von externen Zuordnungen

Wenn sich die Kachelzuordnungen einer gekachelten Ressource geändert haben oder der Inhalt in zugeordneten gekachelten Poolkacheln über die Zuordnungen einer anderen gekachelten Ressource geändert wurde und die gekachelte Ressource über die Renderzielansicht oder die Tiefenschablonenansicht gerendert wird, muss die Anwendung die Kacheln löschen (mit der festen Funktion Clear APIs) löschen oder die Kacheln, die sich innerhalb des gerenderten Bereichs geändert haben, vollständig mit Kopieren*/Aktualisieren*-APIs 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 kann, führt dies dazu, dass Hardwareoptimierungsstrukturen für die angegebene Renderzielansicht oder tiefenschablonenansicht veraltet sind und zu Garbage Rendering-Ergebnissen auf einigen Hardware- und Inkonsistenzen auf verschiedenen Hardwareebenen führen. Diese von der Hardware verwendeten ausgeblendeten Optimierungsdatenstrukturen können für einzelne Zuordnungen lokal und für andere Zuordnungen im selben Arbeitsspeicher nicht sichtbar sein.

Der ID3D11DeviceContext1::ClearView-Vorgang unterstützt das Löschen von Renderzielansichten mit Rechtecke. Für Hardware, die gekachelte Ressourcen unterstützt, muss ClearView auch das Löschen von Tiefenschablonenansichten mit Rechtecke unterstützen, für Nur-Tiefenoberflächen (ohne Schablone). Mit diesem Vorgang können Anwendungen nur den erforderlichen Bereich einer Oberfläche löschen.

Wenn eine Anwendung vorhandene Speicherinhalte von Bereichen in einer gekachelten Ressource beibehalten muss, in denen sich Zuordnungen geändert haben, muss diese Anwendung die klare Anforderung umgehen. Die Anwendung kann diese Vorgehensweise ausführen, indem sie zuerst den Inhalt speichert, an dem sich Kachelzuordnungen geändert haben (indem sie sie z. B. mithilfe von ID3D11DeviceContext2::CopyTiles auf eine temporäre Oberfläche kopiert), 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 möglicherweise beeinträchtigt wird, da Renderingoptimierungen verloren gehen können.

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

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

Angenommen, ein Bereich in einer gekachelten Ressource wird gerendert, und die Kachelpoolkacheln, auf die der Renderbereich verweist, werden auch von außerhalb des Renderbereichs zugeordnet (auch über andere gekachelte Ressourcen gleichzeitig oder nicht). Daten, die in 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 ist auf die Optimierung von Datenstrukturen zurückzuführen, die teilweise hardwarebedingt verwendet werden, die für einzelne Zuordnungen für renderbare Oberflächen lokal sein können und für andere Zuordnungen für denselben Speicherspeicherort 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). Obwohl diese Umarbeitung redundant erscheint, macht es alle anderen Zuordnungen zum gleichen Speicher richtig verständlich, wie auf seine Inhalte zugegriffen werden kann, und zumindest die Speichereinsparungen, die nur eine einzige physische Speichersicherung aufweisen, bleiben intakt. Wenn Sie außerdem zwischen der Verwendung verschiedener gekachelter Ressourcen wechseln, die Zuordnungen gemeinsam nutzen (es sei denn, sie lesen), müssen Sie die ID3D11DeviceContext2::TiledResourceBarrier-API zwischen den Switches aufrufen.

Rendern in Kacheln, die im Renderbereich gemeinsam genutzt werden

Wenn ein Bereich in einer gekachelten Ressource in gerendert wird und innerhalb des Renderbereichs mehrere Kacheln demselben Speicherort des Kachelpools zugeordnet sind, sind die Renderingergebnisse für diese Kacheln nicht definiert.

Datenkompatibilität zwischen kachelnen Ressourcenfreigabekacheln

Angenommen, mehrere gekachelte Ressourcen 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, entsprechende Aufrufe von ID3D11DeviceContext2::TiledResourceBarrier erfolgen und die gekachelten Ressourcen miteinander kompatibel sind. Letzteres wird hier in Bezug darauf beschrieben, was es bedeutet, dass gekachelte Ressourcen, die Kacheln gemeinsam nutzen, inkompatibel sind. Die Inkompatibilitätsbedingungen für den Zugriff auf dieselben Daten in doppelten Kachelzuordnungen sind die Verwendung unterschiedlicher Oberflächendimensionen oder -formate oder Unterschiede beim Vorhandensein von Renderziel- oder Tiefenschablonenbindungsflags für die Ressourcen. Das Schreiben in den Speicher mit einem Zuordnungstyp führt zu nicht definierten 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 Arbeitsspeichers für einen anderen Zweck), ist der nachfolgende Lese- oder Rendervorgang in Ordnung, da die Daten nicht über inkompatible Interpretationen ausbluten. Sie müssen jedoch die TiledResourceBarrier-API aufrufen, wenn Sie zwischen dem Zugriff auf inkompatible Zuordnungen wie dieser wechseln.

Wenn das Renderziel- oder Tiefenschablonenbindungsflag für keine der Ressourcen festgelegt ist, die Zuordnungen miteinander teilen, gibt es weit 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 entsprechenden unkomprimierten 32-Bit- oder 16-Bit-Formate pro Komponentenformat, z. B. BC6H und R32G32B32A32. Viele 32-Bit-Formate pro Element können auch mit R32_* aliast werden (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*, B8G8R8X8_*, R16G16_*); Dieser Vorgang war immer für nicht gekachelte 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.

Schließlich kann nur der mit 0 gefüllte Speicher sicher freigegeben werden, wenn nichts über die ressourcenfreigaben Kachelzuordnungen üblich ist, außer dass keines über Renderziel- oder Tiefenschablonenbindungsflags verfügt. die Zuordnung wird als die 0-Decodierung für die Definition des angegebenen Ressourcenformats angezeigt (in der Regel nur 0).

Zugehörige Themen

Pipelinezugriff auf gekachelte Ressourcen