[Intel-gfx] [PATCH 10/13] drm/i915: Enable PPGTT command parser checks

Chris Wilson chris at chris-wilson.co.uk
Thu Jan 30 00:08:29 CET 2014


On Wed, Jan 29, 2014 at 03:00:11PM -0800, Volkin, Bradley D wrote:
> On Wed, Jan 29, 2014 at 02:33:55PM -0800, Chris Wilson wrote:
> > On Wed, Jan 29, 2014 at 01:55:11PM -0800, bradley.d.volkin at intel.com wrote:
> > > From: Brad Volkin <bradley.d.volkin at intel.com>
> > > 
> > > Various commands that access memory have a bit to determine whether
> > > the graphics address specified in the command should use the GGTT or
> > > PPGTT for translation. These checks ensure that the bit indicates
> > > PPGTT translation.
> > > 
> > > Most of these checks use the existing bit-checking infrastructure.
> > > The PIPE_CONTROL and MI_FLUSH_DW commands, however, are multi-function
> > > commands. The GGTT/PPGTT bit is only relevant for certain uses of the
> > > command. As such, this change also extends the bit-checking code to
> > > include a "condition" mask and offset. If the condition mask is non-zero
> > > then the parser only performs the bit check when the bits specified by
> > > the condition mask/offset are also non-zero.
> > > 
> > > NOTE: At this point in the series PPGTT must be enabled for the parser
> > > to work correctly. If it's not enabled, userspace will not be setting
> > > the PPGTT bits the way the parser requires. VLV is the only platform
> > > where this is a problem, so at this point, we disable parsing for VLV.
> > 
> > That doesn't make sense. Are we not verifying that userspace has set the
> > bits as appropriate for the hardware setup? So the value we expect
> > depends upon how we have enabled ppgtt (or not).
> 
> We could but don't currently. I was under the impression the parser wasn't
> seen as having as much benefit without ppgtt and that we're generally moving
> towards ppgtt as the default for all relevant platforms.

Oh, I remember that argument. It's just the way you phrased the note
made me think that it was a limitation of the patch.

Personally I would implement the checks against the hardware state as we
know it. It's a nice pedalogical example, and removes a buried
assumption from the code.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list