Ok, so overall you want:
- SCENE → FB2 → FB1 → Default FB
and you’re getting screen flashing on the splash screen?
Also, this is a continuation of this thread, correct?
When starting a new thread, please provide context information. See:
for tips on this. Include information such as:
- GPU and GPU driver version,
- OS
- what exactly you did when the problem started occurring,
- what you’ve tried to resolve the problem yourself, and the results of those tests,
- code snippets you believe may be relevant to your problem, etc.
You didn’t include anything about GPU, but based on this datasheet:
I’m going to assume you’re running on:
- SOC: Texas Instruments TDA4
- CPU: ARM Cortex-R5 processor
- GPU: Imagination Tech PowerVR Rogue 8XE
Also, this time you posted in an OpenGL forum instead of OpenGL ES. I’m going to assume you’re still dev/testing on OpenGL ES and move your thread there.
In any case, if my assumptions here are correct, key to your problem is probably that you’re running on an embedded tile-based GPU. Tile-based GPU is key here. Your flashing problem likely indicates that you are issuing a rendering command sequence that is causing a pipeline flush in the middle of the GPU rendering a render target (think default framebuffer or FBO). You should also be able to observe this in a decent profiling tool, and Imagination Tech (in my experience) has good profiling tools.
Do you know what a pipeline flush is? If so, I won’t spend much verbiage on this except to summarize that rasterization for a render target is being split. This can happen for a number of reasons. Obvious examples include issuing a glReadPixels(), glBlitFramebuffer(), glFinish(), or glFlush() in the middle of rendering a render target.
Where I’ve hit it on PowerVR before is with glClientWaitSync() using GL_SYNC_FLUSH_COMMANDS_BIT. This triggers a full pipeline flush. If you want to sync just on vertex work completion and not full-pipeline completion, there’s a trick to do that.
Also IIRC, reconfiguring an FBO can trigger a pipeline flush if there is outstanding rendering work on that FBO. So keep a small pool of FBOs and round-robin across them to avoid this. In the driver, the framebuffer is “the” resource with which all rasterization work is associated, so don’t reconfig those soon after queuing work on them unless you want a pipeline flush to occur. That said, there’s a finite GPU mem cost per FBO/framebuffer however, so you can’t go crazy and just create a bunch of them or you’ll exceed GPU memory.
You always have to keep in mind with a tile-based mobile GPU that (unlike a discrete desktop GPU) the whole architecture of the chip is geared toward rasterization occurring a frame or two late. If you do anything to thwart that, your performance will tank, and you may additionally get on-screen flashing effects as well.