Accessing Hardware Acceleration with OpenGL ES (Mali GPU)

[SubtleCo]

Hi friends,

Please forgive me, as I'm a little out of my depth here.

I'm trying to get an ebiten application to use GPU acceleration on a custom Debian device with OpenGLES 3.2. I stood up a prototype with a Raspberry Pi, and as long as I set the variable MESA_GL_VERSION_OVERRIDE=4.5, my app looks great. After standing up a few Raspberry Pi prototypes, we ordered a sample of our device from a manufacturer in China.

They sent over a board with a Rockchip ARM architecture with a Mali GPU. I've been able to use a few of their built in apps to confirm that GPU acceleration via GLES is ready to go. I just can't figure out a way to access it myself for our app. See for yourself - Raspberry Pi prototype on left, Rockchip supplier sample on right (Thank you for the sample!):

https://www.youtube.com/watch?v=RlaCBFjINdA

When running the manufacturer's test app, I get this output:

arm_release_ver of this libmali is 'g2p0-01eac0'. rk_so_ver is '4'
===
glmark2 2021.02
===
OpenGL Information:
GL_VENDOR: ARM
GL_RENDERER: Mali-GL2
GL_VERSIONL OpenGL ES 3.2 v1.g2p0-01eac0.xxx.....

Edit - adding CPU measurements

OH I should mention - running my test app on the raspberry pi shows 20% CPU usage in top while the same on the rockchip shows 370%, which is why I'm almost positive my issue is not being able to tap into the GPU.

end edit

So, aside from just letting frustration win and yelling "help!", I'd love to know the following:

1. I've seen mention on other discussions around here about OpenGL ES. Does Ebiten support that?
2. On the Gophers slack, someone suggested I run ldd on both my test animation app and the supplier's sample app. I also ran it on 'glxgears' which is (I guess) a builtin GL test app. Results below.
3. The same slack user mentioned using possibly CGO to help glue things together. Is that anything?

Anyway, I'm a bit up a creek. If anyone has any advice, or can help me figure out the right questions, I'd be so grateful.
Thanks!

Here are my ldd outputs:

1. GLX Gears (works very well)

ldd $(which glxgears)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
	linux-vdso.so.1 (0x0000007fbece4000)
	libGLEW.so.2.1 => /usr/lib/aarch64-linux-gnu/libGLEW.so.2.1 (0x0000007fbebc8000)
	libGLU.so.1 => /usr/lib/aarch64-linux-gnu/libGLU.so.1 (0x0000007fbeb54000)
	libGL.so.1 => /usr/lib/aarch64-linux-gnu/libGL.so.1 (0x0000007fbea51000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007fbe994000)
	libX11.so.6 => /usr/lib/aarch64-linux-gnu/libX11.so.6 (0x0000007fbe84a000)
	libXext.so.6 => /usr/lib/aarch64-linux-gnu/libXext.so.6 (0x0000007fbe82a000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fbe6b9000)
	/lib/ld-linux-aarch64.so.1 (0x0000007fbecb6000)
	libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007fbe52e000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007fbe50a000)
	libGLX.so.0 => /usr/lib/aarch64-linux-gnu/libGLX.so.0 (0x0000007fbe4c8000)
	libGLdispatch.so.0 => /usr/lib/aarch64-linux-gnu/libGLdispatch.so.0 (0x0000007fbe399000)
	libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007fbe385000)
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fbe356000)
	libxcb.so.1 => /usr/lib/aarch64-linux-gnu/libxcb.so.1 (0x0000007fbe31f000)
	libXau.so.6 => /usr/lib/aarch64-linux-gnu/libXau.so.6 (0x0000007fbe30c000)
	libXdmcp.so.6 => /usr/lib/aarch64-linux-gnu/libXdmcp.so.6 (0x0000007fbe2f6000)
	libbsd.so.0 => /usr/lib/aarch64-linux-gnu/libbsd.so.0 (0x0000007fbe2d0000)
	librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007fbe2b8000)

2. Manufacturer's test application (works very well)

ldd $(which glmark2-es2)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
	linux-vdso.so.1 (0x0000007f9dae2000)
	libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f9d9aa000)
	libjpeg.so.62 => /usr/lib/aarch64-linux-gnu/libjpeg.so.62 (0x0000007f9d95a000)
	libpng16.so.16 => /usr/lib/aarch64-linux-gnu/libpng16.so.16 (0x0000007f9d915000)
	libX11.so.6 => /usr/lib/aarch64-linux-gnu/libX11.so.6 (0x0000007f9d7cb000)
	libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007f9d640000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f9d583000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007f9d55f000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f9d3ee000)
	/lib/ld-linux-aarch64.so.1 (0x0000007f9dab4000)
	libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000007f9d3c4000)
	libxcb.so.1 => /usr/lib/aarch64-linux-gnu/libxcb.so.1 (0x0000007f9d38d000)
	libXau.so.6 => /usr/lib/aarch64-linux-gnu/libXau.so.6 (0x0000007f9d37a000)
	libXdmcp.so.6 => /usr/lib/aarch64-linux-gnu/libXdmcp.so.6 (0x0000007f9d364000)
	libbsd.so.0 => /usr/lib/aarch64-linux-gnu/libbsd.so.0 (0x0000007f9d33e000)
	librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007f9d326000)
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f9d2f7000)

3. My ebiten test app (runs poorly)

ldd animation
	linux-vdso.so.1 (0x0000007f9483f000)
	libX11.so.6 => /lib/aarch64-linux-gnu/libX11.so.6 (0x0000007f946ad000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f94602000)
	libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f945ee000)
	libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 (0x0000007f945c7000)
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f94596000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f94422000)
	libxcb.so.1 => /lib/aarch64-linux-gnu/libxcb.so.1 (0x0000007f943ea000)
	/lib/ld-linux-aarch64.so.1 (0x0000007f9480f000)
	libXau.so.6 => /lib/aarch64-linux-gnu/libXau.so.6 (0x0000007f943d6000)
	libXdmcp.so.6 => /lib/aarch64-linux-gnu/libXdmcp.so.6 (0x0000007f943c0000)
	libbsd.so.0 => /lib/aarch64-linux-gnu/libbsd.so.0 (0x0000007f9439b000)
	libmd.so.0 => /lib/aarch64-linux-gnu/libmd.so.0 (0x0000007f9437f000)

[hajimehoshi]

Ebitengine supports OpenGL ES on Linux, but this is not well tested. An OpenGL ES .so file is loaded dynamically so ldd doesn't show it. TBH I don't have a good insight about the slowness in your environments. I hope someone has better insights...

[SubtleCo]

Thanks for your response. Do you think I'm looking in the right place in thinking that the issue lies in using OpenGL ES on the rockchip and the desktop version on the raspberry pi?

I added this to my post after your reply - I measure 20% CPU usage on the raspi, and 370% on the Rockchip, which is why I'm thinking I'm not able to use the GPU.

[hajimehoshi]

I'm not familiar with how Raspberry Pi works, but Ebitengine's app works as a regular X desktop application. Is there any special things around desktops in Raspberry Pi compared to other Linux?

[SubtleCo]

Actually funny you should mention that - I had disabled the desktop environment and was using OpenBox on the raspi in an attempt to reduce all unnecessary processes. BUT I'm not sure that matters - both Raspian (basically Debian) and the custom Debian I'm fighting with now use X.

I'm starting to look at the procaddr_linbsd to see how ES is invoked. I might pull down and add some print statements to ensure ES is getting picked

[superloach]

silly idea, but perhaps run pprof or something to try and pin down what part is slowing down?

[SubtleCo]

I have - the result on the raspi and the rockchip look basically the same. I really do think the issue is that I'm just unable to tap the GPU. When I run my app and monitor with top, I can see 20% cpu usage on the raspi and 370% on the rockchip. I don't have any GPU monitoring tools available to me that I know of, but I'm almost positive we'd see that the GPU isn't doing any work here

[bubnenkoff]

@SubtleCo same problem

[SubtleCo]

Got it!
export EBITENGINE_OPENGL=es as mentioned here

Looks like It just needed to be set manually! Thanks all!

[hajimehoshi]

Interesting. Ebitengine tries OpenGL first, and then tries OpenGL ES as a fallback. So, OpenGL (unexpectedly) worked, but the driver implementation was very slow, right?

[SubtleCo]

exactly. It is very interesting that it thought openGL was working when it wasn't. And yes, the failed use of openGL caused the app to run entirely on the CPU and not on the GPU. Forcing that env variable lets us use the GPU as intended.

[hajimehoshi]

Thanks! I'm thinking to fix Ebitengine to prefer OpenGL ES to OpenGL in some environments, but I am not sure what is the best way so far.

[arl]

On Linux, the best way greatly depends on the target system unfortunately and at the end of the day, anything automatic won't be 100% reliable.

Setting an environment variable is fine.

Maybe look for the existence of some file called ~/.config/ebitengine.cfg or something, and read the driver selection from there? That file could be read/written during the game installation process

[hajimehoshi]

Ebitengine 2.8 will prefer ES by default. Stay tuned!