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

[Daniel Kurtz]

On Thu, Jan 16, 2014 at 8:20 AM, Eric Anholt <eric at anholt.net> wrote:
> 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.

Eric,

Awesome!  Libepoxy looks very promising.
With a few hacks and tweaks, I was able to get epoxy to build for my
system, and even built the epoxied piglit (rebased on top of my
EGL+GLES patches).  But I ran out of time today before I could run
some piglit tests.


Any idea when you plan to upstream the piglit patches?


By the way, it's not exactly clear what the difference is between
waffle and libepoxy.
Can someone explain it to a newbie like me?


Lastly, for anyone else who is new, like me, these links might save
you some time...

Waffle - a library for selecting GL API and window system at runtime
https://github.com/chadversary/waffle

Epoxy is a library for handling OpenGL function pointer management for you.
https://github.com/anholt/libepoxy

epoxy branch of Eric's piglit git tree:
http://cgit.freedesktop.org/~anholt/piglit/log/?h=epoxy

-Dan