On 2017å¹´09æ??14æ?¥ 10:07, zhoucm1 wrote: > > > 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. But think a bit more, if not by default, that isn't meaningful, we can continue to use seq_no base fence and Marek's syncfile fd approach. Regards, David Zhou > > > Thanks all. > David Zhou >> >> Dave. >
