Unable to run glxinfo/glxgears

[craftyguy]

I've been trying to get glxinfo and/or glxgears to run when using glshim (on a Nokia N900).

My ~/lib directory has tinygles in it as well, so I am explicitly setting LIBGL_GLES to system libGLES binary so that it doesn't get used in this test.

localhost:~$ LD_LIBRARY_PATH=~/lib  LIBGL_FB=1  LIBGL_GLES=/usr/lib/libGLESv1_CM.so.1 DISPLAY=:0 glxinfo
name of display: :0
libGL:loaded: /usr/lib/libGLESv1_CM.so.1
libGL:loaded: libEGL.so.1
libGL: built on Mar 17 2018 12:28:41
libGL: framebuffer output enabled
libEGL warning: DRI2: failed to authenticate
ERROR: EGL Error detected: EGL_BAD_NATIVE_WINDOW (0x300B)
glXGetProcAddress: glGetProgramivARB not found.
glX stub: glGetStringi
glXGetProcAddress: glGetConvolutionParameteriv not found.
libGL: GL_INVALID_ENUM when calling glGet<GL_INT>(GL_NUM_EXTENSIONS)
Warning: GL error 0x500 at line 501
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: 
server glx version string: 
server glx extensions:
client glx vendor string: 
client glx version string: 
client glx extensions:
GLX version: 1.4
GLX extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_EXT_create_context_es2_profile
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 5.0, 128 bits)
OpenGL core profile version string: 1.4 glshim wrapper
OpenGL core profile extensions:
    GL_ARB_multitexture, GL_ARB_texture_cube_map, GL_EXT_blend_color, 
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, 
    GL_EXT_blend_logic_op, GL_EXT_blend_subtract, GL_EXT_secondary_color, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  78 (X_CreateColormap)
  Serial number of failed request:  7
  Current serial number in output stream:  10

localhost:~$ LD_LIBRARY_PATH=~/lib  LIBGL_FB=1  LIBGL_GLES=/usr/lib/libGLESv1_CM.so.1 DISPLAY=:0 glxgears
Error relocating /usr/bin/glxgears: glXQueryDrawable: symbol not found

If I set LIBGL_GL, as you suggest in some other issue threads here, I get a segfault with glxinfo:

localhost:~$ LD_LIBRARY_PATH=~/lib  LIBGL_FB=1  LIBGL_GLES=/usr/lib/libGLESv1_CM.so.1 LIBGL_EGL=/usr/lib/libGL.so.1 LD_PRELOAD=~/lib/libpreload.so DISPLAY=:0 glxinfo
name of display: :0
libGL:loaded: /usr/lib/libGLESv1_CM.so.1
libGL:loaded: /usr/lib/libGL.so.1
libGL: built on Mar 17 2018 12:28:41
libGL: framebuffer output enabled
Segmentation fault
localhost:~$ LD_LIBRARY_PATH=~/lib  LIBGL_FB=1  LIBGL_GLES=/usr/lib/libGLESv1_CM.so.1 LIBGL_EGL=/usr/lib/libGL.so.1 LD_PRELOAD=~/lib/libpreload.so DISPLAY=:0 glxgears
Error relocating /usr/bin/glxgears: glXQueryDrawable: symbol not found

localhost:~$ ldd $(which glxinfo)
        /lib/ld-musl-armhf.so.1 (0xb6f18000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb6e7a000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb6d61000)
        libc.musl-armhf.so.1 => /lib/ld-musl-armhf.so.1 (0xb6f18000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6d35000)
        libxcb-dri3.so.0 => /usr/lib/libxcb-dri3.so.0 (0xb6d22000)
        libxcb-present.so.0 => /usr/lib/libxcb-present.so.0 (0xb6d0f000)
        libxcb-sync.so.1 => /usr/lib/libxcb-sync.so.1 (0xb6cf9000)
        libxshmfence.so.1 => /usr/lib/libxshmfence.so.1 (0xb6ce7000)
        libglapi.so.0 => /usr/lib/libglapi.so.0 (0xb6cad000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb6c8e000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb6c7b000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6c66000)
        libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xb6c54000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6c26000)
        libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xb6c03000)
        libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0xb6bef000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6bda000)
        libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb6bbb000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6ba1000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6b8e000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6b79000)
        libbsd.so.0 => /usr/lib/libbsd.so.0 (0xb6b54000)

And when using glshim:

localhost:~$ LD_LIBRARY_PATH=~/lib  LIBGL_FB=1  LIBGL_GLES=/usr/lib/libGLESv1_CM.so.1 DISPLAY=:0 ldd $(which glxgears)
        /lib/ld-musl-armhf.so.1 (0xb6f10000)
        libGL.so.1 => /home/user/lib/libGL.so.1 (0xb6e5d000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb6d44000)
        libc.musl-armhf.so.1 => /lib/ld-musl-armhf.so.1 (0xb6f10000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6d2a000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6cfc000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6ce9000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6cd4000)
        libbsd.so.0 => /usr/lib/libbsd.so.0 (0xb6caf000)
Error relocating /usr/bin/glxgears: glXQueryDrawable: symbol not found
localhost:~$ LD_LIBRARY_PATH=~/lib  LIBGL_FB=1  LIBGL_GLES=/usr/lib/libGLESv1_CM.so.1 LIBGL_EGL=/usr/lib/libGL.so.1 DISPLAY=:0 ldd $(which glxgears)
        /lib/ld-musl-armhf.so.1 (0xb6eda000)
        libGL.so.1 => /home/user/lib/libGL.so.1 (0xb6e27000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb6d0e000)
        libc.musl-armhf.so.1 => /lib/ld-musl-armhf.so.1 (0xb6eda000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6cf4000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6cc6000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6cb3000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6c9e000)
        libbsd.so.0 => /usr/lib/libbsd.so.0 (0xb6c79000)
Error relocating /usr/bin/glxgears: glXQueryDrawable: symbol not found

[craftyguy]

@lunixbochs if you don't mind, I will submit a PR to fix compiling of glshim/swrast branch on musl. I'll also test on x86/glibc, but I don't have a way to test armhf/armv7 w/ glibc.

[craftyguy]

I've tried building with the flags above, and also verifying that NEON is being used (it is), but framerate is still ~38fps.

[lunixbochs]

Is ZB_copyFrameBuffer being called?

[craftyguy]

Assuming you are referring to this instance of it, no, it does not seem to be getting called: https://github.com/lunixbochs/glshim/blob/swrast/src/tinygles/zbuffer.c#L192

I tossed in a print statement to check.

[lunixbochs]

You should run a profiler on it. perf is a good one.

[craftyguy]

Yea unfortunately, as I've discovered in the past on other projects, Alpine Linux has a serious lacking of any profilers. Sigh.

Well, even the gains here so far are better than before, at least as measured by glxgears.

[lunixbochs]

If you stub tglLightfv it fixes the colors. TinyGL definitely seems to have a buggy lighting model. Looks like GL_POSITION causes it.

[ollieparanoid]

I've looked into packaging perf and it's not that trivial unfortunately - but I could prioritize it for myself and work on it if necessary.

In October we had some version of oprofile packaged in an extra branch, but I'm not sure if that worked. Maybe that helps already.

[lunixbochs]

Made some small optimizations, and the latest commit uses glshim's vectorized matrix code instead of tinygles' (unvectorized). There's some kind of regression causing a lighting glint in glxgears, but otherwise it should be faster and the lighting seems way closer to reality.

[craftyguy]

Just tested again, and it seems performance went down for me ~6fps. I see you just pushed another commit though in the last couple of minutes so I'll give that a try right now!

localhost:~/glshim$ LD_LIBRARY_PATH=~/glshim/lib LIBGL_SWRAST=1 DISPLAY=:0 glxgears
glshim: using software renderer
libGL: built on Mar 21 2018 15:59:12
gl_enable_disable(): 0x0BA1 not supported
163 frames in 5.0 seconds = 32.495 FPS
165 frames in 5.0 seconds = 32.997 FPS

[lunixbochs]

Which commit hash caused the 6fps drop?

[craftyguy]

Sorry I should have mentioned that in my last comment. It was 60b1e47e127d64688221d98b3b140f874f79b28a. I am building 8c0a7f2a9f23ef2b7600525c2a20345cb165429d right now

[craftyguy]

Ok looks like 8c0a7f2 fixes lighting as you suggested (there's still some strangeness in the center of the gears though)

localhost:~/glshim$ LD_LIBRARY_PATH=~/glshim/lib LIBGL_SWRAST=1 DISPLAY=:0 glxgears
glshim: using software renderer
libGL: built on Mar 21 2018 16:15:02
gl_enable_disable(): 0x0BA1 not supported
175 frames in 5.0 seconds = 34.847 FPS
159 frames in 5.0 seconds = 31.758 FPS
168 frames in 5.0 seconds = 33.581 FPS
170 frames in 5.0 seconds = 33.817 FPS

[lunixbochs]

Can you try reverting this part (glx.c)? https://github.com/lunixbochs/glshim/commit/e3d5b6b39cf15b1b599663bd00c987b07b9d234f#diff-95debcd9f74cee5ec6da1f8650e388ce

[craftyguy]

The changes to src/tinygles/glx.c? I'm not totally sure Github is taking me to the part you want me to try reverting..

[craftyguy]

Reverting that change to glx.c removed the performance regression and it's now ~2fps faster than ever!

localhost:~/glshim$ LD_LIBRARY_PATH=~/glshim/lib LIBGL_SWRAST=1 DISPLAY=:0 glxgears
glshim: using software renderer
libGL: built on Mar 21 2018 16:15:02
gl_enable_disable(): 0x0BA1 not supported
200 frames in 5.0 seconds = 39.811 FPS
202 frames in 5.0 seconds = 40.323 FPS
200 frames in 5.0 seconds = 39.997 FPS

[lunixbochs]

I guessed that change was causing a color conversion step inside X11.

[lunixbochs]

How fast is it if you comment out the GL_LIGHTING line in tinygles/enable.c? fabrice said the lighting code was probably slow.

[craftyguy]

Commenting out that line gives a nice bump:

236 frames in 5.0 seconds = 47.138 FPS
235 frames in 5.0 seconds = 46.999 FPS
237 frames in 5.0 seconds = 47.292 FPS

I'm not near the device to be able to see if there's any visual impact to doing this though, but I suspect there would be?

[lunixbochs]

It should actually fix the glinting, which is caused by lighting bugs. Also you don't really need vertex lighting for UI.

[craftyguy]

So I'm back in front of my device, it looks like the gears are being rendered with no color now. Maybe that's a side effect of running without the GL_LIGHTING line?

In any case, I've tried to run a UI (hildon, again), and hit the null pointer segfault I mentioned when I tried glxinfo earlier: https://github.com/lunixbochs/glshim/issues/174#issuecomment-374022577

[lunixbochs]

Ah I forgot to respond to this. You still working on it? Next step should be debugging the visual requested from X11 in glxinfo / by tinygles in glXCreateContext. I guess it shouldn’t be null? Or we should do something else when it’s null?

[craftyguy]

Heh, no worries. I'm not currently working on this, but maybe all this info will help someone who does pick it up again. Thanks for helping me along.