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

[Rafael Antognolli]

On Tue, Oct 25, 2016 at 07:29:16PM -0400, 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..

OK, got your point.

> 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?

I don't know, but I could take a look at that if it's really needed (and
assuming nobody does it first). For now I'll just assume it's not
necessary.

Thanks,
Rafael