PDA

View Full Version : [EGL 1.1]



bonfo
04-21-2009, 03:15 AM
Hi all,
I have some issues with the eglMakeCurrent() specification.

What I'm trying to do is to have multiple threads that render to the same surface.
So I'm creating a single EGLSurface form the window native surface and then an EGLContext for each thread.
Each thread calls the eglMakeCurrent function passing the eglSurface (for both read/write) and its own eglContext.
In this way I have a context current only on one thread.

I tried this solution on the OpenGL|ES Java binding on the Android platform and when the second thread call the eglMakeCurrent() i get an EGL_BAD_ACCESS error. The documentation (http://www.khronos.org/opengles/sdk/1.1 ... urrent.xml (http://www.khronos.org/opengles/sdk/1.1/docs/man/eglMakeCurrent.xml)) says:


EGL_BAD_ACCESS is generated if context is current to some other thread.

and I'm sure that the context is a brand new context that cannot be current on any other thread.
So the OpenGL|ES documentation doesn't specify clearly that my code is invalid.

But to be really sure that the problem is not my implementation that is buggy, I went an read the specification. In the section 3.7.3 of the eglspec.1.1.pdf (November 10, 2004) it's written:


Only one rendering context may be in use, or current, for a particular thread at a given time, and only one context may be bound to a particular surface at a given time.


Because I'm sure that the OpenGL|ES Java binding on the J2ME platform allows to have multiple context bound to the same surface, I tried a native implementation.
Using the Imagination Technolgies SDK (PCEMULATION build 2.04.24.0811) I saw that I can bound multiple context to the same surface. That is, the multi-thread approch with each thread its own EGLContext works fine.

So here is the final question: who is doing wrong? Me, Android, Java or Imagination Technologies? :D :D ;)

Xmas
04-21-2009, 07:13 AM
As the spec says, "only one context may be bound to a particular surface at a given time". If an implementation lets you have a surface current in two or more threads at the same time that's either an extension or a bug. And given that multiple threads accessing the same surface doesn't exactly lead to a defined rendering result, it's very likely the latter.

bonfo
04-22-2009, 12:46 AM
So, the documentation should say:


EGL_BAD_ACCESS is generated if context is current to some other thread or if the surface has already a context bound.


Is that right?

P.S.:
@Xmas: do you read that using your SDK i was able to acces the same surface form different Threads? I think is something "powerful" and should be enabled. Than, of course, is responsability of the developer to synchronize the threads to have a "well defined" behaviour.

Xmas
04-22-2009, 03:57 AM
This is straight from the EGL 1.4 spec, the reference pages should be updated to say the same:

If ctx is current to some other thread, or if either draw or read are bound to contexts in another thread, an EGL_BAD_ACCESS error is generated.

If you have to synchronize the threads anyway it should be simple to unbind the surface in any other thread than the current rendering thread.

Yes, this is a bug in our SDK.

bonfo
04-22-2009, 08:18 AM
Ok, now I'm completely convinced 8)

The last question related to the multithreading.
What if I create an EGLContext and an EGLSurface for each thread, but all the EGLSrufaces are created form the same native-window?

Do i still have the limitation?

Thanks for your kindness. ;)

Xmas
04-22-2009, 10:16 AM
The last question related to the multithreading.
What if I create an EGLContext and an EGLSurface for each thread, but all the EGLSrufaces are created form the same native-window?

Do i still have the limitation?
In that case window surface creation fails:

If there is already an EGLConfig associated with win (as a result of a previous eglCreateWindowSurface call), then an EGL_BAD_ALLOC error is generated.

bonfo
04-24-2009, 01:13 AM
Could you please give me the reference in the spec of the sentence you reported?

Thanks for explaining and clarifying me this part of EGL. ;)

Valerio

Xmas
05-05-2009, 04:46 AM
It's in the EGL 1.4 spec, page 27, middle of the page.
http://www.khronos.org/registry/egl/spe ... ec.1.4.pdf (http://www.khronos.org/registry/egl/specs/eglspec.1.4.pdf)