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

[Chad Versace]

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.