Zum Streaming beziehungsweise Speichermanagement:
Ein Problem an modernen GPUs ist immer noch, dass sie selbst kein "Texture-Paging" besitzen. Deshalb müssen zu Beginn eines Zeichenaufrufs sich alle Texturen inklusive allen Mipmap-Levels, aus denen potentiell im Shader während des Zeichenaufrufs gelesen wird, im DRAM der GPU befinden. Tatsächlich gelesen werden aber immer nur ein Bruchteil all dieser Texturdaten. Gerade die niedrigen Mipmap-Level, die den Großteil allen Speicherplatzes kosten, werden nur selten ausgelesen.
Es gibt mehrere Möglichkeiten, wie eine Anwendung das Speichermanagement, also welche Texturen im Speicher der GPU befinden oder welche Texturen durch andere Texturen ersetzt werden, und das Kopieren der Texturen kontrollieren kann. In der einfachsten Form überlässt die Anwendung das Speichermanagement fast komplett der 3D-API (OpenGL usw) beziehungsweise dem Treiber. Hier ist dann die Anwendung nur dafür zuständig der 3D-API mitzuteilen, welche Texturen der Zeichenaufruf benötigt. Der Treiber bestimmt dann welche Textur jetzt an welcher Stelle im DRAM der GPU steht oder welche Textur mit welcher Textur bei Speichermangel ersetzt wird. Ebenso ist der Treiber für das Planen des Kopierens der Texturen zwischen CPU und GPU-DRAM und für das Kopieren selbst zuständig. Da komplette Texturen inklusive allen Mipmapleveln im DRAM der GPU gelagert und hineinkopiert werden und zudem ein Großteil dieser Daten nicht beim Zeichnen benötigt wird, werden bei dieser Art des Speichermanagements Speicherplatz im DRAM der GPU verschwendet und zudem der PCI-E stärker belastet. Deshalb ist sie ineffizient.
Es gibt allerdings auch fortgeschrittene Verfahren für das Speichermanagement und das Kopieren, wie das Texture-Streaming aus der Unreal-Engine oder die Megatextures von ID. Bei diesen Verfahren übernimmt hier die Anwendung selbst das Speichermanagement und das Planen des Kopierens, in der Hoffnung dass ihre eigenen Heuristiken dafür und ihre eigene Planung dafür besser sind als die des Treibers. Des Weiteren kann eine Anwendung auch selbst berechnen, welche Mipmaplevel ein gegebener Zeichenaufruf überhaupt benötigt. Diese Berechnungen werden benutzt, dass die Anwendung bei den fortgeschrittenen Verfahren den Speicher nicht mehr auf Texturenbasis sondern auf Mipmap-Basis feiner managt. Dadurch müssen wiederum nur noch die benötigten Mipmaplevel kopiert beziehungsweise im DRAM der GPU vorgehalten werden, wodurch PCI-E Bandbreite und Speicherplatz auf der GPU eingespart werden. Allerdings muss diese Art des Speichermanagements die Anwendung selbst übernehmen, wodurch es Programmieraufwand und zudem etwas CPU-Rechenzeit kostet.
Und ich lese daraus, dass sich die Anzahl der Taktzyklen zur Darstellung einer Textur erhöhen kann, falls zu wenig Speicher vorhanden sein sollte.
"Next time" sollte sich hier so wie ich es verstehe auf den nächsten Frame beziehen, also im wesentlichen, dass bei Speicherplatzmangel die Textur mit einer zu niedrigen Auflösung/hohem Mipmap-Level für den Frame gezeichnet wird und dann beim nächsten Frame wieder versucht wird ob Speicherplatz für eine höhere Texturauflösung vorhanden ist. So ein Texture-Popping sieht man eigentlich bei Spielen mit Unreal-Engine relativ oft.
Wird DX 12 eigentlich die Speichernutzung effizienter machen, oder dies zumindest bei entsprechender Programmierung ermöglichen?
Mein Wissensstand über die "Next-Gen-APIs" ist sehr schlecht; ich habe bislang nur einmal die Mantle Specs überflogen. Da scheint sich das (automatische) Speichermanagement der API von dem Grundprinzip her kaum von aktuellen OpenGL/DX zu unterscheiden. Der Hauptvorteil ist meines Wissenstands nach, dass man sich selbst mit Hilfe von Queues leichter ein eigenes Speichermanagement inklusive Kopieren implementieren kann.
