glshim

[Cartridge]

Thanks for your kindness, all of you.


I've followed those instructions before without success, it seems to just null out. At least last month. You may have made changes since then. But your small tut dates frorm october (When you edited) so I doubt I'm doing something wrong. Maybe I'm just a bit slow or need more details on those steps. I see no output whatsoever when I run libGL in Exagear. No error even, just plain what it was before using the shim. Is the remote library linked to a certain Exagear version? 1.0? 1.1? 1.2? From your small tut, you seemed like you were using 1.0 because of the distro that it is written (12.04lts). Maybe exagear changed some stuff around and nulls out the shim. If you happen to own an exagear key, I will gladly share you the 1.2 update through PM.

 

[lunixbochs]

What do you mean "[COLOR= rgb(39, 42, 52)]when I run libGL in Exagear'? You need to run a program like glxgears that uses it. Running the library itself does nothing.[/COLOR]


Also, there's no "remote library" anymore. You build an x86 glshim from the unstable branch and make sure it's the first thing in your library path for libGL.so.1. Test with glxgears. If it doesn't print messages about libGL initialization, you're not using glshim (regardless of the remote part). Use ldd to confirm you're using the library you built.


Once that's done, build a native libgl_remote (which is an executable) from the same git commit and either use Exagear's opath to execute it or export the environment variable LIBGL_REMOTE_NOSPAWN=1 and manually run libgl_remote from another terminal using the shm_name the first application prints.

 

[Cartridge]

I understood already that the library is not run by itself. That's the whole point of glshim, translation. I understand that. But I now understand that the opath is to execute it upon starting exagear. What does this following command actually do? "sudo touch /opt/exagear/images/ubuntu-1204lts/usr/local/bin/libgl_remote" If the opath can execute it or execute the remote executable manually. And one question has been lingering my mind ever since you started the remote source files. When you run the GL shim and then run the remote executable, after running it at least once, I need to hard close it or kill the process each time I run a new program? You stated in your small tut that I would want to do this over SSH so I can kill one of the sides. That phrase I have a bit of trouble understanding and me being french does not help even though I'm bilingual.


--Edit--


I also forgot to note when doing it manually the glshim_shm always returns as 0 and when I try that 0 command it states that the memory is not mapped.

 

[lunixbochs]

The touch command was a workaround. I had trouble with exagear's overlay filesystem if a dummy file didn't exist in the guest.


I'm working on a version that properly detects failure of the other side and aborts the process. Until then, you might need to kill libgl_remote or the game yourself if something goes wrong (as libgl_remote likes to hang and eat cpu if the host process gets hard killed). That's one of the reasons you might need SSH. The other is that if you're running libgl_remote manually, you'll need access to a terminal *after* the game opens a fullscreen window to launch it.


Can you provide full terminal logs of a failed launch (for both commands)? I'm considering doing a screencast showing how to use remote rendering in the current state.

 

[Cartridge]

Is this what I should be seeing with GLXGears?

$ LIBGL_REMOTE=1 LIBGL_FB=0 glxgears
libGL error: MESA-LOADER: malformed or no PCI ID
libGL error: MESA-LOADER: invalid drm fd
libGL error: failed to get driver name for fd 4
libGL error: unable to load driver: armsoc_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: armsoc
2 frames in 6.6 seconds =  0.304 FPS
557 frames in 5.0 seconds = 111.324 FPS
551 frames in 5.0 seconds = 110.149 FPS
417 frames in 5.0 seconds = 82.996 FPS
141 frames in 5.0 seconds = 28.068 FPS <- fullscreen Odroid U2

I'm using Zandronum (The Linux port (Not through wine)) as the test target since it only requires OGL 1.3 and up It also supports 1.2 but with non power to texture. It's also giving me the same LIBGL error as stated above but I've been told the ARMSOC_DRI panics when it's actually working well.


How exactly can I detect if LIBGL_Remote is actually executing since the game seems not any faster or slower. I've never used GDB before to debug programs since most linux progams already -Wall most of everything so we see what is wrong. While zandronum likes to keep quiet about these things

 

[Cartridge]

I think it's actually working now, before without the remote, Zandronum refused to accept to go in windowed mode and crashed. Now I can do both full and windowed mode in a case where I have to set it before and not while I'm playing or else it gets stuck in a loop that goes "Fullscreen widescreen fullscreen" and so on going back and forth by itself. " 2nd most weird thing. Zandronum + wine was already a bit faster than a native linux port, that is without the remote shim. Now I haven't tried the remote shim with wine yet but it seems promising.

 

[lunixbochs]

You have Mesa libGL in your library path that is winning over my driver. It's likely software rendered. Run a glxinfo for more proof (if it's glshim, it will say "glshim 4.3" or something as the renderer).


Put LD_LIBRARY_PATH=/path/to/glshim/lib in your environment. Also remember LIBGL_FB=0 is the default, and LIBGL_FB=1 should happen automatically if the first fails (so you shouldn't need to specify either one with upstream glshim).


glshim startup looks like this. If you don't see any messages like this, you aren't using glshim (or your game is forwarding stdio somewhere else and you probably won't see any output at all, which is the case with Uplink)

libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
libGL: built on Dec 11 2015 12:34:56

 

[Cartridge]

Here is what GLXInfo gives me, you were right. It's not working when not having ld library path in environment.

$ LD_LIBRARY_PATH=/usr/local/lib/ LIBGL_REMOTE=1 glxinfo
name of display: :0.0
libGL: warning, gles is NULL
libGL:loaded: libEGL.so.1
libGL: built on Dec  9 2015 16:00:43
libGL: remote pid 12046
Segmentation fault

 

[lunixbochs]

Which glshim commit are you on? I actually have no idea offhand if glxinfo works with glshim remote. Have you tried glxgears?

 

[Cartridge]

I'm on the latest unstable branch built today. Here are all the steps I took today.


1st of all. I removed and purged exagear. I then reinstalled it for a fresh install.


2nd Install all required progams to compile.


3rd Compiled the x86ver on the exagear envirronment and put the libGL files in the usr/local/lib/


4th I then compiled the remote shim with the host computer as explained in page 17 of this thread and put the executable in /usr/local/bin/


5th, I then touched it since you said it makes a dummy file to make the remote shim work.


6th, I got zandronum both linux and windows ports. (Later tonight I found out zandronum calls GDB whenever it crashes, so I may have another log for you)


7th tried it on. I then tried glxinfo and now I will test glxgears as I speak.

 

[Cartridge]

Here's what it says with GLXgears and running the remote shim remotely


On exagear's side :

LD_LIBRARY_PATH=/usr/local/lib/ LIBGL_REMOTE=1 LIBGL_REMOTE_NOSPAWN=1 glxgears 
libGL: warning, gles is NULL
libGL:loaded: libEGL.so.1
libGL: built on Dec  9 2015 16:00:43
libGL: shm_name='/glshim.0'
libGL: remote pid 1
Segmentation fault

and on host's side :

libgl_remote /glshim.0
libGL: built on Dec  9 2015 16:12:27
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
ERROR: EGL Error detected: EGL_BAD_NATIVE_WINDOW (0x300B)
ERROR: EGL Error detected: EGL_BAD_MATCH (0x3009)

The two errors I mentioned earlier about null-ing out we have proof here that it nulls out and the other being that the remote executable giving me a memory not mapped error, now i can't reproduce it. I have the zipped up file of the source code I used when I got those errors if you ever need it.


Here's the Zandronum's log GDB. If you ask me, that's not really debugging much for a log that small. LOL!

*** Fatal Error ***
Address not mapped to object (signal 11)
Address: 0x12aa4000

System: Linux gamestation-turbo 3.8.13.30 #10 SMP PREEMPT Sun Apr 5 20:21:10 CEST 2015 i686 i686 i686 GNU/Linux

Zandronum version 2.1.2 (96d0d01502b9)
Compiler version: 4.4.3

Command line: /usr/games/zandronum/zandronum -file doomz-r14test15.pk3

Wad 0: zandronum.pk3
Wad 1: doom2.wad
Wad 2: doomz-r14test15.pk3

Current map: DOOMZ1

viewx = -29360128
viewy = -4194304
viewz = 3342336
viewangle = b6200000

Executing: gdb --quiet --batch --command=gdb-respfile-T4wF3f

--edit--


the LIBGL_FB=1 still does nothing for me.

 

[lunixbochs]

Does native ARM glxgears work against glshim on this machine? (without remote involved)


EGL_BAD_NATIVE_WINDOW means glshim tried to initialize GLES against your window and your hardware driver threw an error. (LIBGL_FB=1 on remote may fix this on some platforms)

 

[Cartridge]

Yes native ARM GLXGears works with GLShim

LD_LIBRARY_PATH=/usr/local/lib/ glxgears
LIBGL: Initialising glshim
libGL: unusual desktop color depth 32
libGL: built on Nov  5 2015 14:42:36
LIBGL: Current folder is:/home/odroid
libGL egl backend: libEGL.so
libGL backend: libGLESv1_CM.so
3016 frames in 5.0 seconds = 603.166 FPS
4649 frames in 5.0 seconds = 929.742 FPS

--EDIT--


For me LIBGL_FB does not change according to errors, I have to tell it to do it or else no. When using it both with glxgears and remote, it tells me frarmebuffer output is now enabled when I tell it to. It still does not solve the fact that it does not work.

 

[lunixbochs]

Hold on, "LIBGL: Initialising glshim" is a message from PtitSeb's glshim. Are you sure mine works on your device?

 

[Cartridge]

Wait, FACEPALM my face hard. I forgot but I swear I put the libgl libraries I built in usr/local/lib... Again wait... What does my Host glshim have to do with remote shim? The libgl libraries I built I put them in and i quote "/opt/exagear/images/debian-8/usr/local/lib/" and I put the LibGL remote executable I put it on my host folders in "/usr/local/bin/" I'll rerun glxgears on my host with your sources and see if it works. That glxgears just above us, the last one, was generated by the ARM host with pitseb's fork. Since you say that message is from pitseb's fork. I know you are right because the date on those libraries arre like Month=07 and not Month=12. I'll backup my libraries and rerun native glxgeasr with your sources.

 

[Cartridge]

Here's the new log of Glxgears built with the latest glshim of your sources lunix.


It seems to outstand pitseb's fork by about 50 frames

LD_LIBRARY_PATH=/home/odroid/Downloads/glshim-unstable/lib/ glxgears
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
libGL: built on Dec  9 2015 18:35:52
2055 frames in 5.0 seconds = 410.992 FPS
4817 frames in 5.0 seconds = 963.397 FPS

 

[lunixbochs]

LD_LIBRARY_PATH=/home/odroid/Downloads/glshim-unstable/lib/ glxgears
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
libGL: built on Dec  9 2015 18:35:52
2055 frames in 5.0 seconds = 410.992 FPS
4817 frames in 5.0 seconds = 963.397 FPS

K, now throw in LIBGL_REMOTE=1

 

[Cartridge]

It panics and closes after seconds of use. See the following :

LD_LIBRARY_PATH=/home/odroid/Downloads/glshim-unstable/lib/ LIBGL_REMOTE=1 glxgears
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
libGL: built on Dec  9 2015 18:35:52
libGL: remote pid 29902
libGL: built on Dec  9 2015 16:12:27
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
3053 frames in 5.0 seconds = 610.506 FPS
4798 frames in 5.0 seconds = 959.489 FPS
4500 frames in 5.0 seconds = 899.832 FPS
panic: ring data size must be 0 < (-999754362) < 4194304
Aborted

I also thank you very much for your time. It's greatly appreciated.

 

[lunixbochs]

If it's working on the host, it should also work on Exagear. Can you try NOSPAWN with host->host remote as well? (also, you shouldn't need NOSPAWN if opath is working properly).

 

[Cartridge]

Here's what happens. I got a screenie of it. The picture speaks for itself.

If you can't make out the writing on this picture, click on it and click view raw image. (1080P yeah! those writings man are so small!)


It segfaults on both sides.