Share via

APIs für kachelnierte Ressourcen

  • Artikel

Die in diesem Abschnitt beschriebenen APIs funktionieren mit kachelten Ressourcen und Kachelpools.

Zuweisen von Kacheln aus einem Kachelpool zu einer Ressource

Die APIs ID3D11DeviceContext2::UpdateTileMappings und ID3D11DeviceContext2::CopyTileMappings bearbeiten und abfragen Kachelzuordnungen. Aktualisierungsaufrufe wirken sich nur auf die im Aufruf identifizierten Kacheln aus, und andere werden wie zuvor definiert belassen.

Jede bestimmte Kachel aus einem Kachelpool kann mehreren Speicherorten in einer Ressource und sogar mehreren Ressourcen zugeordnet werden. Diese Zuordnung umfasst Kacheln in einer Ressource, die über ein von der Implementierung ausgewähltes Layout (Mipmap-Paketerstellung) verfügen, in dem mehrere Mipmaps in einer einzelnen Kachel zusammengefasst werden. Wenn Daten über eine Zuordnung in die Kachel geschrieben, aber über eine anders konfigurierte Zuordnung gelesen werden, sind die Ergebnisse nicht definiert. Die sorgfältige Verwendung dieser Flexibilität kann jedoch für eine Anwendung nützlich sein, z. B. die Gemeinsame Nutzung einer Kachel zwischen Ressourcen, die nicht gleichzeitig verwendet werden, wobei der Inhalt der Kachel immer über die gleiche Ressourcenzuordnung initialisiert wird, aus der sie später gelesen werden. Ebenso funktioniert eine Kachel, die die gepackten Mipmaps mehrerer verschiedener Ressourcen mit denselben Oberflächenabmessungen enthält, einwandfrei. Die Daten werden in beiden Zuordnungen gleich angezeigt.

Änderungen an Kachelzuweisungen für eine Ressource können jederzeit in einem unmittelbaren oder verzögerten Kontext vorgenommen werden.

Abfragen der Ressourcenkachelung und -unterstützung

Verwenden Sie ID3D11Device2::GetResourceTiling, um die Ressourcenkachelung abzufragen.

Verwenden Sie ID3D11Device2::CheckMultisampleQualityLevels1, um andere Ressourcenkacheln zu unterstützen.

Kopieren von kachelten Daten

Alle Methoden in Direct3D zum Verschieben von Daten arbeiten mit kachelten Ressourcen so, als ob sie nicht gekachelt sind, mit der Ausnahme, dass Schreibvorgänge in nicht zugeordnete Bereiche gelöscht und Lesevorgänge aus nicht zugeordneten Bereichen 0 erzeugen. Wenn bei einem Kopiervorgang mehrmals in denselben Speicherspeicherort geschrieben wird, da mehrere Speicherorte in der Zielressource demselben Kachelspeicher zugeordnet sind, sind die resultierenden Schreibvorgänge auf mehrfach zugeordnete Kacheln nicht deterministisch und nicht wiederholbar. Das heißt, Zugriffe erfolgen in jeder Reihenfolge, in der die Hardware zum Ausführen der Kopie erfolgt.

Direct3D 11.2 führt Methoden für diese zusätzlichen Kopiermethoden ein:

  • Kopieren zwischen Kacheln in einer kachelfähigen Ressource (bei einer Kachelgranularität von 64 KB) und (zu/von) einem Puffer im GPU-Speicher (oder Stagingressource) – ID3D11DeviceContext2::CopyTiles
  • Kopieren aus dem von der Anwendung bereitgestellten Speicher auf Kacheln in einer gekachelten Ressource – ID3D11DeviceContext2::UpdateTiles

Diese Methoden swizzle/deswizzle nach Bedarf und lassen ein D3D11_TILE_COPY_NO_OVERWRITE-Flag zu, wenn der Aufrufer verspricht, dass auf den Zielspeicher nicht durch GPU-Arbeit verwiesen wird, die sich im Flug befindet.

Die an der Kopie beteiligten Kacheln dürfen keine Kacheln enthalten, die gepackte Mipmaps enthalten oder nicht definierte Ergebnisse aufweisen. Zum Übertragen von Daten zu/aus Mipmaps, die die Hardware in eine Kachel packt, müssen Sie die Standardmäßigen (nicht kachelspezifischen) Copy/Update-APIs oder ID3D11DeviceContext::GenerateMips für die gesamte mip-Kette verwenden.

Hinweis zu GenerateMips: Die Verwendung von ID3D11DeviceContext::GenerateMips für eine Ressource mit teilweise zugeordneten Kacheln führt zu Ergebnissen, die einfach den Regeln zum Lesen und Schreiben von NULL folgen, die auf den Algorithmus angewendet werden, den der Hardware- und Anzeigetreiber für GenerateMips verwendet. Daher ist es für eine Anwendung nicht besonders nützlich, dies zu tun, es sei denn, die Bereiche mit NULL-Zuordnungen (und deren Auswirkungen auf andere Mips während der Generierungsphase) haben keine Auswirkungen auf die Teile der Oberfläche, die der Anwendung wichtig ist.

Das Kopieren von Kacheldaten von einer Stagingoberfläche oder aus dem Anwendungsspeicher wäre die Möglichkeit, Kacheln hochzuladen, die z. B. von einem Datenträger gestreamt wurden. Eine Variante, wenn das Streaming von einem Datenträger eine Art komprimierter Daten in den GPU-Speicher hochlädt und dann auf der GPU decodiert. Das Decodierungsziel kann eine Pufferressource im GPU-Speicher sein, aus der CopyTiles dann in die eigentliche kachelte Ressource kopiert. Dieser Kopierschritt ermöglicht es der GPU, zu schwenken, wenn das Swizzle-Muster nicht bekannt ist. Swizzling ist nicht erforderlich, wenn die kachelte Ressource selbst eine Pufferressource ist (z. B. im Gegensatz zu einer Textur).

Das Speicherlayout der Kacheln auf der Seite der nicht gekachelten Pufferressource der Kopie ist einfach linear im Arbeitsspeicher innerhalb von 64-KB-Kacheln, die die Hardware und der Anzeigetreiber bei der Übertragung zu/aus einer gekachelten Ressource nach Bedarf pro Kachel schwizzle/deswizzle würden. Bei MSAA-Oberflächen (Multisample Antialiasing) werden die Stichproben jedes Pixels in der Reihenfolge des Stichprobenindex durchlaufen, bevor sie zum nächsten Pixel wechseln. Für Kacheln, die teilweise auf der rechten Seite gefüllt sind (für eine Fläche, die nicht ein Vielfaches der Kachelbreite in Pixeln hat), entspricht die Tonhöhe/Schrittfolge, um eine Zeile nach unten zu bewegen, die volle Größe in Byte der Anzahl der Pixel, die auf die Kachel passen würden, wenn die Kachel voll wäre. Es kann also eine Lücke zwischen jeder Zeile von Pixeln im Arbeitsspeicher geben. Der Einfachheit halber werden Mipmaps, die kleiner als eine Kachel sind, nicht im linearen Layout gepackt. Dies scheint eine Verschwendung von Speicherplatz zu sein, aber wie bereits erwähnt kopieren in mips, dass die Hardwarepakete zusammen nicht über CopyTiles oder UpdateTiles erlaubt ist. Die Anwendung kann nur generische UpdateSubresource*()- oder CopySubresource*()-APIs verwenden, um kleine Mips einzeln zu kopieren, aber im Fall von CopySubresource*() bedeutet dies, dass der lineare Arbeitsspeicher dieselbe Dimension wie die kachelte Ressource haben muss. CopySubresource*() kann für instance nicht aus einer Pufferressource in eine Textur2D kopieren.

Wenn ein Hardwarestandard-Swizzle definiert ist, können Flags hinzugefügt werden, um anzugeben, dass die Daten im Puffer in diesem Format interpretiert werden sollen (bei der Übertragung ist kein Swizzle erforderlich), obwohl in diesem Fall auch alternative Ansätze zum Hochladen von Daten sinnvoll sein können, z. B. das Zulassen des direkten Zugriffs von Anwendungen auf den Speicher des Kachelpools.

Kopiervorgänge können in einem unmittelbaren oder verzögerten Kontext ausgeführt werden.

Ändern der Größe des Kachelpools

Verwenden Sie ID3D11DeviceContext2::ResizeTilePool, um die Größe eines Kachelpools zu ändern.

Gekachelte Ressourcenbarriere

Verwenden Sie ID3D11DeviceContext2::TiledResourceBarrier, um eine Einschränkung für die Datenzugriffsreihenfolge zwischen mehreren verknüpften Ressourcen anzugeben.

Kacheln von Ressourcen