glCopyTexImage zu lahm

[Matti]

Gibt es Möglichkeiten, glCopyTexImage irgendwie zu beschleunigen? Oder kann man den Viewport auch direkt in eine Textur setzen, so daß man gar nichts mehr kopieren muß?

[Abe Ghiran]

Hi!
Also ich benutze hier glCopyTexSubImage2D(), das funktioniert bei mir prima (Matrox Parhelia). Die Framerate halbiert sich zwar fast (logisch, weil ich erst einen frame in die textur render und danach den "richtigen" frame) aber das kopieren selber merkt man nicht - ganz im Gegensatz zu einem screenshot, wo ich mit glReadPixels() aus dem Buffer lese.

In ein Bitmap zu rendern sollte gehen, dann muß man aber wohl einen extra render context dafür anlegen und im PixelFormatDescriptor PFD_DRAW_TO_BITMAP als Target angeben. Frag mich aber nicht wie das im detail funktioniert, ich habe das noch nie gemacht.

Grüße, Jan

[Matti]

Original geschrieben von Abe Ghiran
Hi!
Also ich benutze hier glCopyTexSubImage2D(), das funktioniert bei mir prima (Matrox Parhelia). Die Framerate halbiert sich zwar fast (logisch, weil ich erst einen frame in die textur render und danach den "richtigen" frame) aber das kopieren selber merkt man nicht - ganz im Gegensatz zu einem screenshot, wo ich mit glReadPixels() aus dem Buffer lese.

Ich hab ne Voodoo3. Könnte es vielleicht an den Treiber liegen? Daß die Voodoo3-Treiber nicht für solche "Spielereien" wie Render-to-Texture ausgelegt sind?


Original geschrieben von Abe Ghiran
In ein Bitmap zu rendern sollte gehen, dann muß man aber wohl einen extra render context dafür anlegen und im PixelFormatDescriptor PFD_DRAW_TO_BITMAP als Target angeben. Frag mich aber nicht wie das im detail funktioniert, ich habe das noch nie gemacht.

Grüße, Jan
nein, das meine ich nicht. Ich meine, den Viewport direkt in eine Textur im Graka-RAM legen...

[Abe Ghiran]

Sorry, da bin ich jetzt überfragt.

Bei einer Voodoo 3 könnte ich mir allerdings ganz gut vorstellen, daß da der Treiber nicht ganz mitspielt und / oder memory transfers zwischen Textur- und Bildspeicher nicht optimiert wurden.

Das einzige was mir noch einfällt, wäre mal mit den ganzen Attributen zu experimentieren die die Pixeltransfers beeinflussen (GL_UNPACK_ALIGNMENT, etc, die sollten ja glCopyTexXXX auch beeinflussen), vielleicht schmeckt da der Voodoo3 irgendetwas nicht.
Allerdings kann man da ja wohl nicht viel ausrichten, da das alignment des Colorbuffers ja wohl festlegt ist (ich denke mal du benutzt 32bit = 4byte, das sollte ja auch kein Problem sein) aber vielleicht kannst du bei der Textur in die du den Framebuffer kopierst was machen.

Grüße, Jan

[Melle@work]

Voodoo3->MaxColorBits = 16;

Aber das nur am Rande, darum ging ja hier net wirklich. ;)

[Matti]

das ist mir schon klar, aber wenn ich vom 16-Bit-Frame-Buffer in eine 16-Bit-Textur kopiere, kanns doch nicht so lahm sein...
...eigentlich muß doch gar nichts umgewandelt werden.


EDIT:
in der OpenGL-Doku steht, daß bei CopyTexImage auch die Einstellungen von PixelStore und PixelTransfer verwendet werden (ich glaube die Funktionen heißen so, bin mir jetzt nicht so sicher). Das würde bedeuten, daß aus dem 16-Bit-Wert 3 Float-Werte gemacht werden, die werden mit Red/Green/Blue-Scale multipliziert, auf 0..1 zurechtgeschnitten und dann wieder in einen 16-Bit-Wert umgewandelt.
Kann es sein, daß neue Grafikkarten, wenn Red-, Green und Blue-Scale = 1 sind, die Textur direkt kopieren, und daß die Voodoo3-Treiber diese Optimierung nicht haben?? Oder gibt es eine Möglichkeit, PixelStore und PixelTransfer zu deaktivieren??

[zeckensack]

Die Konvertierung nach Float und zurück beschreibt nur die logische Funktionsweise. Wenn Zielformat==Quellformat, dann kann dieser Schritt komplett entfallen, auch bei unterschiedlichen Integerformaten läßt sich dieser Prozeß Spec-konform rein auf Integeranweisungen reduzieren.

Pixeltransfer kann man nicht abschalten. Wenn man bestimmte States setzt, dann verhält es sich aber genauso als wäre das abgeschaltet.
Unpack-Alignment auf 0, Pack-Alignment auch,
Skip-Zeug alles auf 0, etc. (<=ist default)

Alle Bias-Werte auf 0, alle Scales auf 1 (<= beide default).

Ich befürchte vielmehr, daß die V3-GL-Treiber rotz sind :spock:

[Matti]

Original geschrieben von zeckensack
Unpack-Alignment auf 0, Pack-Alignment auch,


ist das per Default schon 0?
Ich verwende die Default-Werte, aber wenn es per Default nicht 0 ist, würde es ja mein Problem erklären...

[Abe Ghiran]

Laut redbook haben beide als default den Wert 4.

Grüße, Jan

[Matti]

...bringt auch nichts. Liegt wahrscheinlich doch an den Treibern...

Nur wegen einer 256x256-Textur kopieren komme ich auf 10 FPS. Wenn ich diese eine Zeile mit dem CopyTexImage auskommentiere hab ich 40 FPS.

[traexx]

was hast du sonst für nen PC? Probier mal das kopieren ohne jedesmal danach den Buffer zu flushen ;) Aber es ist eh das Problem, das man jedesmal das Bild aus dem RAM in den Videospeicher transferieren muss -> lahm (Bei mir 1:3 gegenüber Texturblitting) :( Obwohl das bei deinen 128 kb zum kopieren eigentlich kein Problem sein dürfte o.O

tja, für ne Voodoo 3 gibts garantiert keine aktuellen Treiber mehr :/

[Matti]

liegt an den Treibern. Ich habs grad auf ner 9700 getestet, und da läufts mit 270 FPS und bei auskommentiertem CopyTexImage mit 290 FPS.

[traexx]

Original geschrieben von Matti
liegt an den Treibern. Ich habs grad auf ner 9700 getestet, und da läufts mit 270 FPS und bei auskommentiertem CopyTexImage mit 290 FPS.

was wirst du jetzt machen?

[Matti]

Original geschrieben von traexx
was wirst du jetzt machen?
wie meinst du das?
Ich muß mich eben damit abfinden, daß OpenGL-Programme, die glCopyTexImage verwenden, auf ner V3 mit max 10 FPS laufen...