performance problems on RPI4/RK3399

Hi folks!

I am from PiLabs, the makers of the friendly xfce build for the pi4 and other ARM sbc's called TwisterOS (https://twisteros.com/) I am testing xfce4 on both RPI4 and RK3399 on mainline (k5.8 on RPI4 and k5.9 on RK3399) with focal up to date. the problem is the next one:

while latest xfce solved the tearing issues we had on previous xfce versions, there is a terrible performance penalty on both panfrost and v3d, around 70% compared to xpresent (glx here) and a bit more compared with other desktop environments .It was measured with glmark2 but also on real applications. the framerate looks bad on the desktop anyway.

xpresent performs way better but the instabilities (on RK3399 panfrost it hangs randomly) and glitches (insanely high on v3d RPI4) make it unusable.

we need your help as long as you would like to be competitive on ARM Linux.

Best regards!! Salvador

changed the description

For the issues and glitches with present, I assume this is a driver bug, Xpresent support from the compositor point of view is pretty much straightforward.

Regarding GLX, yes, it's can be pretty heavy indeed. Can you please indicate which exact version of xfwm4 you are testing?

I am running with this one: xfwm4_4.15.3-1

I would suggest to try the current code from git instead, it's received several optimizations for GLX.

oka, I will try it. I would like to rely on repos bc too much custom may result on a mayhem, but I will try just with the compositor and see what happens. thanks

can I ask you something more @olivier ? if I am on an older xfce4, what I need to do to have this tearless experience (glx/xpresent). bc RPI OS still have a lot of tearing, and it seems that upgrading just the compositor from source didn't do the trick .

Well, vsync support relies on hardware and driver support, so a few things you'd want to check:

1. Are xpresent and GLX really enabled in the build (xfwm4 --version)
2. Xpresent might be enabled but not supported by the driver (unfortunately there is no way for the compositor to know it)
3. GLX requires hardware acceleration, check glxinfo | grep renderer

But long story short, if vblank doesn't work even though it's enabled in the build, then most likely your system is missing hardware support.

oka! well, the only thing that differs here is the kernel. on ubuntu it does work, so I will just compile the kernel. it's obviously hw accelerated (by mesa), but seems something missing and maybe was some change on the kernel that allowed tear free experience on ubuntu.

added 5. Compositor label

added 5. Tearing / Vblank label

@Askmewho: any update?

yes, the glitches on xpresent on both platforms were due terrible regressions on master mesa. they remain some of them... but far better so far. closing.

on rpi4 the tearing will be solved as soon as they bump the kernel on RPI OS.

closed