[Intel-gfx] [PATCH v5] drm/i915 : Added Programming of the MOCS

Daniel Vetter daniel at ffwll.ch
Mon Jun 22 06:50:37 PDT 2015


On Fri, Jun 19, 2015 at 06:34:22AM +0000, Antoine, Peter wrote:
> On Thu, 2015-06-18 at 16:50 +0100, Damien Lespiau wrote:
> > On Thu, Jun 18, 2015 at 03:45:44PM +0100, Antoine, Peter wrote:
> > > Not a blocker. It gets a little more interesting, as the L3CC
> > > registers are shared across all engines, but is only saved in the RCS
> > > context. But, it is reset on the context switch when ELSP is set. So
> > > we would have to program it (i.e. MMIO) and also set it in the batch
> > > start for the RCS. Each ring would have to have a proper
> > > init_context() and these registers programmed there.
> > 
> > Hum, so yes, it's like you say. I think leaving a comment somewhere in
> > the init path telling us we rely on the RCS init_context() for all the
> > rings would be nice, but that's extra topping that can be done any time.
> > 
> It is in the file header for the mocs.h in the comment before the table
> is defines and in the function header for the init. I can add another
> one before it's called, but that might be a little overkill. :)

Or can we demote the init_context vfunc to a device-global one? We're
already piling up gt vfuncs in dev_priv->gt, I think it'd fit in there
nicely. Bonus points for pulling the actual setup calls out of per-ring
code too.

Doing setup across all rings in an RCS callback is indeed really
surprising and pretty much guarantees tears and screaming down the road.
Our init paths are littered with little confusions like this causing
really annoying bugs all over.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list