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

Rob Clark robdclark at gmail.com
Thu Jun 15 20:17:20 UTC 2017


On Thu, Jun 15, 2017 at 1:17 PM, Tapani Pälli <tapani.palli at intel.com> wrote:
> On 06/15/2017 07:57 PM, Rob Clark wrote:
>
> On Thu, Jun 15, 2017 at 12:04 PM, Tapani Pälli <tapani.palli at intel.com>
> wrote:
>
> 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.
>
> 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


More information about the mesa-dev mailing list