Evtl. nutzt ja hier der ein oder ander schon die recht frischen Framebufferobjekte für RTT und kann was dazu schreiben. In Projekt "W" rendere ich recht oft in eine Textur, und das bisher über Pixelbuffer, die ja aufgrund des Kontextwechsel relativ langsam sind und zudem auch kein Mipmapping unterstützen. Jetzt hab ich kurzerhand mal FBOs angetestet, und die FBOs sind bei gleicher Ausgangslage (als es wird immer das selbe gerendert) immer langsamer.

Bei meinen Tests mit einer 3D-Ansicht der Region die via RTT dann in der GUI des Spiels angezeigt wird hab ich mit PBuffer >150 FPS, mit FBO ohne Mipmap ~120 FPS und bei FBO mit autom. Mipmap-Generierung nur schlappe 75 FPS, wobei FBO und Pixelbuffer jeweils die gleiche Größe haben (1kx1k).

Kanns also sein dass FBOs noch recht langsam sind, oder liegts evtl. mal wieder daran dass ich nen 90er Release-Treiber (Graka iss ne 7900GS) nutze die ja nicht grade Bugfrei sind? FBOs wären mir natürlich lieber, da ich u.a. Gebäude isometrisch darstelle und sowas für Aliasing sehr anfällig ist, weshalb ich dann schon gerne RTT mit automatischer Mipmap-Generierung hätte.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi ...

also das wundert mich ehrlich gesagt.
Ich habe damals wegen des Tutorials im Wiki mit Pixelbuffern angefangen für mein Shadow Mapping. da kam ich bei meinem aktuellen Projekte auf ~90-100 FPS. Der spätere Umstieg auf FBOs hat mich auf ~120-130 FPS hochgeschossen, also schon eine extreme Steigerung.
Und ich könnte mir auch keinen Grund bei anständig implementierten FBOs vorstellen, warum sie langsamer sein sollten als Pixelbuffer, da sie ja keinen Contextwechsel benötigen, was beim Pixelbuffer ja das größte Problem war.
Und ich versteh zwar nicht so viel von der technischen Realisierung solcher Extensions, aber dennoch halte ich es für logisch, dass die Graka selber ziemlich schnell zwischen den Buffern wechseln kann, immerhin wird kein ganzer context getauscht sondern nur der Framebuffer ...

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Welchen Treiber (die 90er Reihe hat leider einige Bugs) nutzt du, und auf welcher Hardware? So langsam glaube ich, dass Pixelpuffer bei mir so schnell wie FBOs sind weil NVidias OpenGL-Treiber ja auch mehrkernoptimiert sind (hab nen X2 4200+), und dadurch etwaiger CPU-Overhead durch die Kontextwechsel (ich denke mal dass hier die CPU zumindest teilweise ine Rolle spielt) auf einem Mehrkernprozessor wegfällt (und damit auch der Vorteil der FBOs). Was man auch nicht vergessen darf : Durch den eigenen Kontext eines Pixelpuffers fallen ggü. FBOs je nach Szene auch diverse Statechanges wegen, zumindest in meinem Falle. Man muss kann Matrizen pushen, keinen Viewport wechsel, etc. Vllt. liegts mitunter auch daran.

Die paar FPS bei normaler Umstellung wären mir ja eigentlich egal (allein schon weil FBOs viel bequemer zu nutzen sind), aber ich bin wie gesagt nur auf FBO gewechselt damit ich automatische Mipmap-Generierung habe, die ich aufgrund von starker Kantenbildung bei z.B. ner Gebäudevorschau unbedingt haben will. Und sobald ich die nutze wirds dann stark langsamer, für meinen Geschmack leider zu stark.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi ...

in den hw-eigenschaften meiner graka steht treiberversion 6.14.10.9371. Keine ahnung zu welcher Serie der gehört, steht da nirgends (oder doch???) ... sollte aber neuer sein, da ich das system ziemlich neu aufgelegt habe (vor knapp über nem monat) ...
Ich hab ne GF 6600GT ...

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Wie benutzt du die FBOs eigentlich? Also in welcher Reihenfolge würde mich mal interessieren. Um ein wenig Licht ins Dunkel zu bringen worauf ich anspiele. Ich weiß nicht ob die Grafikkarte da auch so ähnlich arbeitet wie sie es bei PixelBufferObjects tut. Aber dort hatte ich in einem Document von NVidia etwas recht interessantes gelesen. Und zwar beschleunigtes Auslesen eines Bildes mittels PixelBufferObjects.

Im großen und ganzen ging es darum, das man anstelle eines PBOs zwei benutzt hat. Man hat den Ersten angeworfen direkt danach den Zweiten. Dadurch das die Karte das asynchron liest waren Teile des ersten PBOs schon gelesen. Wenn man jetzt auf den ersten PBO zugegriffen hat musste gewartet werden bis alles fertig ist und das hat aufgrund der halben Größe auch nicht so lange gedauert. Und wärend dann die Daten gelesen wurden konnte der zweite Buffer im Hintergrund gefüllt werden. Und man konnte ohne Warten auf diesen dann zugreifen.

Da MipMaps nun mal eine gewisse Zeit zum Generieren benötigen könnte ich mir also vorstellen, dass denen eine kleine Pause können solltest. Also wenn Möglich nicht sofort nach dem Erstellen dann benutzen sondern evtl erst noch andere Sachen erledigen. Ist aber nur eine wüste Theorie! Eigentlich sollen die Karten aber asynchron arbeiten. Immer unter der Vorraussetzung, das dem nicht bereits schon so ist.

Ich weiß aber nicht mehr wo ich das mal gesehen habe. Könnte in dem VBO Dokument sein. Bin mir da aber gerade alles andere als sicher.

PS: Shaijan: Aufgrund der Versionsnummer würde ich tippen, dass du einen 93.71er Treiber hast.

Die PBOs werden nur dann gebraucht wenn man eine Textur als Vertexstream benutzen will (Bald eh unsinnig) oder etwas von der Grafikkarte zurückl zu CPU transportieren will. Ansonsten kann man die PBOs erst mal vergessen. EIne eventuell mögliche variante ist noch das hochladen von texturen, aber das macht auch nur Sinn wenn man die dynamisch nachladen muss.

Mein Hauptaugenmerk lag auf der ASynchronität der Aktionen die die Grafikkarte durchführt. Und nicht auf den PBOs.

Aber wenn alles auf der Grafikkarte bleibt muß gar nicht zwischen CPU und GPU synchronisiert werden.

In meinem Anwendungsfall rendere ich die 3D Ansicht in das FBO, und rufe es danach auch direkt ab (und erstelle somit auch die autom. Mipmaps). Das geschieht alles in den Callbacks meiner GUI fürs Rendern der jeweiligen Fenster, und eine andere Reihenfolge ist nicht möglich, zumal ich nur ein FBO nutze dass ich dann mehrfach verwende. Und da die Fenster auch noch teilwese transparent sind muss ich direkt in diese Callback auch die gerenderte Textur ins Fenster zeichnen.

Aber da ich ja nichts von der GPU auslese sollte es eigentlich keine Rolle spielen wann ich die Mipmaps automatisch generieren lassen. Klar dass dies etwas dauert, aber automatisches Mipmapping hab ich auch schon für normales RTT genutzt (über die SGIS-Erweiterung, Name ist mir grade entfallen), und da ist der Geschwindigkeitseinbruch nicht so stark. Vorerst werde ich also weiter bei den Pixelpuffern bleiben und da dann halt AA über dieses umständliche WGL_EXT_multisample implementieren, dann brauch ich die Mipmaps zur Kantenreduktion wohl nicht mehr.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

So richtig schlau werd ich da doch nicht draus, erst recht nich nachdem was ich jetzt gemacht hab. Ich hab jetzt Mipmapping für den PBuffer aktiviert (WGL_MIPMAP_TEXTURE_ARB = GL_TRUE) und erstelle dann die Mipmaps von Hand über GL_GENERATE_MIPMAP_SGIS. Und was passiert? Trotz automatischer Mip-Map Generierung des eigentl. eh schon langsameren PBuffers (und es funktioniert, Kanten adé) verleire ich ggü. PBuffer ohne Mip-Maps maximal 3-5 FPS, bin damit also sehr viel schneller (bis zu 75%) als bei FBOs mit automatischen Mip-Maps.

Wie gesagt sehr sehr komisch, evtl. liegts aber auch an der Treiber und Hardware-Kombo dass die FBOs verlgeichsweise langsam sind. Bleibe ich also bei PBuffer + GL_GENERATE_MIPMAP_SGIS.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi ...

um ein wenig mehr Klarheit zu bekommen, kannst du ja mal eine kleine Demo zusammenstellen (nicht unbedingt von deinem Projekt, wenn dus noch nicht zeigen möchtest) mit PBOs und FBOs, dann könnte man vergleichen ...
aber wäre auch nur extra aufwand, wenn die PBOs so gut bei dir laufen ...

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Die PBuffers bitte nicht mit PBO abkürzen, denn die PBOs sind was völlig anderes