Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The end of my AArch64 desktop experiment

marcin.juszkiewicz.com.pl

Post reply on HN
Print view View original

41–50 of 89 posts

Re: The end of my AArch64 desktop experiment

#41

Post by boxed »

preisschild wrote: post #16
boxed wrote: post #12

Earlier quoted context omitted.

Linux on apple silicon is a thing though: https://asahilinux.org/

True, but they had to implement their own bootloader chain and because of such overhead they need a lot of effort to port to each new apple SoC generation

Ok.. and? That's job someone has already done, so what does it matter?

From what I've understood there's significant backwards compatibility for the new SoCs, so the significant work they need to do is to support new features, not getting things running.

Re: The end of my AArch64 desktop experiment

#42

Post by jdub »

akoboldfrying wrote: post #27
HerbManic wrote: post #5

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, t…

Apple M series is also aarch64 architecture, isn't it? Could you explain more why you expect Ampere to be slow but M series to be fast?

Because they're designed for different things.

Ampere's primary focus is running lots of simple tasks concurrently, at relatively low power, with lots of I/O. So, many tens to hundreds of cores, not too fast, at lower power draw than amd64, with lots of PCIe lanes for storage and network.

Apple's primary focus is user experience and power efficiency. That's why you'll find a handful of fast performance cores and low power efficiency cores, along with graphics acceleration to drive high resolution displays.

Re: The end of my AArch64 desktop experiment

#43

Post by jdub »

rwmj wrote: post #40
M95D wrote: post #33

Earlier quoted context omitted.

> my major complaint is Device Tree sucks Why? Device tree is great. You can patch it yourself if something doesn't work, add overlays, etc.

It's a bad solution compared to having the hardware just enumerate itself like PCI does. (No one uses the firmware supplied DTs because they're usually broken.)

Take a look at how modern PCs enumerate all of their non-PCI hardware. I'll put a bucket over here.

Re: The end of my AArch64 desktop experiment

#44

Post by jsnell »

edg5000 wrote: post #17

> 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 don't know if it's your intent, but that reads really condescending. It's obvious the author knows how to build packages from source. They're working professionally for a Linux distro on arch support!

But that was several layers deep into yak shaving broken graphics, and at some point you need to actually get your real work done.

Re: The end of my AArch64 desktop experiment

#46

Post by anthonj »

NavinF wrote: post #23
anthonj wrote: post #8

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…

I don't think youtube playback is a relevant comparison since it uses ~0 CPU. Pretty much all phones have hardware accelerated decoding. Lots of TVs and streaming devices use an ancient Android phone SoC yet they too can play YT and run a browser. The entire UI is often a local web app.

I imagine, be he mentions video playback on youtube making things worse, and he does have a dedicated amd gpu.

But iirc for both Firefox and chromium on Linux desktop hw acceleration is tricky so maybe it's that.

Re: The end of my AArch64 desktop experiment

#47

Post by bayindirh »

10000truths wrote: post #34

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 se…

I believe something I call "the window phenomenon" has occurred. Sometimes, life allows you have the time to do these big experiments on your life and then it gets busy again and you can't dive into it with the same capacity, so you have to do what you have to do while surviving what you have at hand.

I have gone through many patches like this, and I believe he had to handle life while is experimental workstation had to limp through.

Then when he had the time, he had just pulled the plug.

Re: The end of my AArch64 desktop experiment

#48

Post by bayindirh »

dlahoda wrote: post #45

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.

AI will be more harmful than helpful than a very big and unexplored (for them) codebase for them.

Moreover, playing with code which fiddles with hardware directly is neither simple, nor easy, nor fun.

Re: The end of my AArch64 desktop experiment

#49

Post by neobrain »

__patchbit__ wrote: post #2

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

Unlikely. I've been daily-driving the predecessor (X13s). While it's usable and technically all drivers are there, it's far from "without pain" due to endless number of small but annoying quirks. Just to give you an idea: boot fails 4 out of 5 times, external displays aren't recognized unless plugged in/out several times, sporadic resets during overnight sleep, etc. On top of that speakers will sound prohibitively tinny due unimplemented software-side speaker protection. I haven't tried T14s, but at least the audio issues will still apply there.

Apple devices supported by Asahi are a far more polished experience.

Re: The end of my AArch64 desktop experiment

#50

Post by [deleted] »

jdub wrote: post #43
rwmj wrote: post #40

Earlier quoted context omitted.

It's a bad solution compared to having the hardware just enumerate itself like PCI does. (No one uses the firmware supplied DTs because they're usually broken.)

Take a look at how modern PCs enumerate all of their non-PCI hardware. I'll put a bucket over here.

[deleted]
Post reply on HN