Re: [RFC 0/6] drm/fences: add in-fences to DRM

From: Inki Dae
Date: Thu Mar 24 2016 - 19:04:06 EST

Hi Guestavo,

2016ë 03ì 24ì 23:39ì Gustavo Padovan ì(ê) ì ê:
> Hi Inki,
> 2016-03-24 Inki Dae <inki.dae@xxxxxxxxxxx>:
>> Hi,
>> 2016ë 03ì 24ì 03:47ì Gustavo Padovan ì(ê) ì ê:
>>> From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx>
>>> Hi,
>>> This is a first proposal to discuss the addition of in-fences support
>>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>>> in DRM drivers. The new struct fence_collection contains a array with all
>>> fences that a atomic commit needs to wait on
>> As I mentioned already like below,
>> I don't see why Android specific thing is tried to propagate to Linux DRM. In Linux mainline, it has already implicit sync interfaces for DMA devices called dma fence which forces registering a fence obejct to DMABUF through a reservation obejct when a dmabuf object is created. However, Android sync driver creates a new file for a sync object and this would have different point of view.
>> Is there anyone who can explan why Android specific thing is tried to spread into Linux DRM? Was there any consensus to use Android sync driver - which uses explicit sync interfaces - as Linux standard?
> Because we want explicit fencing as the Linux standard in the future to
> be able to do smart scheduling, e.g., send async jobs to the gpu and at
> the same time send async atomic commits with sync_file fd attached so
> they can wait the GPU to finish and we don't block in userspace anymore,
> quite similar to what Android does.

GPU is also DMA device so I think the synchonization should be handled transparent to user-space.
And I know that Chromium guy already did similar thing with non-atomic commit only using implicit sync,
branch name : chromeos-3.14

Of course, this approach uses a new helper framework placed in drm directory so I think if this framework can be moved into dma-buf directory after some cleanup and refactoring them if necessary.
Anyway, I'm not sure I understood the smart scheduling you mentioned but I think we could do what you try to do without the explicit fence.

> This would still use dma-buf fences in the driver level, but it has a
> lot more advantages than implicit fencing.

You means things for rendering pipeline debugging and merging sync fences?

Inki Dae

> Gustavo