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@xxxxxxxxx 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
