Segfault on some gl and sdl apps

[ghost]

For example RetroArch works with gl backend, but not with sdl. Gens/gs sdl backend doesn't work. ScummVM which uses sdl is working. I've tried also sdlarch and nanoarch. Both are crashing with segfault. Message that could be helpful [inf] Frontend supports RGB565 - will use that instead of XRGB1555. Also, strace output of the nanoarch https://drive.google.com/file/d/1U2be60bBX3DEpJraNjiDhlR4o-FunZ-1/view And I have only 96MB accessible to GPU, may that be a problem?

[ptitSeb]

Memory of the GPU is more than enough.

To understand what is going on, I need the command line you are using, and the output of the console. Also, a gdb backtrace would help a lot (but don't forget to compile gl4es with debug info). (I can give you direction on the backtrace and/or debug info if needed).

[ptitSeb]

Also, I assume the SDL (2.0?) that you are using is compile with OpenGL support and not just OpenGLES.

[ghost]

SDL is using OpenGL. However it seems that RetroArch don't use your lib in gl mode. MegaGlest, however does work with acceleration.

[ptitSeb]

You can probably try to force GL driver with SDL_VIDEO_GL_DRIVER=/PATH/TO/libGL.so

[ghost]

When I run an OpenGL app it has console output like: LIBGL: Initialising gl4es Is that a debug info, or do I need to change CMAKE_BUILD_TYPE?

[ptitSeb]

the "LIBGL:" are not debug info, but they can give usefull info already. For the "gdb debug info", yes, you need to switch build type to RelWithDebInfo or Debug. There is also debug info that can be activated inside each C source file (not all of them, only the major one), by uncommenting the //#define DEBUG in top of the file. But debug info is very chatty! so a backtrace to narrow where to search is preferable at first.

[ghost]

And SDL apps already use your lib by default. libretro seems to have its own lib search paths, so I think it's running without acceleration in gl mode.

[ptitSeb]

For libretro, I don't have first hand exeperience, but an other user had success runing it with gl4es, but with the GLES2 backend (so with LIBGL_ES=2)

[ghost]

https://pastebin.com/LFAG7fUy https://pastebin.com/Fh8ShiTC

[ghost]

Also my screen bit depth is 24, so some apps requiring 16 or 32 fail to start.

[ghost]

Well, I'm running gdb. What now? https://pastebin.com/PpZP71gY

[ghost]

Gdb backtrace from retroarch, not very informative. https://pastebin.com/4mC2ec0e

[ghost]

https://pastebin.com/JXH0z8xB GLES2 one.

[ptitSeb]

Ah yes, the backtrace is useless.

I see you are using the GLES 1.1 backend.

For retroarch, it's better (mandatory?) to use the GLES2 backend, I think retroarch needs shaders. Add LIBGL_ES=2 in front of your command line to temporarily create the env. variable.

EDIT ninja'd...

[ptitSeb]

I think you need to compile retroarch with debug info. Not sure how you get it, via some aptcommand or build. If you built it, add -g to the CFLAGS and CXXFLAGS and rebuild it. The backtrace will probably be better then.

[ptitSeb]

Also, does simple things like glxgears running correctly? With both Backend?

[ptitSeb]

For the 24bits stuff, you can probably hack a bit src/glx/glx.c to force 16bits context (use the "PANDORA" defines). I may create an option in the CMakeList for that one day (or an env. variable).

[ghost]

https://pastebin.com/uk3mAQk5 GLES2, GL2. Glxgears? Fine. Even megaglest, with my memory pinning injector.

[ghost]

int depthBits = 16;//glxfbconfig->depthBits; Will that force?

[ptitSeb]

Maybe. I don't remember well, it's been some time that I haven't touched this part.

[ghost]

Sorry for not responding. Nanoarch and sdlarch crashed not because of your lib, but because of incomplete RetroArch support. RetroArch built with debug options and with SDL backend gives a black window with a fps counter. With OpenGL backend a segmentation fault does happen. However I noticed that with GLES2 backend, and when running fullscreen what is important, it gives 60 fps. But in the windowed mode it's running at 10 fps, and probably the lack of the X acceleration is the cause. I think Exynos drivers won't work for the Allwinner H3 board. Still, I've got a workaround, so I'm closing that issue.