glshim


I knew it was too crazy to not be wrong, duh!

I had a stray older libGL in my home directory which sometimes took precedence over LD_LIBRARY_PATH. When I saw the game working it was actually using the latest glshim. Thanks and sorry for the fuss!
 
Or so we thought! :(

It takes up to a minute of gameplay to get this crash:

Code: 
Program received signal SIGSEGV, Segmentation fault.
0xb65de148 in __memcpy_neon () at ../ports/sysdeps/arm/armv7/multiarch/memcpy_impl.S:332
332     ../ports/sysdeps/arm/armv7/multiarch/memcpy_impl.S: No such file or directory.
(gdb) bt
#0  0xb65de148 in __memcpy_neon () at ../ports/sysdeps/arm/armv7/multiarch/memcpy_impl.S:332
#1  0xb6cc00f4 in memcpy (__len=12, __src=0xa3a12ffc, __dest=0x22a8dc8) at /usr/include/arm-linux-gnueabihf/bits/string3.h:51
#2  copy_gl_array_texcoord (src=<optimized out>, from=<optimized out>, width=3, stride=<optimized out>, to=to@entry=5126,
    to_width=to_width@entry=4, skip=45055, skip@entry=22600, count=count@entry=45399, filler=0xbeffa2b4,
    filler@entry=0xbeffa2ac) at /tmp/glshim-master/src/gl/array.c:91
#3  0xb6cc63d4 in copy_gl_pointer_tex (ptr=<optimized out>, width=width@entry=4, skip=skip@entry=22600,
    count=count@entry=45399, buff=0x20bba88) at /tmp/glshim-master/src/gl/array.c:269
#4  0xb6c9f24c in arrays_to_renderlist (list=0x223da38, list@entry=0x0, mode=mode@entry=4, skip=22600, count=45399)
    at /tmp/glshim-master/src/gl/gl.c:641
#5  0xb6ca1108 in glshim_glDrawElements (mode=4, count=972, type=<optimized out>, indices=<optimized out>)
    at /tmp/glshim-master/src/gl/gl.c:718
#6  0x0020cea4 in ?? ()
#7  0x00211358 in drawTerrain() ()
#8  0x00090af0 in draw3DScene() ()
#9  0x000953bc in displayWorld() ()
#10 0x0011cb6c in ?? ()
#11 0x0011de9c in gameLoop() ()
#12 0x0011f220 in mainLoop() ()
#13 0x002b3e58 in wzMain3() ()
#14 0x00120a00 in realmain(int, char**) ()
#15 0xb6597632 in __libc_start_main (main=0x5613c <main>, argc=1, argv=0xbeffeee4, init=<optimized out>,
    fini=0x2b5de5 <__libc_csu_fini>, rtld_fini=0xb6fea4c5 <_dl_fini>, stack_end=0xbeffeee4) at libc-start.c:287
#16 0x000566b0 in _start ()

This is definitely coming from the latest glshim, no mistakes this time :)
 
@ptitSeb The crashes are gone but unfortunately some of the textures too :)
 

Attachments

  • warzone.jpg
    warzone.jpg
    238.7 KB · Views: 476
Yay! I could swear I saw a small but noticeable performance boost.

I read something about texture compression in the changelog (parental guidance required? ;)) - what are the chances of having ARM native compression to keep memory usage down? It seems, if I turn texture compression on at app level, nothing bad happens (well done!) but there's no difference either.
 
@MarKov : yep, performance should be better because of the fix (I was processing to much datas before).

About compression, hardware doesn't support S3TC. So even glshim now handle it (both decoding from and encoding to), it will not bring any boost.
If you want more fps, try the many env. variable tweaks, like LIBGL_SHRINK or LIBGL_BATCH (look in the readme of the github for more details).
 
I take it compression is done in software at the moment; is it possible to translate S3TC to ARM format(whatsitname) in hardware?
 
MarKov said:
I take it compression is done in software at the moment; is it possible to translate S3TC to ARM format(whatsitname) in hardware?
Click to expand...
There is 2 big familly of texture compression on SGX hardware: ETC & PVR.
ETC can be use, supported on all GLES 1.1 hardware, and there can be some DXT1 -> ETC transcoder written... but ETC only works on RGB and doesn't handle alpha chennels. Most compressed textures are RGBA so it will be mostly useless.
PVR is very ressource intensive, only supported on SGX, and I don't think there is an opensource encoder for PVR. So not really an option.

And to explain further:
Right now, when a texture is loaded as Compressed (with DXTx compression), it's decoded but size of the texture is then reduce before going to memory, to still save space.
But if a regular texture is loaded with internal format set to some Compressed format, nothing is done to save memory...
 
I've compiled glshim 0.42 but there's something I'm unclear of in the setup procedure, the libgl_remote, does it go to the /usr/local/bin of the Pandora or the /usr/local/bin of the exagear ubuntu image?
 
I can't seem to get it working. I've tried with a fresh install of exagear with just mesa-utils (and dependencies) on top to have glxinfo and glxgears, but whenever I try to start glxinfo, I get:
"couldn't find RGB GLX visual or fbconfig".

EDIT: xeyes is working if that's any help
 
Last edited:
ETC1 can be used to 'do RGBA' but it requires gles2. I used this method for hurrican. I used a script to covert my RGBA images to 2 images one containing the RGB data and another only containing the alpha channel. I then encode the RGB to ETC1. The Alpha texture is left normal.
Then using multitexture and a specific shader the 2 textures can be loaded and blended together.
 
OK I got it. Since I installed mesa to get glxgears it was trying to use the mesa driver. I've made it use the glshim driver instead but got this:

~# LD_LIBRARY_PATH=/usr/local/lib LIBGL_REMOTE=1 LIBGL_REMOTE_NOSPAWN=1 glxgears -info
libGL: warning, gles is NULL
libGL: warning, egl is NULL
libGL: built on Mar 15 2016 10:06:02
connect: Connection refused
Aborted

Is there a problem with the gles/egl ?
 
You must log in or register to reply here.

Similar threads

Pickle
Caanoo / WIZ Howto For Opengl-es 1.1 Lite On The Wiz
2 3 4
Replies
62
Views
24K
trentg
T
Farox
Help on port GL-117 Combat flight sim
Replies
19
Views
4K
Farox
Farox
T
Pandora Opengl Es Drivers & Sdl For Pandora
Replies
10
Views
3K
Xmas
X
sebt3
Glut|Es And Cegui
Replies
5
Views
2K
sebt3
sebt3
R
Opengl-es 1.x
Replies
2
Views
1K
rixed
R
Back
Top