Tagged: opengl es 2.0
- January 26, 2013 at 2:08 pm #31119
I have faced with an issue when trying to use a shader program in my second GL context that is shared with my first context where shaders and program were created.
The issue is that call of glUseProgram for the second context generates GL_INVALID_OPERATION error. On target device it leads to crash, but on Imagination PC emulator it does correct rendering with specified shader program (except mentioned GL error) – this is very strange.
I checked this on another emulators (ARM Mali and Google ANGLE), on them my test application did not get any GL errors at glUseProgram call, so the problem is related only to Imgtec driver.
Here is pseudo-code from my application (OpenGL ES 2.0):
eglFirstContext = eglCreateContext(eglDisplay, eglConfig, NULL, ai32ContextAttribs);
eglSecondContext = eglCreateContext(eglDisplay, eglConfig, eglFirstContext, ai32ContextAttribs); // eglSecondContext is linked with eglFirstContext
eglMakeCurrent(eglDisplay, eglSurface, eglSurface, eglFirstContext);
programId = [creating shader program with simplest vertex/fragment shaders]
eglMakeCurrent(eglDisplay, eglSurface, eglSurface, eglSecondContext);
glUseProgram(programId); // generates GL_INVALID_OPERATION
If I comment the second eglMakeCurrent call, then problem disappears, which means it is context sharing problem for sure.
I tested texture sharing on linked contexts – works as expected.
Could you please clarify the problem and propose some workable solution?
Thanks in advance!January 28, 2013 at 9:37 am #36574January 28, 2013 at 9:48 am #36575
My application is single-threaded. On device (with Imgtec driver) I also use single-thread rendering.
So maybe there is some other reason…January 28, 2013 at 5:10 pm #36576
It sounds like this may be a bug in our emulator. We’d need to investigate to confirm this.
Can I ask why you would need multiple contexts if your application is single threaded?
JoeJanuary 28, 2013 at 7:04 pm #36577
My application uses two GL contexts in the following way: the first context is created for window surfaces that display different Views on the screen and the second one is needed for offscreen PBuffer rendering (like moving textures from one texture atlas into another).
As I know, PBuffer requires separate GL context, because it potentially may have such pixel format that differs from pixel format chosen for displayable window surfaces.
Since it is bug in the driver, could you recommend some workaround for this situation?
Thank you!January 29, 2013 at 10:12 am #36578
I’m aware of one bug in the emulator where rendering to a pbuffer may not work correctly when the “Host” profile is selected from the GUI. You could try selecting a hardware profile to emulate.
It does sound like the resources are not being shared correctly across contexts. I’ll see if I can reproduce the problem here.January 29, 2013 at 12:34 pm #36579
Please note that problem reproduced regardless of using pbuffer.
In my test application I just used one window surface and two shared contexts to reproduce the problem.
I will be happy if you check this for me.
Thank you.January 31, 2013 at 10:48 am #36581
There seems to be some subtle errors in the way the emulator is currently handling context sharing, in particular the management of the program and shader objects. I’m not sure if there is a solution yet for the issue beyond “stop using shared contexts”. Apologies if that’s not a suitable workaround. I have logged this as a bug and will hopefully get to it before the next major update!