On Tue, Jan 14, 2014 at 09:47:45PM +0800, Daniel Kurtz wrote: > On Tue, Jan 14, 2014 at 9:38 AM, Chad Versace > <[email protected]> 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. _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
