[Piglit] [PATCH 2/8] piglit-dispatch: Install waffle procs during dispatch init

[Chad Versace]

On Tue, Jan 14, 2014 at 09:47:45PM +0800, Daniel Kurtz wrote:
> On Tue, Jan 14, 2014 at 9:38 AM, Chad Versace
> <chad.versace at linux.intel.com> wrote:
> > On Mon, Jan 13, 2014 at 08:30:16PM +0800, Daniel Kurtz wrote:
> >> Hi Chad,
> >>
> >> With this patch applied, we don't even get as far as glGetIntegerv(),
> >> since we can't even resolve "glGetString" to deduce the GL_VERSION in
> >> piglit_dispatch_default_init()->piglit_dispatch_init()->piglit_get_gl_version().
> >>
> >> # bin/egl-create-context-valid-flag-debug gles3 -auto
> >> piglit_dispatch_default_init(api:2)
> >> piglit_dispatch_init(api:2)
> >> piglit_get_gl_version: calling glGetString(GL_VERSION)
> >> piglit: error: get_wfl_core_proc failed due to WAFFLE_ERROR_NOT_INITIALIZED
> >> GetProcAddress failed for "glGetString"
> >> PIGLIT: {'result': 'fail' }
> >>
> >> Without my patch, however, we were calling the default dispatch resolution path:
> >> piglit_get_gl_version
> >>   piglit_dispatch_glGetString
> >>     stub_glGetString
> >>       resolve_glGetString
> >>          get_core_proc
> >>             get_core_proc_address
> >>               get_ext_proc_address
> >>                 glXGetProcAddressARB()
> >>
> >> This kind of works, and glXGetProcAddressARB returns the address of
> >> glGetString() in libGLso...  However, this is the wrong glGetString()
> >> function, since we should be finding glGetString() of libGLESv2.so. On
> >> my system, this glGetString() returns NULL, and since
> >> piglit_get_gl_version isn't able to handle a NULL version string, so
> >> the test crashes with a seg fault.
> >>
> >> So, on my system at least, my patch changed these crashing EGL tests
> >> into failures.  I considered that progress :-).  Of course, if it
> >> breaks other
> >>
> >> My patch does fixes some of the OpenGL ES 2.0 and 3.0 tests, though,
> >> since they use the PIGLIT_GL_TEST_CONFIG_{BEGIN, END} macros, which do
> >> call waffle_init(). So...
> >>
> >> Why aren't the EGL/GLX tests initializing waffle?
> >> Is it supposed to work already, or is adding waffle support to EGL
> >> tests still a work in progress?
> >> What do you recommend to get them working?
> >
> > Waffle serves mainly as an abstraction layer over the window
> > system (X11/GLX, X11/EGL, Wayland/EGL, GBM/EGL). Tests for specific
> > window system API, such as the GLX and EGL tests, need to directly make
> > GLX or EGL calls. After all, the tests are validating GLX and EGL
> > extensions, which are inaccessible through Waffle.
> >
> > In my original plan, before Waffle was integrated into Piglit, the GLX
> > and EGL tests would not use Waffle at all, because I didn't see a need
> > for it. But, maybe there is a need now.
> 
> So, I think you are correct to say that EGL calls themselves don't
> need waffle.  In fact, some of the EGL tests do pass without
> initializing waffle... the ones that are verifying that pure EGL
> operations (such as context creation) fail with invalid parameters.
> :-)
> 
> However, for most of the EGL tests piglit use GL calls (even just
> glGetString or glGetIntegerv) to verify our EGL operations.
> Therefore, most of the EGL tests still need waffle for GL dispatch,
> right?
> 
> > I think the best approach to move forward is to add a new function to
> > libpiglitutil, piglit_egl_dispatch_init(). This will initialize
> > piglit-dispatch by directly calling piglit_dispatch_init(), as opposed
> > to piglit_dispatch_default_init(). By directly calling
> > piglit_dispatch_init(), it can avoid the waffle initialization problem.
> >
> > However... I tried that approach today without success. I quickly
> > descended into a neverending pit of linker errors.
> >
> > To implement piglit_egl_dispatch_init(), libpiglitutil requires that
> > piglit_dispatch_init() be defined. But piglit_dispatch_init() is defined
> > in libpiglitutil_gl. libpiglitutil_gl links to libpiglitutil, not the
> > other way around.
> >
> > (Quick explanation of library separation: libpiglitutil contains
> > utilities independent of the GL api, such as EGL utilities.  This
> > enables EGL tests to use those utilities without linking to libGL*.
> > Each of libpiglitutil_{gl,gles1,gles2,gles3} links to its corresponding
> > libGL*.)
> >
> > So... I moved piglit-dispatch.c from libpiglitutil_${api} to
> > libpiglitutil. But this also failed, because piglit-dispatch.c requires
> > that gl_fw be defined. (Like I said, gl_fw should have never leaked into
> > this file). Each libpiglitutil_${api} defines gl_fw.
> >
> > So... I fixed the gl_fw linking problem. Which introduced another
> > linking problem. Which I fixed. Which introduced another... :(
> >
> > After playing that game for 2 hours, I still have linker errors from
> > undefined symbols. I plan to continue to work on it, and hopefully
> > finish it this week. Here's my branch if you wish to follow:
> >
> >     http://cgit.freedesktop.org/~chadversary/piglit
> >     branch=fix-egl-dispatch
> >
> > I'll keep you updated.
> 
> Thanks for the update so far!
> 
> Today, however, I've been working on an even harder task...
> 
> It turns out it is just lucky I am able to build and run piglit tests at all.
> I actually shouldn't even have libGL, nor OpenGL/glx headers on my
> system - just libEGL and libGLESv1_CM and libGLESv2, and EGL/GLES
> headers.
> 
> But in fact, through some other dependencies, a stub version of mesa
> was still getting built and installed, and it was installing libGL and
> GLX headers.  Plus, my waffle build script is always building it with
> waffle_has_glx, so it is providing waffle with both EGL and GLX.
> 
> After removing libGL, the GLX headers and waffle's GLX support, piglit
> now doesn't build at all.  I have not yet been successful at removing
> all of the hard dependencies in piglit on GL and GLX so that it can be
> built with just EGL/GLES.
> 
> Has anybody built piglit for just X11 + EGL/GLES successfully?

I never tried building Piglit with only X11+EGL+GLES. That does sound
much harder than fixing piglit-dispatch in the EGL tests. If you
succeed, you are likely to uncover many deep dark secrets about Piglit's
build system, GL dispatch system, and dependencies :)

Likewise, yesterday as I began to go deeper into solving the EGL
dispatch problem, and discovered a chain of interdependent problems that
needed solving first, I believe I finally arrived at an initial node in
the problem-dependency graph, on which many larger linker issues depend:
piglit-dispatch does not yet support GLES1.

I began to add GLES1 dispatch to Piglit, which was easier than
I expected. Hopefully the chain of linking problems will begin to fall
away as hacking proceeds.