Hey,

ich bin vor ein paar Tagen auf diese Slides gestoßen: http://www.slideshare.net/CassEveritt/beyond-porting
Dort wird eine Technik beschrieben texture changes fast komplett zu eliminieren mit Hilfe von sparse texture arrays und wenn möglich auch noch mit bindless textures um ohne binds auch die sample parameter der einzelnen array-layer unterschiedlich zu halten.
Wie das funktioniert versteh ich. Allerdings frage ich mich ob es eine geschickte Möglichkeit gibt den Teil mit den sparse texture arrays auch ohne "sparse" hinzukriegen … also für OpenGL 3.3 hardware oder generell hardware die keine sparse textures unterstützt.

Das Problem dabei ist, dass man zwar ein Texture Array erstellen kann, dieses nimmt aber ohne "sparse" zu sein auch für jeden layer physischen speicher in Anspruch, was ziemlich doof wäre wenn nur wenige der Layer tatsächlich genutzt werden.

Mir fallen da auf Anhieb 4 Möglichkeiten ein (ich gehe davon aus, dass nichts über die Anzahl und Art der genutzten Texturen bekannt ist):

1. Texture Resize:
Das Texture Array wird mit "sehr" wenigen layern (evtl nur 1em) erstellt und wächst wenn eine neue Textur hinzugefügt werden soll. Dafür müsste man die Daten aber jedes mal komplett neu auf die Graka schieben wenn ich das richtig sehe. D.h. man müsste sie im RAM behalten.

2. Wenige große Arrays:
Das Texture Array wird mit "sehr" vielen layern erstellt und bleibt für immer so. Es wird gehofft, dass der Speicher reicht beziehungsweise auch ausgenutzt wird. Natürlich doof wenn man dann viele unterschiedliche Texturformate hat.

3. Viele kleine Arrays:
Das Texture Array wird mit "relativ" wenigen layern erstellt und bleibt für immer so. Es wird also nicht zu viel Speicher verschwendet, allerdings hat man auch wieder mehr Texture Changes.

4. Ein mix aus den anderen 3 Varianten:
Große Texturformate bekommen anfangs wenige layer, kleine können evtl ein paar mehr bekommen. Layer werden durch neu hochladen der daten hinzugefügt. Wenn es Speicherprobleme gibt kann man ungenutzte layer auch wieder frei geben.

Ich hab bis jetzt nur mit Texture Arrays mit fester layer-anzahl gearbeitet und hab keine Ahnung ob es evtl mit viel tricksen Möglich ist das nachzubauen.

Was sagt ihr dazu?

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Wieso sollte man das müssen?
Man kann doch die Daten im RAM der GPU kopieren.
Allerdings ist das Kopieren von größeren Mengen grundsätzlich kein performanter Ansatz und auch nicht skalierbar.

Texturearrays sehe ich vorallendingend nicht als die Lösung, weil dann alle Texturen gleich groß mit genau gleicher Filterung sein müssen.

Texture Arrays sind evtl nicht optimal, aber die beiden von dir beschriebenen Probleme sind leicht behoben:

Man benutzt für alle Textures bei denen das interne Format und die dimensionen gleich sind ein gemeinsames Array. Das bedeutet zwar dass man immer noch mehrere Texturen hat, mit ein bisschen rumsortieren der Objekte kann man aber viele Texture Changes damit los werden. Und mit bindless Textures kann man die Texture Changes so oder so komplett los werden.
Will man unterschiedliche Filterung, nimmt man Sampler Objects zur Hilfe. Man trennt also die Filterung von der Textur. Da hat man wieder große Vorteile wenn man bindless textures hat, da man sich einen handle auf ein Textur+Sampler pair besorgen kann, den man dann an seine Shader übergibt.

Mit bindless textures wird das also alles noch ne Ecke einfacher.

Aber wie genau man ein Textur Array komplett im GPU ram vergrößern kann sehe ich nicht (bin ich nur doof?).

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

In der Praxis sind halt bei mir sehr sehr selten, mehrere Texturen gleich groß.
Bei dem Sampler, weiß ich nicht, was du meinst.

Einfach so gruppieren ist in der Praxis auch meistens nicht so einfach, weil man anderen Eigenschaften sortieren muss. (In der Regel Tiefe, Shadertyp etc.)

Direkt vergrößern geht leider meines Wissens noch nicht mit OpenGL.
Allerdings kann man einfach ein zweites Objekt erstellen und die Texturedaten rüberkopieren. Die CPU braucht man dafür allerdings natürlich nicht.

Sampler Objects sind extra objekte die die Sampling-Parameter von Texturen speichern und diese so von den Texturen trennen und man sie zwischen mehreren Texturen sharen kann oder eine Textur mit mehreren Parameter Sets haben kann.

Sind seit OpenGL 3.3 im core.

https://www.opengl.org/wiki/Sampler_Object

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Die "Sampler" kannte ich noch nicht.
Allerdings ist mir nicht ganz klar, was das bei der Problemstellung weiterhilft.
Um den Sampler zu ändern muss man ja wieder Statewechsel durchführen: Also kein Zusammenfassen mehrerer Drawcalls mehr möglich.

Es gibt aber potentiell weniger Kombinationen von sampling Parametern als Texturen, d.h. weniger state changes wenn man das in der sortierung der drawcalls beachtet.
Die state changes kann man ohne bindless textures gar nicht eliminieren … aber ich suche hier nach Möglichkeiten sie zu minimieren.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)