Re: [PATCH v4 00/38] GPU scheduler for i915 driver

Dave Gordon
2016-01-12T13:49:37Z

On 12/01/2016 11:43, John Harrison wrote:
> On 12/01/2016 04:37, Tian, Kevin wrote:
>>> From: John.C.Harrison@Intel.com
>>> Sent: Tuesday, January 12, 2016 2:42 AM
>>>
>>> From: John Harrison <John.C.Harrison@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.
>
>
>>
>> Thanks
>> Kevin
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx