From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Hackmann Subject: Re: atomic explicit fencing vs android Date: Fri, 13 Nov 2015 17:47:00 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1647294127==" Return-path: Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by gabe.freedesktop.org (Postfix) with ESMTPS id 175026E0AB for ; Fri, 13 Nov 2015 17:47:02 -0800 (PST) Received: by ykdv3 with SMTP id v3so175974392ykd.0 for ; Fri, 13 Nov 2015 17:47:01 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Clark Cc: "dri-devel@lists.freedesktop.org" , =?UTF-8?Q?St=C3=A9phane_Marchesin?= List-Id: dri-devel@lists.freedesktop.org --===============1647294127== Content-Type: multipart/alternative; boundary=94eb2c07fa502ba9380524765a1a --94eb2c07fa502ba9380524765a1a Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 1:47 PM, Rob Clark wrote: > > I suppose the philosophy here is > that on android, surfaceflinger (userspace) is the trusted one (which > may well be correct on some vendor kernel branches), whereas upstream > the kernel is the trusted one. > To clarify, this wasn't the philosophy behind the Android fence semantics. It was more that someone internally had to make a judgement call about the semantics to go with, and that decision's been baked into the SurfaceFlinger codebase since then. After LPC I spoke with our graphics team about your and Daniel Vetter's concerns. They have plans to change SurfaceFlinger so hwcomposer HALs can optionally use DRM's semantics for retire fences. One possible option, perhaps... as I understand it, w/ android it is > possible to create and signal fences from userspace. So userspace > could create and maintain it's own queue of fences, which it returns > from hwc->set(), and are signalled (timestamp copied, etc) when the > kernel fences from the next atomic ioctl are signalled. > CONFIG_SW_SYNC_USER exposes a userspace API for creating and signaling fences from userspace. But it's only intended for testing, and we *really* don't want vendors shipping it in production code -- once userspace can create the fences it sends to the kernel, you have a whole new set of deadlock scenarios to worry about. For example if userspace creates a fence, sends it to the kernel, and crashes before signalling it, you're stuck with a deadlocked display pipeline waiting on a fence that can never fire. --94eb2c07fa502ba9380524765a1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 13, 2015 at 1:47 PM, Rob Clark <robdclark@gmail.com> wrote:
I suppose the philosophy here is
that on android, surfaceflinger (userspace) is the trusted one (which
may well be correct on some vendor kernel branches), whereas upstream
the kernel is the trusted one.

To clari= fy, this wasn't the philosophy behind the Android fence semantics.=C2= =A0 It was more that someone internally had to make a judgement call about = the semantics to go with, and that decision's been baked into the Surfa= ceFlinger codebase since then.

After LPC I spoke w= ith our graphics team about your and Daniel Vetter's concerns.=C2=A0 Th= ey have plans to change SurfaceFlinger so hwcomposer HALs can optionally us= e DRM's semantics for retire fences.

One possible option, perhaps... as I understand it, w/ android it is
possible to create and signal fences from userspace.=C2=A0 So userspace
could create and maintain it's own queue of fences, which it returns from hwc->set(), and are signalled (timestamp copied, etc) when the
kernel fences from the next atomic ioctl are signalled.

CONFIG_SW_SYNC_USER exposes a userspace API for creating a= nd signaling fences from userspace.=C2=A0 But it's only intended for te= sting, and we *really* don't want vendors shipping it in production cod= e -- once userspace can create the fences it sends to the kernel, you have = a whole new set of deadlock scenarios to worry about.=C2=A0 For example if = userspace creates a fence, sends it to the kernel, and crashes before signa= lling it, you're stuck with a deadlocked display pipeline waiting on a = fence that can never fire.
--94eb2c07fa502ba9380524765a1a-- --===============1647294127== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1647294127==--