[Intel-gfx] [PATCH v4 00/38] GPU scheduler for i915 driver

[Tian, Kevin]

> From: Gordon, David S
> Sent: Tuesday, January 12, 2016 9:49 PM
> 
> On 12/01/2016 11:43, John Harrison wrote:
> > On 12/01/2016 04:37, Tian, Kevin wrote:
> >>> From: John.C.Harrison at Intel.com
> >>> Sent: Tuesday, January 12, 2016 2:42 AM
> >>>
> >>> From: John Harrison <John.C.Harrison at Intel.com>
> >>>
> >>> Implemented a batch buffer submission scheduler for the i915 DRM
> >>> driver.
> >>>
> >>> The general theory of operation is that when batch buffers are
> >>> submitted to the driver, the execbuffer() code assigns a unique seqno
> >>> value and then packages up all the information required to execute the
> >>> batch buffer at a later time. This package is given over to the
> >>> scheduler which adds it to an internal node list. The scheduler also
> >>> scans the list of objects associated with the batch buffer and
> >>> compares them against the objects already in use by other buffers in
> >>> the node list. If matches are found then the new batch buffer node is
> >>> marked as being dependent upon the matching node. The same is done for
> >>> the context object. The scheduler also bumps up the priority of such
> >>> matching nodes on the grounds that the more dependencies a given batch
> >>> buffer has the more important it is likely to be.
> >>>
> >> A curious question. Is this new GPU scheduler still useful when GuC
> >> is enabled? Sorry if this Q. has been answered before.
> > Yes. The scheduler works with any back end submission mechanism -
> > legacy ring buffer, execlist or Guc. Indeed, the pre-emption support
> > (next patch series in the set) currently requires the GuC. Execlist
> > support is possible but just not currently planned due to time
> > constraints. Legacy ring buffer pre-emption is very different and a
> > lot more work for very little benefit - pre-execlist hardware does not
> > support very much in the way of pre-emption facilities.
> We have previously implemented preemption on gen7 ringbuffer, but just
> as a proof of concept and we're not going to push that upstream.
> Ringbuffer mode can in any case only support co-operative preemption,
> whereas execlist and GuC modes don't require (much) cooperation from
> preemptible tasks.
> >
> >
> > The GuC itself does not really do much in the way of scheduling. It
> > does know about the
> In the line above, John meant "does NOT know"!
> 
> .Dave.
> > dependencies between batch buffers, for example, so cannot re-order
> > work according to priority. Adding such support without still having
> > large chunks of kernel driver support is a currently unscoped and
> > unplanning task.
> >

Thank you both for clarification. It makes sense.

Thanks
Kevin