Quick FBO question....

Is there any case / reason where initializing an FBO part way through your draw thread will upset the current FrameBuffer and cause it to flicker for one frame?

I have some fairly tried and tested FBO code that works flawlessly and has done for some time… Up until recently I have always prepped the FBOs before entering the main core of my simulation.

Recently I have needed to initialize some FBOs dynamically (and occasionally re-size them), so instead of setting them up prior to my simulation I am creating and drawing to them part way through my main draw thread. This causes a blank frame in the main framebuffer immediately after initialization for that frame only.

I get no OpenGL errors, all the stuff I am drawing to the FBO is present and correct, and the FBO reports that it is initialized properly. I am also very careful to preserve and restore matrices and the current FrameBuffer… So it’s pretty impossible to track down… I have poured over this and stepped through it with an OpenGL debugger checking states and so on, and found nothing out of order.

I can’t find anyone else having this problem, nor any warnings that what I am doing is illegal in any documentation, but just wanted to double check here before I start ripping things to pieces!!

Thanks for any feedback.

I would run it through GLintercept paired with XML, see how the output is. other then that might be a driver bug. tested on other machines?

happy ripping :wink:

That’s what I am afraid of… a driver bug that is, but I am always mindful of the saying that when you are 105% sure it’s a driver bug it’s still a bug in your code… I also think people would have picked it up before, and my hope was that perhaps there was some unwritten rule about not initializing an FBO and using it in the same frame… but I guess that was a stretch! :slight_smile:

Will be testing it on a different GPU tomorrow, and after that it will be a case of pulling things apart piece by piece. Yum!

Thanks for the feedback though.

scratt: 105% sure it’s a driver bug it’s still a bug in your code…
absolutely most of the time.

scratt let us know what the problem was if you discover it.

He He. Well in my research I found a driver bug anyway, but not directly solving this issue… Apparently on the x1600 drivers Texture Unit 7 is ‘borrowed’ internally from time to time, and if you are working with aa points, lines etc. it can bork your settings… I have had that confirmed by the nice guys at ATI.

I am not sure if it’s related but armed with that info I am going to re-work some stuff today on the FBO and see if that was related in any way…

OK… The FBO thing was my bad…

I am Impostoring, which uses FBOs. I am also doing HDR, which uses an FBO.
On top of that I am also running cameras, which also use FBOs.

I had made some assumptions about what would happen with this mix.
Those assumptions were evidently wrong…

<s>Now I need to go do some research on how to protect and restore stacked FBO states…
If anyone has any suggestions I am all ears. :)</s>

EDIT : Scratch that! I took a flyer and wrote a quick class to stack FBOs and it worked! Didn’t think it would be that easy! :slight_smile: