Speichermanagement bei Texture Arrays

[Asmodeus]

Unter OpenGL und DX10 stehen ja nun auch Texture Arrays zur Verfügung. Mich würde nun interessieren, wie es sich dabei mit dem Speichermanagement verhält. Ich habe unter OpenGL das Problem, dass ich bisher sehr viele verschiedene Texturen mit gleichen Größen handhaben muss. Dafür sind dann immer eine Menge Texturwechsel notwendig. Deshalb will ich diese vielen Texturen in Texture Arrays zusammenfassen. Nun kann es aber passieren, dass ich so viele Texturen habe, dass der Grafikkartenspeicher dafür nicht ausreicht. Meine naive Vorstellung ist nun so, dass bei vielen Einzeltexturen bei ungenügend Speicher einfach einige davon in den Hauptspeicher ausgelagert werden. Also ich habe 500 Texturen, es ist nur für 480 Platz, also werden 20 auf in den HS ausgelagert. Wie sieht es nun aus, wenn ich die 500 in 5 Arrays zu je 100 Texturen zusammenfasse? Funktioniert die Sache dann so intelligent, dass von dem 5. Array trotzdem 80 Texturen auf der Grafikkarte liegen und nur 20 im HS, oder wir das gesamte 5. Array wegen des Platzmangels in den HS verschoben?

Gruss, Carsten.

[Neomi]

Dank Virtualisierung des Grafikspeichers sollte das kein Thema sein. Damit müßte es dann auch möglich sein, nur die benutzten Mipstufen einer Textur bzw. sogar nur die benutzten Teile davon im Speicher halten zu müssen.

[Coda]

Das dürfte dann aber nur unter Vista funktionieren.

[derRäuber]

Bei OpenGL dürfte das bei entsprechender Treiberanpassung auch jetzt bereits möglich sein.
Ich glaube aber nicht dass dies ATI oder NVIDIA implementiert hat.

Zudem dürfte so eine Speicherverwaltung auch recht aufwändig sein.
Also ich habe mir bisher immer vorgestellt, dass einfach ein FIFO-stack für ganze Texturobjekte angewandt wird.
Man stelle sich mal vor wie kompliziert es für den Treiber würde wenn polygonale Texturbereiche verwaltet werden müssen.

[Demirug]

Das dürfte dann aber nur unter Vista funktionieren.

Selbst da noch nicht. Nicht umsonst gibt es bei D3D10 noch ein Limit wie viel Platz eine Resource in Summe benötigen darf und eine Vorgabe wie viel Speicher der Treiber als Block zur Verfügung stellen muß.
„Richtiger“ virtueller Grafikspeicher kommt erst mit WDDM 2.1.

[derRäuber]

Wenn der Speicher virtualisiert ist, bedeutet dass aber nicht gleichzeitig dass dann auch so eine Speicherverwaltung von Subtexturen angewandt wird.
Wie bereits gesagt halt ich dies einfach für viel zu aufwändig.

[Demirug]

Wenn der Speicher virtualisiert ist, bedeutet dass aber nicht gleichzeitig dass dann auch so eine Speicherverwaltung von Subtexturen angewandt wird.
Wie bereits gesagt halt ich dies einfach für viel zu aufwändig.

WDDM 2.1 fordert das. Um genauer zu sein müssen die GPUs dafür sogar in der Lage sein einzelne Teiler einer Mip Map auszulagern.

[derRäuber]

WDDM 2.1 fordert das. Um genauer zu sein müssen die GPUs dafür sogar in der Lage sein einzelne Teiler einer Mip Map auszulagern.Wie soll das konkret aussehen?
Ich kann mir nicht vorstellen dass man polygonale Speicherbereiche verwalten wird.
Höchsten vielleicht dass rechteckige Bereiche Zeichenobjekten zugeordnet werden und dann ausgelagert werden können.

[Demirug]

Wie soll das konkret aussehen?
Ich kann mir nicht vorstellen dass man polygonale Speicherbereiche verwalten wird.
Höchsten vielleicht dass rechteckige Bereiche Zeichenobjekten zugeordnet werden und dann ausgelagert werden können.

Auf die gleiche Art wie die virtuelle Speicherverwaltung bei den CPUs funktioniert. Nur lagert eine GPU nicht direkt auf die Festplatte sondern in den Hauptspeicher aus.

[derRäuber]

Auf die gleiche Art wie die virtuelle Speicherverwaltung bei den CPUs funktioniert. Nur lagert eine GPU nicht direkt auf die Festplatte sondern in den Hauptspeicher aus.Bist du dir da sicher?

Gerade bei Subtexturen sind die Zugriffsmuster ganz und gar nicht linear.
Damit würde bei einer Seitenverwaltung erheblich ineffizient gearbeitet.

[Demirug]

Bist du dir da sicher?

Ja bin ich.

Gerade bei Subtexturen sind die Zugriffsmuster ganz und gar nicht linear.
Damit würde bei einer Seitenverwaltung erheblich ineffizient gearbeitet.

Wenn die CPU anfängt ständig ein und auszulagern wird der Rechner auch langsam.
Bei einer GPU ist das allerdings etwas weniger dramatisch. Sobald es zu einem Pagefault kommt wird der entsprechende Thread blockiert und die GPU arbeitete mit einem anderen weiter der nicht auf das einlagern einer Page wartet. Die Sache ist natürlich nur dann relevant wenn der Videospeicher nicht reicht.

[derRäuber]

Irgendwann müssen aber die Texturdaten gelesen werden, und das holen der Daten über den Systembus dauert *extrem* lange.
Angenommen man hat einen ausgelagerten 8k² Texturatlas und will auf eine vertikal schmale Subtextur zugreifen. Dann gute Nacht mit linearen Speicherseiten über die gesammte Textur.

Es währe doch viel sinnvoller zweidimensionale Seiten anzulegen.

[Xmas]

Texturen werden ja auch in aller Regel nicht linear gespeichert, sondern in Morton- oder auch Hilbert-Order. Damit entsprechen Pages der Speicherverwaltung automatisch rechteckigen Blöcken der Textur.