Bug 101656 - Invalid signal timestamps with EGL_SYNC_NATIVE_FENCE_ANDROID on android
Summary: Invalid signal timestamps with EGL_SYNC_NATIVE_FENCE_ANDROID on android
Status: RESOLVED NOTOURBUG
Alias: None
Product: DRI
Classification: Unclassified
Component: General (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-30 04:39 UTC by Yogesh Marathe
Modified: 2017-07-25 14:39 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Yogesh Marathe 2017-06-30 04:39:56 UTC
Description: I'm using EGL_SYNC_NATIVE_FENCE_ANDROID to create a fence fd in producer consumer situation. I'm doing this for every buffer, I see that I'm getting a valid fd every time, I pass that to consumer and on consumer side I call getSingalTime() on this. This uses SYNC_IOC_FILE_INFO ioctl though libsync to get time 64 bit timestamp of when fence was signaled. The observation is sometimes I'm getting lower timestamp for newer fences! 

e.g. fd1 is with Buffer1 later created fd2 is with buffer2, getSignalTime of fd2 is lower than fd1, glFulsh is called before both fds were obtained (force signal).

Expectation - timestamps of newer fds should be higher than older fds always.

Some Code

Producer side

EGLDisplay dpy = eglGetCurrentDisplay(); 
EGLSyncKHR sync = eglCreateSyncKHR(dpy,
                    EGL_SYNC_NATIVE_FENCE_ANDROID, NULL);
            if (sync == EGL_NO_SYNC_KHR) {
                return UNKNOWN_ERROR;
            }
    glFlush();
    fenceFd = eglDupNativeFenceFDANDROID(dpy, sync);

   eglDestroySyncKHR(dpy, sync);
   if (fenceFd == EGL_NO_NATIVE_FENCE_FD_ANDROID) {
                return UNKNOWN_ERROR;
            }

Consumer side

if (item->mFence->isValid()) {
    status_t err = item->mFence->waitForever("acquireBufferLocked");
    if (err != NO_ERROR) {
            return err;
    }
 }

Is EGL_SYNC_NATIVE_FENCE_ANDROID tested in multiple create, dup, destroy sequence?
Comment 1 Rafael Antognolli 2017-07-05 20:59:38 UTC
This bug is related to the discussion here:
https://lists.freedesktop.org/archives/intel-gfx/2017-February/119851.html
Comment 2 Yogesh Marathe 2017-07-25 14:39:55 UTC
Turns out to be kernel issue, where fence timestamp was not initialized.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.