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

[Tapani Pälli]

On 06/15/2017 06:52 PM, Rob Clark wrote:
> 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?


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 :/


>
>> 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.

Not exposed to applications, this is a framework level test.

> BR,
> -R
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev