Hallo.
Nehmen wir an ich will eine wirklich große Texture von, sagen wir erstmal 1024x1024 px, als Hintergrund für mein Fenster haben. Wie stelle ich das möglichst performant an? Wenn ich die Textur in jedem Frame neu binde, müssen dann nicht unnötigerweise Daten über den Bus geschickt werden? Oder ist das das normale Vorgehen?
Ich würde sonst gerne den gesamten Pixel kram so halten, dass ich nichts mehr transportieren muss. Mehr als einen Hintergrund hat man ja nicht.

Normalerweise lädst du die Textur nur einmal beim Programmstart in den GRAM und das Binden... das ist ein Integer der jeden Frame gesendet wird. Da kannst du nur durch sortieren ein bisschen Performance noch raushauen. Aber SOOO viel ist das nicht ^^

Das klappt natürlich nur für kleine/mittelgroße Anwendungen. Wenn du die Textur nicht mehr brauchst kannst du sie löschen um Speicher auf der Graka freizukriegen und dann wieder hochladen - aber dafür gibt es dann einen Ladenscreen

Ansonsten gäbe es noch Textur-Streaming, oder so ähnlich - kenn ich aber nicht genau ^^

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Ok. Aber sagen wir ich habe einen Textur von 2048x2048px. Das ist ja schon recht gewaltig. Wie kann man hierbei Speicher einsparen?
Ich dachte daran, dass ich die Pixel nicht in eine Texture packe, sondern in einen neuen Framebuffer lade und dann nur diesen zeichne. Wäre das nicht besser/performanter? Texture speicher ist ja auch begrenzt afaik.

Auch ein Framebuffer muss irgendwo liegen und liegt auch im gleichen Speicher wie die Texturen.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Vielen Dank.

Nun, zunächst ist eine einzelne 2048er Textur nicht viel. Das sind gerade mal 12 MB bei RGB. Wozu hat eine Grafikkarte wohl ~1 GB GRAM? Solltest du auf Mobile oder ältere Hardware zielen sieht die Sache natürlich anders aus.

Eine Option könnte Hardware-Texturkompression sein. Sofern die Hardware das kann ist das sehr flott oder zum Teil sogar schneller zu rendern als die unkomprimierte Textur. Allerdings leidet die Bildqualität stark, insbesondere werden die Farben auf 16bit reduziert.

http://wiki.delphigl.com/index.php/DDS
http://en.wikipedia.org/wiki/S3_Texture_Compression

Die OpenGL-Erweiterung GL_EXT_texture_compression_s3tc sollte dir helfen.

_________________
Yeah!

Ja u.a. Mobilgeräte.
Danke.

Äh, in dem Fall...die Mobilegeräte haben eigene Kompressionsformate:
http://stackoverflow.com/questions/9148 ... ompression
https://developer.apple.com/library/ios ... eData.html
(habe da wenig Ahnung, wir nutzen Unity3d wo das alles mehr oder weniger automatisch geht)

_________________
Yeah!

Thread Hijack: Kann jemand, der sowas zur schnellen verfügung hat, mal ein paar Beispielvergleichsbilder erstellen und die in unser Wiki und auf Wikipedia packen? Wäre awesome!

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Schnell - nein.
Wenns in absehbarer Zeit aber nicht da ist - bestimmt.
Brauch noch etwas Zeit ([/mad an]scheiß Java [/mad aus]) das Zeug zum Laufen zu kriegen

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Im Netzt findet man einige Vergleiche, kommt immer auf das Kompressionsverfahren an.
Für OpenGL gibt es Hardware mässig DXT1,3,5, ATI1/2(für kompresssion von Normalmaps 2Komponenten) für so ziemlich alle Intel, NV und AMD Karten.
Dann gibt es noch diverse Hacks dieser Formate und Kombinationen, z.B. DXT5 wo man in Alpha Luminance und in G und B Chrominanz Red und Chrominanz Blue packt, dann das gleiche noch mit einem 2 Bit scale im R Kanal(YCbCr+correction).
Humus hatte mal noch Cb und Cr in ATI2 und Y in DXT1 verpackt, dann gibt es noch ein paar neue Formate mit den OpenGL 4.4 Fähigen Karten und für Mobile gibt es noch ETC, bei Apple PVRTC und ARM ASTC.
Da allerdings alle nur S3TC, also DXT1,3,5 aka BC1,3,5(ja MS mag keine Standards, lieber das gleiche anders nennen) gemeinsam können sind diese nahezu die einzig genutzten.
Der größte Vorteil dieser 3 Formate ist, dass diese per Hardware laufen und kein weiteren Overhead produzieren, während die Erweiterungen auf diesen, teilweise kleine Overheads haben, z.B. YCbCr zurück nach RGB Color Space transformieren.
Diese Formate sind aber auch wesentlich schneller als Raw Textures, da diese 16 Texel mit einem fetch, statt 1 pro fetch machen(weil 4x4 pixel pro 1 bzw. 2Byte kodiert sind).
Wenn nun der nächste Texel benötigt wird, dann liegt er im Cache aber nicht bei Raw und deswegen ist das um einiges schneller.

Man sollte also auch komprimieren, wenn man noch genug Speicher zur verfügung hat.
Dies beste Qualität hat bisher YCbCr in einer DXT5 verpackt.
Ich hoffe allerdings, dass sich ASTC oder ein recht ähnliches Verfahren etabliert, dann kann man per Regler die Qualität und Kompressionstärke fest legen.

Edit:
Unity3D tut für Apple PVRTC benutzten und sonnst DXT1 und 5, bzw. RAW für render Targets und luminance Bilder.

Zum Thema Texturgröße sag ich mal folgendes, der Ladeprozess wird länger dauern aber die FPS leidet nicht drunter, da OpenGL die passende Mipmapstufe errechnet und auf dieser dann mehrere Texel lädt.
Es kommt immer auf die Sicht der Kamera an, wenn die Kamera auf eine 2048^2 Textur schaut und diese nicht Flächedeckend ist, dann wird bei 1024x768 maximal die 1024^2 Mipmapstufe genutzt, geht man näher dran, dann die 2048^2 MipMap-Stufe und weiter weg dann vieleicht eine 4x4.
Wenn man S3TC verwendet, dann gibt es als kleinste Mipmap-Stufe nur 4x4, selbst wenn nur ein Texel sichtbar ist, nutzt er die 4x4 Stufe, da ja 4x4 Blöcke in ein Texel kodiert sind. Hier kommen wir dann zum 2. wichtigen Punkt.
Es gibt Texturfilter und diese laden mehere Texel für ein Pixel und interpolieren ein Farbwert.
Dies ist der Grund, wieso Texturen verwaschen aussehen, wenn man diese 1zu1 im Ortho Modus rendert, hier stellt man den Filter üblicherweise auf Pixel und dann wird auch wirklich nur ein Texel geladen und nix Interpoliert.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004