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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <56F4725D.6040501@samsung.com>
Date:	Fri, 25 Mar 2016 08:03:57 +0900
From:	Inki Dae <inki.dae@...sung.com>
To:	Gustavo Padovan <gustavo@...ovan.org>,
	dri-devel@...ts.freedesktop.org,
	Daniel Stone <daniels@...labora.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Arve Hjønnevåg <arve@...roid.com>,
	linux-kernel@...r.kernel.org,
	Riley Andrews <riandrews@...roid.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM

Hi Guestavo,

2016년 03월 24일 23:39에 Gustavo Padovan 이(가) 쓴 글:
> Hi Inki,
> 
> 2016-03-24 Inki Dae <inki.dae@...sung.com>:
> 
>> Hi,
>>
>> 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
>>> From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
>>>
>>> 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,
>> http://www.spinics.net/lists/dri-devel/msg103225.html
>>
>> 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,
https://chromium.googlesource.com/chromiumos/third_party/kernel
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?

Thanks,
Inki Dae

> 
> 	Gustavo
> 
>