From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/8] drm/i915: Get rid of the synchronous flag in switch_mm Date: Thu, 19 Jun 2014 18:03:41 +0200 Message-ID: <20140619160341.GV5821@phenom.ffwll.local> References: <1403108138-6366-1-git-send-email-oscar.mateo@intel.com> <20140618195031.GQ5821@phenom.ffwll.local> <92648605EABDA246B775AAB04C95A7A301320D53@IRSMSX103.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by gabe.freedesktop.org (Postfix) with ESMTP id 4EE3C6E16E for ; Thu, 19 Jun 2014 09:03:51 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so2559104wgg.32 for ; Thu, 19 Jun 2014 09:03:50 -0700 (PDT) Content-Disposition: inline In-Reply-To: <92648605EABDA246B775AAB04C95A7A301320D53@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 Thu, Jun 19, 2014 at 02:00:24PM +0000, Mateo Lozano, Oscar wrote: > > -----Original Message----- > > From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Wednesday, June 18, 2014 8:51 PM > > To: Mateo Lozano, Oscar > > Cc: intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915: Get rid of the synchrono= us flag > > in switch_mm > > = > > On Wed, Jun 18, 2014 at 05:15:35PM +0100, oscar.mateo@intel.com wrote: > > > From: Oscar Mateo > > > > > > As a first step, split switch_mm into two different functions: > > > sync_switch_mm (currently used by ppgtt_enable) and switch_mm (used by > > > the outside world). > > > > > > Signed-off-by: Oscar Mateo > > = > > I guess that jira task description was a bit unclear - removing the bool > > synchronous argument isn't the goal itself. The idea was to rework the = gpu > > reset sequence so that it matches the same sequence we use at driver lo= ad > > and so can use the same code. This patch removes the bool synchronous, = but > > the logical split with two different ways to load ppgtt is still there. > = > No, I realized I didn=B4t really do anything, but I saw the possibility o= f saving one special casing in Execlists and I jumped for it, forgetting ab= out the JIRA task (psychological fixation, I guess) > Anyway, I was going to ask for more details on the JIRA... > = > > The reason for aiming as hard as possible to use the exact same code for > > driver load, gpu reset and runtime pm/system resume is that we've simply > > seen too many bugs due to slight variations and unintended omissions. > > = > > If for some really odd reason this is impossible (e.g. when the gpu nee= ds a > > special dance when coming out of reset) then we need a giant comment > > explaining the magic. But without such a clear reason the goal should a= lways > > be to have just 1 single autorative piece of code for a given state tra= nsition. > = > Ok. How about this: on ring init, I manually set the Aliasing PPGTT and > the default context object synchronously via MMIO writes (the Aliasing > PPGTT via the ppgtt->sync_switch_mm() and the default context directly > using the CCID). I assume that, whenever we are in ring init, the GPU is > sufficiently idle to manually frob all the required registers. That way, > I get rid of i915_gem_context_enable() completely and I don=B4t have to do > any special casing at all. Ring commands (PPGTT switch and > MI_SET_CONTEXT) are then left completely for the normal do_switch(). > What do you think? Can't we do the ring_init loading the same way as a normal context switch? That's kinda my dream land thing. Of course if the initial loading is sufficiently differnt then we have a problem. So essentially do_switch would check whether the ppgtt changes and load that as part of the context. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch