does the emulator support sharing multiple egl contexts?
1,613 views
Skip to first unread message
Gulfas
Jul 17, 2012, 8:29:42 PM7/17/12
to andro...@googlegroups.com
Hi,
I have two threads, each one with its own EGL context. The context of the main thread is shared with the one from the secondary thread.
Whenever I call from the secondary thread to eglMakeCurrent(display, surface,surface, secondaryCtx) I get the error
E/libEGL (572): eglMakeCurrent:685 error 3002 (EGL_BAD_ACCESS)
The same code works on Linux/OpenGL/GLX/X11.
I am working on an emulator running API level 14.
Any ideas?
Cheers,
Pablo Márquez
Jul 27, 2012, 5:40:10 AM7/27/12
to andro...@googlegroups.com
Hi Edward,
Thanks for your answer!
I get the same error EGL_BAD_ACCESS on real devices: Samsung Galaxy S2 and S3.
--
pablo.mar...@yahoo.co.uk
Thanks for your answer!
I get the same error EGL_BAD_ACCESS on real devices: Samsung Galaxy S2 and S3.
Regarding your suggestion, I guess I'll have to use a mutex to ensure the egl surface is not accessed simultaneously by more than one thread.
I expected the EGL device driver would handle this better...
Just out of curiosity, any ideas where I can find a EGL authority who can enlighten me?
Cheers,
Pablo.
Just out of curiosity, any ideas where I can find a EGL authority who can enlighten me?
Cheers,
Pablo.
On Thu, Jul 26, 2012 at 5:05 PM, Edward Jackson <edward.d...@gmail.com> wrote:
Try unlinking the context for each respective thread after you're done.eglMakeCurrent(display, surface,surface, primaryCtx)...glCode(...)glCode(...)glCode(...)...eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
eglMakeCurrent(display, surface,surface, secondaryCtx)...glCode(...)glCode(...)glCode(...)...eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/3nyP3Dn-a6kJ.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
___________________________________________
Pablo Marquez - Mobile +44 (0) 77 10 59 77 22pablo.mar...@yahoo.co.uk
David Given
Jul 27, 2012, 6:03:23 AM7/27/12
to andro...@googlegroups.com
Pablo Márquez wrote:
[...]
The whole area of multithreaded rendering is basically as buggy as hell
on Android. This isn't Android's fault --- you're absolutely at the
mercy of the GLES vendor libraries, and they're infamously bad. You will
*not* get this working portably.
In our product, we have three different build configurations, for:
- platforms which do multithreaded rendering correctly (each thread can
have a context bound to a different surface);
- platforms which ignore multithreaded rendering completely (there is a
single global context, bound to a single surface, which all threads use);
- platforms which try to do multithreaded rendering but just get it wrong.
As an example of the last: on some of our test devices, mostly Samsungs,
unbinding a context from a thread causes the screen to go black.
It gets particularly bad when you try to handle context lost events
correctly. The NDK will send you an event to tell you that the EGL
context is being invalidated, but then expect you to handle that
synchronously; if you don't free up all resources before the event
returns, weird stuff happens. This means that if you have a separate
render thread with a bound context you have to somehow get that thread
to unbind the context before the NDK event returns, as only code running
from that thread can do it...
In my experience the only totally reliable setup is to do all your
OpenGL work synchronously from the NDK event thread. This is a bit
problematic if, like us, your app fundamentally wants to do its
rendering from a worker thread. (Yes, we have tried using RPC to
delegate all OpenGL and EGL functions to the main event thread. No, it
wasn't worth it...)
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams
[...]
> Regarding your suggestion, I guess I'll have to use a mutex to ensure
> the egl surface is not accessed simultaneously by more than one thread.
>
> I expected the EGL device driver would handle this better...
Danger, Will Robinson!
> the egl surface is not accessed simultaneously by more than one thread.
>
> I expected the EGL device driver would handle this better...
The whole area of multithreaded rendering is basically as buggy as hell
on Android. This isn't Android's fault --- you're absolutely at the
mercy of the GLES vendor libraries, and they're infamously bad. You will
*not* get this working portably.
In our product, we have three different build configurations, for:
- platforms which do multithreaded rendering correctly (each thread can
have a context bound to a different surface);
- platforms which ignore multithreaded rendering completely (there is a
single global context, bound to a single surface, which all threads use);
- platforms which try to do multithreaded rendering but just get it wrong.
As an example of the last: on some of our test devices, mostly Samsungs,
unbinding a context from a thread causes the screen to go black.
It gets particularly bad when you try to handle context lost events
correctly. The NDK will send you an event to tell you that the EGL
context is being invalidated, but then expect you to handle that
synchronously; if you don't free up all resources before the event
returns, weird stuff happens. This means that if you have a separate
render thread with a bound context you have to somehow get that thread
to unbind the context before the NDK event returns, as only code running
from that thread can do it...
In my experience the only totally reliable setup is to do all your
OpenGL work synchronously from the NDK event thread. This is a bit
problematic if, like us, your app fundamentally wants to do its
rendering from a worker thread. (Yes, we have tried using RPC to
delegate all OpenGL and EGL functions to the main event thread. No, it
wasn't worth it...)
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams
David Given
Jul 27, 2012, 1:41:25 PM7/27/12
to andro...@googlegroups.com
Edward Jackson wrote:
[...]
> How did you get around the unbinding context issue? Our development
> device is a Galaxy S3 (i747). Our application is supposed to load image
> tiles (for mapping) in a separate thread and display them in another
> thread. Our single threaded version works, albeit with hiccups when the
> tiles are loaded, but as soon as we go to multi-threading, we
> see nothing but a black screen.
Our solution probably won't help, I'm afraid.
We have two common cases: pure OpenGL games; and EGL KHR_locksurface
based games. Android doesn't support locksurface so we have to emulate
it with OpenGL.
Locksurface is, unfortunately, a multithreaded API (the thread which
locks the surface doesn't have to be the one that unlocks it or calls
eglSwapbuffers()...).
On platforms which support it, therefore, we continuously bind and
unbind the context whenever we need it. This allows us to do multiple
operations from different threads. On platforms where this doesn't work
we use RPC so that all operations happen from a single thread. This
isn't too much overhead, as when doing locksurface graphics most of the
hit is manipulating the framebuffer, which once the surface is locked
can happen from any thread.
For pure OpenGL games... well, so far we don't have any games that try
to do multithreaded rendering or more than one context, so this hasn't
come up yet.
It may be worth pointing out that our product allows us to run the
Khronos OpenGL conformance tests on any platform that our product is
ported to, including Android. We've largely given up running them on
Android --- they always fail...
[...]
> How did you get around the unbinding context issue? Our development
> device is a Galaxy S3 (i747). Our application is supposed to load image
> tiles (for mapping) in a separate thread and display them in another
> thread. Our single threaded version works, albeit with hiccups when the
> tiles are loaded, but as soon as we go to multi-threading, we
> see nothing but a black screen.
Our solution probably won't help, I'm afraid.
We have two common cases: pure OpenGL games; and EGL KHR_locksurface
based games. Android doesn't support locksurface so we have to emulate
it with OpenGL.
Locksurface is, unfortunately, a multithreaded API (the thread which
locks the surface doesn't have to be the one that unlocks it or calls
eglSwapbuffers()...).
On platforms which support it, therefore, we continuously bind and
unbind the context whenever we need it. This allows us to do multiple
operations from different threads. On platforms where this doesn't work
we use RPC so that all operations happen from a single thread. This
isn't too much overhead, as when doing locksurface graphics most of the
hit is manipulating the framebuffer, which once the surface is locked
can happen from any thread.
For pure OpenGL games... well, so far we don't have any games that try
to do multithreaded rendering or more than one context, so this hasn't
come up yet.
It may be worth pointing out that our product allows us to run the
Khronos OpenGL conformance tests on any platform that our product is
ported to, including Android. We've largely given up running them on
Android --- they always fail...
Latimerius
Jul 27, 2012, 2:53:51 PM7/27/12
to andro...@googlegroups.com
I wasn't even able to use share context, let alone go into threading.
I asked about it on android-developers (because this was from Java)
two weeks ago, predictably with no reply:
https://groups.google.com/forum/?fromgroups#!topic/android-developers/BHH08ak8MRA
(Summary: anytime I use the 'share_context' parameter of
eglCreateContext(), subsequent eglMakeCurrent() on that context fails
with EGL_BAD_MATCH.)
I asked about it on android-developers (because this was from Java)
two weeks ago, predictably with no reply:
https://groups.google.com/forum/?fromgroups#!topic/android-developers/BHH08ak8MRA
(Summary: anytime I use the 'share_context' parameter of
eglCreateContext(), subsequent eglMakeCurrent() on that context fails
with EGL_BAD_MATCH.)
David Given
Jul 27, 2012, 4:17:03 PM7/27/12
to andro...@googlegroups.com
On 27/07/12 19:53, Latimerius wrote:
> I wasn't even able to use share context, let alone go into threading.
> I asked about it on android-developers (because this was from Java)
> two weeks ago, predictably with no reply:
>
> https://groups.google.com/forum/?fromgroups#!topic/android-developers/BHH08ak8MRA
>
> (Summary: anytime I use the 'share_context' parameter of
> eglCreateContext(), subsequent eglMakeCurrent() on that context fails
> with EGL_BAD_MATCH.)
A while back I found this:
> I wasn't even able to use share context, let alone go into threading.
> I asked about it on android-developers (because this was from Java)
> two weeks ago, predictably with no reply:
>
> https://groups.google.com/forum/?fromgroups#!topic/android-developers/BHH08ak8MRA
>
> (Summary: anytime I use the 'share_context' parameter of
> eglCreateContext(), subsequent eglMakeCurrent() on that context fails
> with EGL_BAD_MATCH.)
http://blog.vlad1.com/2010/07/01/how-to-go-mad-while-trying-to-render-to-a-texture/
It's a writeup of one of the Mozilla developers working on Canvas 3D on
various platforms. Turns out that shared contexts on Android are
supported only on some platforms.
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
Latimerius
Jul 27, 2012, 5:02:13 PM7/27/12
to andro...@googlegroups.com
On Fri, Jul 27, 2012 at 10:17 PM, David Given <d...@cowlark.com> wrote:
> A while back I found this:
>
> http://blog.vlad1.com/2010/07/01/how-to-go-mad-while-trying-to-render-to-a-texture/
>
> It's a writeup of one of the Mozilla developers working on Canvas 3D on
> various platforms. Turns out that shared contexts on Android are
> supported only on some platforms.
Thanks for the link David, for some reason I didn't come across it.
> A while back I found this:
>
> http://blog.vlad1.com/2010/07/01/how-to-go-mad-while-trying-to-render-to-a-texture/
>
> It's a writeup of one of the Mozilla developers working on Canvas 3D on
> various platforms. Turns out that shared contexts on Android are
> supported only on some platforms.
Yeah, after a lot of effort to make it work and checking my code
against the EGL spec I started to suspect there might be a problem
with the EGL implementation on Android. It took me a lot of time to
come to this conclusion though as Android is my first exposure to EGL,
I assumed I must be understanding something wrong...
Gulfas
Jul 31, 2012, 9:41:50 AM7/31/12
to andro...@googlegroups.com
Hi David,
Thanks!
I'd add: multithreaded rendering is not only buggy on Android; I experienced a problem on some Ubuntu 64 bit desktops where my application crashed inside the ATI/AMD driver code when trying to use a shared context from a secondary thread. After updating the drivers the problem was fixed. At least Android's EGL driver doesn't crash and returns an error code :).
On Android, I must admit it's a bit frustrating not being able to use a shared context from a secondary thread. I was not trying to do something crazy or too wild, in my game I have secondary thread which reads the assets from the disk and setups opengl textures while the main thread renders to the screen.
I'd add: multithreaded rendering is not only buggy on Android; I experienced a problem on some Ubuntu 64 bit desktops where my application crashed inside the ATI/AMD driver code when trying to use a shared context from a secondary thread. After updating the drivers the problem was fixed. At least Android's EGL driver doesn't crash and returns an error code :).
On Android, I must admit it's a bit frustrating not being able to use a shared context from a secondary thread. I was not trying to do something crazy or too wild, in my game I have secondary thread which reads the assets from the disk and setups opengl textures while the main thread renders to the screen.
I still use the same code with multiple threads in the platforms that can handle shared contexts (Linux), but I added a fallback function to load the assets in the main thread if the secondary thread fails to set the shared context (EGL_BAD_ACCESS) or any other error.
Cheers,
Pablo
Reply all
Reply to author
Forward
0 new messages