[Piglit] Fwd: [PATCH 00/10] Allow building and running EGL+GLES tests without GLX

[Daniel Kurtz]

On Jan 20, 2014 4:47 AM, "Chad Versace" <chad.versace at linux.intel.com> wrote:
>
> On Wed, Jan 15, 2014 at 07:09:55PM +0800, Daniel Kurtz wrote:
> > With the following patches I am able to build and run piglit tests on a system
> > with no OpenGL and no GLX (ie, no glproto, no libGL.so and no /usr/include/GL).
> >
> > The X11, GBM and wayland patches are really 'bug reports', it seems like they
> > too should be probed rather than assumed.
>
> I tested building and running this series (minus the last dlsym patch)
> on a system with no libraries nor headers for X11 and OpenGL. Instead
> the system had GLES1, GLES2, GLES3, Wayland and GBM. Unsurprisingly,
> Piglit failed to build and the series needed a few touch-ups. Rather
> than asking you to set up such a system, fix the bugs, and resubmit the
> series, I went ahead and applied the fixes myself and committed the
> series. It was painful enough for me to set up an X-free GL-free system
> that I didn't want to make you go through the pain too :)
>
> Thanks, really, thanks for getting the ball rolling on breaking Piglit's
> dependency on X11.
>
> About the fixes I applied...
>
> Using my X-free GL-free test system, I discovered that, even with your
> series, Piglit refused to build. I had to reorder a few of your patches
> and add two more to get Piglit to work my test system. My extra two are:
>
> cmake: Fix libpiglitutil on systems without X11
> egl_khr_create_context: Fix X11 and GL requirements in CMake
>
> I fixed a bug in your patch "cmake: GLX is not always present on Linux".
> The patch turned off PIGLIT_HAS_GLX too eagerly. PIGLIT_HAS_GLX doesn't
> actually require glproto, but PIGLIT_BUILD_GLX_TEST does not

I guess there is something about GLX and glproto that I'm missing. I
was assuming that glproto defined the GLX protocol, so a system "has
GLX" iff it has glproto installed.

> Your bugreport patch about probing Wayland support, I completed it by
> probing for wayland-client.pc and wayland-egl.pc.
>
> I also expanded or clarified a few of the commit messages where you
> stated questions or uncertainty in the message.
>
> So... Patches 1-9 of your series are now committed to master. The few
> fixes and expanded commit messages I did are documented with a v2 tag.
>
> I successfully ran Piglit with PIGLIT_PLATFORM=gbm after applying the
> fixes. Honestly, I was surprised that it worked! The system had GBM,
> GLES1, GLES2, and GLES3. The result summary is below. The full summary,
> with all skipped tests removed, is attached.

Thanks for all of the reviewing and testing!

>
> summary:
> pass: 106
> fail: 3
> crash: 1
> skip: 15455
> warn: 0
> dmesg-warn: 0
> dmesg-fail: 0
> total: 15565
>
> I also did a regression test against Piglit master on Intel Sandybridge
> system with GLX and OpenGL installed, as well as GLES1,2,3. There were
> no *real* regressions; just the usual sporadic failures due to Python
> bugs and whatnot.
>
> > I'm really not sure about that last patch. It works for my situation, since
> > my libEGL.so, libGLESv2.so and libGLESv1_CM.so are all exactly the same library
> > (they are all just symlinks to vendor .so). But I don't think it will work in
> > the general case where these are really separate libraries, with potentially
> > conflicting core functions.
>
> I'm also uncertain about your last patch.
>
> Are you aware of any shipping EGL implementation that we wish to run
> Piglit on in the short-term and where eglGetProcAddress to fails to work
> for core functions? Mesa doesn't suffer from that problem; it behaves
> as if it supported EGL_KHR_get_all_proc_addresses even though it does
> not yet expose the extension string.

Yes, the mali libEGL is "to spec": eglGetProcAddress does not return
valid function pointers for GL core functions.
For example, using eglGetProcAddress() to fetch glGetString returns NULL:
piglit # shader_runner_gles3
/usr/local/piglit/tests/spec/glsl-es-3.00/execution/varying-struct-copy-out-vs.shader_test
-auto
get_ext_proc_address: eglGetProcAddress(glGetString) => (nil)
GetProcAddress failed for "glGetString"

That is a major stumbling block for me. It also makes it difficult to
use Eric Anholt's libepoxy, which suffers from a similar set of
libGL/GLX-dependency issues.
After hacking up epoxy locally to get gles-only core function dispatch
working, I am now more confident with using dlsym.

> If the problem is only theoretical, and Piglit will not encounter such
> an implementation in the short-term, then I propose we drop the dlsym
> patch. Otherwise, we need to design the patch to work reliably in the
> general case where distinct EGL, GL, and GLES 1-3 libraries are
> installed, which is the case for Mesa.
>

The current hack I have just does dlsym on the executable, which will
follow some default path to find the requested GL client library
symbol. However, I think we agree that to be 100% correct we should
dispatch client library core symbols by doing dlsym on the specific
client library. AFAICT, this will require plumbing the library *type*
(gl or gles) as well as version through to the core resolve function.
Is that really the case for mesa?  EGL, GL, GLES1, and GLES2/3 are
completely separate libraries?  Or are they symlinks to the same .so?

I could work on that some more, but, for now though, the "*" dlsym
works for me, and shouldn't break anybody, right?
If the patch went in as-is, we would at least be better off than where
we are today.

-Dan