On Sat, 29 Oct 2011 09:07:35 +0100 Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky <b...@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. Agreed. > > 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 > cgroups... 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 easily. > > 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? > -Chris > Ben _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
