GNOME 3 Might Be Too Resource Hungry To Ever Run Nicely On The Raspberry Pi

If you try running the GNOME Shell today on the Raspberry Pi, it's a frustratingly slow experience. While some work is being done in addressing GNOME's GPU, CPU, and memory consumption, it might not ever be in a state to run smoothly on Raspberry Pi hardware.

Earlier this month was the GNOME 2018 Performance Hackfest and one of those in attendance was Broadcom's Eric Anholt who maintains the VC4 and V3D graphics driver stacks. The former is most notable for being the fully open-source graphics driver solution for the VideoCore hardware found on Raspberry Pi single board computers up to this point.

While at the GNOME hackfest, Eric was working on adding support for capturing DRM events within the sysprof system profiler. This is useful for those profiling GNOME's performance and trying to make optimizations to also see what is happening in the Direct Rendering Manager space like GPU jobs and vblanks.

That work is exciting and will benefit most of the DRM drivers for being able to expose more performance analytics through sysprof. But even with GNOME's recent motivation on improving performance, Eric Anholt has his doubts whether GNOME 3 will ever work nicely on the Raspberry Pi.

Eric wrote:

Ultimately, though, I’m skeptical of GNOME 3 ever being usable on a Raspberry Pi. The clutter-based gnome-shell painting is too slow (60% of a CPU burned in the shell just trying to present a single 60fps glxgears), and there doesn’t seem to be a plan for improving it other than “maybe we’ll delete clutter some day?” Also, the javascipt extension system being in the compositor thread means that you drop application frames when something else (network statechanges, notifications, etc) happens in the system. This was a bad software architecture choice, and digging out of that hole now would take a long time. (I’m agnostic on whether it was wrong to move those into the same process as the compositor, but same thread was definitely wrong). I’ll keep working on the debugging tools to try to enable anyone to work on these problems, though.

Those interested in the rest of his DRM profiling hackery and VC4/V3D improvements can see the rest of his driver status update. The other news he reports on is the V3D Gallium3D driver being enabled by default now as part of the V3D (formerly "VC5") DRM driver set to go upstream in the Linux 4.18 kernel cycle.