[Mesa-dev] [Bug 101656] Invalid signal timestamps with EGL_SYNC_NATIVE_FENCE_ANDROID on android
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Jun 30 04:39:56 UTC 2017
https://bugs.freedesktop.org/show_bug.cgi?id=101656
Bug ID: 101656
Summary: Invalid signal timestamps with
EGL_SYNC_NATIVE_FENCE_ANDROID on android
Product: Mesa
Version: 17.1
Hardware: x86-64 (AMD64)
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: EGL
Assignee: mesa-dev at lists.freedesktop.org
Reporter: yogesh.marathe at intel.com
QA Contact: mesa-dev at lists.freedesktop.org
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?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170630/c8c7710e/attachment-0001.html>
More information about the mesa-dev
mailing list