@hrw I have the same motherboard. For an Intel Arc A380 and AMD WX3200 (Polaris), I use @chimera (musl based and with BSD userland base) as it incorporates the PCIe patches OOTB. The AMD card has had intermittent bugs depending upon Mesa and kernel version (sometimes was stable but would also crash rarely, and haven’t used it since December or January on a regular basis), and now I mostly use the Arc card. The Arc requires PCI resizable bar to be turned on in the UEFI firmware platform settings. It also does not POST even with EDK2 and the X86 oprom emulator, so no boot graphics.

I also use an Nvidia RTX 3060, with @ultramarine and @UniversalBlue Bluefin GDX LTS beta, as they both incorporate the Nvidia binary drivers by default. This card doesn’t require kernel PCIe bug patching.

With #freebsd, there are NO supported GPU drivers on aarch64, but KDE runs on X11 on the scfb (UEFI GOP framebuffer) so having a card that POSTs and provides a UEFI framebuffer is important. This requires X86 oprom emulation unless you have an AMD card new enough (eg. Navi 2x) to have aarch64 UEFI driver in the oprom, or you load the AMD UEFI driver from the UEFI shell. (AMD has official downloads of their UEFI GOP drivers.)

With #openbsd, X11 will work on the UEFI framebuffer as well. They do build AMD GPU driver into their arm64 kernel, but it is unstable on the Ampere Altra so I disable it.

#unix desktop IS possible on #arm64 in 2025, but it is death by 1000 cuts and requires constant compromises and workarounds. And I’m just doing this as a hobby… 🫠

#amperealtra #amperecomputing

@osnews PSA from an owner of a custom Ampere Altra workstation: gpu/graphics choice is limited and affects OS choice! There is a reason System76 chose a NVidia gpu.

The Ampere Altra has a PCIe bug that causes problems with AMD gpus and the linux amdgpu driver, requiring an out-of-tree linux kernel patch that is sporadically maintained and unlikely to ever be upstreamed. (chimera-linux.org is the only distro that ships with this patch applied) The amdgpu drm driver maintainers have expressed no interest in working around this bug within the driver itself either.

Remember that this driver ends up in FreeBSD and OpenBSD too! Personally a Polaris generation gpu has worked with stock OpenBSD 7.6 kernel because the kernel handles device memory mapping differently than linux and doesn’t seem trigger the PCIe bug. With a newer Navi 2nd gen gpu, the bug interrupts firmware loading in stock OpenBSD. It can be worked around, but:

There is also an issue where Vega and newer gpus require cpu hardware floating point math in the kernel driver code which wasn’t supported on arm64 until drm in Linux 6.2. The most recent releases of FreeBSD and OpenBSD are either on an older drm than that, or haven’t ported the hardware floating point code within the kernel driver on arm64 yet. So even if you get the Navi firmware to load, you don’t get any farther than that (Display Core requires the fpu code).

Nvidia supports arm64 with their closed source driver and is unaffected the PCIe bug (or works around it, depending on what you read, but the code is secret so 🤷) but no BSD for you! They only have Linux arm64 drivers. The older cards supported by nouveau will also get you nowhere on BSD.

Also note that Nvidia DOES NOT ship an arm64 option rom GOP driver for EFI console graphics on any of their cards. Your motherboard/platform could provide an emulator in the UEFI firmware to use the x86-64 GOP driver (my Asrock motherboard doesn’t.) Polaris AMD gpus didn’t include arm64 GOP in the rom, but the 2nd gen Navi DOES. So you can get boot console on it but only working OS graphics on patched linux 🫠

#bsd #openbsd #amdgpu #amdgraphics #linux #arm64 #armlinux #nvidia #nvidiagpudisplaydriver #ChimeraLinux #amperecomputing #amperealtra