On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing) <david1.z...@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?醟 <mar...@gmail.com> 于 2017年9月13日 下午6:11写道： > > On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 <david1.z...@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
