From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 26/53] drm/i915/bdw: New logical ring submission mechanism Date: Mon, 7 Jul 2014 14:41:44 +0200 Message-ID: <20140707124144.GS5821@phenom.ffwll.local> References: <1402673891-14618-1-git-send-email-oscar.mateo@intel.com> <1402673891-14618-27-git-send-email-oscar.mateo@intel.com> <20140620210035.GC32083@bdvolkin-ubuntu-desktop> <92648605EABDA246B775AAB04C95A7A3137BEC32@IRSMSX103.ger.corp.intel.com> <20140623131355.GA14360@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by gabe.freedesktop.org (Postfix) with ESMTP id C5FBC6E303 for ; Mon, 7 Jul 2014 05:41:36 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so15822846wiv.3 for ; Mon, 07 Jul 2014 05:41:34 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140623131355.GA14360@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , "Mateo Lozano, Oscar" , "Volkin, Bradley D" , "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org On Mon, Jun 23, 2014 at 02:13:55PM +0100, Chris Wilson wrote: > On Mon, Jun 23, 2014 at 01:09:37PM +0000, Mateo Lozano, Oscar wrote: > > So far, yes, but that=B4s only because I artificially made intel_lrc.c = self-contained, as Daniel requested. What if we need to execute commands fr= om somewhere else, like in intel_gen7_queue_flip()? > > = > > And this takes me to another discussion: this logical ring vs legacy ri= ng split is probably a good idea (time will tell), but we should provide a = way of sending commands for execution without knowing if Execlists are enab= led or not. In the early series that was easy because we reused the ring_be= gin, ring_emit & ring_advance functions, but this is not the case anymore. = And without this, sooner or later somebody will break legacy or execlists (= this already happened last week, when somebody here was implementing native= sync without knowing about Execlists). > > = > > So, the questions is: how do you feel about a dev_priv.gt vfunc that ta= kes a context, a ring, an array of DWORDS and a BB length and does the inte= l_(logical)_ring_begin/emit/advance based on i915.enable_execlists? > = > I'm still baffled by the design. intel_ring_begin() and friends should > be able to find their context (logical or legacy) from the ring and > dtrt. Well I'm opting for a the different approach of presuming that the callers knows whether we're running with execlists or legacy rings and so will have a clean (and full) split. If we really need to submit massive amounts of cs commands from the kernel we should launch that as a batch, which should be fairly unform for both legacy ring and execlists mode. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch