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

[Chad Versace]

On Tue 25 Oct 2016, Rob Clark wrote:
> 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.

The two modes of using EGL_ANDROID_native_fence_sync correspond
to an "in" fence and an "out" fence.

If you give a valid sync fd to eglCreateSync, then the next flush will
submit the fd as an "in" fence along with the submitted batch buffer. The kernel
will schedule the work to begin after the in-fence signals.

If you give fd == -1 to eglCreateSync, then the next flush, when it
submits the batch buffer to i915, will tell the EXECBUFFER2 ioctl
to return an "out" fence fd. The out-fence will signal when the batch
buffer completes execution.

For more details, see I915_EXEC_FENCE_IN and I915_EXEC_FENCE_OUT in this
email:

    Subject: [Intel-gfx] [PATCH 41/41] drm/i915: Support explicit fencing for execbuf
    From: Chris Wilson <chris at chris-wilson.co.uk>
    To: intel-gfx at lists.freedesktop.org
    Date: Thu, 20 Oct 2016 16:04:23 +0100
    Message-Id: <20161020150423.4560-42-chris at chris-wilson.co.uk>
    In-Reply-To: <20161020150423.4560-1-chris at chris-wilson.co.uk>
    List-Id: <intel-gfx.lists.freedesktop.org>