On Jan 20, 2014 4:47 AM, "Chad Versace" <[email protected]> wrote: > > On Wed, Jan 15, 2014 at 07:09:55PM +0800, Daniel Kurtz wrote: > > With the following patches I am able to build and run piglit tests on a > > system > > with no OpenGL and no GLX (ie, no glproto, no libGL.so and no > > /usr/include/GL). > > > > The X11, GBM and wayland patches are really 'bug reports', it seems like > > they > > too should be probed rather than assumed. > > I tested building and running this series (minus the last dlsym patch) > on a system with no libraries nor headers for X11 and OpenGL. Instead > the system had GLES1, GLES2, GLES3, Wayland and GBM. Unsurprisingly, > Piglit failed to build and the series needed a few touch-ups. Rather > than asking you to set up such a system, fix the bugs, and resubmit the > series, I went ahead and applied the fixes myself and committed the > series. It was painful enough for me to set up an X-free GL-free system > that I didn't want to make you go through the pain too :) > > Thanks, really, thanks for getting the ball rolling on breaking Piglit's > dependency on X11. > > About the fixes I applied... > > Using my X-free GL-free test system, I discovered that, even with your > series, Piglit refused to build. I had to reorder a few of your patches > and add two more to get Piglit to work my test system. My extra two are: > > cmake: Fix libpiglitutil on systems without X11 > egl_khr_create_context: Fix X11 and GL requirements in CMake > > I fixed a bug in your patch "cmake: GLX is not always present on Linux". > The patch turned off PIGLIT_HAS_GLX too eagerly. PIGLIT_HAS_GLX doesn't > actually require glproto, but PIGLIT_BUILD_GLX_TEST does not
I guess there is something about GLX and glproto that I'm missing. I was assuming that glproto defined the GLX protocol, so a system "has GLX" iff it has glproto installed. > Your bugreport patch about probing Wayland support, I completed it by > probing for wayland-client.pc and wayland-egl.pc. > > I also expanded or clarified a few of the commit messages where you > stated questions or uncertainty in the message. > > So... Patches 1-9 of your series are now committed to master. The few > fixes and expanded commit messages I did are documented with a v2 tag. > > I successfully ran Piglit with PIGLIT_PLATFORM=gbm after applying the > fixes. Honestly, I was surprised that it worked! The system had GBM, > GLES1, GLES2, and GLES3. The result summary is below. The full summary, > with all skipped tests removed, is attached. Thanks for all of the reviewing and testing! > > summary: > pass: 106 > fail: 3 > crash: 1 > skip: 15455 > warn: 0 > dmesg-warn: 0 > dmesg-fail: 0 > total: 15565 > > I also did a regression test against Piglit master on Intel Sandybridge > system with GLX and OpenGL installed, as well as GLES1,2,3. There were > no *real* regressions; just the usual sporadic failures due to Python > bugs and whatnot. > > > I'm really not sure about that last patch. It works for my situation, since > > my libEGL.so, libGLESv2.so and libGLESv1_CM.so are all exactly the same > > library > > (they are all just symlinks to vendor .so). But I don't think it will work > > in > > the general case where these are really separate libraries, with potentially > > conflicting core functions. > > I'm also uncertain about your last patch. > > Are you aware of any shipping EGL implementation that we wish to run > Piglit on in the short-term and where eglGetProcAddress to fails to work > for core functions? Mesa doesn't suffer from that problem; it behaves > as if it supported EGL_KHR_get_all_proc_addresses even though it does > not yet expose the extension string. Yes, the mali libEGL is "to spec": eglGetProcAddress does not return valid function pointers for GL core functions. For example, using eglGetProcAddress() to fetch glGetString returns NULL: piglit # shader_runner_gles3 /usr/local/piglit/tests/spec/glsl-es-3.00/execution/varying-struct-copy-out-vs.shader_test -auto get_ext_proc_address: eglGetProcAddress(glGetString) => (nil) GetProcAddress failed for "glGetString" That is a major stumbling block for me. It also makes it difficult to use Eric Anholt's libepoxy, which suffers from a similar set of libGL/GLX-dependency issues. After hacking up epoxy locally to get gles-only core function dispatch working, I am now more confident with using dlsym. > If the problem is only theoretical, and Piglit will not encounter such > an implementation in the short-term, then I propose we drop the dlsym > patch. Otherwise, we need to design the patch to work reliably in the > general case where distinct EGL, GL, and GLES 1-3 libraries are > installed, which is the case for Mesa. > The current hack I have just does dlsym on the executable, which will follow some default path to find the requested GL client library symbol. However, I think we agree that to be 100% correct we should dispatch client library core symbols by doing dlsym on the specific client library. AFAICT, this will require plumbing the library *type* (gl or gles) as well as version through to the core resolve function. Is that really the case for mesa? EGL, GL, GLES1, and GLES2/3 are completely separate libraries? Or are they symlinks to the same .so? I could work on that some more, but, for now though, the "*" dlsym works for me, and shouldn't break anybody, right? If the patch went in as-is, we would at least be better off than where we are today. -Dan _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
