i965: Resolve framebuffers before signaling the fence
authorChris Wilson <chris@chris-wilson.co.uk>
Mon, 12 Jun 2017 14:17:20 +0000 (15:17 +0100)
committerChris Wilson <chris@chris-wilson.co.uk>
Tue, 11 Jul 2017 14:46:58 +0000 (15:46 +0100)
commit618be8cc1ad1760103930b69ffbf528d7b861ab3
treec8492df42eb8b31f9f81e57450594c2deca35105
parentbf7a4f444110a153268e72cf6bc0a4f610ab05a4
i965: Resolve framebuffers before signaling the fence

From KHR_fence_sync:

  When the condition of the sync object is satisfied by the fence
  command, the sync is signaled by the associated client API context,
  causing any eglClientWaitSyncKHR commands (see below) blocking on
  <sync> to unblock. The only condition currently supported is
  EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR, which is satisfied by
  completion of the fence command corresponding to the sync object,
  and all preceding commands in the associated client API context's
  command stream. The sync object will not be signaled until all
  effects from these commands on the client API's internal and
  framebuffer state are fully realized. No other state is affected by
  execution of the fence command.

If clients are passing the fence fd (from EGL_ANDROID_native_fence_sync)
to a compositor, that fence must only be signaled once the framebuffer
is resolved and not before as is currently the case.

v2: fixup assert to use GL_SYNC_GPU_COMMANDS_COMPLETE (Chad)

Reported-by: Sergi Granell <xerpi.g.12@gmail.com>
Fixes: c636284ee8ee ("i965/sync: Implement DRI2_Fence extension")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sergi Granell <xerpi.g.12@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Chad Versace <chadversary@chromium.org>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chadversary@chromium.org>
src/mesa/drivers/dri/i965/brw_sync.c