Zuordnung für verzögerte Kontexte
Dieser Abschnitt gilt nur für Windows 7 und höher sowie Windows Server 2008 R2 und höhere Versionen des Windows-Betriebssystems.
Die Laufzeit kann eine dynamische Ressource (über einen Aufruf der ResourceMap-Funktion des Treibers) in einem verzögerten Kontext zuordnen, da die Direct3D-API version 11 sicherstellt, dass die erste Verwendung der zugeordneten dynamischen Ressource darin besteht, den vorherigen Inhalt zu verwerfen. Die beste Option besteht darin, bei jedem Verwerfen eine neue dynamische Ressource mit der ursprünglichen dynamischen Ressource zu erstellen. Die Erstellung dieser Aliasressource ist erforderlich, damit Vorgänge, die für die virtuelle dynamische Ressource im Zeitleiste des verzögerten Kontexts ausgeführt werden, nicht die Vorgänge beeinflussen, die für die virtuelle dynamische Ressource im Zeitleiste des unmittelbaren Kontexts ausgeführt werden. Denken Sie daran, dass verzögerte Kontexte lediglich Aufzeichnungsvorgänge sind, die schließlich während eines Aufrufs der CommandListExecute-Funktion des Treibers ausgeführt werden. Wenn eine dynamische Ressource verwendet wird, bleiben die ursprünglichen Absichten der Anwendung erhalten, und der Anwendung wird kombinierter GPU-zugänglicher Arbeitsspeicher bereitgestellt (d. a. der Arbeitsspeicher ist für den CPU-Upload mit einmaliger Verwendung optimiert).
Jede Ressourcenzuordnung kann die Zeiger direkt auf die aliasierte Ressource bereitstellen. Die verzögerte Kontextaufzeichnung zur Implementierung dieser Art von Aliasing wird zusätzlich belastet. Beispielsweise kann es für die verzögerte Kontextaufzeichnung erforderlich sein, dass neue Ansichten für Aliastexturen erstellt werden. Integrationen mit Treiberaliasing sind erforderlich und scheinen plausibel zu sein. Wenn eine Befehlsliste ausgeführt wird, muss die letzte vom Lokalen Kontext erstellte Ressource (um die Aufrufe des Zuordnungsverwerfens zu erfüllen) als die "aktuelle" Ressource ersetzt werden, die die dynamische Ressource für den unmittelbaren Kontext unterstützt usw.
Ein Aufruf der ResourceCopy-Funktion des Treibers zum Kopieren einer Ressource in eine dynamische Ressource muss weiterhin sowohl für den verzögerten Kontext, nach Aufrufen des Zuordnungsverwerfens als auch für den unmittelbaren Kontext nach einem Aufruf der CommandListExecute-Funktion des Treibers unterstützt werden, wobei die lokale verzögerte Kontextressource idealerweise in die unmittelbare Kontextversion der "aktuellen" Ressource getauscht wird. Ein Aufruf der ResourceCopy-Funktion des Treibers mit dynamischen Ressourcenzielen wird nicht häufig verwendet, daher sollten Sie einen Kopiermechanismus beim Schreiben verwenden. Wenn ResourceCopy aufgerufen wird, der sich entweder auf die dynamische Ressource im verzögerten Kontext nach einem Aufruf des Zuordnungsverwerfens oder auf den unmittelbaren Kontext auswirkt, der eine lokale Befehlsliste-Ressource als aktuell enthält, sollte eine neue Ressource konzeptionell zugeordnet werden, um das neue Ziel der Kopie bereitzustellen, und die alte Ressource muss in die neue Ressource kopiert werden (wenn der Vorgang eine ResourceCopyRegion ist).