Trouble running OpenGL ES + Wayland on latest Archlinux ARM

[thomas001le]

I run the latest odroid uboot and kernel (from the wiki, compiled from git) together with the latest archlinux arm userspace on an OGA 1.0. I have trouble getting opengl es to work.

At first, Wayland would only run using the software based mesa implementation. I then managed to start weston using hardware accelleration using https://github.com/rockchip-linux/libmali. This package basically installed some custom GL libraries into /usr/local/lib:

Code: Select all

$ ls -lh /usr/local/lib/
total 38M
lrwxrwxrwx 1 root root   11 Mar 28 13:58 libEGL.so -> libEGL.so.1
-rwxr-xr-x 1 root root 8.1K Mar 28 13:58 libEGL.so.1
lrwxrwxrwx 1 root root   17 Mar 28 13:58 libGLESv1_CM.so -> libGLESv1_CM.so.1
-rwxr-xr-x 1 root root 8.1K Mar 28 13:58 libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   14 Mar 28 13:58 libGLESv2.so -> libGLESv2.so.2
-rwxr-xr-x 1 root root 8.1K Mar 28 13:58 libGLESv2.so.2
lrwxrwxrwx 1 root root   12 Mar 28 13:58 libMali.so -> libMali.so.1
-rwxr-xr-x 1 root root 8.1K Mar 28 13:58 libMali.so.1
lrwxrwxrwx 1 root root   18 Mar 28 13:58 libMaliOpenCL.so -> libMaliOpenCL.so.1
-rwxr-xr-x 1 root root 8.1K Mar 28 13:58 libMaliOpenCL.so.1
lrwxrwxrwx 1 root root   11 Mar 28 13:58 libgbm.so -> libgbm.so.1
-rwxr-xr-x 1 root root  19K Mar 28 13:58 libgbm.so.1
lrwxrwxrwx 1 root root   10 Mar 28 13:58 libmali-bifrost-g31-rxp0-gbm.so -> libmali.so
lrwxrwxrwx 1 root root   12 Mar 28 13:58 libmali.so -> libmali.so.1
lrwxrwxrwx 1 root root   16 Mar 28 13:58 libmali.so.1 -> libmali.so.1.9.0
-rwxr-xr-x 1 root root  38M Mar 28 13:58 libmali.so.1.9.0

With those files in place the weston-launch output looks promising:

Code: Select all

[13:59:04.705] Loading module '/usr/lib/libweston-9/gl-renderer.so'
[13:59:04.708] EGL client extensions: EGL_EXT_client_extensions
               EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
               EGL_KHR_platform_gbm
rk-debug mali-ver=rsx-p0-1.2
[13:59:04.727] EGL version: 1.4 Bifrost-"r6p0-01rel0"
[13:59:04.727] EGL vendor: ARM
[13:59:04.727] EGL client APIs: OpenGL_ES
[13:59:04.727] EGL extensions: EGL_KHR_partial_update EGL_KHR_image_pixmap
               EGL_EXT_image_dma_buf_import EGL_KHR_config_attribs
               EGL_KHR_image EGL_KHR_image_base EGL_KHR_fence_sync
               EGL_KHR_wait_sync EGL_KHR_gl_colorspace
               EGL_KHR_get_all_proc_addresses EGL_IMG_context_priority
               EGL_ARM_pixmap_multisample_discard
               EGL_ARM_implicit_external_sync EGL_KHR_gl_texture_2D_image
               EGL_KHR_gl_renderbuffer_image EGL_KHR_create_context
               EGL_KHR_surfaceless_context EGL_KHR_gl_texture_cubemap_image
               EGL_EXT_create_context_robustness
[13:59:04.728] warning: Disabling render GPU timeline and explicit synchronization due to missing EGL_ANDROID_native_fence_sync extension
[13:59:04.728] Bad/unknown DRM format code 0x00000000.
[13:59:04.729] EGL_KHR_surfaceless_context available
[13:59:04.734] GL version: OpenGL ES 3.2 v1.r6p0-01rel0.7e9c02db0b7656de6636eb08f95998d6
[13:59:04.734] GLSL version: OpenGL ES GLSL ES 3.20
[13:59:04.734] GL vendor: ARM
[13:59:04.734] GL renderer: Mali-TDVX
[13:59:04.735] GL extensions: GL_ARM_rgba8 GL_ARM_mali_shader_binary

In fact the window fade effect when closing the terminal is now fast and smooth and not choppy like with the software backend.

The problem I still have is running any OpenGL or OpenGL ES application. From my understanding OpenGL application will not use hardware accelleration since only OpenGL ES is accellerated?

For OpenGL ES, applications just complain that they can't get a EGL context or display:

Code: Select all

$ es2_info
Error: eglGetDisplay() failed

$ es2gears_wayland
rk-debug mali-ver=rsx-p0-1.2
EGLUT: failed to initialize EGL display

$ es2gears_x11
rk-debug mali-ver=rsx-p0-1.2
EGLUT: failed to initialize EGL display

Any idea what I am missing?

[crashoverride]

Any idea what I am missing?

The output shows the GBM version of libmali installed:

Code: Select all

lrwxrwxrwx 1 root root   10 Mar 28 13:58 libmali-bifrost-g31-rxp0-gbm.so -> libmali.so

You need an X11 version of libmali:
https://github.com/rockchip-linux/libma ... xp0-x11.so

[macc24]

Any idea what I am missing?

The output shows the GBM version of libmali installed:

Code: Select all

lrwxrwxrwx 1 root root   10 Mar 28 13:58 libmali-bifrost-g31-rxp0-gbm.so -> libmali.so

You need an X11 version of libmali:
https://github.com/rockchip-linux/libma ... xp0-x11.so

This would work only for Xwayland apps, wayland version(if it exists(i don't use blobs)) is needed for native wayland apps

[crashoverride]

There is also a wayland binary:
https://github.com/rockchip-linux/libma ... wayland.so

[thomas001le]

Thanks for the update! I installed the wayland version and now es2gears_wayland actually seems to work (at a meager 120 FPS though).

es2gears_x11 did not work with neither the wayland nor the x11 version of the driver. Also es2_info did not work. The error messages are the same.
Do those 2 programs need a Xorg X11 server and not only Xwayland?

[crashoverride]

I have no information for Wayland related issues. I plan to use X11+MATE until the end of time.

[thomas001le]

I have no information for Wayland related issues. I plan to use X11+MATE until the end of time.

Interesting, one reason I went with Wayland was that it looked like Xorg could not run hardware accelerated. Only the framebuffer driver seems to be available for Xorg, so all 2D operations are done in software whereas Wayland seems to use EGL for everything.
Is that not correct?

[odroid]

Rockchip supplies another Mali Bifrost G31 driver for x11 EGL. But we haven't tested it.
https://github.com/rockchip-linux/libma ... ter/debian
http://opensource.rock-chips.com/wiki_Mali#RK3326

[meveric]

my image is running on X11, both the Debian Buster image (where there is an installer for X11 desktop by me) as well as my gaming image for the Go Advance/Go Super.
So I can say X11 runs very good and offers quite some benefits over gbm drivers used by other images.
Not only the desktop, but also you don't need to implement turning of the display in all applications or SDL2 or things like that, but can instead use stock drivers and applications without any modification.

[macc24]

I have no information for Wayland related issues. I plan to use X11+MATE until the end of time.

Interesting, one reason I went with Wayland was that it looked like Xorg could not run hardware accelerated. Only the framebuffer driver seems to be available for Xorg, so all 2D operations are done in software whereas Wayland seems to use EGL for everything.
Is that not correct?

For example, weston and wlroots based compositors can run with framebuffer backend.
Xorg can run hardware accelerated too, that's the point of glamor

[thomas001le]

I tried running Xorg with glamor, but it doesn't seem to run accelerated:

Code: Select all

[   211.696] (II) Loading sub module "glamoregl"
[   211.696] (II) LoadModule: "glamoregl"
[   211.697] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[   211.760] (II) Module glamoregl: vendor="X.Org Foundation"
[   211.760]    compiled for 1.20.10, module version = 1.0.1
[   211.761]    ABI class: X.Org ANSI C Emulation, version 0.4
[   211.773] (EE) modeset(0): glamor: Failed to create GL or GLES2 contexts
[   211.774] (EE) modeset(0): glamor initialization failed

Here is my rather short xorg config, which basically just switches to modesetting instead of fbdev.

Code: Select all

Section "Device"
  Identifier "card0"
  Driver "modesetting"
EndSection

I tried with the x11 driver and the gbm driver from https://github.com/rockchip-linux/libmali.

Since

my image is running on X11, both the Debian Buster image (where there is an installer for X11 desktop by me) as well as my gaming image for the Go Advance/Go Super.

Does your Xorg run accelerated?

[meveric]

Since

my image is running on X11, both the Debian Buster image (where there is an installer for X11 desktop by me) as well as my gaming image for the Go Advance/Go Super.

Does your Xorg run accelerated?

Partly, yes.

[escalade]

So I can say X11 runs very good and offers quite some benefits over gbm drivers used by other images.
Not only the desktop, but also you don't need to implement turning of the display in all applications or SDL2 or things like that, but can instead use stock drivers and applications without any modification.

You can do the same thing on Wayland, most compositors support rotation. I have tested upstream SDL2 with Weston, it works.

[macc24]

You can try using https://github.com/Maccraft123/dtg-ng with line 30 of fs/build commented out https://github.com/Maccraft123/dtg-ng/b ... /build#L30 and it will drop you off to regular sway desktop with panfrost opengl driver.