Zuordnungen in einen Kachelpool

Wenn eine Ressource als Streamingressource erstellt wird, stammen die Kacheln, aus denen die Ressource besteht, von den Positionen in einem Kachelpool. Ein Kachelpool ist ein Speicherpool (der von einer oder mehreren Zuordnungen im Hintergrund unterstützt wird – nicht von der Anwendung gesehen). Das Betriebssystem und der Anzeigetreiber verwalten diesen Speicherpool, und der Speicherbedarf kann von einer Anwendung leicht verstanden werden. Streamingressourcen ordnen Regionen mit 64 KB zu, indem sie auf Standorte in einem Kachelpool verweisen. Ein Fallout dieses Setups besteht darin, dass mehrere Ressourcen dieselben Kacheln gemeinsam nutzen und wiederverwenden können. Außerdem können dieselben Kacheln bei Bedarf an verschiedenen Speicherorten innerhalb einer Ressource wiederverwendet werden.

Die Kosten für die Flexibilität beim Auffüllen der Kacheln für eine Ressource aus einem Kachelpool bestehen darin, dass die Ressource die Zuordnung der Kacheln im Kachelpool definieren und verwalten muss, die für die Ressource benötigt werden. Kachelzuordnungen können geändert werden. Außerdem müssen nicht alle Kacheln in einer Ressource gleichzeitig zugeordnet werden. Eine Ressource kann NULL-Zuordnungen aufweisen. Eine NULL-Zuordnung definiert eine Kachel als nicht verfügbar aus sicht der Ressource, die darauf zugreift.

Es können mehrere Kachelpools erstellt werden, und eine beliebige Anzahl von Streamingressourcen kann einem beliebigen Kachelpool gleichzeitig zugeordnet werden. Kachelpools können auch vergrößert oder verkleinert werden. Weitere Informationen finden Sie unter Ändern der Größe des Kachelpools. Eine Einschränkung, die zur Vereinfachung der Implementierung des Anzeigetreibers und der Laufzeit vorhanden ist, besteht darin, dass eine bestimmte Streamingressource nur Zuordnungen zu höchstens einem Kachelpool gleichzeitig aufweisen kann (im Gegensatz zur gleichzeitigen Zuordnung zu mehreren Kachelpools).

Die Speichermenge, die einer Streamingressource selbst zugeordnet ist (d. h. unabhängiger Kachelpoolspeicher), ist ungefähr proportional zur Anzahl der Kacheln, die dem Pool zu einem bestimmten Zeitpunkt tatsächlich zugeordnet sind. In der Hardware läuft diese Tatsache darauf hinaus, den Speicherbedarf für den Speicher von Seitentabellen ungefähr mit der Menge der Kacheln zu skalieren, die zugeordnet sind (z. B. mithilfe eines Tabellenschemas mit mehreren Ebenen).

Der Kachelpool kann als eine vollständige Softwareabstraktion betrachtet werden, die es Direct3D-Anwendungen ermöglicht, die Seitentabellen auf der Grafikverarbeitungseinheit (GPU) effektiv zu programmieren, ohne die Implementierungsdetails auf niedriger Ebene kennen zu müssen (oder sich direkt mit Zeigeradressen befassen zu müssen). Kachelpools wenden keine zusätzlichen Dereferenzierungsebenen in der Hardware an. Optimierungen einer Seitentabelle mit einer ebener Ebene mit Konstrukten wie Seitenverzeichnissen sind vom Kachelpoolkonzept unabhängig.

Lassen Sie uns untersuchen, welchen Speicher die Seitentabelle selbst im schlimmsten Fall benötigen könnte (obwohl implementierungen in der Praxis nur Speicher benötigen, der ungefähr proportional zu dem zugeordnet ist).

Angenommen, jeder Seitentabelleneintrag ist 64 Bits.

Angenommen, eine Streamingressource wird mit einem 128-Bit-Format pro Element erstellt (z. B. ein RGBA-Float), sodass eine Kachel mit 64 KB nur 4.096 Pixel enthält. Die maximal unterstützte Textur2DArray-Größe von 16384 * 16384 * 2048 (aber nur mit einer einzelnen Mipmap) würde etwa 1 GB Speicher in der Seitentabelle erfordern, wenn sie vollständig aufgefüllt wird (ohne Mipmaps) mit 64-Bit-Tabelleneinträgen. Durch das Hinzufügen von Mipmaps würde der Speicher der vollständig zugeordneten Seitentabellen (worst case) um etwa ein Drittel auf etwa 1,3 GB vergrößert.

Dieser Fall würde Zugriff auf etwa 10,6 TB adressierbaren Arbeitsspeicher gewähren. Es kann jedoch eine Beschränkung für die Menge des adressierbaren Arbeitsspeichers geben, was diese Mengen reduzieren würde, vielleicht auf etwa den Terabyte-Bereich.

Ein weiterer zu berücksichtigende Fall ist eine einzelne Textur2D-Streamingressource von 16384* 16384 mit einem 32-Bit-Format pro Element, einschließlich Mipmaps. Der benötigte Speicherplatz in einer vollständig aufgefüllten Seitentabelle würde bei 64-Bit-Tabelleneinträgen ungefähr 170 KB betragen.

Betrachten Sie schließlich ein Beispiel mit einem BC-Format, z. B. BC7 mit 128 Bits pro Kachel von 4x4 Pixeln. Das ist ein Byte pro Pixel. Ein Texture2DArray von 16384*16384*2048 einschließlich Mipmaps würde etwa 85 MB erfordern, um diesen Speicher in einer Seitentabelle vollständig aufzufüllen. Das ist nicht schlecht, wenn man bedenkt, dass eine Streamingressource 550 Gigapixel (in diesem Fall 512 GB Arbeitsspeicher) umfasst.

In der Praxis würden diese vollständigen Zuordnungen bei weitem nicht definiert, da die menge des verfügbaren physischen Arbeitsspeichers es nicht zulassen würde, dass annähernd so viel gleichzeitig zugeordnet und referenziert werden kann. Bei einem Kachelpool können Anwendungen Kacheln jedoch wiederverwenden (als einfaches Beispiel, indem sie eine "schwarze" farbige Kachel für große schwarze Bereiche in einem Bild wiederverwenden) – effektiv den Kachelpool (d. h. Seitentabellenzuordnungen) als Tool für die Speicherkomprimierung verwenden.

Der anfängliche Inhalt der Seitentabelle ist für alle Einträge NULL . Anwendungen können auch keine anfänglichen Daten für den Speicherinhalt der Oberfläche übergeben, da sie ohne Speichersicherung gestartet wird.

In diesem Abschnitt

Thema	BESCHREIBUNG
Erstellung eines Kachelpools	Anwendungen können einen oder mehrere Kachelpools pro Direct3D-Gerät erstellen. Die Gesamtgröße jedes Kachelpools ist auf die Ressourcengrößenbeschränkung von Direct3D 11 beschränkt, die ungefähr 1/4 des GPU-RAM beträgt.
Ändern der Größe des Kachelpools	Ändern Sie die Größe eines Kachelpools, um einen Kachelpool zu vergrößern, wenn die Anwendung mehr Arbeitssätze für die Zuordnung von Streamingressourcen benötigt, oder verkleinern, wenn weniger Speicherplatz benötigt wird.
Gefahrennachverfolgung im Vergleich mit den Kachelpoolressourcen	Für Ressourcen ohne Streaming kann Direct3D bestimmte Gefahrenbedingungen während des Renderns verhindern, aber da die Gefahrennachverfolgung für Streamingressourcen auf einer Kachelebene liegt, kann die Nachverfolgung von Gefahrenbedingungen beim Rendern von Streamingressourcen zu teuer sein.

 

Verwandte Themen

Erstellen von Streamingressourcen