On Sat, Oct 29, 2011 at 09:40:57PM +0200, Daniel Vetter wrote: > On Sat, Oct 29, 2011 at 12:22:25PM -0700, Ben Widawsky wrote: > > On Sat, 29 Oct 2011 11:45:34 -0700 > > Eric Anholt <e...@anholt.net> wrote: > > > > > 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. > > > > > > Just using wait_request interface would require less code and not have > > > that issue. > > > > I must be missing something simple, but I didn't see an easy way to use > > that interface to do what I want. Instead of outstanding requests, I'd > > need to start tracking per fd seqnos (yes it's done elsewhere, but > > didn't seem much different to me). > > We track request per-fd already in the file_priv, so if the oustanding > requests is already at the limit and would go over the top with an > additional request, you can just look at the previously submitted request > for this fd, grab it's seqno and wait for that. The ugly part then just > boils down to allowing wait_request without the struct_mutex held. But > that's rather generally usefull infrastructure.
Meh, not wait on the previously submitted req, but the first one to retire next, obviously. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
