DietPi-Software | RK3399 GPU support

[dagamboa]

Required Information

• DietPi version | 6.28
• Distro version | Buster
• Kernel version | 5.4.28-rockchip64
• SBC device | NanoPC T4 (aarch64)

Steps to reproduce

1. Install fresh buster image
2. Install desktop (I used LXqt)
3. Login and type "startx"

Expected behaviour

• Desktop starts

Actual behaviour

• Fatal error: (EE) no screens found(EE)

Extra details

Basically I did as stated, but after an apt-get upgrade desktop starts without problem

Installed some software, configured desktop autologin and everything "works"

Not sure if related but I noticed that vnc doesn't work on shared desktop mode and sometimes after a reboot X.org gives another fatal error: AddScreen/ScreenInit failed for driver 0

[MichaIng]

@LieDanG
Many thanks for your report. I guess it is a missing library that is required for RK3399 X.org packages. apt-get upgrade solves it since it seems to overwrite those packages with the ones from Debian repo.

I fixed it for v6.29 by manually installing the library during install process. However since apt-get upgrade overrides them anyway, it is kinda pointless to install the RockChip packages in the first place, at least on Debian Buster. The assumption was that RockChip X.org packages provide some enhanced GPU acceleration compared to the generic Debian ones, but they need to raise their version string for them to stay installed.

To verify, could you paste:

apt show xserver-xorg-core

The other error might be related to an acceleration driver that is not present on Debian X.org packages. Please try:

sed -i '/exa/s/^ /# /' /etc/X11/xorg.conf
sed -i '/glamor/s/^#//' /etc/X11/xorg.conf

• EDIT: On the other hand, the package ships /usr/lib/xorg/modules/libexa.so, so probably the man pages are just outdated?

I have to think through this and also just asked RockChip devs to update their version strings and some details about exa acceleration driver + general GPU acceleration through their vs Debian X.org packages.

[MichaIng]

@rafee74
I link you here as well, since this is basically the same issue, affecting all RK3399 SBCs.

So basically what we need to do is:

1. Decide whether to use the RockChip provided X.org packages or stock Debian repo ones.
   • If we want to use them, we need to find a way to block the ones from Debian repo from being installed. Best solution IMO is to pin the priority of those packages from Debian repo to "-1", so they are skipped in the very first place.
   • Decide whether to use exa or glamor as default acceleration method. And old discussion states that glamor does not work very well (on RK3399: https://github.com/rockchip-linux/rk-rootfs-build/issues/25#issuecomment-336113014), but it is still the default and probably the only supported one by stock Debian modesetting acceleration driver.
2. Decide whether to update our udev rules to allow full GPU usage for non-root users: https://github.com/rockchip-linux/rk-rootfs-build/tree/master/overlay/etc/udev/rules.d
   Else users would need to be added to video and render groups. If the device files are owned by the correct groups, actually for security reasons I would prefer to keep permissions strict. We can automate adding the autologin user to those groups when desktop or video application is used.
3. Create an xorg.conf which includes DPMS mode. AFAIK currently, due to do doubled "Monitor" section one overrides the other one: https://github.com/MichaIng/DietPi/blob/master/.conf/dps_6/99-dietpi-dpms_off.conf and https://github.com/MichaIng/DietPi/blob/master/.conf/dps_6/xorg_rk3399.conf

To test performance, not only es2gears but glmark2-es2 could be used as well. There was still the issue that es2gears does not show any gears, hence GLESv2 seems to not work as expected.

Since I do not own an RK3399 SBC to test effectively, we basically need someone with deeper knowledge. The Mali GPU libs/drivers for GLESv2 and EGL are there, so this is not the problem, but I lack the detailed knowledge about how to make X.org use them correctly/best.

[rafee74]

@MichaIng
I own 3 NanoPi M4 but in a few days I have to complete the configuration of all 3 boards for my project. I used 1 of them to test some configurations I need, I think to complete today or tomorrow.
If you want I can help you testing for some days (and in my free time...) but within next week I need to complete and configure them in my final configuration. But I don't consider me an expert.

When I upgraded last time I'm not able anymore to run es2gears, it give me an error. I'll try glmark2-es.
What I want to do is to reinstall image, activate desktop (LXDE or LXQt), upgarde xorg packages as per your instructions and test again GPU acceleration.

Let me know if you need some other tests or if I can help you in other way.

[MichaIng]

@rafee74
Jep, just when you find some spare time.

The issue currently indeed is that apt upgrade installs the Debian X.org packages and likely breaks the xorg.conf by this. I'll think through some solutions, linked you here mainly to let you know of progress and final solution for v6.29.

[dagamboa]

@MichaIng
apt show xserver-xorg-core:

Package: xserver-xorg-core
Version: 2:1.20.4-1
Priority: optional
Section: x11
Source: xorg-server
Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
Installed-Size: 6,044 kB
Provides: xorg-input-abi-24, xorg-video-abi-24, xserver-xorg-video-modesetting
Depends: xserver-common (>= 2:1.20.4-1), keyboard-configuration, udev (>= 149), libegl1-mesa | libegl1, libaudit1 (>= 1:2.2.1), libbsd0 (>= 0.7.0), libc6 (>= 2.17), libdbus-1-3 (>= 1.9.14), libdrm2 (>= 2.4.66), libepoxy0 (>= 1.4.3), libgbm1 (>= 17.1.0~rc2), libgcrypt20 (>= 1.8.0), libgl1, libpciaccess0 (>= 0.12.902), libpixman-1-0 (>= 0.30.0), libselinux1 (>= 2.0.82), libsystemd0, libudev1 (>= 183), libunwind8, libxau6, libxdmcp6, libxfont2 (>= 1:2.0.1), libxshmfence1
Recommends: libgl1-mesa-dri (>= 7.10.2-4), libpam-systemd
Suggests: xfonts-100dpi | xfonts-75dpi, xfonts-scalable
Conflicts: xserver-xorg-input-evtouch, xserver-xorg-video-modesetting
Breaks: libgl1-mesa-dri (<< 18.0.5), systemd (<< 226-4~), xserver-xorg (<< 1:7.7+10~)
Replaces: xserver-xorg (<< 1:7.7+10~), xserver-xorg-video-modesetting
Homepage: https://www.x.org/
Tag: hardware::input, hardware::video, implemented-in::c, interface::daemon,
 interface::graphical, interface::x11, network::server, role::program,
 uitoolkit::xlib, use::driver, x11::application, x11::xserver
Download-Size: 3,440 kB
APT-Manual-Installed: no
APT-Sources: https://deb.debian.org/debian buster/main arm64 Packages
Description: Xorg X server - core server

[MichaIng]

@LieDanG
Jep, as I thought, the Debian repo package. Could you check if the following solves the error messages with VNC:

sed -i '/exa/s/^ /# /' /etc/X11/xorg.conf
sed -i '/glamor/s/^#//' /etc/X11/xorg.conf

[rafee74]

@MichaIng
Ok, I've done the tests with a fresh install:

• LXDE as desktop environment
• compiled and installed glmark2
• no other software installed, only default packages as per DietPi installation
• tests done with default Xorg packages (those installed with DietPi script), after an apt upgrade and then after wget of Xorg packages from Rockchip GitHub repository.

glmark2 works correctly from dietpi user, even if with errors, glmark-es2-drm works but with sudo.
The other 2 command ends with errors, even with sudo:

dietpi@monitor01:~$ sudo glmark2-drm 
Error: Failed to bind api EGL_OPENGL_ES_API
Error: eglChooseConfig() didn't return any configs
Error: Error: Couldn't get GL visual config!
Error: main: Could not initialize canvas

dietpi@monitor01:~$ sudo glmark2-es2
Error: eglInitialize() failed with error: 0x3001
Error: eglInitialize() failed with error: 0x3001
Error: main: Could not initialize canvas
Errore di segmentazione

Here attached are files with test results and with Xorg packages details.

Let me know if you need some more tests.

---

apt-show-default.txt
apt-show-upgrade.txt
apt-show-wget.txt
glmark2-default.txt
glmark2-es2-drm-default.txt
glmark2-es2-drm-upgrade.txt
glmark2-es2-drm-wget.txt
glmark2-upgrade.txt
glmark2-wget.txt

[MichaIng]

@rafee74
Many thanks for running those tests. It makes sense that DRM requires sudo, or usermod -aG render dietpi, this is expected.

You apt show wget shows not any package installed at all? Did dpkg -i succeed on the downloaded packages? However for glmark2 this should not play any role since it seems to have nothing to do with the Xorg packages, only with the installed Mali driver anyway.

I think we'll revert to Debian packages for now. Hardware acceleration for X applications is something that might need to be tested but seems to be at least not possible via glmark2 or e2gears anyway.

[rafee74]

@MichaIng
Ops...., I didn't read carefully apt show command results and I didn't noticed there isn't the Status line. Sorry.

Anyhow, in the mean time I've wanted to install Armbian official image. I had downloaded it some time ago, I think at the end of February or beginning of March. This image is the server one, based on Debian Buster with kernel 5.4. The complete boot to a shell takes more than 1 minute, but after an update & upgrade (using ambian-config) the boot time is about 15 seconds. Now it uses kernel 5.4.32
Then I installed minimal desktop (XFCE) and compile and install glmark2.
The board is heating very much even if I use the vendor heat-sink.
Glmark2 hang up completely the board and I have to cut power off. In the mean time glmark2 work, the temperature growns to over 60-62 degres and then the board hangs.
But es2gears now show me the rotating gears!!!
With lsmod i saw there is also panfrost driver but I don't know if gpu acceleration is active. I've tried to search information but without success.

Did you think it's better to stay on kernel 4.4 or try with 5.4?

[MichaIng]

@rafee74
Panfrost is the open source project for backwards engineering Mali GPU drivers: https://panfrost.freedesktop.org/
True, it has been added to Linux from 5.2 on and the mesa GL packages seem to work as userspace libaries to load it, but also it has very limited support still, compared to the closed-source official drivers by ARM, from what I read, and might never be "finished", since this backwards engeneering takes longer for each GPU as it's "lifetime". But if one can hope, then for the RK3399/Mali T864 which is still flagship.

The complete boot to a shell takes more than 1 minute, but after an update & upgrade (using ambian-config) the boot time is about 15 seconds. Now it uses kernel 5.4.32

That is good news, probably something has been improved about the boot time with latest kernel/device tree/bootloader packages.

Glmark2 hang up completely the board and I have to cut power off. In the mean time glmark2 work, the temperature growns to over 60-62 degres and then the board hangs.
But es2gears now show me the rotating gears!!!

That actually doesn't sound like "good" GPU acceleration, as expected, however finally it needs to be compared with the ARM Mali drivers.

Did you think it's better to stay on kernel 4.4 or try with 5.4?

Actually the very long boot time was the only reason why I built Linux 4.4 images, hence is this is not an issue anymore with current versions, I would stay with 5.4. All our RK3399 testing images are based on Armbian with Linux 5.4 as well, besides the one with Linux4.4 in their names: https://dietpi.com/downloads/testing/

[MichaIng]

I reverted the Xserver installs on RK3399 and ASUS TB to not use the X.org packages from RockChip anymore by stay with the Debian ones for now. Default xorg.conf has been simplified to be a compatible default accordingly. So it's only the Mali drivers that are installed from the RockChip repo for now.

If someone finds X.org applications being slow with this, while being fast with those and a certain xorg.conf/setup around, I'm open for implementing it.

[MichaIng]

I mark this as closed. It will solve itself with Debian Bullseye, being released this summer, which providers newer Mesa drivers with good GPU support for various SoCs. Any attempt to use 3rd party drivers and libraries is problematic, as usually any application using e.g. those EGL/GLES interfaces needs to be build against related 3rd party development headers as well. Maintaining this too much effort for something that is only relevant for a soon old Debian version.