[Intel-gfx] [PATCH v3 1/2] drm/i915: add render state initialization

[Mateo Lozano, Oscar]

> -----Original Message-----
> From: Lespiau, Damien
> Sent: Wednesday, May 14, 2014 12:14 PM
> To: Mateo Lozano, Oscar
> Cc: Mika Kuoppala; intel-gfx at lists.freedesktop.org; ben at bwidawsk.net;
> miku at iki.fi; kristen at linux.intel.com
> Subject: Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: add render state initialization
> 
> On Wed, May 14, 2014 at 10:24:53AM +0000, Mateo Lozano, Oscar wrote:
> > Hi Mika,
> >
> > > -----Original Message-----
> > > From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
> > > Behalf Of Mika Kuoppala
> > > Sent: Tuesday, May 06, 2014 3:30 PM
> > > To: intel-gfx at lists.freedesktop.org
> > > Cc: ben at bwidawsk.net; miku at iki.fi; kristen at linux.intel.com
> > > Subject: [Intel-gfx] [PATCH v3 1/2] drm/i915: add render state
> > > initialization
> > >
> > > HW guys say that it is not a cool idea to let device go into rc6
> > > without proper 3d pipeline state.
> > >
> > > For each new uninitialized context, generate a valid null render
> > > state to be run on context creation.
> >
> > In Android, we have been seeing a problem in BDW D0 stepping (C0 is
> > fine), in which actual rendering does not happen, even though
> > everything seems to be healthy. The only "tell" seems to be that the
> > pixel shader invocation count does not go up.  I wouldn´t dare say I
> > understand why this fixes our problem, but it clearly does, so feel
> > free to add:
> >
> > Tested-by: Oscar Mateo <oscar.mateo at intel.com>
> 
> Stating the obvious here, mainly for my own understanding :)
> 
> FWIW, that looks like the userspace driver you are using actually relying on the
> kernel setting up a golden state and missing "one bit" or one packet. For
> instance it could be that it's missing a 3DSTATE_WM_HZ_OP command (that's
> the last fix Ken did in the gen8 render copy state).
> 
> Out of sheer luck (or almost :) we happen to have this working.
> 
> So that's another kind of papering over than the one "needed" for rc6.
> 
> It seems to potentially be a useful service the kernel is providing to user space
> apps though, trying to setup a sane state so user space batches don't hang the
> GPU if they are missing one command. Of course hangs can still happen if the
> batches themselves have bugs.
> 
> How to be sure that's the correct golden state is another interesting question
> we need to answer.

Oops, sorry, I forgot a very important detail: the same userspace driver works just fine with a 3.10 kernel. I attribute this to the fact that the 3.10 kernel didn´t do MI_SET_CONTEXT unless you were explicitly creating contexts, but there could be another explanation, of course.