On 2017å¹´09æ??14æ?¥ 09:52, Dave Airlie wrote: > On 14 September 2017 at 00:16, Christian König <deathsimple at vodafone.de> wrote: >> Am 13.09.2017 um 16:06 schrieb Marek Olšák: >>> On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing) >>> <David1.Zhou at amd.com> wrote: >>>> 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? >>> You have a good point. I'd be OK with either approach, or even with >>> having both options in the kernel. >> >> I don't have a strong opinion for the CS IOCTL either. If it saves us an >> extra IOCTL when we directly return a syncfile fd then why not? >> >> But we really shouldn't use syncfile for the VA IOCTL. That's nothing we >> want to share with other processes and the returned fence or sequence needs >> to be lightweight. >> >> Ideally I would say it should be a sequence number, so that you can say >> max(seq1, seq2) and always have the latest. >> >> The next best approach I think would be to use syncobj, cause it is simply >> rather easily to implement. > I'd go with not returning fd's by default, it's a bad use of a limited resource, > creating fd's should happen on giving the object to another process or API. > > However having an optional chunk or flag to say this ioctl will return an > android sync fd if asked is fine with me, if is usually returns a syncobj. OK, that means we return fd only when UMD ask, right? I will send V2. Thanks all. David Zhou > > Dave.
