[Mesa-dev] [PATCH v2 3/3] i965/gen9: Add workarounds for object preemption.

[Rafael Antognolli]

On Wed, Oct 31, 2018 at 04:27:31PM -0700, Kenneth Graunke wrote:
> On Wednesday, October 31, 2018 11:15:28 AM PDT Rafael Antognolli wrote:
> > On Tue, Oct 30, 2018 at 04:32:54PM -0700, Kenneth Graunke wrote:
> > > On Monday, October 29, 2018 10:19:54 AM PDT Rafael Antognolli wrote:
> > > Do we need any stalling when whacking CS_CHICKEN1...?
> > 
> > Hmmm... there's this:
> > 
> > "A fixed function pipe flush is required before modifying this field"
> > 
> > in the programming notes. I'm not sure what that is, but I assume it's
> > some type of PIPE_CONTROL?
> 
> Yeah.  I'm not honestly sure what kind - "fixed function pipe flush"
> isn't a thing.  Nobody ever uses wording that corresponds to actual
> mechanics of the hardware. :(
> 
> Maybe this would work:
> 
>     brw_emit_end_of_pipe_sync(brw, PIPE_CONTROL_RENDER_TARGET_FLUSH);

Hey Ken,

Ressurrecting this old thread... I just noticed that I had this in patch
2/3 (inside brw_enable_obj_preemption()):

 brw_emit_pipe_control_flush(brw, PIPE_CONTROL_FLUSH_ENABLE);

That's bit 7 of the PIPE_CONTROL, and from the docs:

 "Hardware on parsing PIPECONTROL command with Pipe Control Flush Enable
 set will wait for all the outstanding post sync operations
 corresponding to previously executed PIPECONTROL commands are complete
 before making forward progress."

Do you think that's maybe what they meant? And in that case, I guess
maybe I would need a PIPE_CONTROL with post sync operation right before
this one, right?

> > > We may also need to disable autostripping by whacking some chicken
> > > registers if it's enabled (Gen9 WA #0799).  Which would be lame,
> > 
> > Looking again at #0799, it seems it's only applicable up to C0 on SKL,
> > and B0 on BXT. So maybe we should be fine here? Or just disable it on
> > BXT?
> 
> You're right, I misread that.  (I saw the Gen8 "FROM" tag and didn't
> notice that it uses "UNTIL" on Gen9...)  Nothing to do here.
> 
> > > because that's likely a useful optimization.  I guess we could disable
> > > preemption for TRILIST and LINELIST as well to be safe.
> > 
> > Is this because of the autostripping mentioned above, or some other
> > workaround? Or just your impression?
> > 
> > I can update it to include that, but just want to be sure that it's
> > still applicable, once we figure the thing about #0799.
> 
> Autostrip converts TRILIST/LINELIST into TRISTRIP/LINESTRIP, so
> the idea would be to avoid preemption for anything that hits the
> autostrip feature.  But, no need, as you noted above.
> 
> --Ken