<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix"> <blockquote type="cite"> syncfile indeed be a good way to pass fence for user space, which already is proved in Android and is upstreamed. </blockquote> 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): </div> <blockquote type="cite" cite="mid:MWHPR1201MB0206A14F0D2148D5036A9485B46E0@MWHPR1201MB0206.namprd12.prod.outlook.com"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Exchange Server">  <style></style> <div>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 <style type="text/css">  </style> <div class="x_quote"> <div style="margin:0 0px; font-size:105%">Marek Ol?醟 <a class="moz-txt-link-rfc2396E" href="mailto:maraeo@gmail.com"><maraeo@gmail.com></a> 于 2017年9月13日下午8:06写道：</div> </div> </div> <div class="PlainText">On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing) <a class="moz-txt-link-rfc2396E" href="mailto:David1.Zhou@amd.com"><David1.Zhou@amd.com></a> 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?醟 <a class="moz-txt-link-rfc2396E" href="mailto:maraeo@gmail.com"><maraeo@gmail.com></a> 于 2017年9月13日下午6:11写道： > > On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 <a class="moz-txt-link-rfc2396E" href="mailto:david1.zhou@amd.com"><david1.zhou@amd.com></a> 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 </div> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ amd-gfx mailing list <a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a> </pre> </blockquote> </body> </html>