The end of the AArch64 desktop experiment

I'm not surprised at the outcome. These Ampere system single core/thread performance is pretty low and that is where you feel it. The OS/software simply cannot allocate the threads across enough cores effectively to make up for this difference.

This is why things like the Apple M Series feels so fast, because while they don't win the multi core performance especially when going up against a 80 core beast like this, they have single thread performance exactly were it is needed.

Maybe we will need 80 cores in future, that is cool but for daily home use it is still just way too much for what we need.

I don't understand the kernel problem. Why did he feel he had to rebuild the kernel weekly? When the amdgpu stopped working why couldn't he just go back to the last working kernel?

> there was no org.freedesktop.Platform.GL.nvidia in Flatpak repositories for AArch64

All he had to do was build some packages from source, right? It's really worth learning how to do this, since it removes a lot of constraints.

And the kernel patch should land in the kernel pretty soon, I hope? He won't have to run a patched kernel forever. Should be possible to get that in a release in a year or so?

I'm not sure why the author didn't attempt to dive deeper into the error message he saw. amd_vcn_dec sounds like it's an issue with the GPU's video decoding logic. If there's a timeout when trying to process a decode request, it may be that power management for the GPU is buggy somehow. Given that this is a server build and idle power consumption is likely not a big deal, I'd suggest pinning the GPU power state to see if it resolves the issue (see amdgpu.ppfeaturemask and amdgpu.runpm kernel parameters).

Fascinating! I've been running the laptop version-ish of this experiment with the 14M9610, and my major complaint is Device Tree sucks. It's been explained to me why all of ARM can't just enumerate devices like PCs do, but it still sucks. This means every ARM device starts off in custom kernel territory, which makes all sorts of hacks okay to begin with, since you need a custom kernel anyway.

I see the problem, but I don't see a clear analysis on the actual source of the problem. I assumed the issue was mainly single core performance, but he is also suggesting context switches could be the cause?

So could you fix that with a new scheduler? Or you just need another SoC with better single core performance? I could imagine that the latter already exists, just not in soc with >16 cores. My naive view is that such high core count system comes with tradoff on core size and interconnect/memeory bus complexity.

And I mean.. my phone is a middle lower end device and for sure I can play youtube videos (maybe in a popup as well) and run the browser without noticing that much difference from my laptop.

Can the ThinkPad T14 ARM Snapdragon variant function without pain as a daily Linux/BSD driver?

he does not mention AI usage.

how it helped to solve problems and search over git sources.

intresting what he would achieve mixing nixos and ai for patches.

I wonder if a source-based distro like Gentoo would have made OP's life slightly easier. Portage for instance should allow you to maintain a set of patches to automatically apply when you update your kernel. Those flatpak problems also shouldn't exist there.

I’ve been using ARM Debian desktop stably for a long time. I don’t see what the issue is, am I missing something or is this just his hardware choice?

I use a DGX Spark every day as my daily driver and it's great. I barely use the "AI" facilities of it, but as an Aarch64 desktop Linux, I have no complaints.

The AArch64 desktop experiment started in 2020 with the Macbook M1 and it ended in 2026 with great success with Apple phasing out support for Intel.

It is called Apple Silicon.

The Desktop Linux will take over from here guys. Next year it will be ready, together with GNU Hurd for everyone and their Grandma.