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@xxxxxxxxx wrote: > > > From: Brad Volkin <bradley.d.volkin@xxxxxxxxx> > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
