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

[Zhou, David(ChunMing)]

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?


发自坚果 Pro

Christian K鰊ig <deathsimple at vodafone.de> 于 2017年9月13日 下午9:04写道：

syncfile indeed be a good way to pass fence for user space, which already is proved in Android and is upstreamed.
Not really. syncfile needs a file descriptor for each handle it generates, that's quite a show stopper if you want to use it in general.

Android syncfile are meant to be used for inter process sharing, but as command submission sequence number they are not such a good fit.

Mareks approach looks really good to me and we should follow that direction further.

Regards,
Christian.

Am 13.09.2017 um 14:25 schrieb Zhou, David(ChunMing):
Yes, to be comptibility, I kept both seq_no and syncfile fd in the patch set, you can take a look, which really is simpler and effective way.

syncfile indeed be a good way to pass fence for user space, which already is proved in Android and is upstreamed.

Regards,
David Zhou


发自坚果 Pro

Marek Ol?醟 <maraeo at gmail.com><mailto:maraeo at gmail.com> 于 2017年9月13日 下午8:06写道：

On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing)
<David1.Zhou at amd.com><mailto:David1.Zhou at amd.com> wrote:
> Could you describe how difficult to directly use CS syncfile fd in Mesa
> compared with concerting CS seq to syncfile fd via several syncobj ioctls?

It just simplifies things. Mesa primarily uses seq_no-based fences and
will continue to use them. We can't remove the seq_no fence code
because we have to keep Mesa compatible with older kernels.

The only possibilities are:
- Mesa gets both seq_no and sync_file from CS.
- Mesa only gets seq_no from CS.

I decided to take the simpler option. I don't know if there is a perf
difference between CS returning a sync_file and using a separate
ioctl, but it's probably insignificant since we already call 3 ioctls
per IB submission (BO list create+destroy, submit).

Marek

>
> Regards,
> David Zhou
>
> 发自坚果 Pro
>
> Marek Ol?醟 <maraeo at gmail.com><mailto:maraeo at gmail.com> 于 2017年9月13日 下午6:11写道：
>
> On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 <david1.zhou at amd.com><mailto:david1.zhou at amd.com> wrote:
>> Hi Marek,
>>
>> You're doing same things with me, see my "introduce syncfile as fence
>> reuturn" patch set, which makes things more simple, we just need to
>> directly
>> return syncfile fd to UMD when CS, then the fence UMD get will be always
>> syncfile fd, UMD don't need to construct ip_type/ip_instance/ctx_id/ring
>> any
>> more, which also can pass to dependency and syncobj as well.
>
> For simpler Mesa code, Mesa won't get a sync file from the CS ioctl.
>
> Marek



_______________________________________________
amd-gfx mailing list
amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170913/cb847fa7/attachment-0001.html>