> 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@xxxxxxxxx > >>> Sent: Tuesday, January 12, 2016 2:42 AM > >>> > >>> From: John Harrison <John.C.Harrison@xxxxxxxxx> > >>> > >>> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
