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

Daniel Kurtz djkurtz at chromium.org
Tue Jan 14 05:47:45 PST 2014


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?


More information about the Piglit mailing list