On 2017年09月14日 09:52, Dave Airlie wrote:
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.
OK, that means we return fd only when UMD ask, right?
I will send V2.
Thanks all.
David Zhou
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
