On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
Post by Eric Engestrom Post by Marathe, Yogesh
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
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;
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.