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@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.
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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
