> 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> äº? 2017å¹´9æ??13æ?¥ ä¸?å??8:06å??é??ï¼? > > On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing) > <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> äº? 2017å¹´9æ??13æ?¥ ä¸?å??6:11å??é??ï¼? > > > > On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 <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 > 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/f1b5c313/attachment-0001.html>
