[PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[zhoucm1]

On 2017年09月14日 09:52, Dave Airlie wrote:
> On 14 September 2017 at 00:16, Christian König <deathsimple at vodafone.de> wrote:
>> Am 13.09.2017 um 16:06 schrieb Marek Olšák:
>>> On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing)
>>> <David1.Zhou at amd.com> wrote:
>>>> For android using mesa instance, egl draw will dequeue an android buffer,
>>>> after egl draw, the buffer will back to android bufffer queue, but need
>>>> append a syncfile fd. If getting syncfile fd for every egl draw always
>>>> needs
>>>> several syncobj ioctls, the io overhead isn't small. But if we directly
>>>> return syncfile when egl draw CS,  isn't it better?
>>> You have a good point. I'd be OK with either approach, or even with
>>> having both options in the kernel.
>>
>> I don't have a strong opinion for the CS IOCTL either. If it saves us an
>> extra IOCTL when we directly return a syncfile fd then why not?
>>
>> But we really shouldn't use syncfile for the VA IOCTL. That's nothing we
>> want to share with other processes and the returned fence or sequence needs
>> to be lightweight.
>>
>> Ideally I would say it should be a sequence number, so that you can say
>> max(seq1, seq2) and always have the latest.
>>
>> The next best approach I think would be to use syncobj, cause it is simply
>> rather easily to implement.
> I'd go with not returning fd's by default, it's a bad use of a limited resource,
> creating fd's should happen on giving the object to another process or API.
>
> However having an optional chunk or flag to say this ioctl will return an
> android sync fd if asked is fine with me, if is usually returns a syncobj.
OK, that means we return fd only when UMD ask, right?
I will send V2.


Thanks all.
David Zhou
>
> Dave.