GL4ES on the Orange PI 3 lts

[DotJARgon]

I have compiled gl4es for the orange pi 3 lts running debian. I ran glxgears before and after compiling gl4es using the guide in compile.md, and the framerate remains exactly the same, 200 on average. The problem is that when I try to run other applications, the cpu hits maximum load, and the gpu seems to be doing almost nothing. It seems like when I try to run applications, it is just using software rendering. I may have made a mistake somewhere in compiling it, or maybe I did not set up the library path correctly? (I am still new to setting up environment variables and libraries on linux). Is there any way to verify whether this is working correctly?

[ptitSeb]

You have to use LD_LIBRARY_PATH env. var. to point to the lib where you build gl4es. If you build from your home, it should be in ~/gl4es/lib You can define it temporarily, for example to launch glxgears: LD_LIBRARY_PATH=~/gl4es/lib:$LD_LIBRARY_PATH glxgears You will see many lines starting with LIBGL: xxxxx during initializationof gl4es. You can also define it for many command, using export LD_LIBRARY_PATH=~/gl4es/lib:$LD_LIBRARY_PATH (or add this line in you ~/.bashrc so you don't have to type it.

[DotJARgon]

Thank you! I was definitely setting up the library path incorrectly! I tried to start glxgears the way you showed and got the following:

GLXGEAR_FAIL.txt

[DotJARgon]

I recompiled with x11 after looking at some other issues with missing symbols, but now it actually seems to run even slower funny enough. I tried openmorrow, and it seemed to run almost the same, albeit more frame stutters, and an error message that repeated over and over again:

Warning: detected OpenGL error 'invalid enumerant' at after RenderBin::draw(..)

and the mouse cursor suddenly had black around it.

OPENMORROW_FAIL.txt

And then upon closing openmorrow from within the game, it simply crashed

[DotJARgon]

Additionally after further testing, I tried to get half life running through wine, however it seems to be stuck on the llvm pipe rather than the gl4es library, even though I put the environment library output as you had stated. I am not sure if this is perhaps just a wine issue though

[ptitSeb]

gl4es is using LLVMpipe GLES driver (you can see Vendor is "VMware, Inc." instead of "ARM" or something like that). So basicaly, useless. GL4ES need to be used with the binay blob gles driver. You don't seem to have them installed on your OS. I cnnot help you here, I don't know the OrangePi3 or how to get the binary blob installed / what kind of OS to use for that.

[DotJARgon]

I managed to find an os with drivers installed on it, a branch of armbian Jammy, I will test tonight the functionality of box86, and box64 and attempt gl4es on the orange pi with drivers. I suspect it will work fairly well! One question I have is on how to get wine to use the opengl drivers, when I had tried on the llvmpipe driver os, when I gave the library path, the LIBGL message did not appear in the console

[DotJARgon]

@ptitSeb Is there any way for gl4es to even replace the hardware acceleration for something like the cinnamon desktop gui? One problem I am having with this os, is that it was compiled with hardware acceleration with opengl, not opengl es like what is available, and makes it damn near impossible to see what I am doing. Here are some examples of what this looks like:

I managed to get gl4es in the .bashrc file however and it is working perfectly

[ptitSeb]

never tested gl4es with cinnamon (or any other GUI). I test gl4es with games mainly, and a handfull of software. So it might be triggering some bugs somewhere.

[DotJARgon]

@ptitSeb This ticket can be closed actually! I determined it was cinnamon having issues with interacting with panfrost! The panfrost drivers for Armbian Jammy XCFE for the orange pi 3 lts is stable (unlike cinnamon) and does not require gl4es, since it comes packaged with opengl, and opengl es support (and theoretically directx support somehow)