Hi Min,
On Fri, Apr 27, 2018 at 11:36 AM Min He <min...@intel.com> wrote:
> To avoid blocking other EGL calls, release the display mutex before
> calling update_buffers(), which will call droid_window_dequeue_buffer().
> The lock appears like below:
> 1. Consumer thread: updateTexImage() -> updateAndReleaseLocked() ->
> syncForReleaseLocked() -> eglDupNativeFenceFDANDROID() ->
> _eglLockDisplay() -> waiting for the dpy lock.
> 2. Producer thread: eglQuerySurface() (acquired dpy lock) ->
> droid_query_buffer_age() -> update_buffers() ->
> android::Surface::dequeueBuffer() ->
> android::BufferQueueProducer::waitForFreeSlotThenRelock()
> This patch fixes some failure cases in android graphics cts test.
> Signed-off-by: Min He <min...@intel.com>
> Signed-off-by: Chenglei Ren <chenglei....@intel.com>
> Tested-by: Chenglei Ren <chenglei....@intel.com>
> ---
> src/egl/drivers/dri2/platform_android.c | 7 +++++++
> 1 file changed, 7 insertions(+)
> diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
> index 7f1a496..c6f895a 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -610,11 +610,18 @@ droid_query_buffer_age(_EGLDriver *drv,
> {
> struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surface);
> + /* To avoid blocking other EGL calls, release the display mutex before
> + * we enter droid_window_dequeue_buffer() and re-acquire the mutex
upon
> + * return.
> + */
> + mtx_unlock(&disp->Mutex);
> if (update_buffers(dri2_surf) < 0) {
> _eglError(EGL_BAD_ALLOC, "droid_query_buffer_age");
> + mtx_lock(&disp->Mutex);
> return -1;
> }
> + mtx_lock(&disp->Mutex);
With droid_window_enqueue_buffer(), we put the unlock just around
window->queueBuffer(). I'd say that at least for consistency, we should do
similar thing inside droid_window_dequeue_buffer(). Moreover,
droid_window_dequeue_buffer() actually does much more inside than
droid_window_enqueue_buffer(), so we might actually want to have the mutex
held there, when accessing internal data.
Best regards,
Tomasz
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
