How to specify EGL and GLES2 shared object locations on build?

system · March 20, 2019, 12:40am


	Attention	Topic was automatically imported from the old Question2Answer platform.
	Asked By	Thier Richárd István

Dear Godot team!

I am currently trying to get both 2.1.5 and latest 3.1 work somehow. I try various machines now (not working anywhere yet - sometimes maybe for my fault) among which machines are also a Raspberry and an Orange pi. On Orange pi I can get 2.1.5 to work, but it is really-really slow. Also 3.1 writes into the console that I am using llvm-pipe as the ES2 renderer.

This means that Godot picks up a wrong location for the libraries I have. I had a similar problem once with “gl4es” but there the programmer who wrote it, made it possible to “tell” where the relevant EGL and GLES2 libraries are on my system.

The similar problem was here:

github.com/ptitSeb/gl4es

gl4es Seem to work, but for some reason runs as slow as a software rasterizer after installing RetroPie on orange pi

opened 04:52PM - 08 Jul 18 UTC

closed 09:50PM - 20 Jul 18 UTC

prenex

This is kind of a weird issue and I do not know what is the root cause and where… to fix this. Also contacted armbian and retrorangepi forums for information: https://forum.armbian.com/topic/7662-gl4es-maybe-hw-gl-not-working-after-retropie-setupsh/?tab=comments#comment-57721 http://orangepi.club/showthread.php?tid=2536&pid=5146#pid5146 In short: gl4es was already working on my orangepi pc-plus and I had good frame rate with extreme-tux-racer. Earlier my only problem was supertuxkart showing a blue-only screen and music but nothing from the game but I could live with that... Then I installed a retrorangepi-version of Retropie on my armbian and now somehow it seems that gl4es still logs out itself as before, it seems to work as before except it is now as slow as the software renderer. I tried and the frame-rate is so much the same that I guess it is really the very same.... Below is the log of starting extreme tux racer (etr) with doing an export LD_LIBRARY_PATH="$HOME/install/gl4es/lib" and export LIBGL_ES=2 ``` 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) ``` Sadly I do not remember if the libegl warnings were there even while it worked well. I do not think too much this is a problem with gl4es itself (as it worked before), but it would be nice to know what could go wrong and how it is possible to have gl4es running and seeing only the very same frame rate as in the software rendered case. I tried to test if my GLES is also running in software mode and I got 77 points on `glmark2-es2` for which armbian people quessed that I have non-software rendering. Also when run es2gears I get 80% CPU usage and when I run glxgears I get 220% which seem to indicate ES2 is ok, but for some reason even though I start the app with gl4es I somehow get software rendering. PS.: Now glshim does not seem to work at all and it is just segfaulting, but that is an other case. Maybe I see the gl4es startup logged but it just not doing any work because there is an issue? Or is it maybe possible that it finds some random software renderer that es2gears otherwise is not using?

Is there a way to tell the build of the Godot engine to pick up EGL and GLES from a different directory? I know where are the relevant files, but still the software renderer is picked up and found. How can I easily tell the build or the system where to look for these?

TL;DR: My system both has llvm-pipe and a hardware renderer for GLES2 but Godot by default only finds the software renderer which is slow for our purposes. How to tell the build or the engine where to look for EGL and GLES libraries?