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
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@xxxxxxxxx> 于 2017年9月13日 下午8:06写道:
On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing)
<David1.Zhou@xxxxxxx> 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@xxxxxxxxx> 于 2017年9月13日 下午6:11写道:
>
> On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 <david1.zhou@xxxxxxx> 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
<David1.Zhou@xxxxxxx> 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@xxxxxxxxx> 于 2017年9月13日 下午6:11写道:
>
> On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 <david1.zhou@xxxxxxx> 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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel