[Intel-gfx] [RFC 03/44] drm/i915: Add extra add_request calls

Chris Wilson chris at chris-wilson.co.uk
Tue Jul 8 09:44:33 CEST 2014


On Mon, Jul 07, 2014 at 08:41:47PM +0200, Daniel Vetter wrote:
> On Mon, Jun 30, 2014 at 02:10:16PM -0700, Jesse Barnes wrote:
> > On Thu, 26 Jun 2014 18:23:54 +0100
> > John.C.Harrison at Intel.com wrote:
> > I think "no_flush" would be more in line with some of the other
> > functions in the kernel.  "wo" makes me think of "write only".  But
> > it's not a big deal.
> > 
> > I do wonder about the rules for when add_request is needed though, and
> > I need to look later in the series for the usage.  When I looked at it
> > in relation to fences, it didn't seem to be a good fit since it looked
> > like requests got freed when the active list was cleared, vs when they
> > were actually consumed by some user.
> 
> Yeah, wo_flush is highly confusing while no_flush is rather clear. There's
> also the question of how this all will interfere with execlists since
> those patches also have the need to keep track of stuff, but slightly
> different.
> 
> I'll go through your rfc for some light reading but I think we should
> settle execlists first before proceeding with the schedule in earnest.

On top of these extra requests, it is time to worry about read-read
optimisations. I would like for busy_ioctl to tell me that a flip is
pending on a particular pipe (though that probably requires extending
the ioctl to pass back separate busy/write/read rings) and at that point
I start to worry about undue synchronisation. That seems fitting for a
request overhaul.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list