Gefahrennachverfolgung im Vergleich mit den Kachelpoolressourcen
Bei Nicht-Streamingressourcen kann Direct3D bestimmte Gefahrenbedingungen während des Renderings verhindern, da die Gefahrennachverfolgung jedoch auf Kachelebene für Streamingressourcen liegt, kann die Verfolgung von Gefahrenbedingungen beim Rendern von Streamingressourcen zu teuer sein.
Bei Nicht-Streamingressourcen lässt die Laufzeit beispielsweise nicht zu, dass subResource als Eingabe (z. B. eine Shaderressourcenansicht) und als Ausgabe (z. B. eine Renderzielansicht) gebunden wird, wenn ein solcher Fall auftritt, die Laufzeit die Eingabe aufgehoben. Dieser Nachverfolgungsaufwand in der Laufzeit ist billig und erfolgt auf Der Unterressource-Ebene. Einer der Vorteile dieses Nachverfolgungsaufwands besteht darin, die Wahrscheinlichkeit von Anwendungen je nach Ausführungsreihenfolge des Hardware-Shaders versehentlich zu minimieren. Die Ausführungsreihenfolge des Hardware-Shaders kann variieren, wenn nicht auf einer bestimmten Grafikverarbeitungseinheit (GPU), dann sicherlich über verschiedene GPUs hinweg.
Das Nachverfolgen, wie Ressourcen gebunden sind, kann für Streamingressourcen zu teuer sein, da die Nachverfolgung auf Kachelebene erfolgt. Es treten neue Probleme auf, z. B. die Überprüfung von Abwesendversuchen zum Rendern in einer Renderzielansicht mit einer Kachel, die mehreren Bereichen auf der Oberfläche gleichzeitig zugeordnet ist. Wenn sich herausstellt, dass diese Gefahrenverfolgung pro Kachel für die Laufzeit zu teuer ist, wäre dies im Idealfall zumindest eine Option in der Debugebene.
Eine Anwendung muss den Anzeigetreiber informieren, wenn er einen Schreib- oder Lesevorgang für eine Streamingressource ausgegeben hat, die auf den Kachelpoolspeicher verweist, auf den auch durch separate Streamingressourcen in anstehenden Lese- oder Schreibvorgängen verwiesen wird, dass er erwartet, dass der erste Vorgang abgeschlossen wird, bevor die folgenden Vorgänge beginnen können.
Verwandte Themen
Zuordnungen befinden sich in einem Kachelpool