Re: [PATCH v5 09/35] drm/i915: Force MMIO flips when scheduler enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 22, 2016 at 12:42:48PM -0800, Jesse Barnes wrote:
> On 02/20/2016 01:22 AM, Chris Wilson wrote:
> > On Fri, Feb 19, 2016 at 11:28:05AM -0800, Jesse Barnes wrote:
> >> On 02/18/2016 06:26 AM, John.C.Harrison@xxxxxxxxx wrote:
> >>> From: John Harrison <John.C.Harrison@xxxxxxxxx>
> >>>
> >>> MMIO flips are the preferred mechanism now
> > 
> > Because introducing variable latency in waking up a big core is a good
> > idea?
> 
> Is the latency variability really that bad?  I'm not too concerned about waking up the core either, I think it's going to be hit up quite a bit in these situations anyway, and vblanks should be driving the rendering as well.

The workqueue we use is subject to being preempted by the user, so the
latency can be made arbitrarily large. Also, we don't control what tasks
are ahead of the flip.
 
> >> but more importantly, pipe
> >>> based flips cause issues for the scheduler. Specifically, submitting
> >>> work to the rings around the side of the scheduler could cause that
> >>> work to be lost if the scheduler generates a pre-emption event on that
> >>> ring.
> > 
> > No. That is just incredibily bad design.
> > 
> >> Why can't we use mmio flips unconditionally?  Maarten or Ville?
> > 
> > Why would we want to? CS flips work just fine in execlists and no reason
> > was ever given as to why they were not enabled, just laziness.
> 
> I'm not saying it can't be done, but I thought with atomic we decided to go with mmio because it makes things a lot simpler (iirc Ville's design did that way back?).

My point is that the interface to the scheduler excludes even the
possibility of doing so because it is not cleanly segrated into a tool
for determining the next request to execute but instead subsumes half of
GEM and half of the engine backend becoming another unwanted midlayer
incorporating its own policy. The scheduler doesn't even deal in
requests, which is what prevents us from constructing a request here
with the known dependency and passing it to the scheduler for execution.

As I saw it, CS flips would be one of the best demonstrations for a
scheduler - because to execute the flip within the deadline should
cause a priority boost for all the prerequisites, and then ideally
reduce the number of missed target msc under load. (Though we can
equally promote the last_write_request through another scheduler
interface.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux