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>
