On 14 September 2017 at 00:16, Christian König <deathsimple@xxxxxxxxxxx> 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@xxxxxxx> 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. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
