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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
