Sehr schnelle Texturupdates (OpenGL)

[Kr0e]

Hallo,

ich schreibe zur Zeit einen OpenGL Video Renderer. Ich bin soweit fertig und nutze den Pixelbuffer um DMA (Direct Memory Access)
zu benutzen. glTexSubImage2D wäre sonst viel zu langsam. Bei HD Videos kann es vorkommen, dass 260 mb / s übertragen werden müssen... Nun habe ich aber gelesen, dass der Pixelbuffer1. sehr veraltet ist und 2. nicht mehr weiterentwickelt wird.

Gibt es irgendeine Alternative zum Pixelbuffer ?

Ich kenne zwar den Framebuffer, der wohl um einiges besser Render-To-Texture machen kann... Aber ich glaube nicht, dass
es dort dieses Feature (DMA) noch gibt.

Ich habe leider wenig Ahnung was die neuen Technologien von OpenGL betrifft.
Gibt es da inzwischen vlt effizientere Methoden ?

Gruß,
Chris

 

[Guest2]

Moin,

willkommen in der allgemeinen OpenGL Namensverwirrung.

Unter dem Begriff "Pixelbuffer" laufen bei OpenGL eine Reihe von völlig verschiedenen "Dingen". Wenn Du schreibst "veraltet" und "nicht mehr weiterentwickelt" bezieht sich das vermutlich auf den "PBuffer". Dieser ist tatsächlich alt und ich würde diesen auch nicht mehr in aktuellen Projekten einsetzen. Allerdings unterstützt dieser auch imho kein DMA.

Wenn Du "Pixelbuffer" in Zusammenhang mit DMA schreibst, meinst Du vermutlich "Pixel Buffer Object (PBO)". Das war früher eine Extension, gehört aber schon seit OpenGL 2.1 fest dazu. Auch in der aktuellen GL4.0 Core Spec wird dieser unter den allgemeinen "Buffer Objects" als "PIXEL_PACK_BUFFER" und "PIXEL_UNPACK_BUFFER" geführt. Von "veraltet" oder "nicht mehr weiterentwickelt" kann da also keine Rede sein.

Wenn in Deinem Quelltext also "PIXEL_PACK_BUFFER" oder "PIXEL_UNPACK_BUFFER" vorkommt, besteht kein Grund zur Sorge. Und wenn Du eine Lösung hast die für Dich funktioniert, solltest Du diese vermutlich auch nicht ändern.


Ähnliche Verwirrung gibt es übrigens auch beim Begriff "Framebuffer". Wobei ich aktuell nicht weis, ob Du

a: deine "Bilder" per OpenGL erzeugst und dann "wegstreamen" willst, oder
b: deine "Bilder" per Stream kommen und Du diese per OpenGL darstellen willst.

Hier hatte ich Dich so verstanden, dass Du a willst. Hier klingt das ehr als ob Du b willst. Wenn Du nämlich b willst, ist das kein "Render to texture" sondern ehr das Gegenteil davon. Bei b würde Dir das "Frame Buffer Object (FBO)" demnach nur bedingt nutzen.

Gruß,
Fancy

 

[Kr0e]

Danke, dass du mir diese Namensunterschiede mal erklärt hast ... Ich dachte immer PBO und Pbuffer wäre das Selbe...
Ich wollte in der Tat a).

Vielen Dank

PS: Wo ich grad dabei bin ein paar Fragen zu klären... Was genau bedeutet eigentlich dieses ARB in der Namensgebung der Funktionen vom PBO ? DAs war mir irgendwie auch nie klar..

 

[Guest2]

ARB steht für "Architecture Review Board".

Das ganze hängt mit dem Lebenszyklus einer Extension zusammen. Angenommen NVIDIA oder ATI "erfinden" für ihre neuen Grafikkarten eine ganz neue Funktion. Damit diese dann auch von den Entwicklern genutzt werden kann, wird eine OpenGL Header Datei ausgeliefert, in der die neue Funktion deklariert ist. Und zwar mit dem Herstellerspezifischen Suffix (NV für NVIDIA und ATI für ATI ). Einigen sich nun mehrere Hersteller darauf, das die Extension ganz toll ist, ändert sich das Suffix zu EXT. Findet das ARB die neue Funktion nun auch ganz toll, wird EXT zu ARB. Entscheidet das ARB später das diese Funktion zum OpenGL Standard gehören soll, wird das Suffix entfernt. Die Letzte Stufe ist, das das ARB die Funktion für nicht mehr aktuell hält (depricated) und sie anschließend wieder aus dem Standard streicht (das ist seit GL3 neu). Das Suffix wird dann wieder zu EXT.

Der Lebenszyklus einer Extension ist dann einfach:

NV/ATI -> EXT -> ARB -> Core -> EXT


Da das PBO schon sehr lange fest dazugehört, solltest Du vermutlich auch problemlos die nicht ARB Funktionen nutzen können (und solltest auch). Z.B. glMapBufferARB() wird dann zu glMapBuffer().

Gruß,
Fancy