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