atomic explicit fencing vs android
Rob Clark
robdclark at gmail.com
Fri Nov 13 13:47:28 PST 2015
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
More information about the dri-devel
mailing list