I have an application which hast multiple contexts (egl) and each context have very strict execution time. Let’s say I have a context manager that makes current these context one by one and with duration 10 ms. Each context has its own FBO and different applications are filling them. To make more understandable:
Ctx1(with FBO1), Ctx2(with FBO2) are the context.
Code is like that:
[i]eglmakecurrent(Ctx1)
glBindFrameBuffer(FBO1) // eglmakecurrent clears FBO, so each time I have to bind it again
glClear(color)
glPushMatrix
glLoadIdentity
Application1() // OpenGL code
glPopMatrix
glLoadIdentity
glBindFrameBuffer (0) and related blend operations to draw to pbuffer[/i]
The same for Ctx2…
It is OK when there is no time limitations for Application1(). Now assume that Application1() has 100 openGL calls which takes 20ms to run and I have 10 ms. So I am stopping the execution of Application1(), lets say 50 API’s had run. And I draw nothing to Pbuffer (to display previous drawings). I make another context current and make its executions. Than I make current Ctx1 again and I want to continue my execution from 51st API.
As every settings are stored in context, there is no problem about textures, colors …etc. But some anti aliasing problems are occured. Some lines are seemed to be flashing. Do I have to store some settings related with context o there is another thing do I have to do?
[QUOTE=palmiye;1293111]I have an application which hast multiple contexts (egl) and each context have very strict execution time.
…
Now assume that Application1() has 100 openGL calls which takes 20ms to run and I have 10 ms.
So I am stopping the execution of Application1(), lets say 50 API’s had run. And I draw nothing to Pbuffer (to display previous drawings).
I make another context current and make its executions.
Than I make current Ctx1 again and I want to continue my execution from 51st API. [/QUOTE]
You’re using EGL here. That suggests you may be targeting a tile-based GPU (e.g. mobile). Are you? Which GPU?
If so, the performance of this is going to be very bad due to instigating full pipeline flushes in the middle of rendering a render target, which can generate rendering artifacts and lots of extra DRAM bandwidth writing out and reading in full-size render targets mid-render.
But some anti aliasing problems are occured. Some lines are seemed to be flashing.
Are you using MSAA and/or depth buffer on the FBO with aliasing problems? If so and tile-based GPU, I’m not surprised. Suspending the rendering of a render-target mid-render on these GPUs is a bad idea.
To save bandwidth, some mobile GPUs only keep the MSAA pixel rep on-chip in fast tile cache memory and do the MSAA resolve before writing single-sample pixels back to the render target in DRAM (when possible), which can generate rendering artifacts if you trigger a full pipeline flush mid-render. Some will also try to keep the depth buffer info only on-chip when possible for the current tile and avoid writing this back to memory (when possible). See your the OpenGL ES Developer’s Guide for your GPU for details.
You might be able to defeat these optimizations (if even present in your driver) by rendering to an FBO backed with textures for the render targets instead of renderbuffers, but YMMV based on the GPU and driver.
Before you spend much time suspecting this though, I would double-check that you have your state setup properly for the suspend/resume of your FBO rendering to ensure that it is exactly correct. A GL state setup difference could explain your artifacts more easily.
It is AMD e8860. As far as I know, MSAA is not used but I will check it (for ex Line smooth enable is used).
Actually I am binding texture to FBO (I am not using renderbuffers). I am comparing glContext data ( I think you mention this data by “GL State”), there is no difference, but it is very difficult to get the glContext which belongs to wrong drawing, as there as thoushands of gl calls and it randomly draws wrong.So I am not sure I am comparing true context data
