On Mon, Jun 5, 2017 at 10:50 AM, Anuj Phogat <anuj.pho...@gmail.com> wrote:
> On Sun, Jun 4, 2017 at 9:53 PM, Jason Ekstrand <ja...@jlekstrand.net>
> wrote:
> > Without this stall, the test group ES3-CTS.functional.fbo.msaa.\* hangs
> > about 1 out of every 2 or 3 times on my Sky Lake GT3 laptop. With the
> > flush and stall, I can run it 6 times in a row without a hang.
> >
> > Cc: "17.1" <mesa-sta...@lists.freedesktop.org>
> > ---
> > src/mesa/drivers/dri/i965/brw_blorp.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> > index c452b7e..bfb866a 100644
> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > @@ -1127,6 +1127,20 @@ intel_hiz_exec(struct brw_context *brw, struct
> intel_mipmap_tree *mt,
> > {
> > const char *opname = NULL;
> >
> > + /* From the Ivy Bridge PRM, Vol. 2, pt. 1, section 11.5.3.1 "Depth
> > + * Buffer Clear":
> > + *
> > + * "If other rendering operations have preceded this clear, a
> > + * PIPE_CONTROL with depth cache flush enabled, Depth Stall bit
> enabled
> > + * must be issued before the rectangle primitive used for the
> depth
> > + * buffer clear operation."
> > + *
> > + * This is similar to what is required for CCS operations.
> > + */
> > + brw_emit_pipe_control_flush(brw,
> > + PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> > + PIPE_CONTROL_DEPTH_STALL);
> > +
> We're already doing this in brw_fast_clear_depth(). There is also a
> related comment in the same function:
>
> * In addition, from the Ivybridge PRM, volume 2, 1.10.4.1
> PIPE_CONTROL,
> * Depth Cache Flush Enable:
> *
> * This bit must not be set when Depth Stall Enable bit is set in
> * this packet.
> *
> * This is confirmed to hold for real, HSW gets immediate gpu hangs.
> *
> * Therefore issue two pipe control flushes, one for cache flush and
> * another for depth stall.
>
> I think you can simply move the relevant code from brw_fast_clear_depth()
> to intel_hiz_exec().
>
Right. Somehow I missed that. To put a finer point on things, I don't
think it's required for depth resolves but it does seem to be needed for
HiZ resolves which makes sense because they are basically the same as
fast-clears only they write a different value to the HIZ buffer.
I'll send out a new patch now that I've thought about it more.
> > switch (op) {
> > case BLORP_HIZ_OP_DEPTH_RESOLVE:
> > opname = "depth resolve";
> > --
> > 2.5.0.400.gff86faf
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
