From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933615AbcKHMwc (ORCPT ); Tue, 8 Nov 2016 07:52:32 -0500 Received: from mail.fireflyinternet.com ([109.228.58.192]:53104 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932477AbcKHMwa (ORCPT ); Tue, 8 Nov 2016 07:52:30 -0500 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Date: Tue, 8 Nov 2016 12:52:09 +0000 From: Chris Wilson To: Gustavo Padovan , dri-devel@lists.freedesktop.org, marcheu@google.com, Daniel Stone , seanpaul@google.com, linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com Subject: Re: [PATCH v7 0/3] drm: add explict fencing Message-ID: <20161108125209.GA11395@nuc-i3427.alporthouse.com> Mail-Followup-To: Chris Wilson , Gustavo Padovan , dri-devel@lists.freedesktop.org, marcheu@google.com, Daniel Stone , seanpaul@google.com, linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com References: <1478588090-8664-1-git-send-email-gustavo@padovan.org> <20161108103508.GH18604@nuc-i3427.alporthouse.com> <20161108113256.q52243qihb6kwe2h@phenom.ffwll.local> <20161108114551.GL18604@nuc-i3427.alporthouse.com> <20161108124340.de4gqcuhkwn3uq2u@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161108124340.de4gqcuhkwn3uq2u@phenom.ffwll.local> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 08, 2016 at 01:43:40PM +0100, Daniel Vetter wrote: > On Tue, Nov 08, 2016 at 11:45:51AM +0000, Chris Wilson wrote: > > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote: > > > On Tue, Nov 08, 2016 at 10:35:08AM +0000, Chris Wilson wrote: > > > > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote: > > > > > From: Gustavo Padovan > > > > > > > > > > Hi, > > > > > > > > > > This is yet another version of the DRM fences patches. Please refer > > > > > to the cover letter[1] in a previous version to check for more details. > > > > > > > > Explicit fencing is not a superset of the implicit fences. The driver > > > > may be using implicit fences (on a reservation object) to serialise > > > > asynchronous operations wrt to each other (such as dispatching threads > > > > to flush cpu caches to memory, manipulating page tables and the like > > > > before the flip). Since the user doesn't know about these operations, > > > > they are not included in the explicit fence they provide, at which point > > > > we can't trust their fence to the exclusion of the implicit fences... > > > > > > My thoughts are that in atomic_check drivers just fill in the fence from > > > the reservation_object (i.e. the uapi implicit fencing part). If there's > > > any additional work that's queued up in ->prepare_fb then I guess the > > > driver needs to track that internally, but _only_ for kernel-internally > > > queued work. > > > > That's not a trivial task to work out which of the fence contexts within > > the reservation object are required and which are to be replaced by the > > explicit fence, esp. when you have to consider external fences. > > Hm, what kind of async kernel tasks are you thinking off? Atm I don't know > of anyone who does e.g. clflush through the gpu. And ttm bo placement > moves for display should be explicit enough that drivers will deal with > them correctly. At least that seems to have been the conclusion from the > long amdgpu thread. Now that we (i915) serialise on an reservation_object (obj->resv), we have floated ideas to use that to serialise async tasks (such as offloading the 100ms clflush to a (cpu) worker, a gpu task would pose a similar problem with a fence inserted that is not exposed to userspace). Also tempted to look at using async tasks + fences to do GTT updates but that is not a common pain point at the moment, and cases where it is the GTT thrashing itself is the issue. So how does i915 deal with ttm bo fences? -Chris -- Chris Wilson, Intel Open Source Technology Centre