Sign in to follow this  
john_day_gamedev

OpenGL FBO stops rendering

Recommended Posts

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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites
Since it's Win 2k, ATI is not updating their drivers. Perhaps you can ignore this OS and just require XP and above.
It's a shame since Win2k is as nice as XP.

You could also try another similar card like 9500, 9600, 9700 and see if it makes a difference.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this