From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [RFC 03/44] drm/i915: Add extra add_request calls Date: Tue, 8 Jul 2014 08:44:33 +0100 Message-ID: <20140708074433.GG26405@nuc-i3427.alporthouse.com> References: <1403803475-16337-1-git-send-email-John.C.Harrison@Intel.com> <1403803475-16337-4-git-send-email-John.C.Harrison@Intel.com> <20140630141016.45dd3ff9@jbarnes-desktop> <20140707184147.GV5821@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from fireflyinternet.com (mail.fireflyinternet.com [87.106.93.118]) by gabe.freedesktop.org (Postfix) with ESMTP id 55D576E4FC for ; Tue, 8 Jul 2014 00:44:45 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140707184147.GV5821@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Intel-GFX@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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@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