Open craftyguy opened 6 years ago
@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.
I've tried building with the flags above, and also verifying that NEON is being used (it is), but framerate is still ~38fps.
Is ZB_copyFrameBuffer being called?
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.
You should run a profiler on it. perf is a good one.
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.
If you stub tglLightfv it fixes the colors. TinyGL definitely seems to have a buggy lighting model. Looks like GL_POSITION causes it.
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.
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.
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
Which commit hash caused the 6fps drop?
Sorry I should have mentioned that in my last comment. It was 60b1e47e127d64688221d98b3b140f874f79b28a. I am building 8c0a7f2a9f23ef2b7600525c2a20345cb165429d right now
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
Can you try reverting this part (glx.c)? https://github.com/lunixbochs/glshim/commit/e3d5b6b39cf15b1b599663bd00c987b07b9d234f#diff-95debcd9f74cee5ec6da1f8650e388ce
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..
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
I guessed that change was causing a color conversion step inside X11.
How fast is it if you comment out the GL_LIGHTING line in tinygles/enable.c? fabrice said the lighting code was probably slow.
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?
It should actually fix the glinting, which is caused by lighting bugs. Also you don't really need vertex lighting for UI.
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
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?
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.
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.
If I set LIBGL_GL, as you suggest in some other issue threads here, I get a segfault with glxinfo:
And when using glshim: