Hallo!

Habe letzten Monat versucht Videostreaming in OpenGL auf PBOs umzustellen und musste leider nach vielen Versuchen festellen, dass der folgende Code SEHR langsam auf ATI Karten läuft (ein HD-1920-Frame wird in 100-200ms übertragen).
NVIDIA Karten führen das Ganze aber sehr schnell + asynchron aus (<1ms).


Der problematische Teil des Ganzen scheint das anschließende Textur Update per glTexSubImage2d() zu sein. Kommentiert man diesen Teil aus, läuft der obige Code auch auf ATI Karten mit gleicher Performance wie NVIDIA.

Meiner Meinung nach scheint ATI's internes Texturformat nicht kompatibel mit GL_RGBA, GL_UNSIGNED_BYTE zu sein, weshalb wahrscheinlich der übertragene Buffer wieder zurück in den CPU RAM kopiert, konvertiert und wieder in den VRAM geladen wird.

Habe deshalb auch schon viele Kombinationen durchprobiert (inkl. glPixelStore). Leider ohne Erfolg.

Bisher habe ich immer auf ATI Systeme gesetzt, aber bei der bisherigen Informationspolitik liegen Welten zwischen NVIDIA und ATI.

Weiss irgendwer Rat??

Hast du eine möglichkeit, GL_BGRA zu verwenden? Grafikkarten verwenden eher dieses Format.

Gruß Lord Horazont

_________________
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

Mit der Umstellung auf GL_BGRA, kann man tatsächlich noch ein paar Millisekunden gewinnen. Unglaublicherweise halbiert man damit bei NVIDIA fast die Update Zeit nochmal.
Bei ATI gibt es aber keinen signifikaten Unterschied. Habe außer GL_BGRA auch nochmal die ATI spezifischen Formate GL_RGBA_FLOAT32_ATI / GL_RGBA_FLOAT16_ATI durchprobiert (dann auch GL_FLOAT anstatt GL_UNSIGNED_BYTE).

Bzgl. des Textur Formates kann ich eigentlich jeden Input vertragen, da ich sowieso noch eine Farbkonvertierung durch ein selbst geschriebenes Fragment Program von YUY2 oder YV12 nach RGB32 vornehme (Diese kommt aber erst im Anschluß an den Transfer und verlangsamt den Transfer Prozess nicht)

Denke mir aber mal, dass mehrere Leute schon mal ein PBO genutzt haben. Finds erstaunlich, dass bzgl. ATI noch kein Forumbeitrag gepostet wurde -> heißt ja im Umkehrschluss, dass es irgendwie gehen muss...

Also mit PBO habe ich noch nichts gemacht nur was gelesen. Was ich aber bei ATI definitiv weiß ist, dass solche Format wie GL_RGB (24Bit) doch schon einige Zeit benötigen. Also beim normalen Texturupload. Und die PBO-Unterstützung hat ATI erst vor nicht alzulanger Zeit in die Treiber eingebaut.

Aber mal ein Paar Sachen die du evtl probieren könntest.
1. Die Textur direkt zerstören und neu erstellen. Und dann glTexImage benutzen. Und ein 32 Bitiges Format.

2. PBOs sind Asynchron. Es kann auch sein, dass die Befüllung des Buffers länger dauert. Und eine ATI Karte deswegen etwas länger warten muss bis es die Daten in die Textur übernehmen kann. Bzw war in der Spezifikation der PBOs auch ein Beispiel enthalten wie man Asynchron den Bildschirminhalt auslesen kann. Und so kann man unter Umständen schon ein wenig Zeit einsparen.

So habe nochmal die gesamte Prozedur zerlegt.
Der Transfer der Pixeldaten läuft asynchron und ohne nennenswerte Leistung der CPU. Habe dies mit dem Process Explorer überprüft.

Hierfür habe ich desweiteren das Texturupdate wie oben gepostet auskommentiert und an anderer Stelle wieder implementiert. Vor dem Aufruf von glTexSubImage2d lege ich den aktuellen (und einzigen) Thread für 100ms schlafen, um alle eventuellen Memory-Transfers beenden zu lassen. Nehme danach ein "normales" Texturupdate vor:




PBO binden, Texture binden, Update...
(Habe für Ftarget GL_TEXTURE_2D, als auch GL_TEXTURE_RECTANGLE_ARB, POT und NPOT Auflösungen probiert)

Das Update überprüfe ich mit QueryPerformanceCounter und stelle auch hier wieder fest: Der Treiber blockt und braucht extrem lange für glTexSubImage2D; CPU Last hoch.
Ist das noch niemandem aufgefallen?

Die Implementation habe ich nach OpenGL (opengl.org) Spezifikation durchgeführt.