Re: Fence, timeline and android sync points

[Maarten Lankhorst <maarten.lankhorst@canonical.com>]

On 14-08-14 21:15, Jerome Glisse wrote:
> On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote:
>> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>> Sucks because you can not do weird synchronization like one i depicted in another
>>> mail in this thread and for as long as cmdbuf_ioctl do not give you fence|syncpt
>>> you can not such thing cleanly in non hackish way.
>>
>> Actually i915 can soon will do that that.
> 
> So you will return fence|syncpoint with each cmdbuf_ioctl ?

It might, soon. There have been patches on the ml about it. It can create a userspace android fence backed by a kernel dma fence.
And it will be created like any other userspace android fence. ;-)

Yet even with that, it will continue to support the implicit sync model since they're not mutually exclusive.

I also fail to understand why you think a fence should be associated with a buffer object. It's the other way around. TTM currently requires buffer objects to be fenced off to protect against eviction.

reservation_object is used for this, and by sharing the reservation_object pointer with a dma-buf you get cross-device synchronization.

It has a bunch of helpers to make common operations easy, see include/linux/reservation.h and drivers/dma-buf/reservation.c
It also allows multiple readers simultaneously across any number of devices. I intend to use this in nouveau.

But there's no requirement to use reservation_object's apart from that's how ttm currently works, and for implicit syncing in dma-buf. If you don't need either go crazy with fence and write your own mechanism on top of fence. Although with android sync and TTM I think I handled all common usecases.

~Maarten