Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941112AbcJTQfr (ORCPT ); Thu, 20 Oct 2016 12:35:47 -0400 Received: from mga04.intel.com ([192.55.52.120]:17165 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S941214AbcJTQfc (ORCPT ); Thu, 20 Oct 2016 12:35:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,371,1473145200"; d="scan'208";a="1047567609" Date: Thu, 20 Oct 2016 19:34:44 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Gustavo Padovan Cc: 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 v5 4/4] drm/fence: add out-fences support Message-ID: <20161020163444.GY4329@intel.com> References: <1476975005-30441-1-git-send-email-gustavo@padovan.org> <1476975005-30441-5-git-send-email-gustavo@padovan.org> <20161020153518.GX4329@intel.com> <20161020155538.GA10205@joana> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161020155538.GA10205@joana> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1459 Lines: 44 On Thu, Oct 20, 2016 at 01:55:38PM -0200, Gustavo Padovan wrote: > 2016-10-20 Ville Syrj?l? : > > > On Thu, Oct 20, 2016 at 12:50:05PM -0200, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > Support DRM out-fences by creating a sync_file with a fence for each CRTC > > > that sets the OUT_FENCE_PTR property. > > > > I still maintain the out fence should also be per fb (well, per plane > > since we can't add it to fbs). Otherwise it's not going to be at all > > useful if you do fps>vrefresh and don't include the same set of planes > > in every atomic ioctl, eg. if you only ever include ones that are > > somehow dirty. > > How would the kernel signal these dirty planes then? Right now we signal > at the vblank. So if I think about it in terms of the previous fbs something like this comes to mind: starting point: plane a, fb 0 plane b, fb 1 ioctl: plane a, fb 2, fence A plane b, fb 3, fence B ioctl: plane a, fb 4, fence C -> fb 2 can be reused, so fence C should signal immediately? vblank: -> fb 0,1 can be reused, so fence A,B signal? It feels a bit wonky since the fence is effectively associated with the previous fb after the previous fb was already submitted to the kernel. One might assume fence A to be the one signalled early, but that would give the impression that fb 0 would be free for reuse when it's not. -- Ville Syrj?l? Intel OTC