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:39:21 +0200 Message-ID: <20140707123921.GR5821@phenom.ffwll.local> References: <20140620210035.GC32083@bdvolkin-ubuntu-desktop> <92648605EABDA246B775AAB04C95A7A3137BEC32@IRSMSX103.ger.corp.intel.com> <20140623131355.GA14360@nuc-i3427.alporthouse.com> <92648605EABDA246B775AAB04C95A7A3137BEC64@IRSMSX103.ger.corp.intel.com> <20140623132719.GB14360@nuc-i3427.alporthouse.com> <92648605EABDA246B775AAB04C95A7A3137BEDF8@IRSMSX103.ger.corp.intel.com> <20140623134140.GC14360@nuc-i3427.alporthouse.com> <92648605EABDA246B775AAB04C95A7A3137BEE76@IRSMSX103.ger.corp.intel.com> <20140623191010.GA31797@bdvolkin-ubuntu-desktop> <92648605EABDA246B775AAB04C95A7A3137C3399@IRSMSX103.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by gabe.freedesktop.org (Postfix) with ESMTP id 70A926E1C0 for ; Mon, 7 Jul 2014 05:39:19 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so15761268wib.7 for ; Mon, 07 Jul 2014 05:39:16 -0700 (PDT) Content-Disposition: inline In-Reply-To: <92648605EABDA246B775AAB04C95A7A3137C3399@IRSMSX103.ger.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Mateo Lozano, Oscar" Cc: "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org On Tue, Jun 24, 2014 at 12:29:45PM +0000, Mateo Lozano, Oscar wrote: > > -----Original Message----- > > From: Volkin, Bradley D > > Sent: Monday, June 23, 2014 8:10 PM > > To: Mateo Lozano, Oscar > > Cc: Chris Wilson; intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical ring > > submission mechanism > > There are 3 cases of non-execbuffer submissions that I can think of: flips, > > render state, and clear-buffer (proposed patches on the list). I wonder if the > > right approach might be to use batchbuffers with a small wrapper around the > > dispatch_execbuffer/emit_bb_start vfuncs. Basically the rule would be to > > only touch a ringbuffer from within the intel_engine_cs vfuncs, which always > > know which set of functions to use. > > > > For flips, we could use MMIO flips. Render state already uses the existing > > dispatch_execbuffer() and add_request(). The clear code could potentially do > > the same. There would obviously be some overhead in using a batch buffer > > for what could end up being just a few commands. Perhaps the batch buffer > > pool code from the command parser would help though. > > This has another positive side-effect: the scheduler guys do not like > things inside the ring without a proper batchbuffer & request, because > it makes their life more complex. I'm probably missing all the context here but I've thought this is the plan forward: We'll use mmio flips with execlists and otherwise we'll submit everything with the right context/engine whaterever using execlist-specific functions. Since the gpu clear code isn't merged yet we can imo ignore it for now and merge execlists first. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch