Zuordnungen in einen Kachelpool
Wenn eine Ressource als Streamingressource erstellt wird, stammen die Kacheln, aus denen die Ressource besteht, von Standorten in einem Kachelpool. Ein Kachelpool ist ein Speicherpool (unterstützt durch eine oder mehrere Zuordnungen hinter den Kulissen – nicht durch die Anwendung). Das Betriebssystem und der Anzeigetreiber verwalten diesen Speicherpool, und der Speicherbedarf wird von einer Anwendung leicht verstanden. Streamingressourcen ordnen 64 KB Regionen zu, indem sie auf Speicherorte in einem Kachelpool verweisen. Ein Fallout dieser Einrichtung ist es, dass mehrere Ressourcen dieselben Kacheln gemeinsam nutzen und wiederverwenden können, und auch für die gleichen Kacheln, die bei Bedarf an unterschiedlichen 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 besteht darin, dass die Ressource die Arbeit zum Definieren und Verwalten der Zuordnung der Kacheln im Kachelpool für die für die Ressource benötigten Kacheln ausführen muss. 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, auf die sie zugreift.
Mehrere Kachelpools können erstellt werden, und eine beliebige Anzahl von Streamingressourcen kann gleichzeitig einem beliebigen Kachelpool zugeordnet werden. Kachelpools können auch vergrößert oder verkrumpft werden. Weitere Informationen finden Sie unter Größenänderung des Kachelpools. Eine Einschränkung, die zur Vereinfachung der Implementierung des Anzeigetreibers und der Laufzeit vorhanden ist, besteht darin, dass eine bestimmte Streamingressource jeweils nur Zuordnungen zu höchstens einem Kachelpool haben kann (im Gegensatz zur gleichzeitigen Zuordnung zu mehreren Kachelpools).
Die Menge des Speichers, der einer Streamingressource selbst zugeordnet ist (d. h. unabhängiger Kachelpoolspeicher), ist ungefähr proportional zur Anzahl der Kacheln, die tatsächlich dem Pool zu einem bestimmten Zeitpunkt zugeordnet sind. In der Hardware wird dadurch der Speicherbedarf für seitentabellenspeicher ungefähr mit der Größe der zugeordneten Kacheln skaliert (z. B. bei Verwendung eines Mehrebenentabellenschemas).
Der Kachelpool kann sich als vollständig Softwarestraktion angesehen werden, mit der Direct3D-Anwendungen effektiv die Seitentabellen auf der Grafikverarbeitungseinheit (GPU) programmieren können, ohne die Details der Implementierung auf niedriger Ebene kennen zu müssen (oder direkt mit Zeigeradressen zu umgehen). Kachelpools wenden keine zusätzlichen Dereferenzierungsebenen in der Hardware an. Optimierungen einer Einzelnen Seitentabelle mithilfe von Konstrukten wie Seitenverzeichnissen sind unabhängig vom Kachelpoolkonzept.
Lassen Sie uns untersuchen, welche Speicherung die Seitentabelle selbst im schlimmsten Fall erfordern könnte (in der Praxis erfordern Implementierungen jedoch nur einen ungefähr proportionalen Speicher, was zugeordnet ist).
Angenommen, jeder Seitentabelleneintrag ist 64 Bit.
Für die Groß-/Kleinschreibung der Seitentabellengröße für eine einzelne Oberfläche, angesichts der Ressourcenbeschränkungen in Direct3D 11, angenommen, eine Streamingressource wird mit einem 128-Bit-pro-Element-Format (z. B. einem RGBA-Float) erstellt, sodass eine Kachel mit 64 KB nur 4096 Pixel enthält. Die maximal unterstützte Texture2DArray-Größe von 16384*16384*2048 (aber nur mit einem einzigen Mipmap) erfordert etwa 1 GB Speicher in der Seitentabelle, wenn vollständig ausgefüllt (nicht einschließlich Mipmaps) mit 64-Bit-Tabelleneinträgen. Das Hinzufügen von Mipmaps würde den vollständig zugeordneten (worst case) Seitentabellenspeicher um etwa ein Drittel auf etwa 1,3 GB vergrößern.
Dieser Fall würde Zugriff auf ca. 10,6 Terabyte adressierbaren Arbeitsspeicher gewähren. Es kann jedoch ein Grenzwert für die Menge des adressierbaren Speichers geben, was diese Mengen verringern würde, vielleicht auf den Bereich von Terabyte.
Ein weiterer zu berücksichtigende Fall ist eine einzelne Texture2D-Streamingressource von 16384*16384 mit einem 32-Bit-pro-Element-Format, einschließlich Mipmaps. Der in einer vollständig ausgefüllten Seitentabelle benötigte Speicherplatz beträgt ungefähr 170 KB mit 64 Bit-Tabelleneinträgen.
Betrachten Sie schließlich ein Beispiel für die Verwendung eines BC-Formats, z. B. BC7 mit 128 Bit pro Kachel mit 4 x 4 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 in Anbetracht dessen, dass eine Streamingressource 550 Gigapixel umfasst (in diesem Fall 512 GB Arbeitsspeicher).
In der Praxis würde nichts in der Nähe dieser vollständigen Zuordnungen definiert werden, da die menge des verfügbaren physischen Speichers nicht zulässt, dass in der Nähe dieser Menge zu einem bestimmten Zeitpunkt zugeordnet und referenziert wird. Mit einem Kachelpool können Anwendungen jedoch Kacheln wiederverwenden (z. B. wiederverwenden einer "schwarzen" farbigen Kachel für große schwarze Bereiche in einem Bild) – effektiv die Verwendung des Kachelpools (d. h. Seitentabellenzuordnungen) als Tool für die Speicherkomprimierung.
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 |
|---|---|
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, was ungefähr 1/4 GPU-RAM ist. |
|
Ändern Sie die Größe eines Kachelpools, um einen Kachelpool zu vergrößern, wenn die Anwendung mehr Arbeit für die Zuordnung der Streamingressourcen benötigt, oder um zu verkleinern, wenn weniger Speicherplatz erforderlich ist. |
|
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. |
Verwandte Themen
Erstellen von Streamingressourcen