0
prenex

gl4es (maybe HW GL) not working after Retropie-Setup.sh

Recommended Posts

https://github.com/retr0rangepi/RetroPie-Setup

^^After manually running this setup program, gl4es and glshim does not seem to work anymore...

 

Before this installment everything worked for me and I used both glshim and gl4es to play games like tuxracer. Both gl4es and glshim are build from source and already installed. See error messages below.

 

gl4es:

LIBGL:loaded: libEGL.so
LIBGL: Using GLES 2.0 backend
MESA-LOADER: failed to retrieve device information
libEGL warning: DRI2: failed to open mali_drm (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
LIBGL: Hardware Limited NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Substract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer detected
LIBGL: Extension GL_OES_element_index_uint detected and used
LIBGL: Extension GL_OES_packed_depth_stencil detected and used
LIBGL: Extension GL_OES_depth24 detected and used
LIBGL: Extension GL_OES_rgb8_rgba8 detected and used
LIBGL: Extension GL_EXT_multi_draw_arrays detected
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_depth_texture detected and used
LIBGL: Extension GL_EXT_texture_rg detected and used
LIBGL: Extension GL_OES_texture_float detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Extension GL_EXT_frag_depth detected and used
LIBGL: Max vertex attrib: 16
LIBGL: Extension GL_OES_standard_derivatives detected and used
LIBGL: Max texture size: 8192
LIBGL: Max Varying Vector: 32
LIBGL: Texture Units: 8(8), Max lights: 8, Max planes: 6
LIBGL: Hardware vendor is VMware, Inc.
LIBGL: sRGB surface supported
LIBGL: Targeting OpenGL 2.0
LIBGL: Forcing NPOT support by disabling MIPMAP support for NPOT textures 
LIBGL: Current folder is:/home/p/install/gl4es
MESA-LOADER: failed to retrieve device information
libEGL warning: DRI2: failed to open mali_drm (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)

glshim:

$ glxgears
LIBGL: Initialising gl4es
LIBGL: v1.0.9 built on Jun 28 2018 20:31:51
LIBGL: Using GLES 1.1 backend
LIBGL:loaded: libGLESv1_CM.so
LIBGL:loaded: libEGL.so
LIBGL: Using GLES 1.1 backend
MESA-LOADER: failed to retrieve device information
libEGL warning: DRI2: failed to open mali_drm (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
Segmentation fault

As you can see, glshim does not even start anymore, but gl4es does not segfault however everything is so slow that I think software rasterizer works only.

 

The retropie-setup script run very long and installed a lot of stuff, but I did not expected it will destroy support for opengl. Also I do not know if gles is now hardware accelerated or not, but normal opengl clearly not anymore. es2_gears runs, but that would run full speed regardless of having or not having hw acceleration so I cannot compare if it works or not. I mostly only used "normal gl" through gl4es earlier.

 

Rationale: I have and OrangePi PC+ which was (and is) running great. It has a 64Gb SD and an 500Gb USB disk on which I store data for some web pages and my own gitea server for version controlling my stuff. Because I like these things to run all the time as a server, I did not wanted to "just use retrorangepi" but I wanted to have a system that both serves my lightweight web apps and runs as a machine acting as a media center for our not-so-smart lcd TV to watch movies from online sources with youtube_dl and play linux and retro games with cheap controllers while also serving my lightweight web stuff that basically has no traffic anyways.

 

Sadly I did not make backup from the SD contents before installing the retropie as I did not know that it can have this big changes...

 

I will try to provide all information you ask for. Does anyone had any issue like this? Maybe those who make the images for retrorangepi or some people who use pi all-around like I try?

 

Btw I use the legacy 3.x kernel as that seemed to have the best support for 3D, hw video and working xpad etc.etc.

 

Any help or ideas what I should look into?

Share this post


Link to post
Share on other sites

Thank you for the suggestion, however I would just prefer to get back the original MALI driver that came with the Legacy kernel system to work once again as before.

 

I don't know what retropie did, but I just want MALI GPU on legacy kernel to work as before and would be happy to have some help knowing where to look. In this way I don't think it is that much retropie-related or is it?

$ ls -lat /usr/lib/arm-linux-gnueabihf/dri
total 100412
drwxr-xr-x 77 root root   69632 Jul  8 10:02 ..
drwxr-xr-x  2 root root    4096 Jul  6 21:05 .
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 etnaviv_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 imx-drm_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 kgsl_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 kms_swrast_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 msm_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 nouveau_dri.so
-rw-r--r--  3 root root 3109528 Jun 14 17:52 nouveau_vieux_dri.so
-rw-r--r--  3 root root 3109528 Jun 14 17:52 r200_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 r300_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 r600_dri.so
-rw-r--r--  3 root root 3109528 Jun 14 17:52 radeon_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 radeonsi_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 swrast_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 vc4_dri.so
-rw-r--r-- 12 root root 7782376 Jun 14 17:52 virtio_gpu_dri.so
-rw-r--r--  1 root root   13888 Aug 31  2017 dummy_drv_video.so

Should I see a mali_something_dri.so here or at some other place originally with a clean armbian legacy kernel install for orangepi pc plus? This is one of the place according to the log message where gl4es tries to find the MALI driver.

 

I will try to recompile glshim and gl4es in a way that cmake configure runs again as maybe just the drivers place has changed. I would love to know where to look for the libraries to tell if they got removed or moved or whatever. At least to know what is their name so that I can do a "find" to search for them...

 

Share this post


Link to post
Share on other sites
12 minutes ago, prenex said:

Should I see a mali_something_dri.so here

I haven messed that much with Allwinner H3's mali, but I can tell you that in many other SoC's, there is no (socname)_dri.so because that is a OpenGL library, and Mali GPU's only support OpenGL-ES. Many programs throw that error when trying to look for the lib in an ARM-based board, and that doesn't necessarily mean that anything is badly configured. I'm not sure if there is some wrapper that provides a kind of "bridge" library, like "whatever_dri.so", to replace the lacking library in OpenGL-ES based GPU's.

 

12 minutes ago, prenex said:

In this way I don't think it is that much retropie-related or is it?

I think it is totally Retropie related :). As you said, Everything works well in Armbian, until you run the Retropie install script, which breaks it. So the solution here would be to debug the retropie install script, and see where it breaks the feature you need.

Share this post


Link to post
Share on other sites
17 minutes ago, JMCC said:

Moved to Peer-to-peer technical support, since Retropie is not part of Armbian.

 

moved with member rights? :P @Igor seems that someone seeks for a moderators job.. And well, when you're in the admin panel.. Probably @TonyMac32 some rights to move threads as well.. :lol:

 

47 minutes ago, prenex said:

Any help or ideas what I should look into?

I would open an issue on their github.

Share this post


Link to post
Share on other sites
Quote

I think it is totally Retropie related . As you said, Everything works well in Armbian, until you run the Retropie install script, which breaks it. So the solution here would be to debug the retropie install script, and see where it breaks the feature you need.

Besides fixing the source of the issue - which is surely not armbians fault and totally retropie / retrorangepi related - in the retrorangepi version of the retropie-setup install script, I would still love to recover from the problem and in that I guess not only retropie-related information are helpful, but generic one to tell where to look in these kind of cases - that is what I meant above :-).

 

So alongside the problem in the script now there is a second problem to try recovering from this without a complete reinstall and it would be great to find some help in it. :-)

 

Btw Armbian is awsome and I really like it so far. I haven't really seen bugs related to the core system myself.

 

Quote

I haven messed that much with Allwinner H3's mali, but I can tell you that in many other SoC's, there is no (socname)_dri.so because that is a OpenGL library, and Mali GPU's only support OpenGL-ES.

Thank you, I did not know that! So this can even mean that gl4es still works but for some random reason everything became much slower??? Do you know are there any paths I should look to know if hardware es2 driver files are in place? I know about glmark2-es2 and made a test, but I had no earlier data to compare if this is good or not:

$ glmark2-es2
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-400 MP
    GL_VERSION:    OpenGL ES 2.0
=======================================================
[build] use-vbo=false: FPS: 112 FrameTime: 8.929 ms
[build] use-vbo=true: FPS: 129 FrameTime: 7.752 ms
[texture] texture-filter=nearest: FPS: 130 FrameTime: 7.692 ms
[texture] texture-filter=linear: FPS: 122 FrameTime: 8.197 ms
[texture] texture-filter=mipmap: FPS: 115 FrameTime: 8.696 ms
[shading] shading=gouraud: FPS: 109 FrameTime: 9.174 ms
[shading] shading=blinn-phong-inf: FPS: 115 FrameTime: 8.696 ms
[shading] shading=phong: FPS: 87 FrameTime: 11.494 ms
[shading] shading=cel: FPS: 68 FrameTime: 14.706 ms
[bump] bump-render=high-poly: FPS: 73 FrameTime: 13.699 ms
[bump] bump-render=normals: FPS: 123 FrameTime: 8.130 ms
[bump] bump-render=height: FPS: 107 FrameTime: 9.346 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 26 FrameTime: 38.462 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 16 FrameTime: 62.500 ms
[pulsar] light=false:quads=5:texture=false: FPS: 128 FrameTime: 7.812 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 13 FrameTime: 76.923 ms
[desktop] effect=shadow:windows=4: FPS: 43 FrameTime: 23.256 ms
Error: Requested MapBuffer VBO update method but GL_OES_mapbuffer is not supported!
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 26 FrameTime: 38.462 ms
Error: Requested MapBuffer VBO update method but GL_OES_mapbuffer is not supported!
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported
[ideas] speed=duration: FPS: 95 FrameTime: 10.526 ms
[jellyfish] <default>: FPS: 34 FrameTime: 29.412 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 21 FrameTime: 47.619 ms
[refract] <default>: FPS: 16 FrameTime: 62.500 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 128 FrameTime: 7.812 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 51 FrameTime: 19.608 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 123 FrameTime: 8.130 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 71 FrameTime: 14.085 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 37 FrameTime: 27.027 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 72 FrameTime: 13.889 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 72 FrameTime: 13.889 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 69 FrameTime: 14.493 ms
=======================================================
                                  glmark2 Score: 77 
=======================================================

I don't know what the score should be with not working gles2 and a working one in a fresh install. I hope this shows it being hardware accelerated in case of GLES2, but I am quite unsure as the shown things are quite simple in glmark2 - and unlike a game scene so I cannot compare. Can anyone say if I run with software GLES2 only now according to this result?

Quote

I'm not sure if there is some wrapper that provides a kind of "bridge" library, like "whatever_dri.so", to replace the lacking library in OpenGL-ES based GPU's.

I only use glshim and/or gl4es. The latter worked well for tuxracer for me, but it is complete lag now. glshim or gl4es does not seem to replace anything in the said directories, just delegate the calls to gles calls. That is why I try to find out if GLES2 is also slow now for some reason or not. Maybe the script changed the ES to use software rendering, but I am not sure, because I cannot compare the above test to any earlier results on my machine.

Quote

I would open an issue on their github. 

I will surely do that too because they need to know about this issue from someone even if I can recover my case I guess.

 

Share this post


Link to post
Share on other sites

Also it seems that "antimicro" can only use my gamepads now if I start it with "sudo antimicro". Seems like the setup script is messing with a lot of things... other people have other issues like here:

 

https://askubuntu.com/questions/930802/antimicro-not-detecting-controller-input-after-install-retropi

 

At least in my case it works with sudo. Also maybe it is a permission thing for the other too who knows...

 

Sadly at the github link there is no "issues" button. I do not know if it is because it is a fork of an other repo or they configured it not to appear. By default there used to be (even on my own github things there is "issues" menu). :-(

Share this post


Link to post
Share on other sites
1 hour ago, prenex said:

glmark2-es2 ======================================================= glmark2 2014.03+git20150611.fa71af2d ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-400 MP GL_VERSION: OpenGL ES 2.0

Seems like GLES is still working, and it was only the glshim/gl4es wrapper that broke. The laggy experience you are having now is mot probably because it is using MESA software emulation for OpenGL, instead of glshim/gl4es.

 

I suggest that, whatever the method you used to originally install glshim/gl4es (compile? deb packages?), you try to revert it (sudo make uninstall / apt-get purge -packages-), and then reinstall it.

Share this post


Link to post
Share on other sites
20 minutes ago, JMCC said:

Seems like GLES is still working, and it was only the glshim/gl4es wrapper that broke. The laggy experience you are having now is mot probably because it is using MESA software emulation for OpenGL, instead of glshim/gl4es.

 

I suggest that, whatever the method you used to originally install glshim/gl4es (compile? deb packages?), you try to revert it (sudo make uninstall / apt-get purge -packages-), and then reinstall it.

 

Thank you for your input that indeed ES still works. I tried to figure it out whether it is software or hw by looking at CPU usage which was 80% with GLES and 220% with opengl even with glxgears. At least knowing that GLES still works is a good thing as maybe the system can be saved without a reinstall...

 

In the meantime I've tried recompiling gl4es. I have even deleted the stuff that cmake creates beause I thought it will be that the cmake cached something but no change after a clean, make, make install...

 

Also there is this other weird issue with the gamepad now by complaining that /dev/input/js0 is not readable without sudo. I see it is in the "input" group and /dev/mali is in "video". I will try to look after permissions and groups. Maybe it is a good idea to add my user to these groups or something...

 

I have tried to ask on some other forum for details about what the script might have done here (I have found this forum in the contact part of the retrorangepi website):

 

http://orangepi.club/showthread.php?tid=2536

 

^^Also from that original conversation it seems like installing the retrorangepi version of retropie on an armbian AFTERWARDS normal install is not really supported or maybe not even really tried by them. But they should have made this clear I guess. I did not do all the things they mention on that topic, just the Retropie-Setup.sh so of course I did not change drivers myself...

 

I don't get what they mean by: "Basically, you need to install the framebuffer Mali drivers (matching the kernel module - version r3p0) in another path (/usr/local/lib) to avoid conflicts with existing X11 Mali lib (included in Armbian image)"

 

I did not do anything like this but maybe the script did try and overwrote the one included in the armbian image?

 

edit:

 

$ groups
p dialout sudo audio video plugdev systemd-journal netdev ssh bluetooth

 

^^so I seem to have the "video" group, but not the "input" group. I guess that is why the gamepad did not work, but then this is not why the gl is failing...

Share this post


Link to post
Share on other sites

It seems mesa-egl got "reinstalled" right nearby the still present "mali-egl".

I could instruct gl4es to use the latter - See here:
https://github.com/ptitSeb/gl4es/issues/65

 

(useful info up there is also that lsof and ldd are useful tools to debug what drivers and devices are in use)


I guess it is also safe (or maybe advised?) to remove mesa-egl by mv-ing it out somewhere else, but I did not do it yet. I guess it can only add performance because then things are not finding the bad one accidentally.

Aside this, the retrorangepi install script mostly seem to have did its job, but I will do further testing...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
0