I have been using FBO’s for awhile now and have come to the conclusion that speedwise its the same as glCopyTexImage… Only thing I guess I have gained from this is the ability go larger than my screen size for my engine. I was wondering if everyone else who is using FBO’s are seeing the same thing or not. I am on a 7800GT, Athlon64 X2 3800+. I have tried using mipmaps and found that not using mipmaps actually gave me a speed boost around 3-5fps…
Not using mipmaps means that it reads the texture one time fewer per texture lookup, this in turn translates into better fps, but you loose a lot of visual quality unless render the texture in a 1:1 ratio to the screen.
But 3-5 fps might not be a lot depending on your base FPS.
You could allso try using nearest texture filtering.
There is an advantage of using glCopySubTexImage (I don’t know but maybe glCopyTexImage works the same as glCopySubTexImage on nVidia) compared to FBO. You can have stencil and depth can be 24 on ATI.
I have tried using mipmaps and found that not using mipmaps actually gave me a speed boost around 3-5fps
It doesn’t need to generate the mipmaps, so it’s faster, but you lose FPS if your scene can benifit from mipmaps (texture cache)
Like if you are doing a normal mapped dynamic water surface, in the distance, it can benifit from mipmaps.
I’ve got pretty much the same result when rendering to a normal texture. But of course if you need such things as MRT and float render targets, you have to use FBO.
V-man, I don’t seem to be able to get 24bit depth with ATI (only a 9600 pro though) wether I’m using FBO or copyteximage. Humus replied to an earlier thread regarding sampling depth textures, stating that we’re getting 16-bit depths (correcting my assumption that we’re getting 8-bit depths).
What card are you using, do you have an example of 24 bit access?
Humus told me that all x800 series and before max at 16bit, now the x1000 series not all have 24bit either. x1600, x1900 do for sure, but x1800 and not sure on x1300 don’t have 24bit depth texture support…
Will we see multisample FBO formats on today’s cards?
qorpse, I think you misunderstood. I was saying the advantage of glCopySubTexImage is that you get 24bit depth and 8bit stencil. On radeon 9600, I’m very sure you can’t get 24 bit depth for a FBO.
There is no such thing as 8 bit depths. Only 16 and 24. Some rare cards have 32 bit.
Will we see multisample FBO formats on today’s cards?
The spec was drafted for GL_EXT_framebuffer_multisample
Search on these forums.
Some people might want a FSAA framebuffer and a non-FSAA FBO. You lose too much performance with FSAA. If you were to use the glCopySubTexImage and your framebuffer is multisampled …
Perhaps I should rephrase my question. Do you think that currently released cards will support GL_EXT_framebuffer_multisample sometime in the near future?
I have observed something weird on GeForce 6600GT (sorry but I don’t remember driver version):
I’ve been using multiple FBO’s - most of them for some 2D stuff, but my implementation always attached 24-bit depth buffer to an FBO.
This caused the application to stop for ~0,5s once per ~15 frames (very regular stops). My first thought was this is caused by using too much GPU memory, but decreasing memory usage didn’t help. Besides, why it stopped once every ~15 frames and not 2-3 (I’ve been using brute force approach to rendering in that version of application). Removing depth buffers from FBO’s not using it solved the problem. The same thing never occured on 7800GT.
I’m having some other problem with FBO on my 7800GT (91.28 beta drivers) - sometimes my GL_RGB_FLOAT16_ATI 2048x2048 buffer gets corrupted (all others are just fine). This is the largest one and I’m getting patterns on upper part of the screen and performance drops from 50 to 2 FPS.
This could still be some kind of resource managment bug on my side. As soon as I find out something more I’ll report this to NVIDIA.
Screenshot (1,1MB)
As you can see HUD looks OK, since it’s rendered directly to screen (after HDR image was processed). And FPS is 2 not 9 (my application doesn’t measure frame times larger than 100ms).
Blurred (400kB)
This is the HDR teture blurred - you can see that these artifacts are obviously not NAN or +/-INF.
Originally posted by k_szczech:
sometimes my GL_RGB_FLOAT16_ATI 2048x2048 buffer gets corrupted (all others are just fine). This is the largest one and I’m getting patterns on upper part of the screen and performance drops from 50 to 2 FPS.
This could still be some kind of resource managment bug on my side.
I’ve read on a thread (maybe it was on shading language section) today’s drivers are not really good at managing large textures. 2k^2 RGB16F needs 24MB, maybe you’re hitting the limits.
Not that I am convinced on this fact, but it has been reported and so I recalled this one here.
today’s drivers are not really good at managing large textures
Thanks - I’ll do some testing at 1024x768 (1024x1024 texture) and see if the problem still exists at this resolution.
Yes it does… 
I’m having some other problem with FBO on my 7800GT (91.28 beta drivers) - sometimes my GL_RGB_FLOAT16_ATI 2048x2048 buffer gets corrupted (all others are just fine). This is the largest one and I’m getting patterns on upper part of the screen and performance drops from 50 to 2 FPS.
Are you using glBufferData() to upload vertex data to vertex buffers? I’ve found that for whatever reason, this function trashes memory on some NVidia cards (even when used correctly). If you use glMapBuffer instead and copy data yourself, the problem will go away. I got similar things from this particular problem. In my stuff, it manifested as errors in my normalization cube map, which caused random error patterns in lighting. It was a real bitch to figure out.
Kevin B
CatAtWork, I’m a not an insider, but if you want me to guess… yeah sure. They probably have a internal driver that half works.
Are you using glBufferData()
I just changed my code to use glMapBuffer, but I’m still getting this bug. Thanks for the tip anyway.
It occurs only with RGB_FLOAT16 render target used for HDR. When using RGB10 for HDR imitation I have no such problems, so I guess that most likely excludes an error on my side (when error occurs I go back to menu and switch to RGB10 - it works again, but I can’t go back to FLOAT16).
I have an idea of workaround for this problem so I’ll leave it at that.
How about performance with POT, NPOT and RECTANGLE textures with FBO?
I started with NPOT, but since GeForceFX does not support these I switched to GL_ARB_texture_rectangle (I need to acces this texture in shaders). Finally I’m using POT textures.