[Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness
ben at bwidawsk.net
Sat Oct 29 12:27:26 PDT 2011
On Sat, 29 Oct 2011 09:07:35 +0100
Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky <ben at bwidawsk.net> wrote:
> > These patches are pretty raw as I'm hoping to get some comments before
> > working to hard too clean them up. The goal is GPU fairness for clients
> > running on i915.
> The biggest danger I see is that num_outstanding is only decremented
> in retire_requests, which under the right circumstances (a single hog or
> a plurarity) will cause latencies of over 1s. Also this unnecessarily
> penalises benchmarks, i.e. a single active client.
Well single active clients only exist for 2d, right? I was thinking I'd
disable the scheduler, and only start using it when the user forced it,
or the number of open drm fds is > 1.
> To start the bikeshedding, we need a debugfs to show the current clients
> and their scheduling data.
> I would like to see the hog values moved at least into the file_priv and
> a gpuprio ioctl so that we can start prioritising by file. It would then
> be possible for a compositing render server to open a fd for it owns
> high priority composition and a fd per client and individual tune their
> priorities. And before you know what's hit you someone will request
The interface for the internal customer more or less does this. Even more
complicated is that in the long run, we probably desire more than fd
granularity (webGL for instance). I was trying to keep this as general as
possible though as it does seem to solve a problem and can be built upon
> It would probably be best to overengineer the ioctl interface as a
> facsimile of the more recent cpu schedulers.
Could you give some advice as to what parameters you would like to see?
More information about the Intel-gfx