Chad Versace <[email protected]> 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 >> <[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.
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.
pgp42QvIkAnJw.pgp
Description: PGP signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
