A04 potential X performance problems + potential solution

DevTerm
, ,
1

While setting up my DevTerm A04, I noticed this error in ~/.local/share/xorg/Xorg.0.log:

[    36.649] (II) Initializing extension GLX
[    36.652] (EE) AIGLX error: sun4i-drm does not export required DRI extension
[    36.758] (II) IGLX: Loaded and initialized swrast
[    36.762] (II) GLX: Initialized DRISWRAST GL provider for screen 0

Coupled with what seemed to me to be sluggish UI, it made me suspect that the system was in fact using software rendering. I did a little research and found that this is caused by the sun4i DRI driver having a hyphen in its name, which messes up the Xorg module loader code. This is fixed upstream (glx: fixup symbol name for get_extensions function (!412) · Merge requests · xorg / xserver), but the version of the Xorg server in Armbian 21.11 (Ubuntu 21.04) is 1.20.11, which is too old to have the fix, which is in 1.21.

I pulled the source for Xorg, dropped the patch from fd.o into it, rebuilt it, installed it, and now I see:

[    36.517] (II) Initializing extension GLX
[    36.817] (II) AIGLX: Loaded and initialized sun4i-drm
[    36.818] (II) GLX: Initialized DRI2 GL provider for screen 0

and, subjectively at least, graphics performance does seem to be better.

I’ve created a PPA (Xorg packages for the Clockworkpi DevTerm A04 : Anna Glasgall) and uploaded my patched package to it. In a couple hours once the builds finish, if you want to try it out for yourself, do

sudo apt-add-repository ppa:aglasgall/devterm-a04-xorg && sudo apt update && sudo apt upgrade

to install the patched packages.

ClockworkPi folks, would you consider including this in your next OS image/apt repository update?

11 Likes
2

Packages are built and the PPA should be usable now.

3 Likes
3

I don’t want this to get lost in the shuffle entirely - ClockworkPi folks (@guu ?), any thoughts on including this?

2 Likes
4

For what it’s worth, I checked my A06 and this appears to only be a problem with AIGLX on the A04.

This was in my log:

[    32.324] (II) Initializing extension GLX
[    32.641] (II) AIGLX: Loaded and initialized rockchip
[    32.642] (II) GLX: Initialized DRI2 GL provider for screen 0
1 Like
5

Yes, the A04 and A06 are wildly different SoCs (Allwinner H6 and Rockchip RK339, respectively).

6

I had to follow these instructions to get this to work: 18.04 - sudo add-apt-repository hangs - Ask Ubuntu

After adding the repository and running sudo apt update && sudo apt upgrade, my log no longer shows the GLX error.

7

Note that this isn’t a function of the PPA, it’s a function of your home network’s or ISP’s IPv6 setup. I can’t work around that at the PPA end, sorry.

1 Like
8

Thanks @annathyst your solution works perfectly. It would have taken me way too long to find that error and I wouldn’t have been able to do anything about it myself.

9

Strange that if I compile the image by myself using the DevTerm github Armbian source, I don’t see this error in dmesg.

This is what I get for xorg server version:
ii xserver-xorg-core 2:1.20.13-1ubuntu1~20.04.2 arm64 Xorg X server - core server

not 1.21 but no errors. Any thoughts on this?

10

Do you have an A04? This only applies to DevTerms with the A04 “core module”. The CM3, A04, and A06 modules have wildly different SoC (System-on-Chip)s.

11

Yes, a04. I can observe it before, using stock image and fixed it using your PPA, but it doesn’t show on freshly compiled image.

Actually if i grep GLX in dmesg output, there’s nothing, not even successful msg.

12

The log entries are from ~/.local/share/xorg/Xorg.0.log, not the kernel dmesg buffer (as they’re from the X server, not the kernel).

13

worked great! thank you!

14

Ok thanks! I remembered seeing that log on stock image now!

However, my newly compiled image doesn’t even have ~/.local/share/xorg/ path.

A search found it in /var/log and shows no error.

image
image1920Ă—1083 189 KB

15

Also got an impression that newly compiled image generates much less heat even I put cpu to 4 cores on with on-demand policy. Haven’t looked into it yet.

16

Did you build the new image from tip of tree for armbian or from the commit specified in the README?

17

Also, when you built the new image, which distribution did you pick to take non-kernel/bootloader packages from?

18

Used some guides from:

(patch section has wrong paths, you can figure out by yourself)

Armbian source has to be commit 5fa022603c0948cc59688ba782b3711f980a0be3 as stated above, otherwise patches won’t apply.

Distribution is 20.04 LTS (focal) to match stock image. (just want to first reproduce stock image before beginning to customize my own ones)

19

So that actually explains it - the stock image is actually based on Ubuntu 21.04 (hirsute), not 20.04 (focal). hirsute is out of support now and won’t have gotten hardware enablement backports from impish (21.10) like focal will have (since focal is an LTS).

Interesting that the patches didn’t apply for you with armbian tip - I built an image last night and they seemed to.

20

Thanks! I thought the stock is 20.04, but just double checked, it’s indeed 21.04 as you said. I think I will go with the LTS for now.