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

zhoucm1 david1.zhou at amd.com
Thu Sep 14 02:26:32 UTC 2017



On 2017年09月14日 10:07, zhoucm1 wrote:
>
>
> 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.
But think a bit more, if not by default, that isn't meaningful, we can 
continue to use seq_no base fence and Marek's syncfile fd approach.

Regards,
David Zhou
>
>
> Thanks all.
> David Zhou
>>
>> Dave.
>



More information about the dri-devel mailing list