On Mar 26, 2016 12:55 AM, "Kenneth Graunke" <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> wrote: > > Our driver uses the brw_render_cache mechanism to track buffers we've > rendered to and are about to sample from. > > Previously, we did a single PIPE_CONTROL with the following bits set: > - Render Target Flush > - Depth Cache Flush > - Texture Cache Invalidate > - VF Cache Invalidate > - Instruction Cache Invalidate > - CS Stall > > This combined both "top of pipe" invalidations and "bottom of pipe" > flushes, which isn't how the hardware is intended to be programmed. > > The "top of pipe" invalidations may happen right away, without any > guarantees that rendering using those caches has completed. That > rendering may continue altering the caches. The "bottom of pipe" > flushes do wait for the rendering to complete. The CS stall also > prevents further work from happening until data is flushed out. > > What we wanted to do was wait for rendering complete, flush the new > data out of the render and depth caches, wait, then invalidate any > stale data in read-only caches. We can accomplish this by doing the > "bottom of pipe" flushes with a CS stall, then the "top of pipe" > flushes as a second PIPE_CONTROL. The flushes will wait until the > rendering is complete, and the CS stall will prevent the second > PIPE_CONTROL with the invalidations from executing until the first > is done. > > Fixes dEQP-GLES3.functional.texture.specification.teximage2d_pbo > subtests on Braswell and Skylake. These tests hit the meta PBO > texture upload path, which binds the PBO as a texture and samples > from it, while rendering to the destination texture. The tests > then sample from the texture. > > For now, we leave Gen4-5 alone. It probably needs work too, but > apparently it hasn't even been setting the (G45+) TC invalidation > bit at all... This all seems reasonable. Assuming Jenkins is happy, Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> > Cc: <a href="mailto:mesa-stable@lists.freedesktop.org">mesa-stable@lists.freedesktop.org</a> > Suggested-by: Francisco Jerez <<a href="mailto:currojerez@riseup.net">currojerez@riseup.net</a>> > Signed-off-by: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> > --- > src/mesa/drivers/dri/i965/brw_pipe_control.c | 2 -- > src/mesa/drivers/dri/i965/intel_fbo.c | 15 ++++++++++++++- > 2 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c b/src/mesa/drivers/dri/i965/brw_pipe_control.c > index b41e28e..4672efd 100644 > --- a/src/mesa/drivers/dri/i965/brw_pipe_control.c > +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c > @@ -338,8 +338,6 @@ brw_emit_mi_flush(struct brw_context *brw) > } > brw_emit_pipe_control_flush(brw, flags); > } > - > - brw_render_cache_set_clear(brw); > } > > int > diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c b/src/mesa/drivers/dri/i965/intel_fbo.c > index b7b6796..707041a 100644 > --- a/src/mesa/drivers/dri/i965/intel_fbo.c > +++ b/src/mesa/drivers/dri/i965/intel_fbo.c > @@ -1065,7 +1065,20 @@ brw_render_cache_set_check_flush(struct brw_context *brw, drm_intel_bo *bo) > if (!_mesa_set_search(brw->render_cache, bo)) > return; > > - brw_emit_mi_flush(brw); > + if (brw->gen >= 6) { > + brw_emit_pipe_control_flush(brw, > + PIPE_CONTROL_DEPTH_CACHE_FLUSH | > + PIPE_CONTROL_RENDER_TARGET_FLUSH | > + PIPE_CONTROL_CS_STALL); > + > + brw_emit_pipe_control_flush(brw, > + PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE | > + PIPE_CONTROL_CONST_CACHE_INVALIDATE); > + } else { > + brw_emit_mi_flush(brw); > + } > + > + brw_render_cache_set_clear(brw); > } > > /** > -- > 2.7.3 > > _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>