From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933324AbcKHLdn (ORCPT ); Tue, 8 Nov 2016 06:33:43 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34902 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933260AbcKHLdA (ORCPT ); Tue, 8 Nov 2016 06:33:00 -0500 Date: Tue, 8 Nov 2016 12:32:56 +0100 From: Daniel Vetter To: Chris Wilson , Gustavo Padovan , dri-devel@lists.freedesktop.org, marcheu@google.com, Daniel Stone , seanpaul@google.com, Daniel Vetter , 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: <20161108113256.q52243qihb6kwe2h@phenom.ffwll.local> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161108103508.GH18604@nuc-i3427.alporthouse.com> X-Operating-System: Linux phenom 4.6.0-1-amd64 User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. The reason for that is that with explicit fencing we want to allow userspace to overwrite any existing implicit fences that might hang around. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch