MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8BIT
Message-id: <56F4725D.6040501@samsung.com>
Date: Fri, 25 Mar 2016 08:03:57 +0900
From: Inki Dae <inki.dae@samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
 Thunderbird/31.6.0
To: Gustavo Padovan <gustavo@padovan.org>, dri-devel@lists.freedesktop.org,
        Daniel Stone <daniels@collabora.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= <arve@android.com>,
        linux-kernel@vger.kernel.org, Riley Andrews <riandrews@android.com>,
        Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
        John Harrison <John.C.Harrison@Intel.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM
References: <1458758847-21170-1-git-send-email-gustavo@padovan.org>
 <56F3A2DC.8080507@samsung.com> <20160324143913.GB4781@joana>
In-reply-to: <20160324143913.GB4781@joana>
DLP-Filter: Pass
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2477
Lines: 53

Hi Guestavo,

2016년 03월 24일 23:39에 Gustavo Padovan 이(가) 쓴 글:
> Hi Inki,
> 
> 2016-03-24 Inki Dae <inki.dae@samsung.com>:
> 
>> Hi,
>>
>> 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
>>> From: Gustavo Padovan <gustavo.padovan@collabora.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
> 
>