I have a pure OpenVG application with two threads: the first thread is the graphics rendering loop, and the other thread does the resource upstreaming.
The first thread does its work and then issues a call to eglSwapBuffers() call. eglSwapBuffes waits for vsync, blits the things and then does a new cycle; just a common rendering loop with no fancies.
The second thread is mostly sitting except when there is the need to upload some resources concurrently (mostly large images or even vector paths).
The EGL setup seems correct to me: both threads are bound to OpenVG API, they use different contexts (altough the rendering thread creates its context sharing resources from the context of the upstream thread) and different surfaces (the rendering thread has a fullscreen native surface, the upstream thread has a dummy small pbuffer)
My problem arises when I increase the priority of the rendering thread to get a stable framerate: the upstream thread goes into starvation and can't upload resources as soon as possible.
CPU usage is low for both threads (less than 5% for both of them), so my only guess is the presence of a per-process lock which prevents two threads accessing the videocore internals at the same time, and eglSwapBuffers() is actively taking the lock while it is waiting for vsync, preventing the other thread to operate.
I would really like to increase the priority of the rendering thread and still maintain the asynchronous upstream thread, are there some best practices to follow or bad practices to avoid in such cases?