[Piglit] [RFC 0/2] egl_android_native_fence_sync tests.

[Rob Clark]

On Tue, Oct 25, 2016 at 5:19 PM, Rafael Antognolli
<rafael.antognolli at intel.com> wrote:
> Hi,
>
> I finally got to work on these piglit tests (took longer than I
> expected). But here is an initial version, and I would like to know if
> I'm going on the right direction. Particularly I would like to know
> whether adding the sw_sync lib code that I copied mostly as is from
> intel-gpu-tools is acceptable/desirable. Also in order to use the
> sw_sync, one needs to be root on a regular linux distro.
>
> I'm still going to add all the tests for trying to create fences from
> invalid EGLDisplay, and things like that, but I should send those soon.
>
> Additionally, I also have a couple questions:
>
>  1) I don't see anywhere in the spec mentioning about creating a sync
>  fence from an invalid fd (or an fd that is not a sync file), but should
>  I test for it anyway? It looks like an error to me.

hmm, interesting.. from a practical standpoint, I'm not sure there is
any good way to discover a bogus fence fd until we do submit/execbuf
ioctl.  Which means it wouldn't be discovered until you did something
that triggered a flush.

I guess on one hand, it is something easy for a user with fd
refcnt'ing issues to mess up.  On the other hand, for non-debug
scenario's we wouldn't want to introduce extra overhead..

I wonder if there is some way we could add an ioctl on the fence fd to
return "are you a valid fence fd" without conflicting with ioctls on
unrelated fd's?

>  2) The spec mentions that if a fence sync object is created with
>  attribute EGL_SYNC_NATIVE_FENCE_FD_ANDROID set to
>  EGL_NO_NATIVE_FENCE_FD_ANDROID, "the next Flush() operation performed
>  by the current client API causes a new native fence object to be
>  created, and the EGL_SYNC_NATIVE_FENCE_ANDROID attribute of the EGL
>  native fence object is set to a file descriptor that refers to the new
>  native fence object." I'm not sure I fully understand this statement,
>  so I have no idea how to test it.

basically, before glFlush() or eglSwapBuffers() (or perhaps some other
calls that are expected to trigger a flush?) eglDupNativeFenceFD() can
return -1, but after it should return a valid fence.

BR,
-R

>
> Rafael Antognolli (2):
>   egl_android_native_fence_sync: Initial test for native fences.
>   egl_android_native_fence_sync: Add test to create fence from fd.
>
>  tests/egl/spec/CMakeLists.txt                      |   1 +
>  .../CMakeLists.gles2.txt                           |   9 +
>  .../egl_android_native_fence_sync/CMakeLists.txt   |   1 +
>  .../egl_android_native_fence_sync.c                | 569 +++++++++++++++++++++
>  .../spec/egl_android_native_fence_sync/sw_sync.c   | 232 +++++++++
>  .../spec/egl_android_native_fence_sync/sw_sync.h   |  49 ++
>  6 files changed, 861 insertions(+)
>  create mode 100644 tests/egl/spec/egl_android_native_fence_sync/CMakeLists.gles2.txt
>  create mode 100644 tests/egl/spec/egl_android_native_fence_sync/CMakeLists.txt
>  create mode 100644 tests/egl/spec/egl_android_native_fence_sync/egl_android_native_fence_sync.c
>  create mode 100644 tests/egl/spec/egl_android_native_fence_sync/sw_sync.c
>  create mode 100644 tests/egl/spec/egl_android_native_fence_sync/sw_sync.h
>
> --
> 2.7.4
>