My journey testing various graphics cards on the Raspberry Pi began soon after the Compute Module 4 was launched in 2020. Since then I've tested almost 20 graphics cards—with a little success.
But there were two roadblocks to getting drivers for even older AMD radeon drivers working well:
- The maximum PCIe Gen 2.0 bandwidth meant use cases were limited to 'processing on GPU' tasks like GPU-assisted compute. Even in the base case, external cards couldn't necessarily pipe through data quick enough for modest gaming or other real-time tasks.
- (And most impactful) The BCM2711 SoC used on the CM4 and Pi 4 had some strange PCI Express bus quirks that caused hard crashes and various faults in drivers attempting to use 64-bit memory addresses. There were strange and exotic workarounds—but these workarounds led to even more limited performance!
The Pi 5, fortunately, seems to have fixed the PCIe bus quirks with its new BCM2712 SoC, and the new chip also introduces unofficial support for PCIe Gen 3.0 speeds (8 GT/sec versus the CM4's 5).
External GPU bringup on the Pi 5 was much faster since we now know many of the driver quirks are due to old code assuming an X86 architecture.
In the video below, I demonstrate the Pi 5 displaying Wayfire through an AMD RX 460, and running at least much of the glmark2 test:
As chronicled in the RX 460 testing GitHub issue (and related issue #6, user Coreforge got a glmark2 score of 3441 over PCIe Gen 1 speeds, had Steam launching (but sometimes crashing) using box86 and box64, ran Portal and Portal 2 with no issues (outside of Steam), and Minecraft 1.14.4 ran but at a reduced framerate due to the lower-speed PCIe Gen 1 connection.
When I have more time (right now I'm in the middle of moving all my gear to a new space...), I will join in more testing, but hopefully Pineberry Pi can get a PCIe adapter like their prototype uPCity I'm using to market, so more people can test and squash the remaining memory alignment bugs for older cards like the RX 460.
I have also been testing my RX 6700 XT, which also uses the amdgpu Linux driver, but with some newer extensions. I have gotten through a few roadblocks but am currently stuck at the part where the driver attempts initializing Display Core.
Honestly, I'm approaching 'infantile' stages of familiarity with graphics drivers, but I know enough to mess up the driver (a lot) and quite rarely get something working on my own. I hope that with the Pi 5's better PCIe bus (and Gen 3.0 speeds, even if unofficial), more people can work on squashing arm64 vs x86-related memory access bugs in various drivers.
The best thing is on the Pi 5, I've so far never encountered any bugs where the entire system crashes (to the point the kernel can't recover). On the Compute Module 4, I had to hard pull power and re-apply it to get back into a working state! Debugging is immeasurably if you can get an error message or exception, and the entire system doesn't explode every time you test it :)
Many other PCIe cards 'just work' out of the box on the Pi 5, and as always—you can follow my progress testing various devices over on the Raspberry Pi PCIe database.
Comments
I hope it gets native support!
Have you tried it with Nvidia GPU's on the rpi 5? I assume their driver is more ARM ready as you already got it working on Ampere too
Yes—check the Pi PCIe Database site I linked above, unfortunately it hits an error about
RmInitAdapter failed, and that seems to plague other arm64 platforms too... not sure what's going on there but probably something that can be fixed.Since we don't have the source code for it, it might be hard though.
You should also try the nvidia "open kernel driver" (where they shoved everything into the firmware so they could open what little is left in the kernel). I've used it successfully with my LX2160A. Box64 works, but Box86 can't use OpenGL because the nvidia aarch64 package has no libraries for armhf.
Wicked round of testing Jeff, very impressed as always! I was just wondering in terms of when the new POE hat comes out for this, would a switch like the NETGEAR GS108LP provide enough power (30W per port) to power a cluster of these Pi's? I assume a 15.4W per port model would not be enough but cannot find much info on this or anyone else running into this thought experiment so wanted to ask the cluster-man himself....
If you buy the more powerful power supply, you would probably have enough power budget. But with the default one, which only provides 60W total power budget, I'd only assume you could run 3-4 Pis before brownouts would be an issue.
Makes sense. Legend thank you for replying! Will give it a go!
Wayfire/Wayland would be great if legacy applications using X11 worked properly but it is just broken...
https://github.com/WayfireWM/wayfire/issues/948.
Unfortunately as this bug has been given a low priority so it doesn't seem like this is going to be fixed any time soon, particularly as it is already almost three years old.
I understand the excitement around Wayland and some things it can do are very impressive but unless it can also do the basics and do them well I'm just not interested, compatibility wins every time (the issue with Wayland is the reason I don't own a Pi 5).
What are you using to make the GPU external?
A specialty board from Pineberry Pi (uPCity) — they may start selling something like it at some point... hopefully!
You might also be able to use the Pineberry HarDrive! with an M.2 to PCIe raiser adapter like DELOCK 64132, I haven't got either but gonna test later...
Could you use windows 11 on the pi and would the windows drivers be able to communicate with the external gpu. As of a week ago windows works on the pi 5
Unfortunately drivers for Windows on Arm are quite lacking—you have to have specific drivers for the arm64 architecture on Windows, and right now very few exist (especially for PCIe devices).