Texturgröße und Performance

[Jonathan]

Aktuell schmeiße ich in den Landvogt einfach Assets rein und hinten kommt 3D Grafik raus. Die Modelle sind eigentlich alle eher low-poly, aber die Texturen haben oft hohe Auflösungen, gerne schonmal 4096^2, weil man die ja echt mit wenig Aufwand später verkleinern könnte. Aber vielleicht ist "später" einfach "heute", hauptsächlich wollte ich die aktuelle Version nochmal auf einem älteren Laptop ausprobieren und dafür die Leistung ein wenig erhöhen.

Wie wirkt sich die Texturauflösung auf die Performance aus? Klar, zunächst einmal sollte es alles in den GPU RAM passen. Aber wie geht es dann weiter? Es gibt ja schon Mip-Maps, d.h. wenn mein Dreieck klein ist, wird ja auch nur eine kleine Textur genommen. Solange der RAM nicht überläuft, ist es überhaupt messbar teurer per Mip-Mapping die kleine Textur zu samplen und die große ungenutzt im Speicher zu haben, anstatt nur die kleine Textur im Speicher zu haben? Mit dieser Überlegung scheint es mir, dass es nur dann schneller wird, wenn die effektive Texturauflösung geringer ist, als die Bildschirmauflösung, weil ansonsten eh immer für jeden Bildschirmpixel ein Texturpixel geladen werden muss (eigentlich mehr weil filtern, bla bla, ihr wisst, was ich meine).

Ich könnte ja mit recht wenig Aufwand alle Texturen in halber Auflösung laden. Mit etwas mehr Aufwand könnte ich auch analysieren, welche Texturen in durchschnittlichen Szenen in der Regel mit welchen Mip-Leveln verwendet werden und dann gezielt die ungenutzten Texturen verkleinern.

Oder sollten mir alle Texturen eigentlich eher egal sein und ich sollte mich viel mehr auf reduzierung der Draw-Calls konzentrieren? (Schnittstelle ist hier btw. OpenGL)

[Krishty]

Ich kann nur von Direct3D 9 unter WDDM 1.2 und später berichten: Texturen werden erst in den VRAM hochgeladen, wenn sie auch benutzt werden. Ist dein Gebäude auf dem Bildschirm so klein, dass die höchste Mipmap-Stufe nicht gesamplet wird, landet sie erst gar nicht auf der GPU.

Das bringt dann zwei weitere Probleme mit sich: Mikroruckler, wenn das Objekt dann doch groß angezeigt wird, weil dann 64 MiB auf die GPU geschoben werden müssen. Und dass einige Modelle das detaillierteste Mip-Level auch dann benutzen, wenn sie gar nicht groß zu sehen sind (bspw. durch Dreiecke mit stark gestreckten Texturkoordinaten).

Ich sample hier aber locker 6 GiB Texturen auf einer GPU mit 2 GiB VRAM und habe, wie gesagt, nur Mikroruckler wenn sich die Szene abrupt ändert.

Adressraum fällt dafür übrigens auch nicht an; meine 6 GiB Texturen stecken in einem 32-Bit-Prozess mit 250 MiB Speicherbedarf.

Du verschwendest außerdem Ladezeit, da die 4k-Texturen ja erstmal geladen werden müssen. Die GPU kann nicht direkt aus einem Memory Mapping samplen, also musst du die Pixel beim Erzeugen der Texturen zumindest einmal von der Platte kopieren, und das kostet natürlich auch Zeit, obwohl sie nicht sofort auf der GPU landen.

Für OpenGL, wie gesagt, kA.

[TomasRiker]

Nutzt du schon Texturkomprimierung? Also ich meine sowas wie DXT, wo die Texturen auch im RAM komprimiert vorliegen und somit weniger Speicher, Bandbreite und Ladezeit brauchen.

[Schrompf]

Ich finde, Du hast das schon selbst fein hergeleitet, und Krishty hat sauber ergänzt. Wenn Deine Texturen zu hoch aufgelöst sind, verursacht das praktisch keine Rechenzeit. Aber probier's doch einfach mal aus! Ich finde es sehr schwer, eine Intuition zu entwickeln, wie hoch die Texeldichte bei einem hinreichend komplexen Objekt wirklich ist. Und Deine Gebäude sind hinreichend verfaltet, da reicht wahrscheinlich ne Drehung um 45° und die GPU samplet plötzlich 2 MipMaps höher.

Ansonsten: DX9 ist schwierig, aber Pix64 gibt's immer noch und das kann Dir zumindest den teuersten DrawCall raussuchen. Am Ende brauchst Du einfach einen alternativen Schatten-Shader mit der Hälfte der Samples. Wenn Du sauber und aufwandsarm in OpenGL laufen lassen kannst, dann steht Dir NVidia NSight oder RenderDoc offen, und die haben noch ganz andere Methoden. Ich erinnere mich da an "nimm mal alle Texturen als 1x1 an" und so Späße. Deine Szenen sehen echt nicht so komplex aus

[Matthias Gubisch]

Wenn du es genau wissen willst dann musst du dir die benutzten Mip Levels anschauen :)
Heutzutage würde man das mit SamplerFeedback machen, da du das auf OpenGL soweit ich weiß nicht zur Verfügung hast musst du das wohl selber machen.

Ich hatte vor Jahren mal einen Shader der mir farbcodiert in ein Rendertarget das gesampelte mip an der Stelle ausgeben konnte.

Ich müsste mal auf meiner Platte kramen ob ich den noch finde, aber im Prinzip gibt es die Formeln wie die Texture Unit das berechnet im Internet
(z.b. hier:https://community.khronos.org/t/mipmap- ... dfdy/67480 als Ausgangspunkt)

Ich glaube in den ersten Versionen von Texture Streaming wurde das auch so gemacht

[Krishty]

Ich müsste mal auf meiner Platte kramen ob ich den noch finde, aber im Prinzip gibt es die Formeln wie die Texture Unit das berechnet im Internet
(z.b. hier:https://community.khronos.org/t/mipmap- ... dfdy/67480 als Ausgangspunkt)

Ich glaube in den ersten Versionen von Texture Streaming wurde das auch so gemacht

Du kannst im Shader ddx und ddy (also pixelweise Änderungsrate) der Texturkoordinaten abgreifen, den Zweierlogarithmus drauf berechnen, und den für die Farbkodierung nutzen. Z.B. bedeutet ddx=0.5, dass von Pixel zu Nachbarpixel die Hälfte der Textur übersprungen wird, du also bei Mip Level [1] bist (vom am niedrigsten aufgelösten gezählt).

Edit: Ist auch, was dein Thread sagt – nur schade, dass ich JavaScript brauchte, um das lesen zu können