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

Dave Gordon david.s.gordon at intel.com
Tue Jan 12 05:49:14 PST 2016

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"!

> 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.
>> Thanks
>> Kevin
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

More information about the Intel-gfx mailing list