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

[Chad Versace]

On Mon, Jan 27, 2014 at 08:45:51PM +0800, Daniel Kurtz wrote:
> 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:

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

Maybe this varies among Linux distributions. But on mine, Archlinux, the
glproto package installs headers that define the lowlevel bits of the
GLX protocol:
    /usr/include/GL/glxproto.h
    /usr/include/GL/glxmd.h
    /usr/include/GL/glxtokens.h
    /usr/include/GL/glxint.h

Regular GLX clients (such as Piglit's OpenGL tests) don't need the
protocol definitions. They just need the function prototypes and tokens,
as defined by:
    /usr/include/GL/glx.h
    /usr/include/GL/glxext.h
These headers do not depend on the glproto headers.

In other words, the glproto package is a development package needed to
develop and test the GLX implementation, but not needed run GLX clients.
(Though, I'm not an GLX expert. So someone may contradict me here).



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

In Mesa, each library is separate.  The set of functions statically
available from each library do differ.

But that's not the complete truth. libGL, libGLESv1_cm, and libGLES2 are
just thin trampoline libaries that dispatch the GL functions to a common
driver library.  libEGL is more complicated; it implements the
device-indpendent parts of EGL functions and dispatches the
device-dependent parts to a driver library. The same is true for the GLX
functions in libGL.


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

If it might break a few Piglit tests on Mesa. Did you test on Mesa?

If it doesn't regress any Piglit tests on Mesa, though, then I agree
with you.  If the patch went in as-is, we would at least be better off
than where we are today.

I'll do a regression test on Wayland/Mesa today.