Warum werden gekachelte Ressourcen benötigt?

Kachelressourcen werden benötigt, sodass weniger GPU-Arbeitsspeicher (Graphics Processing Unit) zum Speichern von Oberflächenbereichen verschwendet wird, von denen die Anwendung weiß, dass sie nicht darauf zugreifen können, und die Hardware kann verstehen, wie über angrenzende Kacheln gefiltert wird.

In einem Grafiksystem (d.h. Betriebssystem, Anzeigetreiber und Grafikhardware) ohne Kachelressourcenunterstützung verwaltet das Grafiksystem alle Direct3D-Speicherbelegungen mit Subressourcengranularität. Bei einem Pufferist der gesamte Puffer die Unterressource. Bei einer Textur (z. B. Texture2D)ist jede Mipebene eine Unterressource. für ein Texturarray (z. B. Texture2DArray)ist jede Mipebene in einem bestimmten Arrayslice eine Unterressource. Das Grafiksystem macht nur die Möglichkeit verfügbar, die Zuordnung von Zuordnungen mit dieser Granularität der Unterressource zu verwalten. Im Kontext von gekachelten Ressourcen bezieht sich "Zuordnung" darauf, Daten für die GPU sichtbar zu machen.

Angenommen, eine Anwendung weiß, dass ein bestimmter Renderingvorgang nur auf einen kleinen Teil einer Bildmipmapkette zugreifen muss (möglicherweise nicht einmal auf den vollständigen Bereich einer bestimmten Mipmap). Im Idealfall könnte die App das Grafiksystem über diese Notwendigkeit informieren. Das Grafiksystem würde sich dann nur die Sorgen machen, um sicherzustellen, dass der benötigte Arbeitsspeicher auf der GPU zugeordnet wird, ohne zu viel Arbeitsspeicher zu belegen. In Der Praxis kann das Grafiksystem ohne Unterstützung für gekachelte Ressourcen nur über den Arbeitsspeicher informiert werden, der auf der GPU mit Subressourcengranularität zugeordnet werden muss (z. B. eine Reihe von vollständigen Mipmapebenen, auf die zugegriffen werden kann). Es gibt auch keine Nachfragefehler im Grafiksystem, sodass potenziell viel zusätzlicher GPU-Arbeitsspeicher verwendet werden muss, um vollständige Unterressourcen zuzuordnen, bevor ein Renderingbefehl ausgeführt wird, der auf einen Beliebigen Teil des Arbeitsspeichers verweist. Dies ist nur ein Problem, das die Verwendung großer Speicherbelegungen in Direct3D ohne Unterstützung von gekachelten Ressourcen erschwert.

Direct3D 11 unterstützt Texture2D-Oberflächen mit bis zu 16384 Pixeln auf einer bestimmten Seite. Ein Bild, das 16384 breit und 16384 hoch und 4 Bytes pro Pixel ist, würde 1 GB Videospeicher beanspruchen (und das Hinzufügen von Mipmaps würde diese Menge verdoppelt). In der Praxis müssten nur selten alle 1 GB in einem einzelnen Renderingvorgang referenziert werden.

Einige Spieleentwickler modellieren Geländeoberflächen mit einer Breite von 128 X 128 KB. Um dies für vorhandene GPUs zu erreichen, wird die Oberfläche in Kacheln aufgeteilt, die klein genug für die Verarbeitung durch Hardware sind. Die Anwendung muss herausfinden, welche Kacheln möglicherweise benötigt werden, und sie in einen Cache von Texturen auf der GPU laden– einem Softwarepagingsystem. Ein erheblicher Nachteil dieses Ansatzes ist, dass die Hardware nichts über das Paging weiß, das gerade ausgeführt wird: Wenn ein Teil eines Bilds auf dem Bildschirm angezeigt werden muss, der kachelübergreifend ist, weiß die Hardware nicht, wie eine feste Funktion (d. h. effiziente) Filterung zwischen Kacheln ausgeführt werden soll. Dies bedeutet, dass die Anwendung, die ihre eigene Softwarekacheln verwaltet, auf manuelle Texturfilterung im Shadercode zurückgreifen muss (was sehr teuer wird, wenn ein anisotroper Filter mit guter Qualität gewünscht wird) und/oder Verschwendung von Speicher-Guttern um Kacheln, die Daten von benachbarten Kacheln enthalten, sodass die Hardwarefilterung fester Funktionen weiterhin Unterstützung bieten kann.

Wenn eine kachelte Darstellung von Oberflächenzuordnungen ein erstklassiges Feature im Grafiksystem sein könnte, könnte die Anwendung der Hardware mitteilen, welche Kacheln verfügbar sein sollen. Auf diese Weise wird weniger GPU-Arbeitsspeicher verschwendet, um Bereiche von Oberflächen zu speichern, von denen die Anwendung weiß, dass nicht zugegriffen wird, und die Hardware kann verstehen, wie über angrenzende Kacheln gefiltert werden kann, wodurch einige der Probleme von Entwicklern entschärft werden, die selbst Softwarekacheln ausführen.

Um jedoch eine vollständige Lösung bereitzustellen, muss etwas unternommen werden, um die Tatsache zu bewältigen, dass die maximale Oberflächendimension derzeit 16384 beträgt, unabhängig davon, ob Kacheln innerhalb einer Oberfläche unterstützt werden – und zwar nahe der 128.000+ , die Anwendungen bereits wünschen. Es ist ein Ansatz, nur die Hardware zur Unterstützung größerer Texturgrößen zu benötigen, aber es gibt erhebliche Kosten und/oder Kompromisse bei dieser Route. Der Texturfilterpfad und der Renderingpfad von Direct3D 11 sind bereits hinsichtlich der Genauigkeit bei der Unterstützung von 16K-Texturen mit den anderen Anforderungen stark ausgelastet, z. B. bei der Unterstützung von Viewport-Erweiterungen, die während des Renderings von der Oberfläche fallen, oder der Unterstützung von Texturumbrüchen vom Oberflächenrand während der Filterung. Eine Möglichkeit besteht darin, einen Kompromiss zu definieren, bei dem die Texturgröße über 16.000 hinaus zunimmt, funktionalität/genauigkeit auf irgendeine Weise aufgegeben wird. Auch bei dieser Empfindlichkeit können zusätzliche Hardwarekosten in Bezug auf die Adressierungsfunktion im gesamten Hardwaresystem erforderlich sein, um größere Texturgrößen zu erhalten.

Ein Problem, das bei sehr großen Texturen ins Spiel kommt, besteht darin, dass die Genauigkeit der Texturkoordinaten für Gleitkommastellen mit einfacher Genauigkeit (und die zugeordneten Interpolatoren zur Unterstützung der Rasterung) nicht mehr genau ist, um Positionen auf der Oberfläche genau anzugeben. Jittery-Texturfilterung würde folgen. Eine kostspielige Option wäre, Interpolatorunterstützung mit doppelter Genauigkeit zu erfordern, obwohl dies bei einer sinnvollen Alternative zu überqualifiziert sein könnte.

Ein alternativer Name für gekachelte Ressourcen ist "Sparsetextur". "Sparse" vermittelt sowohl die Kachelart der Ressourcen als auch vielleicht den Hauptgrund für das Kacheln– dass nicht alle gleichzeitig zugeordnet werden sollen. Tatsächlich könnte eine Anwendung absichtlich eine gekachelte Ressource erstellen, in der keine Daten für alle Regionen und Mips der Ressource erstellt werden. Der Inhalt selbst kann also geringer sein, und die Zuordnung des Inhalts im GPU-Speicher zu einem bestimmten Zeitpunkt wäre eine Teilmenge davon (noch geringer).

Ein weiteres Szenario, das von gekachelten Ressourcen bedient werden kann, ist das Aktivieren mehrerer Ressourcen unterschiedlicher Dimensionen/Formate, um denselben Arbeitsspeicher gemeinsam zu nutzen. Manchmal verfügen Anwendungen über exklusive Sätze von Ressourcen, die bekanntermaßen nicht gleichzeitig verwendet werden, oder Ressourcen, die nur für eine sehr kurze Verwendung erstellt und dann zerstört werden, gefolgt von der Erstellung anderer Ressourcen. Eine Form der Verallgemeinerung, die aus "gekachelten Ressourcen" herausfallen kann, ist, dass es möglich ist, dem Benutzer zu ermöglichen, mehrere verschiedene Ressourcen auf denselben (überlappenden) Arbeitsspeicher zu verweisen. Anders ausgedrückt: Die Erstellung und Zerstörung von "Ressourcen" (die eine Dimension/ein Format definieren usw.) kann von der Verwaltung des Speichers, der den Ressourcen zugrunde liegt, aus sicht der Anwendung entkoppelt werden.

Gekachelte Ressourcen