I’m working on a project where we need to manage egl contexts for OpenGLES 1.1 and OpenGLES 2.0.
Here is the situation:
Create a context from an OpenGLES1.1 config with no shared context, everything works fine.
Create a context from an OpenGLES2.0 config, without shared context, everything is OK too.
Create a context 1.1 with a shared context previously created with 1.1 config is OK too.
But if I try to create an OpenGLES 2.0 context with the appropriate configuration but with a shared context previously created with OpenGLES1.1 config, I get a null pointer. The worst is that I get EGL_SUCCESS when I call eglGetError(). According to the EGL specification, it should be possible.
Is that a known issue ? Is there an incompatibility between the two kinds of egl contexts ? Do we need to use a GLES1.1 and 2.0 capable configuration ?
I’m unaware of any such language allowing this in the EGL specification - it mentions that mixing different APIs is not allowed but I couldn’t find any reference to different versions - but realistically ES1 and ES2 are very different APIs (Fixed vs Programmable). Typically this sort of thing should be explicitly mentioned or it doesn’t work - could you point me at any language which says this more explicitly?
At the moment this is entirely unsupported in our drivers, can I ask what your use case for this is? Have you got this working on any other platforms?
Our use case is pretty complex, but I can try to explain it a bit what’s going on. A part of our application is drawing into a pBuffer using ES1 or ES2 depending on the need (this part of the application will only use ES1 xor ES2, never both). Then we want to render this pBuffer to our window surface using ES1 api.
In our implementation, the ES1 context used in the last draw is shared with all others contexts. This is working on MALI GPUs but not on PowerVR ones. Maybe our implementation is wrong, but I would like to be sure before breaking everything.
Hope this helps to understand what we’re trying to do
The fact that Mali GPUs do it is probably just a coincidence of their driver implementation, which is the reason we don’t support it - nothing in the specification really says we should/should not do it. Regardless, from talking to our driver team it seems that we absolutely do not support this in any way shape or form. I’ll discuss this with them and see if this is something that we need to enable in future, but current hardware will unfortunately maintain this limitation.
Could I ask what the reason is that you don’t just write directly to the window? Is there a sort of composition step which you’d like to perform in one API, with inputs from multiple APIs?
Depending on your platform, you might be better able to use Pixmaps to do this, or if you’re on Android you should be able to use GraphicsBuffers. Whichever of these you use, it would mean that the output data would be stored externally to the OpenGL ES context - allowing both your ES1 and ES2 contexts to access it without having to share.
About the Mali GPU, you’re right, the fact is that their ES1 implementation is just a wrapper over the ES2 one, so the compatibility seems to be a side effect of the implementation.
The reason is that we have a remote clients which are using ESx API to draw. So at one end, we’re drawing in a pBuffer or in a texture (using FBO if supported) using ES1 or ES2 depending on the remote source, and we would like to compose these buffers/textures in the rendering window using ES1 on the other end.
We’ll try your suggestion, I hope it’ll not impact performances too much.
