On Mon, Jun 23, 2014 at 10:45 AM, Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
