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

Rob Clark robdclark at gmail.com
Thu Jun 15 15:52:56 UTC 2017


On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
<eric.engestrom at imgtec.com> wrote:
> On Thursday, 2017-06-15 13:27:06 +0000, Marathe, Yogesh wrote:
>> 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?


> 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);
>
>> 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


More information about the mesa-dev mailing list