[Mesa-dev] egl/android: fence_fd being forced to -1

[Marathe, Yogesh]

> -----Original Message-----
> From: Chad Versace [mailto:chadversary at chromium.org]
> On Tue 20 Jun 2017, Marathe, Yogesh wrote:
> 
> > > From the framework's perspective, at least from the comments in
> > > aosp://system/core/include/system/window.h [1], it's legal to call
> > > ANativeWindow::queueBuffer with fenceFd=-1 if implicit sync is enabled.
> > > And, as far as I know, implicity sync is still enabled on Intel
> > > unless you set a flag in execbuffer.
> > >
> > > Yogesh and Tapani, are you disabling explicit sync for any
> > > execbuffer ioctl's on android-ia? If so, please point me to some
> > > code.  If not, then this definitely feels like a NOTOURBUG.
> >
> > I think you meant implicit sync in the question, no we are not disabling it.
> 
> Right. I meant "are you disabling implicit sync...".
> >
> 
> > As I look at the code further, it appears that the native application
> > depends upon GLConsumer client's fence. This fence is expected to be
> > coming from buffer producer (ANativeWindow/Surface in this case)
> > through a BufferQueue, buffers in this buffer queue have fence fd
> > forced to -1, before they were enqueued. If producer finds fence as -1 during
> enqueue it just sets mFenceFd = Fence::NO_FENCE.
> > Isn't this a problem when buffer is acquired by client which depends upon
> fence?
> 
> In the API's that I have encountered while working with Android's sync
> framework, fenceFd=-1 always implies that the buffer is ready for access. The
> spec for Google's Vulkan Android winsys extension also document fenceFd=-1
> this way. And EGL_ANDROID_native_fence_sync documents it this way also.
> 
> Perhaps, (but I doubt it), as you proceed farther up the stack of the Android
> framework, farther away from drivers and the HALs and closer to the Java, the
> documented behavior changes for fences. But I have little knowledge of those
> upper framework layers.

I think actually that's what is happening, fence's purpose changed at that native application.
It's not about buffer availability. It's trying to use fence fd  from GL client to 
calculate time elapsed while its doing frames; assuming fence fd is always valid
and has meaning to it in terms of sw_sync timeline and sync_pts.

Fence::getSignalTime() from Fence.cpp will never give a valid outcome if egl driver forces fd = -1 
https://android.googlesource.com/platform/frameworks/native/+/master/libs/ui/Fence.cpp