atomic explicit fencing vs android

Rob Clark robdclark at gmail.com
Sat Nov 14 05:15:46 PST 2015


On Fri, Nov 13, 2015 at 8:47 PM, Greg Hackmann <ghackmann at google.com> wrote:
> 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.

Oh, that is great news.  That makes things considerably easier. :-)

>> 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.

hmm, if userspace keeps the fence fd open until it is signalled, then
perhaps closing the fd (ie. when process crashes) should trigger
signalling the fence?  Anyways, even better if we don't have to go
there.

BR,
-R


More information about the dri-devel mailing list