Discussion:
egl/android: fence_fd being forced to -1
(too old to reply)
Marathe, Yogesh
2017-06-15 13:27:06 UTC
Permalink
Raw Message
Hello,

I'm tyring to run flatland native app on android. It apparantly fails because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1. Whats the expectation here if app wants to use fence sync?

If we want to have this native app working with the lib where exactly fence should be
created / populated, it should be with buffer producer, right?

BTW, We can't/ don't want to change the flatland app!

Regards,
Yogesh.
Emil Velikov
2017-06-15 13:54:28 UTC
Permalink
Raw Message
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1. Whats the expectation here if app wants to use fence sync?
If we want to have this native app working with the lib where exactly fence should be
created / populated, it should be with buffer producer, right?
BTW, We can't/ don't want to change the flatland app!
If the app is doing something illegal, I doubt people will be extra
happy in pushing workarounds in Mesa.

But above all - please check that your Mesa version has commit
6f21b5601cc1260eac53f65c8941b3aa66d0f5e9.
Additionally you may want to try this extra patch [1] although I'm not
100% sure how much these will help.

IIRC we had a handful of other Android patches you might also want to
skim/test [2]

-Emil

[1] https://patchwork.freedesktop.org/patch/154705/
[2] https://patchwork.freedesktop.org/project/mesa/patches/?submitter=&state=&q=android&archive=&delegate=
It's kind of a long list, but I'll cleanup most of them shortly.
Marathe, Yogesh
2017-06-15 14:07:54 UTC
Permalink
Raw Message
-----Original Message-----
Sent: Thursday, June 15, 2017 7:24 PM
Subject: Re: [Mesa-dev] egl/android: fence_fd being forced to -1
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because of a
fence issue.
Post by Marathe, Yogesh
while debuging further it is observed that
droid_window_enqueue_buffer() is forcing fence_fd =-1. Whats the
expectation here if app wants to use fence sync?
Post by Marathe, Yogesh
If we want to have this native app working with the lib where exactly
fence should be created / populated, it should be with buffer producer, right?
BTW, We can't/ don't want to change the flatland app!
If the app is doing something illegal, I doubt people will be extra happy in
pushing workarounds in Mesa.
But above all - please check that your Mesa version has commit
6f21b5601cc1260eac53f65c8941b3aa66d0f5e9.
Yes I do have this patch already.
Additionally you may want to try this extra patch [1] although I'm not 100% sure
how much these will help.
IIRC we had a handful of other Android patches you might also want to
skim/test [2]
Thanks for these pointers Emil, I will look at these patches.
-Emil
[1] https://patchwork.freedesktop.org/patch/154705/
[2]
https://patchwork.freedesktop.org/project/mesa/patches/?submitter=&state=
&q=android&archive=&delegate=
It's kind of a long list, but I'll cleanup most of them shortly.
Eric Engestrom
2017-06-15 13:59:48 UTC
Permalink
Raw Message
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1.
I assume you've read the comment on the line above the one you mentioned?

/* Queue the buffer without a sync fence. This informs the ANativeWindow
* that it may access the buffer immediately.
*
* From ANativeWindow::dequeueBuffer:
*
* The fenceFd argument specifies a libsync fence file descriptor for
* a fence that must signal before the buffer can be accessed. If
* the buffer can be accessed immediately then a value of -1 should
* be used. The caller must not use the file descriptor after it
* is passed to queueBuffer, and the ANativeWindow implementation
* is responsible for closing it.
*/
int fence_fd = -1;
dri2_surf->window->queueBuffer(dri2_surf->window, dri2_surf->buffer,
fence_fd);
Post by Marathe, Yogesh
Whats the expectation here if app wants to use fence sync?
If we want to have this native app working with the lib where exactly fence should be
created / populated, it should be with buffer producer, right?
I don't know this code personally, so I Cc'ed Chad, who wrote this code
in commit bfe28b8d93 (albeit 5 years ago, so he might not remember all
of it) and Tapani who reviewed it.
Post by Marathe, Yogesh
BTW, We can't/ don't want to change the flatland app!
Regards,
Yogesh.
Marathe, Yogesh
2017-06-15 14:23:24 UTC
Permalink
Raw Message
-----Original Message-----
Sent: Thursday, June 15, 2017 7:30 PM
Subject: Re: [Mesa-dev] egl/android: fence_fd being forced to -1
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because of a
fence issue.
Post by Marathe, Yogesh
while debuging further it is observed that
droid_window_enqueue_buffer() is forcing fence_fd =-1.
I assume you've read the comment on the line above the one you mentioned?
Yes I read this, although what's not clear to me is the case that not covered
in comments i.e. when a valid fd needs to be used. I will wait for Chad's comments.
Thanks Eric.
/* Queue the buffer without a sync fence. This informs the ANativeWindow
* that it may access the buffer immediately.
*
*
* The fenceFd argument specifies a libsync fence file descriptor for
* a fence that must signal before the buffer can be accessed. If
* the buffer can be accessed immediately then a value of -1 should
* be used. The caller must not use the file descriptor after it
* is passed to queueBuffer, and the ANativeWindow implementation
* is responsible for closing it.
*/
int fence_fd = -1;
dri2_surf->window->queueBuffer(dri2_surf->window, dri2_surf->buffer,
fence_fd);
Post by Marathe, Yogesh
Whats the expectation here if app wants to use fence sync?
If we want to have this native app working with the lib where exactly
fence should be created / populated, it should be with buffer producer, right?
I don't know this code personally, so I Cc'ed Chad, who wrote this code in
commit bfe28b8d93 (albeit 5 years ago, so he might not remember all of it) and
Tapani who reviewed it.
Yeah this app also seems to be around since then.
Post by Marathe, Yogesh
BTW, We can't/ don't want to change the flatland app!
Regards,
Yogesh.
Marathe, Yogesh
2017-06-19 06:24:51 UTC
Permalink
Raw Message
Hello Chad,

Any comments from you on this topic?

Regards,
Yogesh.
-----Original Message-----
Post by Marathe, Yogesh
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because of a
fence issue.
Post by Marathe, Yogesh
while debuging further it is observed that
droid_window_enqueue_buffer() is forcing fence_fd =-1.
I assume you've read the comment on the line above the one you mentioned?
Yes I read this, although what's not clear to me is the case that not covered in
comments i.e. when a valid fd needs to be used. I will wait for Chad's comments.
Thanks Eric.
Post by Marathe, Yogesh
/* Queue the buffer without a sync fence. This informs the ANativeWindow
* that it may access the buffer immediately.
*
*
* The fenceFd argument specifies a libsync fence file descriptor for
* a fence that must signal before the buffer can be accessed. If
* the buffer can be accessed immediately then a value of -1 should
* be used. The caller must not use the file descriptor after it
* is passed to queueBuffer, and the ANativeWindow implementation
* is responsible for closing it.
*/
int fence_fd = -1;
dri2_surf->window->queueBuffer(dri2_surf->window, dri2_surf->buffer,
fence_fd);
Post by Marathe, Yogesh
Whats the expectation here if app wants to use fence sync?
If we want to have this native app working with the lib where
exactly fence should be created / populated, it should be with buffer
producer, right?
Post by Marathe, Yogesh
I don't know this code personally, so I Cc'ed Chad, who wrote this
code in commit bfe28b8d93 (albeit 5 years ago, so he might not
remember all of it) and Tapani who reviewed it.
Yeah this app also seems to be around since then.
Post by Marathe, Yogesh
Post by Marathe, Yogesh
BTW, We can't/ don't want to change the flatland app!
Regards,
Yogesh.
_______________________________________________
mesa-dev mailing list
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Rob Clark
2017-06-15 15:52:56 UTC
Permalink
Raw Message
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Post by Eric Engestrom
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1.
Yogesh, can you describe a bit more what "fails" means? What sequence
of gl calls, for example, is it making?
Post by Eric Engestrom
I assume you've read the comment on the line above the one you mentioned?
/* Queue the buffer without a sync fence. This informs the ANativeWindow
* that it may access the buffer immediately.
*
*
* The fenceFd argument specifies a libsync fence file descriptor for
* a fence that must signal before the buffer can be accessed. If
* the buffer can be accessed immediately then a value of -1 should
* be used. The caller must not use the file descriptor after it
* is passed to queueBuffer, and the ANativeWindow implementation
* is responsible for closing it.
*/
int fence_fd = -1;
dri2_surf->window->queueBuffer(dri2_surf->window, dri2_surf->buffer,
fence_fd);
Post by Marathe, Yogesh
Whats the expectation here if app wants to use fence sync?
If we want to have this native app working with the lib where exactly fence should be
created / populated, it should be with buffer producer, right?
I don't know this code personally, so I Cc'ed Chad, who wrote this code
in commit bfe28b8d93 (albeit 5 years ago, so he might not remember all
of it) and Tapani who reviewed it.
I suspect this code pre-dates fence-fd support in upstream kernel (and
mesa).. so it is probably relying on implicit sync. I suspect we
might be wanting to create fence-fd's internally and passing them to
queueBuffer (for the subset of drivers that support fence fd's).
Although haven't really thought about the implementation much.

Are fence fd's exposed to the application at all in android? IIRC the
android shim egl/gles layer was hiding that extension, so I *guess* it
is only meant to be used internally and not by applications.

BR,
-R
Tapani Pälli
2017-06-15 16:04:45 UTC
Permalink
Raw Message
Post by Rob Clark
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Post by Eric Engestrom
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1.
Yogesh, can you describe a bit more what "fails" means? What sequence
of gl calls, for example, is it making?
The problem described shortly: Flatland uses timestamps from Fence
objects for calculating time (using getSignalTime API) and in case of
having -1 from producer (Mesa) we will end up having same timestamp for
startFence and endFence (since both are Fence::NO_FENCE) and thus
flatland will keep running forever as it thinks no time has been passed
between 2 fences. It is stuck in a loop where it tries to find how many
frames are required so that driver will spend certain amount of time
doing it.

So it uses Android framework classes and makes the assumption that fence
with a timestamp will be there. I believe we should be inserting a fence
after current commands in the batchbuffer at that point and then
returning that fence but so far my attempts have not really worked out
well :/
Post by Rob Clark
Post by Eric Engestrom
I assume you've read the comment on the line above the one you mentioned?
/* Queue the buffer without a sync fence. This informs the ANativeWindow
* that it may access the buffer immediately.
*
*
* The fenceFd argument specifies a libsync fence file descriptor for
* a fence that must signal before the buffer can be accessed. If
* the buffer can be accessed immediately then a value of -1 should
* be used. The caller must not use the file descriptor after it
* is passed to queueBuffer, and the ANativeWindow implementation
* is responsible for closing it.
*/
int fence_fd = -1;
dri2_surf->window->queueBuffer(dri2_surf->window, dri2_surf->buffer,
fence_fd);
Post by Marathe, Yogesh
Whats the expectation here if app wants to use fence sync?
If we want to have this native app working with the lib where exactly fence should be
created / populated, it should be with buffer producer, right?
I don't know this code personally, so I Cc'ed Chad, who wrote this code
in commit bfe28b8d93 (albeit 5 years ago, so he might not remember all
of it) and Tapani who reviewed it.
I suspect this code pre-dates fence-fd support in upstream kernel (and
mesa).. so it is probably relying on implicit sync. I suspect we
might be wanting to create fence-fd's internally and passing them to
queueBuffer (for the subset of drivers that support fence fd's).
Although haven't really thought about the implementation much.
Are fence fd's exposed to the application at all in android? IIRC the
android shim egl/gles layer was hiding that extension, so I *guess* it
is only meant to be used internally and not by applications.
Not exposed to applications, this is a framework level test.
Post by Rob Clark
BR,
-R
_______________________________________________
mesa-dev mailing list
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Rob Clark
2017-06-15 16:57:13 UTC
Permalink
Raw Message
Post by Rob Clark
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails
because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1.
Yogesh, can you describe a bit more what "fails" means? What sequence
of gl calls, for example, is it making?
The problem described shortly: Flatland uses timestamps from Fence objects
for calculating time (using getSignalTime API) and in case of having -1 from
producer (Mesa) we will end up having same timestamp for startFence and
endFence (since both are Fence::NO_FENCE) and thus flatland will keep
running forever as it thinks no time has been passed between 2 fences. It is
stuck in a loop where it tries to find how many frames are required so that
driver will spend certain amount of time doing it.
hmm, any idea what the getSignalTime() API sits on top of? I don't
think we have such a capability with fence fd's..

BR,
-R
Tapani Pälli
2017-06-15 17:17:10 UTC
Permalink
Raw Message
Post by Rob Clark
Post by Rob Clark
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Post by Marathe, Yogesh
Hello,
I'm tyring to run flatland native app on android. It apparantly fails
because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1.
Yogesh, can you describe a bit more what "fails" means? What sequence
of gl calls, for example, is it making?
The problem described shortly: Flatland uses timestamps from Fence objects
for calculating time (using getSignalTime API) and in case of having -1 from
producer (Mesa) we will end up having same timestamp for startFence and
endFence (since both are Fence::NO_FENCE) and thus flatland will keep
running forever as it thinks no time has been passed between 2 fences. It is
stuck in a loop where it tries to find how many frames are required so that
driver will spend certain amount of time doing it.
hmm, any idea what the getSignalTime() API sits on top of? I don't
think we have such a capability with fence fd's..
I don't know much of libsync but it uses libsync functions
'sync_fence_info' and 'sync_pt_info' to retrieve data from fence fd.
Post by Rob Clark
BR,
-R
Rob Clark
2017-06-15 20:17:20 UTC
Permalink
Raw Message
Post by Rob Clark
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Hello,
I'm tyring to run flatland native app on android. It apparantly fails
because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1.
Yogesh, can you describe a bit more what "fails" means? What sequence
of gl calls, for example, is it making?
The problem described shortly: Flatland uses timestamps from Fence objects
for calculating time (using getSignalTime API) and in case of having -1 from
producer (Mesa) we will end up having same timestamp for startFence and
endFence (since both are Fence::NO_FENCE) and thus flatland will keep
running forever as it thinks no time has been passed between 2 fences. It is
stuck in a loop where it tries to find how many frames are required so that
driver will spend certain amount of time doing it.
hmm, any idea what the getSignalTime() API sits on top of? I don't
think we have such a capability with fence fd's..
I don't know much of libsync but it uses libsync functions 'sync_fence_info'
and 'sync_pt_info' to retrieve data from fence fd.
oh, yeah, upstream does look like it supports the SYNC_IOC_FILE_INFO
ioctl. So I guess someone did actually think this through ;-)

BR,
-R
Eric Engestrom
2017-06-15 22:58:07 UTC
Permalink
Raw Message
Post by Rob Clark
Post by Rob Clark
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Hello,
I'm tyring to run flatland native app on android. It apparantly fails
because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1.
Yogesh, can you describe a bit more what "fails" means? What sequence
of gl calls, for example, is it making?
The problem described shortly: Flatland uses timestamps from Fence objects
for calculating time (using getSignalTime API) and in case of having -1 from
producer (Mesa) we will end up having same timestamp for startFence and
endFence (since both are Fence::NO_FENCE) and thus flatland will keep
running forever as it thinks no time has been passed between 2 fences. It is
stuck in a loop where it tries to find how many frames are required so that
driver will spend certain amount of time doing it.
hmm, any idea what the getSignalTime() API sits on top of? I don't
think we have such a capability with fence fd's..
I don't know much of libsync but it uses libsync functions 'sync_fence_info'
and 'sync_pt_info' to retrieve data from fence fd.
oh, yeah, upstream does look like it supports the SYNC_IOC_FILE_INFO
ioctl. So I guess someone did actually think this through ;-)
If memory serves, Gustavo Padovan did most of that work :)
Chad Versace
2017-06-19 18:28:47 UTC
Permalink
Raw Message
Post by Eric Engestrom
Post by Rob Clark
Post by Rob Clark
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Hello,
I'm tyring to run flatland native app on android. It apparantly fails
because of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is forcing
fence_fd =-1.
Yogesh, can you describe a bit more what "fails" means? What sequence
of gl calls, for example, is it making?
The problem described shortly: Flatland uses timestamps from Fence objects
for calculating time (using getSignalTime API) and in case of having -1 from
producer (Mesa) we will end up having same timestamp for startFence and
endFence (since both are Fence::NO_FENCE) and thus flatland will keep
running forever as it thinks no time has been passed between 2 fences. It is
stuck in a loop where it tries to find how many frames are required so that
driver will spend certain amount of time doing it.
hmm, any idea what the getSignalTime() API sits on top of? I don't
think we have such a capability with fence fd's..
I don't know much of libsync but it uses libsync functions 'sync_fence_info'
and 'sync_pt_info' to retrieve data from fence fd.
oh, yeah, upstream does look like it supports the SYNC_IOC_FILE_INFO
ioctl. So I guess someone did actually think this through ;-)
If memory serves, Gustavo Padovan did most of that work :)
Hi, I wrote the comment :) The comment is ancient, and predates the
existence of sync_file in the kernel and Mesa.

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.

[1]: https://android.googlesource.com/platform/system/core/+/android-7.1.1_r43/include/system/window.h#572
Marathe, Yogesh
2017-06-20 15:06:44 UTC
Permalink
Raw Message
-----Original Message-----
Post by Eric Engestrom
Post by Rob Clark
On Thu, Jun 15, 2017 at 12:04 PM, Tapani Pälli
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Hello,
I'm tyring to run flatland native app on android. It apparantly
fails because of a fence issue.
while debuging further it is observed that
droid_window_enqueue_buffer() is forcing fence_fd =-1.
Yogesh, can you describe a bit more what "fails" means? What
sequence of gl calls, for example, is it making?
The problem described shortly: Flatland uses timestamps from Fence
objects for calculating time (using getSignalTime API) and in case
of having -1 from producer (Mesa) we will end up having same
timestamp for startFence and endFence (since both are
Fence::NO_FENCE) and thus flatland will keep running forever as it
thinks no time has been passed between 2 fences. It is stuck in a
loop where it tries to find how many frames are required so that driver will
spend certain amount of time doing it.
Post by Eric Engestrom
Post by Rob Clark
hmm, any idea what the getSignalTime() API sits on top of? I
don't think we have such a capability with fence fd's..
I don't know much of libsync but it uses libsync functions 'sync_fence_info'
and 'sync_pt_info' to retrieve data from fence fd.
oh, yeah, upstream does look like it supports the SYNC_IOC_FILE_INFO
ioctl. So I guess someone did actually think this through ;-)
If memory serves, Gustavo Padovan did most of that work :)
Hi, I wrote the comment :) The comment is ancient, and predates the existence
of sync_file in the kernel and Mesa.
That comment seems to be coming from window.h :), thanks for sync_file input.
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.

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?
[1]: https://android.googlesource.com/platform/system/core/+/android-
7.1.1_r43/include/system/window.h#572
Chad Versace
2017-06-20 17:06:33 UTC
Permalink
Raw Message
Post by Marathe, Yogesh
Post by Chad Versace
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...".
Post by Marathe, Yogesh
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.
Marathe, Yogesh
2017-06-20 17:34:37 UTC
Permalink
Raw Message
-----Original Message-----
Post by Marathe, Yogesh
Post by Chad Versace
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...".
Post by Marathe, Yogesh
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.
Post by Marathe, Yogesh
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
Loading...