Freigeben über

Nebeneinander angeordnete Ressourcen-APIs

Die in diesem Abschnitt beschriebenen APIs arbeiten mit nebeneinander angeordneten Ressourcen und Kachelpools.

Zuweisen von Kacheln aus einem Kachelpool zu einer Ressource

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

Jede gegebene 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 implementierungsauswahles Layout verfügen (Mipmap-Verpackung), wobei mehrere Mipmaps in einer einzelnen Kachel zusammengefasst werden. Der Catch ist, dass, wenn Daten über eine Zuordnung in die Kachel geschrieben werden, aber über eine anders konfigurierte Zuordnung gelesen werden, die Ergebnisse nicht definiert sind. Die sorgfältige Verwendung dieser Flexibilität kann jedoch für eine Anwendung weiterhin nützlich sein, z. B. das Freigeben einer Kachel zwischen Ressourcen, die nicht gleichzeitig verwendet werden, wobei der Inhalt der Kachel immer über dieselbe Ressourcenzuordnung initialisiert wird, wie sie anschließend gelesen werden. Ebenso funktioniert eine Kachel, die den verpackten Mipmaps mehrerer verschiedener Ressourcen mit den gleichen Oberflächendimensionen zugeordnet ist, einwandfrei – die Daten werden in beiden Zuordnungen identisch angezeigt.

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

Abfragen von Ressourcenkacheln und -unterstützung

Verwenden Sie zum Abfragen der Ressourcenkachelung ID3D11Device2::GetResourceTiling.

Verwenden Sie für andere Ressourcenkachelunterstützung ID3D11Device2::CheckMultisampleQualityLevels1.

Kopieren von nebeneinander angeordneten Daten

Alle Methoden in Direct3D zum Verschieben von Daten arbeiten mit nebeneinander angeordneten Ressourcen genauso, als ob sie nicht nebeneinander angeordnet sind, außer dass Schreibvorgänge in nicht zugeordnete Bereiche verworfen und aus nicht zugeordneten Bereichen gelesen werden, erzeugen 0. Wenn ein Kopiervorgang mehrere Male in denselben Speicherspeicherort schreibt, da mehrere Speicherorte in der Zielressource demselben Kachelspeicher zugeordnet sind, sind die resultierenden Schreibvorgänge in multi-zugeordnete Kacheln nicht deterministisch und nicht wiederholbar. Das heißt, der Zugriff erfolgt in jeder Reihenfolge, in der die Hardware die Kopie ausführt.

Direct3D 11.2 führt Methoden für diese zusätzlichen Möglichkeiten zum Kopieren ein:

  • Kopieren zwischen Kacheln in einer nebeneinander angeordneten Ressource (bei einer Granularität der Kachel mit 64 KB) und (zu/von) einem Puffer im GPU-Speicher (oder staging-Ressource) – ID3D11DeviceContext2::CopyTiles
  • Kopieren sie aus dem von der Anwendung bereitgestellten Speicher in Kacheln in einer nebeneinander angeordneten Ressource – ID3D11DeviceContext2::UpdateTiles

Diese Methoden swizzle/deswizzle nach Bedarf, und lassen Sie ein D3D11_TILE_COPY_NO_OVERWRITE Flag zu, wenn der Aufrufer verspricht, dass der Zielspeicher nicht von GPU-Arbeit referenziert wird, die sich im Test-Flight befindet.

Die kacheln, die an der Kopie beteiligt sind, können keine Kacheln enthalten, die verpackte Mipmaps enthalten oder ergebnisse aufweisen, die nicht definiert sind. Um Daten an/von Mipmaps zu übertragen, die die Hardwarepakete in eine Kachel packen, müssen Sie die Standard-APIs (nicht kachelspezifische) Kopieren/Aktualisieren-APIs oder ID3D11DeviceContext::GenerateMips für die gesamte Mip-Kette verwenden.

Hinweis zu GenerateMips: Using ID3D11DeviceContext::GenerateMips on a resource with partially mapped tiles will results that simply follow the rules for reading and writing NULL applied to whatever algorithm the hardware and display driver happen to GenerateMips. Daher ist es für eine Anwendung nicht besonders nützlich, dies zu tun, es sei denn, die Bereiche mit NULL- Zuordnungen (und ihre Auswirkungen auf andere Mips während der Erzeugungsphase) haben keine Auswirkungen auf die Teile der Oberfläche, die die Anwendung kümmert.

Das Kopieren von Kacheldaten aus einer Stagingoberfläche oder aus dem Anwendungsspeicher wäre beispielsweise die Möglichkeit, Kacheln hochzuladen, die möglicherweise vom Datenträger gestreamt wurden. Eine Variation beim Streamen von Datenträgern lädt eine Art komprimierter Daten in den GPU-Speicher hoch und decodiert dann auf der GPU. Das Decodierungsziel könnte eine Pufferressource im GPU-Speicher sein, aus der CopyTiles dann in die tatsächliche nebeneinander angeordnete Ressource kopiert wird. Dieser Kopierschritt ermöglicht es der GPU, zu schwenken, wenn das Schwarmmuster nicht bekannt ist. Swizzling ist nicht erforderlich, wenn die nebeneinander angeordnete Ressource selbst eine Pufferressource ist (z. B. im Gegensatz zu einer Textur).

Das Speicherlayout der Kacheln auf der nicht nebeneinander angeordneten Pufferressourcenseite der Kopie ist einfach linear im Arbeitsspeicher innerhalb von 64 KB-Kacheln, die der Hardware- und Anzeigetreiber bei der Übertragung zu/aus einer nebeneinander angeordneten Ressource je Kachel je Kachel swizzle/deswizzle würde. Bei MsAA-Oberflächen (Multisample Antialiasing) werden die Beispiele der einzelnen Pixel in der Beispielindexreihenfolge durchlaufen, bevor sie zum nächsten Pixel wechseln. Bei Kacheln, die teilweise auf der rechten Seite gefüllt sind (für eine Oberfläche mit einer Breite, die kein Vielfaches von Kachelbreiten in Pixeln aufweist), ist die Neigung/Stride, um eine Zeile nach unten zu verschieben, die in Byte der Anzahl Pixel, die über die Kachel passen würden, wenn die Kachel voll war. Es kann also eine Lücke zwischen jeder Pixelzeile im Arbeitsspeicher geben. Zur Vereinfachung der Spezifikation werden Mipmaps, die kleiner als eine Kachel sind, nicht im linearen Layout zusammengepackt. Dies scheint eine Verschwendung von Speicherplatz zu sein, aber wie erwähnt, kopieren Sie in Mips, dass die Hardwarepakete zusammen nicht über CopyTiles oder UpdateTiles. Die Anwendung kann einfach generische UpdateSubresource*() oder CopySubresource*()-APIs verwenden, um kleine Mips einzeln zu kopieren, wenn copySubresource*() dies bedeutet, dass der lineare Speicher dieselbe Dimension wie die nebeneinander angeordnete Ressource sein muss – CopySubresource*() kann nicht aus einer Pufferressource in eine Texture2D kopiert werden.

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 (keine Swizzle erforderlich bei der Übertragung), obwohl alternative Ansätze zum Hochladen von Daten in diesem Fall auch sinnvoll sein können, z. B. das Zulassen des direkten Zugriffs auf den Kachelpoolspeicher für Anwendungen.

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

Ändern der Größe des Kachelpools

Verwenden Sie zum Ändern der Größe eines Kachelpools ID3D11DeviceContext2::ResizeTilePool.

Unterteilte Ressourcenbarriere

Verwenden Sie ID3D11DeviceContext2::TiledResourceBarrier, um eine Einschränkung für die Datenzugriffsbestellung zwischen mehreren nebeneinander angeordneten Ressourcen anzugeben.

nebeneinander angeordnete Ressourcen

 

 

  • Last updated on