   FBO versus glCopyTexSubImage2D
  Hi all, I used to render my textures in openGL by rendering to the normal framebuffer. When rendering was done I would copy the data to my texture using glCopyTexSubImage2D.Then there were framebuffers, it was my understanding that I could eliminate a copy instruction by using them.first it was:render to framebuffer -> copy framebuffer to other texture -> renderusing framebuffers I can do:render to texture -> renderThis should use less vmem and could do without a copy, so it should be faster...wrong!I created a program to test these results, either I am doing something wrong, or I am missing the point of framebuffers..here's the code / win32 exe ( http://www.arjanhouben.nl/FBOtest.zip )You can use the 'y' and 'n' buttons to turn on/off the use of framebuffers over the old method. The bar in the middle gives an indication of the amount of fps.I hope you can shed some light on this!- Arjan   
  Well, I'm pretty sure it should use exactly the same amount of memory because you'll always have a frame-buffer and a texture being rendered to. It should be faster, and generally is (even if only by a small amount), but that's not guaranteed. It depends on the driver's FBO implementation, and the hardware it's running on.What texture format are you rendering to, and what card are you running it on?   ;  All it does is render a large red square and a small square on the red square. I didn't see any kind of performance information.   ;Quote:Original post by ArjanHThis should use less vmem and could do without a copy, so it should be faster...wrong!It'll only be faster if the copy was the bottle neck in your problem; if your application is trival and/or the bottleneck is elsewhere then it won't help.FBOs however are generally a better solution as they don't involve writing and clearing the framebuffer multiple times which is a plus when you are doing more than one RTT thing; they can also allow you to render to floating point textures which is something you can't do with the default framebuffer.;Quote:Original post by iNsAn1tY[...]It should be faster, and generally is (even if only by a small amount), but that's not guaranteed.[..]Well, on the Nvidia cards I have tested 7900GS, 8800GT, quadro 3500 something, the results were the same. FBO never reached above ~800fps while the version without the FBO could render up to ~5000fps or more on the 8800... pretty dramatic differencesQuote:Original post by V-manAll it does is render a large red square and a small square on the red square. I didn't see any kind of performance information.I wanted to write an example which would focus at the problem, so the example is very basic.Since I am not interested in absolute performance, there is no performance counter, FPS is being measured though. The bar in the middle should give a good performance indication. The wider the bar > more FPS.by pressing y/n you can choose if you are using the FBO or not.Quote:Original post by phantomIt'll only be faster if the copy was the bottle neck in your problem; if your application is trival and/or the bottleneck is elsewhere then it won't help.FBOs however are generally a better solution as they don't involve writing and clearing the framebuffer multiple times which is a plus when you are doing more than one RTT thing; they can also allow you to render to floating point textures which is something you can't do with the default framebuffer.I tend to agree with you on the bottleneck issue, what remains is the fact that there is quite a huge performance difference while FBOs are designed to be _the_ solution for RTT, that just doesn't seem right to me..   ;  The thing is, your numbers are meaningless; 800fps vs 5000fps is frankly unimportant. 800fps is a render time of 0.00125 seconds, 5000fps is 0.0002 that is a difference of 0.001 seconds (or 1 millisecond). That is nothing, if you consider at 60fps it takes 0.016 seconds to render (16 milliseconds), the reason for the change in fps is that instead of copying data you have to bind an FBO which requires some internal state changes. Once you have a 'real' program behind it those changes will be dwarfted by other issues.;  So if I hit y, the bar is larger and if I hit n, the bar is shorter.y means use FBO?   ;Quote:Original post by phantomThe thing is, your numbers are meaningless; 800fps vs 5000fps is frankly unimportant. 800fps is a render time of 0.00125 seconds, 5000fps is 0.0002 that is a difference of 0.001 seconds (or 1 millisecond). That is nothing, if you consider at 60fps it takes 0.016 seconds to render (16 milliseconds), the reason for the change in fps is that instead of copying data you have to bind an FBO which requires some internal state changes. Once you have a 'real' program behind it those changes will be dwarfted by other issues.this is offcourse true, but the reason I started investigating this in the first place, is that my performance decreased when I implemented FBO instead of glCopyxx.My program uses a lot of FBOs, there can be as much as 63 FBOs in use. In theory at least. In practice this number is never reached because the performance collapses if a certain number is reached, my guess is that the vmem is allocated and the card starts eating system mem.This is the main reason why I am still using glCopy over FBOs. The other reason is that below the failure point, the performance just isn't better, in fact FBOs are in all cases slower in my app.This seems odd to me, that why I started this thread :)Quote:y means use FBO?jup, I've just compiled the program on my home (linux) computer and even though the differences are marginal, the FBOs seem to be the winner here. (Nvidia 7600GT);  Same here y gives me a longer bar. If it means red is FBO, than there is a quite a large difference in performance on my machine. Im on ATI X1600.phantom : While i understand that the fps he gave doesnt mean much, the point i think he is trying to make is that, if the state changes of a FBO takes up more time than than a framebuffer copy to texture, why even use it in the first place regardless of how complicated a scene is. The FBO method is just going to take up more time than a framebuffer copy anyway regardless of scene complexity.[Edited by - GamerSg on April 17, 2008 3:15:01 PM];  performance wise theres not much difference between CopyTexSubTetxure + FBO from memory last time i checked (a couple of years ago under nvidia CopyTexSubIMage was a bit quicker but this is perhaps different now)FBOs have the great luxury of not being restricted to the main windows dimenssions/pixel format etc   