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

[Eric Anholt]

Chad Versace <chad.versace at linux.intel.com> writes:

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

I've already rewritten our dispatch to use libepoxy, checkout the epoxy
branch of my piglit tree.  It does EGL, GLX, WGL, GLES1/2/3, etc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20140115/b97f4362/attachment.pgp>