zink: force explicit fence only on first frame flush

we have implicit sync hooked up for drivers now so we don't need to worry
about drawing over our frontbuffer unexpectedly

still a weird issue remaining where we miss the first frame without an explicit
fence, but I expect that will get resolved eventually by wsi

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9290>
This commit is contained in:
Mike Blumenkrantz 2020-10-08 14:56:37 -04:00
parent bbfeebabfd
commit e93ca92d4a
2 changed files with 13 additions and 12 deletions

View File

@ -1638,18 +1638,18 @@ zink_flush(struct pipe_context *pctx,
zink_fence_reference(zink_screen(pctx->screen),
(struct zink_fence **)pfence,
batch->fence);
/* HACK:
* For some strange reason, we need to finish before presenting, or else
* we start rendering on top of the back-buffer for the next frame. This
* seems like a bug in the DRI-driver to me, because we really should
* be properly protected by fences here, and the back-buffer should
* either be swapped with the front-buffer, or blitted from. But for
* some strange reason, neither of these things happen.
*/
if (flags & PIPE_FLUSH_END_OF_FRAME)
pctx->screen->fence_finish(pctx->screen, pctx,
(struct pipe_fence_handle *)batch->fence,
PIPE_TIMEOUT_INFINITE);
if (flags & PIPE_FLUSH_END_OF_FRAME) {
/* if the first frame has not yet occurred, we need an explicit fence here
* in some cases in order to correctly draw the first frame, though it's
* unknown at this time why this is the case
*/
if (!ctx->first_frame_done)
pctx->screen->fence_finish(pctx->screen, pctx,
(struct pipe_fence_handle *)batch->fence,
PIPE_TIMEOUT_INFINITE);
ctx->first_frame_done = true;
}
}
void

View File

@ -214,6 +214,7 @@ struct zink_context {
struct pipe_stream_output_target *so_targets[PIPE_MAX_SO_OUTPUTS];
bool dirty_so_targets;
bool xfb_barrier;
bool first_frame_done;
};
static inline struct zink_context *