Hi All,

I have a querie regarding synchronization using eglWaitNative and eglWaitClient.

  I have two processes in which process A does GL related processing and process B does native processing on a native Pixmap surface. Now the issue is can I use the standard egl apis  eglWaitNative and eglWaitClient to accomplish the synchronization? In which I might define my own way of locking and unlocking when the rendering is happening on the buffer. If this can be used, can someone suggest the sequence in which these api's can be called in both process A and process B.

Thanks and Regards,

If you wanted to do GL rendering first, then native, I’d suggest something like this to start with (or flip it around if you wanted to do native rendering first):

Process A:
loop {
draw GL stuff
signal process B that I’m done
wait for process B to signal that it’s done

Process B:
loop {
wait for process A to signal that it’s done
draw native stuff
signal process A that I’m done

I expect this would be hideously inefficient given all the context switching in both CPU and GPU that would probably be going on underneath the hood, but it should work. For performance I’d suggest (a) avoid mixing native and GL rendering at all, try to render everything in GL (b) failing that try to do it in the same process and (c) think about a different approach, like native rendering into a pixmap, then sourcing the pixmap as an ES texture. ES rendering into a pixmap may be a lot slower than into a pbuffer or window surface, BTW, although that’s very implementation-dependent (for a historical example, rendering into a X pixmap via GLX and desktop OpenGL usually fell back to a software rendering path on the CPU, since the gfx accelerator rarely could write into host memory where pixmaps are probably located - although that’s changed somewhat these days with the mechanisms underlying some of the compositing window managers on

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.