atomic explicit fencing vs android

atomic explicit fencing vs android

[Rob Clark]

Ok, this has been something on my TODO list to write up for a little
while now.. but better late than never ;-)

At LPC Daniel Vetter and myself were talking to Greg Hackmann and came
to realize a bit of an impedance mismatch between how android display
stack expects to use fences, and what Daniel and myself and others had
been expecting upstream.

(And note that I'm not an expert about hwc/surfaceflinger/etc, so just
trying to repeat what various people have told me without butchering
it too much.  Please feel free to correct me as needed.)

Specifically, android expects from hwc->set() interface, which is what
would call atomic ioctl, to return the fence for when the *incoming*
buffers are no longer read by the scanout hw.  See:
http://androidxref.com/6.0.0_r1/xref/hardware/libhardware/include/hardware/hwcomposer.h#369

Whereas the expectation for drm would be to return the fence for when
the *outgoing* buffers are no longer read by the scanout hw, something
which does not depend on further userspace action.

The problem here is that userspace could orchestrate it's own deadlock
this way, telling some other device to wait on a fence which
ultimately in the fence dependency chain leads back to a fence that
the display is waiting on to flip.  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.

Note that regardless of fence semantics, I'm expecting a solution
where there is are per-plane fences.  This seems to fit android
better, and could be potentially advantageous for signalling when
plane scanout completes vs vblank.

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.

Thoughts/comments/alternatives?

BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: atomic explicit fencing vs android

[Greg Hackmann]

[-- Attachment #1.1: Type: text/plain, Size: 1589 bytes --]

On Fri, 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 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.

[-- Attachment #1.2: Type: text/html, Size: 2257 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: atomic explicit fencing vs android

[Rob Clark]

On Fri, Nov 13, 2015 at 8:47 PM, Greg Hackmann <ghackmann@google.com> wrote:
> On Fri, 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 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel