[Intel-gfx] [PATCH xf86-video-intel v1] sna: Added AYUV format support for textured and sprite video adapters.

[Chris Wilson]

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.
-Chris