[REPOST PATCH 4/8] android: convert sync to fence api, v5

[Daniel Vetter]

On Mon, Jun 23, 2014 at 10:45 AM, Maarten Lankhorst
<maarten.lankhorst at canonical.com> wrote:
> But in drivers/drm I can encounter a similar issue, people expect to be able to
> overwrite the contents of the currently displayed buffer, so I 'solved' it by not adding
> a fence on the buffer, only by waiting for buffer idle before page flipping.
> The rationale is that the buffer is pinned internally, and the backing storage cannot
> go away until dma_buf_unmap_attachment is called. So when you render to the
> current front buffer without queuing a page flip you get exactly what you expect. ;-)

Yeah, scanout buffers are special and imo we should only uses fences
as barriers just around the flip, but _not_ to prevent frontbuffer in
general. Userspace is after all allowed to do that (e.g. with the dumb
bo ioctls). If we'd premanently lock scanout buffers that would indeed
result in hilarity all over the place, no surprises there. And all
current drivers with dynamic memory management solve this through
pinning, but not by restricting write access at all.

So I think we can shrug this scenario off as a non-issue of the "don't
do this" kind ;-) Thierry, is there anything else you've stumbled over
in the tegra k1 enabling work?

I still get the impression that there's an awful lot of
misunderstandings between the explicit and implicit syncing camps and
that we need to do a lot more talking for a better understanding ...

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch