Hi, I'm having a problem with my FBO's not showing any rendering after a window resize, and was wondering if anyone else has come across this. details: - running on win2K, ATI9800, - catalyst 6.2 (as directed to by the ATI driver selection webpage) - this is a windowed application, not full screen. - the gui is completely opengl based. All fine apart from: if the window resizes by a any amount via the top edge, if the window is maximized, or sometimes if the window is resized by a large amount, it seems that sometimes an application window/framebuffer resize can cause FBO's to stop rendering, with no GL or FBO errors reported. the application continues to work in all other respects, including gui. has anyone else seen this behaviour? many thanks, JD

ah... just wanted to add that the application is multi-threaded, multi-context and has been very stable until i started to allow gui window resize, and that only FBO's seem to be effected. I know the ATI drivers can be ropey, I even managed to get them to fix a bug a few years back, but has anyone seen only FBO's stop responding?

OK... seemed to fix this,

installing the latest omegaDrivers v3.8.360 made no difference
but I've been able to reduce the number of FBOs I require and everything is working lovely now.

Oh dear

This isn't fixed, it can still fall over at any point. Also it once reported a fbo status which was unkown (dont know the number yet, not any of the standard errors, will catch it next time).

I've got checks for writing and reading back from the FBO's and the FrameBuffer.

Sometimes I can draw and read back from the FBO's and it all looks ok, until you try and use it as a texture, in which case I just get back the prev fbo.texture contents.
And sometimes it fails to even draw to the FBO.

In ether state the rest of the gl system carries on without any problems.

I can pull down and rebuild just the FBO's when this happens and it does recover, but this grinds the display. BTW its reproducable far more quickly the more graphics memory I use.

I wonder if the texture/fbo management in the driver has a bug or memory leak. So when it reallocates memory due to a FrameBuffer resize it loses some handles during shuffling the stuff around.

any ideas would be very welcome.

Just off the top of my head are you setting the glViewPort() each time you render to a FBO... Meaning do you call glViewPort() in the FBO code also to setup the size you want... Please post some code. I am aiming in the dark here. :)

Thank you people for your responses, I think I've got to the bottom of this now.

It had been a while since I'd checked the amount of resources I was requiring at different quality settings.

Basically, running the program at the higher quality setting wasn't just slowing stuff down, but could cause the graphic driver to fall over, by losing handles to textures/fbos or more often then not going into a such a major cache/paging routine that a gl function at some point would take upto 500ms on this machine (sometimes repeatedly until a different rendering sequence happens).

Once I realised this - I managed to rearrange the architecture to optimise texture/fbo caching as best I can, and if I run it at a lower quality setting on this card, everythings stable. I can mostly auto-recover from the handle corruption (since this only happens on framebuffer resize and can be detected) and if the system becomes slugish then I can suggest the user lowers the quality setting.

A last word, I was pretty impressed by how well the driver was managing considering the threashing i was giving it!

Thanks again