glshim


So NOSPAWN segfaults on ARM as well? Can you run each process with gdb? Just do `ENV=whatever gdb --args glxgears`, then run "start", then "c" at every prompt until it segfaults, at which point run "bt" for a stacktrace.


There's also LIBGL_STACKTRACE=1 but I have no idea how that will interact with remote.
 
Last edited by a moderator:
While I'm waiting, here's what NOSPAWN gave me on host side :

Code: 
odroid@gamestation-turbo:~$ libgl_remote /glshim.0
libGL: built on Dec  9 2015 16:12:27
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  154 (DRI2)
  Minor opcode of failed request:  11 (DRI2WaitSBC			)
  Resource id in failed request:  0x3a00002
  Serial number of failed request:  35294
  Current serial number in output stream:  35294

I don't know if it's of any use to you but here it is anyway. Checkback on this very post, I'll edit it.


--Edit--


Here's what you asked for. This time, host side didin't crash. Or at least yet. I'll let it run a bit to see how it reacts. BT gives no stack.

Code: 
(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Temporary breakpoint 1 (main) pending.
Starting program: /usr/bin/glxgears 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
libGL: built on Dec  9 2015 18:35:52
libGL: shm_name='/glshim.0'
libGL: remote pid 1
2431 frames in 5.0 seconds = 486.177 FPS
3743 frames in 5.0 seconds = 748.431 FPS
1941 frames in 5.0 seconds = 386.893 FPS
3302 frames in 5.0 seconds = 660.308 FPS
4367 frames in 5.0 seconds = 873.276 FPS
4878 frames in 5.0 seconds = 975.565 FPS
panic: ring data size must be 0 < (0) < 4194304

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
44	../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
 
Last edited by a moderator:
glshim issue #145 might help with this. I'm curious if it's a bug on wrap. Maybe you could put a printf("read wrap\n"); in src/util/ring.c in the block at line 70 with the comment "our read wrapped around", and a printf("write wrap\n"); around line 108 where ring->dma_wrap is set, then see if the print is correlated with the error. I did notice a discrepancy when doing quick review of that code.


You can also try to do `test/run remote` from the glshim source directory to see if the remote rendering unit tests pass (might need to `pip install -r test/requirements.txt` first).
 
Last edited by a moderator:
printf("write wrap\n"); goes under "if" or "else" and if I should put it inbetween something. Here's that line of code to help remind you.

Code: 
   }
    // wait for free space
    ring_wait_write(ring, size);
    size_t remain = ring->size - *ring->write;
    // pick destination and wrap if necessary
    void *dst;
    if (remain > size) {
        dst = ring->buf + *ring->write;
        ring->dma_write = *ring->write + size;
    } else {
        dst = ring->buf;
        ring->dma_wrap = *ring->write;
        ring->dma_write = size;
    }
    *(uint32_t *)dst = size;
 
Last edited by a moderator:
GL libraries built successfully with those 2 lines added. Now to replace those files with the original ones we compiled.


--edit--


wait, was i supposed to put that on armhf build or x86 build? I put that on the X86 build.


--Edit--


Now both GL libraries are built with the lines added and will add to remote aswell. Why not update my branch myself :p
 
Last edited by a moderator:
Now host gets killed where libgl_remote is run and where glxgears is running it says write wrap but continues to work with funny colors and the missing gears as seen above. This is still arm to arm as we were doing. Exagear is not involved.


2vj3goy.png
 
I got the shim working and it's like nothing I've seen before! It became so fast, working very well and exceeded my expectations. Some skyboxes were missing (sky texture) and some other sprites were changing while gameplay, became blockier. I take it that's the write wrap. Even though it's wrapping, it's not affecting the speed. 


The downside. I got it to work only 3 times. Now it refuses to work for somewhat reason that I know nothing of.


While it was working, it gave me lots of informaton like double buffer and stereo "mode" I think? lots of gl stuff.
 
Last edited by a moderator:
I got the pattern down, I have to persist running the program until the remote accepts the connection. After a while of gameplay, say between 10 seconds and one minute. It panics and gives a ring size thing eror.
 
The remote shim is amazing work. It works very fast on my end. Thank you all for your help. This is a great achievement. We're already asking our ARM computer the moon to run 32bit programs, asking the moon even more with the shim. Despite the ARM computer has to translate everything, it works amazingly well. I think, I'm not 100% sure but If the panic ring size error was addressed, it would be much more stable. At least that's what I always get errorr about making the program crash. Nonetheless, great work and take your time coding the shim. We don't want it to be rushed and unstable now don't we :p
 
I'm trying to run ShovelKnight using exagear and glshim on a Ghz Pandora. I got to the point where the program tries to display something for a split second and then crashes. You can see the output from it here:


http://sprunge.us/DgHh


The "keyboard layout unknown" issue I know how to fix (it requires patching SDL library with Pandora's layout), I just haven't got around doing this for 32bit exagear environment. But no idea bout the GL/EGL related errors.
 
This is likely the relevant errors:


Code: 
Unable to initialize EGL display.
ERROR: EGL Error detected: EGL_NOT_INITIALIZED (0x3001)
ERROR: EGL Error detected: EGL_NOT_INITIALIZED (0x3001)
Unable to initialize EGL display.
ERROR: EGL Error detected: EGL_NOT_INITIALIZED (0x3001)
ERROR: EGL Error detected: EGL_NOT_INITIALIZED (0x3001)


Does glxgears work inside Exagear? Does it work outside Exagear?
 
Last edited by a moderator:
lunixbochs said:
This is likely the relevant errors:


Code: 
Unable to initialize EGL display.
ERROR: EGL Error detected: EGL_NOT_INITIALIZED (0x3001)
ERROR: EGL Error detected: EGL_NOT_INITIALIZED (0x3001)
Unable to initialize EGL display.
ERROR: EGL Error detected: EGL_NOT_INITIALIZED (0x3001)
ERROR: EGL Error detected: EGL_NOT_INITIALIZED (0x3001)


Does glxgears work inside Exagear? Does it work outside Exagear?
Click to expand...

Similar issue with glxgears inside Exagear:


http://sprunge.us/DfSR


I'm currently running on SuperSaxxon OS, so I'm not sure how to get glxgears running on it. -_-
 
Last edited by a moderator:
LIBGL_FB=1 is in theory not necessary anymore btw. You built a libgl_remote binary for ARM and a libGL.so.1 binary for x86 from the same source revision (latest unstable branch), then set up opath so libgl_remote would be executed, correct?
 
lunixbochs said:
LIBGL_FB=1 is in theory not necessary anymore btw. You built a libgl_remote binary for ARM and a libGL.so.1 binary for x86 from the same source revision (latest unstable branch), then set up opath so libgl_remote would be executed, correct?
Click to expand...

Yes, I built them both on Pandora itself. The x86 libGL.so.1 I built from Exagear (after installing build-essentials and cmake) and the ARM libgl_remote I built using codeblocks.pnd environment.


I cloned unstable branch from github repo:


http://sprunge.us/DbhJ


For me running without LIBGL_FB results in a "No valid X11 visual" and then a crash:


http://sprunge.us/bYOf
 
Last edited by a moderator:
Are you able to launch any X11 apps from the same commandline inside and outside Exagear?
 
lunixbochs said:
Are you able to launch any X11 apps from the same commandline inside and outside Exagear?
Click to expand...

I tested xeyes from Exagear and it works. And from outside Exagear running PNDs from command line or normal Xfce apps also works.


I tried writing a small EGL program:


http://sprunge.us/aIBC


But I get this output when I compile/run it:


http://sprunge.us/gEHf


Then again maybe I did something wrong? (I was following the GLES tutorial on Pandora Wiki).
 
Last edited by a moderator:
@petevine


So the last days i'm very busy.


So now back in town and the X-Mas ist standing for the doors...


But the next days i have some tiome to  test again glshim with the IR-CAM.


So i have checked out my sources use freeglut and freeglut is using mesa and so i can not use another hardware accelerator like fbturbo which works good for chromium on the rpi2.
 
Last edited by a moderator:
Yoyobuae said:
I tested xeyes from Exagear and it works. And from outside Exagear running PNDs from command line or normal Xfce apps also works.


I tried writing a small EGL program:


http://sprunge.us/aIBC


But I get this output when I compile/run it:


http://sprunge.us/gEHf


Then again maybe I did something wrong? (I was following the GLES tutorial on Pandora Wiki).
Click to expand...

You have to call eglInitialize before every other eglXXXX.


So :


1. Open X11 Display,


2. Initialize egl


3. open egl Display


4. Choose and create GLES context


5. Create GLES Window


Or, be lazy and use eglport, so most of the egl/gles creation stuff is a simple matter of EGL_Init() and EGL_Open(...)
 
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