atomic explicit fencing vs android

[Greg Hackmann]

On Fri, Nov 13, 2015 at 1:47 PM, Rob Clark <robdclark at 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151113/a8156a73/attachment.html>