On Wed, Oct 03, 2018 at 01:34:47PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-10-03 13:28:30)
> > On Wed, Oct 03, 2018 at 12:29:53PM +0100, Chris Wilson wrote:
> > > Quoting Stanislav Lisovskiy (2018-10-02 10:38:53)
> > > > diff --git a/src/sna/sna_render.h b/src/sna/sna_render.h
> > > > index 6669af9d..ef88d1f9 100644
> > > > --- a/src/sna/sna_render.h
> > > > +++ b/src/sna/sna_render.h
> > > > @@ -139,20 +139,25 @@ struct sna_composite_op {
> > > >  
> > > >                 struct {
> > > >                         uint32_t flags;
> > > > +                       uint8_t wm_kernel;
> > > >                 } gen6;
> > > >  
> > > >                 struct {
> > > >                         uint32_t flags;
> > > > +                       uint8_t wm_kernel;
> > > >                 } gen7;
> > > >  
> > > >                 struct {
> > > >                         uint32_t flags;
> > > > +                       uint8_t wm_kernel;
> > > >                 } gen8;
> > > >  
> > > >                 struct {
> > > >                         uint32_t flags;
> > > > +                       uint8_t wm_kernel;
> > > >                 } gen9;
> > > >         } u;
> > > > +       unsigned long gen9_kernel;
> > > 
> > > Do you want to try again without the surplus changes? Maybe ask Ville
> > > for his patches to base your work on?
> > 
> > Unfortunaltely I still haven't managed to figure out why chrome
> > becomes a bit hangy on my ivb when I start to emit
> > 3DSTATE_CONSTANT_* in the ddx.
> > 
> > The error state is somewhat peculiar BTW. It always hangs at the
> > start of a batch like so:
> > 
> >   ACTHD: 0x00000000 00efa014
> > 
> > batch (rcs0 (submitted by chrome [23031], ctx 2 [5], score 0)) at 0x00000000_00efa000
> > 0x00efa000:      0x7a000003: PIPE_CONTROL
> > 0x00efa004:      0x00105021:    qword write, cs stall, render target cache flush, DC flush, depth cache flush, 
> > 0x00efa008:      0x00000000:    destination address
> > 0x00efa00c:      0x00000000:    immediate dword low
> > 0x00efa010:      0x00000000:    immediate dword high
> > 0x00efa014:      0x61010008: STATE_BASE_ADDRESS
> > 0x00efa018:      0x00000111:    general state base address 0x00000110
> > 0x00efa01c:      0x00001001:    surface state base address 0x00001000
> > 0x00efa020:      0x00001001:    dynamic state base address 0x00001000
> > 0x00efa024:      0x00000001:    indirect state base address 0x00000000
> > 0x00efa028:      0x00005001:    instruction state base address 0x00005000
> > 0x00efa02c:      0x00000001:    general state upper bound disabled
> > 0x00efa030:      0xfffff001:    dynamic state upper bound 0xfffff000
> > 0x00efa034:      0x00000001:    indirect state upper bound disabled
> > 0x00efa038:      0x00000001:    instruction state upper bound disabled
> > 0x00efa03c:      0x7a000003: PIPE_CONTROL
> > 0x00efa040:      0x00000c04:    no write, instruction cache invalidate, texture cache invalidate, state cache invalida>
> > 0x00efa044:      0x00000000:    destination address
> > 0x00efa048:      0x00000000:    immediate dword low
> > 0x00efa04c:      0x00000000:    immediate dword high
> > 
> > No idea why there's an end of pipe flush as the first thing in the batch,
> > and no idea how that could possibly hang due to stuff that was done in
> > another batch/context.
> 
> Yeah, that is suspect. :|
> 
> Waitasec qword write to 0? That seems fishy.

Yeah that one looked a bit odd to me as well, however looks like there
is something there:

Active (rcs0) [18]:
    00000000_03085000    20480 3f 00 00 dirty LLC
    00000000_00000000     4096 3e 02 00 dirty LLC

Full error state attached, in case you're curious about other details.

-- 
Ville Syrjälä
Intel