Zuordnungen in einen Kachelpool

Wenn eine Ressource mit dem D3D11_RESOURCE_MISC_TILED-Flag erstellt wird, werden die Kacheln, aus denen die Ressource besteht, von der auf Speicherorte in einem Kachelpool verweisen. Ein Kachelpool ist ein Speicherpool (unterstützt durch eine oder mehrere Zuordnungen im Hintergrund , die von der Anwendung nicht angezeigt werden). Das Betriebssystem und der Anzeigetreiber verwalten diesen Speicherpool, und der Speicherbedarf kann von einer Anwendung leicht verstanden werden. Gekachelte Ressourcen 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, und dass dieselben Kacheln bei Bedarf an verschiedenen Speicherorten innerhalb einer Ressource wiederverwendet werden können.

Die Kosten für die Flexibilität des Auffüllens der Kacheln für eine Ressource aus einem Kachelpool bestehen darin, dass die Ressource die Arbeit zum Definieren und Verwalten der Zuordnung ausführen muss, deren Kacheln im Kachelpool die für die Ressource benötigten Kacheln darstellen. 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, wenn die Ressource darauf zugreift.

Mehrere Kachelpools können erstellt werden, und eine beliebige Anzahl von gekachelten Ressourcen 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 des Anzeigetreibers und der Laufzeitimplementierung besteht, besteht darin, dass eine bestimmte gekachelte Ressource nur Zuordnungen zu jeweils höchstens einem Kachelpool aufweisen kann (im Gegensatz zur gleichzeitigen Zuordnung zu mehreren Kachelpools).

Die Speichermenge, die einer gekachelten Ressource selbst zugeordnet ist (d. h. der unabhängige Kachelpoolspeicher), ist in etwa 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 Arbeitsspeicherbedarf für den Seitentabellenspeicher ungefähr mit der Anzahl der Kacheln zu skalieren, die zugeordnet werden (z. B. mithilfe eines Mehrebenentabellenschemas).

Der Kachelpool kann als eine vollständige Software-Abstraktion 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 Dehnungsebenen in der Hardware an. Optimierungen einer Einebenenseitentabelle mit Konstrukten wie Seitenverzeichnissen sind unabhängig vom Konzept des Kachelpools.

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

Angenommen, jeder Seitentabelleneintrag ist 64 Bits.

Angenommen, eine gekachelte Ressource wird mit einem Format von 128 Bit pro Element erstellt (z. B. ein RGBA-Float), sodass eine 64 KB-Kachel nur 4096 Pixel enthält. Die maximal unterstützte Textur2DArray-Größe von 16384 * 16384 * 2048 (aber nur mit einer einzelnen mipmap) erfordert etwa 1 GB Speicherplatz in der Seitentabelle, wenn sie vollständig aufgefüllt ist (ohne Mipmaps) mit 64-Bit-Tabelleneinträgen. Das Hinzufügen von Mipmaps würde den vollständig zugeordneten (schlimmsten Fall) Seitentabellenspeicher um etwa ein Drittel auf etwa 1,3 GB vergrößern.

Dieser Fall würde Zugriff auf etwa 10,6 Terabyte adressierbaren Arbeitsspeicher ermöglichen. Es kann jedoch eine Grenze für die Menge des adressierbaren Arbeitsspeichers geben, was diese Mengen reduzieren würde, vielleicht auf den Terabytebereich.

Ein weiterer Zu berücksichtigende Fall ist eine einzelne gekachelte Textur2D-Ressource von 16384* 16384 mit einem Format von 32 Bit pro Element, einschließlich mipmaps. Der erforderliche Speicherplatz in einer vollständig aufgefüllten Seitentabelle beträgt etwa 170 KB mit 64-Bit-Tabelleneinträgen.

Betrachten Sie schließlich ein Beispiel, das ein BC-Format verwendet, 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 gekachelte Ressource 550 Gigapixel (in diesem Fall 512 GB Arbeitsspeicher) umfassen kann.

In der Praxis würden diese vollständigen Zuordnungen bei weitem nicht definiert werden, da die menge des verfügbaren physischen Arbeitsspeichers es nicht zulassen würde, dass nur annähernd so viel zugeordnet und gleichzeitig referenziert werden kann. Mit einem Kachelpool können Anwendungen jedoch Kacheln wiederverwenden (als einfaches Beispiel: Wiederverwendung einer "schwarzen" Kachel für große schwarze Regionen in einem Bild) – effektiv mithilfe des Kachelpools (d. h. Seitentabellenzuordnungen) als Werkzeug für die Speicherkomprimierung.

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

In diesem Abschnitt

Zugehörige Themen

Erstellen gekachelter Ressourcen