From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC 03/44] drm/i915: Add extra add_request calls Date: Mon, 7 Jul 2014 20:41:47 +0200 Message-ID: <20140707184147.GV5821@phenom.ffwll.local> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by gabe.freedesktop.org (Postfix) with ESMTP id 38F7B6E462 for ; Mon, 7 Jul 2014 11:41:37 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w62so4895223wes.10 for ; Mon, 07 Jul 2014 11:41:36 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140630141016.45dd3ff9@jbarnes-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Jesse Barnes Cc: Intel-GFX@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch