Re: Fence, timeline and android sync points

[Jerome Glisse <j.glisse@gmail.com>]

On Thu, Aug 14, 2014 at 09:40:08PM +0200, Maarten Lankhorst wrote:
> 
> 
> 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. ;-)

Android fence are not in my mind a nice thing :)

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

Again i have fail to express myself. I have tried to repeatly said that
what i proposed was not mutualy 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.

Again i fail to properly explain myself. I said no fence should be associted
to buffer nor dma-buf wether shared or not. The only things that you really
need for a buffer is a seqno and this only have use for binding/unbinding
object from GART/GPU address space/... so no i am not saying fence should be
associated with a buffer. I am saying fence should be associated with each
cmdbuf and there should be no link whatsover btw fence and buffer object ie
you do not need to store a pointer to fence inside dma-buf or any buffer
object structure.

I am well aware of how ttm works and i am saying it can be replace with
simpler seqno.

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

My point is that dma-buf should not have reserversion_object pointer it is
useless and counter productive and only add complexity. You do not care about
buffer, you care about synchronizing cmdbuf/hw block with each other. A buffer
is just what those block consume. In other words reservation_object as fence
are useless and only complexify things for no added value on contrary they
are not as flexible as fence associated to cmdbuf.

> 
> 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.

As does what i am talking about. The reservation stuff is a limiting factor
more than an helper in my eyes.

> 
> 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.

My point is that implicit syncing can be implemented in a saner way that would
also allow to implement an explicit syncing with no restriction and only room
for extra optimisation. By enforcing to have the cpu involve in hw block sync
you are limiting what can be done and clever hardware are force to use sub
optimal solution.

> ~Maarten