Hallöchen,

ich hab eine Frage zum Speicher bzw. der benötigten Rechenleistung von Texturgrößen
Und war habe ich mehrere simple 3D-Objekte (GL_QUADS-Gebilde) mit Textur_2D-Textur bespannt. Alle Texturgrößen sind 2er Potenzen. Dabei geh ich immer auf die nächstgrößere Größe und ändere nicht die Grafik. Dabei kann es schon vorkommen, dass ein 260 x 200 Pixel großes Objekt als eine 512 x 512 Textur gespeichert und eingeladen wird. Diese bringe ich dann auf meine Sprites.
Eine andere Methode wäre es, eine große Grafik von 1024 x 1024 zu haben auf welcher sich viele kleinere Grafiken befinden. Diese werden dann einzeln per OpenGL per "glTexCoord2f" "zugeschnitten" und auf die Sprites gelegt.
Die Frage ist nun, was beansprucht die Rechenleistung mehr? Viele 512 x 512er, 256 x 256er und 64 x 64er Texturen wobei manchmal nur die Hälfe genutzt wird, oder eine große 1024 x 1024er Textur mit vielen Sprites welche immer zugeschnitten wird? Ist es dabei egal, wie groß die Textur ist, und ist deshalb nur entscheidend, welcher Teil (also welche Pixelgröße) angezeigt wird, oder ist die alleinige Größe der Textur entscheidend, wie anspruchsvoll die Operation ist? Denn dann würde es ja wenig Sinn machen, ein Objekt von 128 x 128 aus einer 1024 x 1024er Textur zu nehmen, wenn es ebensoviel Leistung braucht, wie die volle 1024er Textur. Dann wär es sicher sinnvoller, eine seperate 128 x 128er Textur zu nehmen.
Weiß da jemand vielleicht bescheid, wie sich das verhält mit den Texturen?

mfg.

Sunny

Ein anderer Mitglied der Community würde sagen :"Ein Fall für Benchmark" .
Im Ernst, ich denke, je weniger man seine Texturen wechselt, desto besser.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Also ich würd mal meinen: es kommt drauf an.

Das lässt sich durch ein ganz einfaches Rechenbeispiel zeigen:

1. Fall:
du hast 3 Texturen (A, B und C) mit je 4 MB Speicher mit je 5 Bildern drinnen und du willst alle Bilder 1 mal zeichnen.
Du hast eine Grafikkarte mit 10 MB verfügbar für Texturen.

Du verwendest die Texturen in der Reihenfolge:
A,B,C,A,B,C,A,B,C,A,B,C,A,B,C
Hier muss der Treiber ab dem 1. auftauchen von C wahrscheinlich jede Textur neu vom Hauptspeicher holen => du hast so ganz grob mal 13*4 MB Daten die über den AGP kommen je Frame.
Machst du es jedoch in der besseren Reihenfolge:
A,A,A,A,A,B,B,B,B,B,C,C,C,C,C
musst du das C nur einmal vom Hauptspeicher holen => 4 MB Daten über AGP.

2. Fall
Du hast deine 15 Bildlein mit je 1 MB Speicher (also ein bisserl mehr Overhead der nicht verwendet wird drinnen). Und du willst wieder alle 1 mal zeichnen. Hier ist die Reihenfolge egal, die letzten 5 Bilder haben keinen Platz mehr in den 10 MB und somit müssen 5 MB über den Bus geholt werden.


Ist jetzt natürlich ein sehr vereinfachtes Beispiel (vor allem weil jedes Bild nur einmal dar gestellt wird) aber ich denke man sieht worauf das hinaus läuft.

Fazit:
Große Texturen sind nicht so nachsichtig wenn du die Texturen in der "falschen" Reihenfolge verwendest. Wenn du jedoch bei kleineren Texturen mehr Overhead hast, dann kann sich das natürlich auch negativ auswirken.


Zusätzlich ist noch zu beachten (und das wär wahrscheinlich wirklich ein Fall für nen Benchmark) dass nicht alle Grafikkarten gleich gut mit kleinen und großen Texturen umgehen können. Beispielsweise der Grafikkarten-Cache dürfte bei kleineren Texturen auch etwas effizienter verwendet werden. Aber auf moderneren Grafikkarten sollte der Unterschied nicht mehr allzu groß sein. Meistens steht auch irgendwo dabei das die optimale Texturgröße so 256x256 oder 512x512 ist, wie viel optimaler als 1024 ist halt ne andere Frage.


Eine 3. Möglichkeit gäbe es bei dir aber auch noch:
Du setzt deine Sprites aus mehreren Texturen zusammen. Aber das zu implementieren dürfte sicher lustig werden :-).

Lyr du hast generell mit deinen Aussagen recht. Eine Sache habe ich aber dennoch anzumerken. 10MB für Texturen. Meine mittlerweile schon seit längerer Zeit ausgemusterterte TNT2 hatte 32 MB Speicher. Alleine da hatte ich schon mehr zur Verfügung. Meine derzeitige hat das 8 fache an Speicher. Die Wahrscheinlichkeit, dass Texturen nicht in den Speicher passen ist normal recht gering. Ändert aber nichts an dem Fall, was passiert wenn es denn nicht passt. Dann wird es langsamer.

Allerdings eine Sache habe ich noch zum Beispiel 1. Wenn die Grafikkarte keinen Speicher mehr hat, dann kann sie eine Textur aus dem Hauptspeicher nicht mehr bei sich ablegen ohne eine andere in den Hauptspeicher zu verschieben. Oder sie greift bei jedem Zugriff der Textur auf den Hauptspeicher zu. Beim Austauschen müsste später ja auch die andere Textur wieder über den Bus geschickt werden. Wie das ganze Caching genau funktioniert weiß ich allerdings nicht. Wobei man auch irgendwie Prioritäten für Texturen vergeben kann.

Optimierungen:
In einer Optimierungsguideline (schon etwas älter) stand auch mal etwas davon, dass man Texturenwechsel/Statechanges generell sehr sparsam einsetzen sollte. Vor allem auch schon deswegen, da man beim Zeichnen zum Beispiel zwischen glBegin und glEnd keine Texturen binden kann. In VBOs ist das zum Beispiel auch nicht möglich. Weswegen ich generell sagen würde größere Texturen bringen mehr Vorteile mit sich. Wenn du die Texturen allerdings zu groß machst hast du das Problem, dass es wahrscheinlich auf älteren System nicht mehr funktioniert. Weil sie so große Texturen nicht verarbeiten können. Ich würde da wohl zu 1024x1024 greifen. In meinem Aktuellen Projekt muss ich sehr häufig zwischen Texturen und Fonttexturen wechseln. Dort gestalte ich es so, dass ich Fonts und Texturen in ein Bild packe. Da es leider nicht möglich ist nach Texturen zu sortieren. So kann ich mir die Texturwechsel einsparen. Aber das ist nur in dem einen Fall so extrem.

Texturgrößen: Eine 260x200 auf 512x512 umzuwandle halte ich für nicht ganz so praktisch. In dem Falle wäre wohl 512x256 besser gewesen. Aber in diesem Falle wäre das immer noch äußerst unpraktisch, da für 4 Pixel die Textur doppelt so groß wird. Evtl würde ich da auch einfach als Grundvorraussetzung sagen, dass alle Texturen n^2 sein müssen. Wenn man so etwas im nachhinein aus dem Programm lösen möchte ist das alles andere als Einfach. So müsste sich der Grafiker einen Kopf machen. Zur Optimierung des Speicherbedarfs könntest du die Textur aber auch in eine 256x256 und eine 4x256 Textur zerlegen. Dadurch könntets du den Speicherverbrauch perfektionieren. Zum Nachteil der Geschwindigkeit versteht sich. Wobei sich das je nach Rendermethode einen recht geringen Unterschied ergeben dürfte. Was aber auch wieder auf jeder Hardware anders sein kann.

Wenn die Technik ruhig etwas neuer sein darf oder du keine aufwendige Filterung benötigt würde sich evtl auch GL_ARB_texture_non_power_of_two oder GL_ARB_texture_rectangle (gibts auch als EXT und NV) anbieten. Damit würdest du den Speicherverbrauch sehr schonen und die Geschwindigkeit leidet da auch nicht drunter. Sollte es aber nicht unterstützt werden hast du ein problem sofern du keinen Ausweichplan hast.

wenn man mehrere texturen auf eine packt muss man natürlich noch aufpassen, dass an den rändern keine filterprobleme entstehen ( zB durch mipmaps oder gl_repeat)

Danke erstmal für die Antworten. Ich werd's mal austesten, wie es für mich in Frage kommen könnte.


Ich dachte, es sind nur quadratische Texturen möglich, alles andere wird auf quadratische Länge gestretcht (hier auf 512 x 512). Oder kann man für eine Seite jede 2er Potenz wählen, unabhängig von der anderen Seitenlänge?

Das dachte ich zu Anfangs auch. Dem ist aber nicht so. Wichtig ist nur, dass die Seitenlängen eine Potenz von 2 sind. Ich könnte mir durchaus auch vorstellen, dass es evtl. irgendwo diverse OpenGL implementationen gibt die damit Probleme hätten. Aber diese Anzahl sollte wenn überhaupt verschwindent gering sein.

Ich glaub bei nem Quake 1 Shader Manual oder irgendwas in der Art, hab ich mal was gelesen das es ein Risiko ist rechteckige Texturen zu verwenden weil sie bei manchen älteren (heutzutage uralten :-) Grafikkarten nicht gehen könnten, seit Quake 2 steht jedoch drinnen: "Is kein Problem". Und der wirds schon wissen was er so von sich gibt :-).

es müssen nur beides 2erPotenzen sein, egal ob quadratisch oder rechteckig