TWO.
YEARS.
It's been almost two years since I started this journey.
And today, it finally works!
I can plug an AMD Radeon graphics card into my Raspberry Pi, plug my monitor into the
graphics card, and it WORKS!
I also got this tiny M.2 VGA graphics card working...and, well, it's been a long road.
I started in 2020 with an Nvidia GT710.
I plugged it in, I installed Nvidia's graphics drivers, I booted the Pi.
And it locked up.
I tried a Radeon 5450.
I recompiled the Linux kernel with AMD's drivers, booted the Pi...
Locked up.
I tried an RX 550.
Lockup.
GTX 750 Ti.
Lockup.
GTX 1080.
Lockup.
I even sold my kidneys to buy this AMD Radeon RX 6700 XT at the peak of the GPU shortage,
and what did it do after hours tweaking the driver and recompiling over and over?
Yeah.
Locked up.
I even tested this tiny little SM750 chip that only has 16 megabytes of VRAM.
It's like, a thousand times simpler than the 6700.
Surely I could get IT to work.
Nope.
But at long last, after some help from Coreforge, TobleMiner, paulwratt, pelwell, elFarto, and
many more GitHub users, and sahaj and many others on Twitter, we got it.
First I'll show you what works.
Because not everything works yet.
On the tiny SM750 card, I can plug it into the Compute Module IO board with this M.2
adapter, and the system recognizes it, but I still need a working driver.
So we made this Linux kernel patch that gets the ancient driver to work, and now, if I enable
the card with sudo modprobe sm750fb, I get...
...a framebuffer console.
The driver doesn't even work with a Linux window manager yet, and heck, this chip doesn't
even DO 3D, so besides a shiny VGA output on the Pi, there's not a whole lot you can
do with it.
So switching tracks, I also have this AMD Radeon 5450, from 2010.
I was told by some AMD engineers the Radeon 5000 or 6000 series cards might be the best
ones to try, since they're old enough to be usable on the slower Pi, but new enough to
be supported by Linux's Radeon driver.
But before we can even get to that, we have a problem.
You can't plug this x16 graphics card into the x1 slot on the Compute Module IO board.
You could cut the edge of the connector with a razor saw, like I did here, or use an external
riser or slot adapter.
Or, if you wanna go pro, and have the money to do it, you can buy a Seaberry.
This mini ITX Pi motherboard is insane.
It has not one, but ELEVEN different PCI Express connections, including this full x16 slot
that's perfect for a graphics card.
So now that it's plugged in, it's time to sort out the driver.
After years of work, we finally have a kernel patch that lets this card run.
And it even has 3D acceleration!
The Pi's built-in VideoCore VPU is still faster, but hey, it's something.
I compiled the patch, copied it over to the Pi, and enabled the graphics card with sudo
modprobe radeon.
Look at that!
A console again!
But it gets even better. I can run startx and get the Raspberry Pi OS UI to load!
Now...
it loads.
And you can do some stuff in it.
But there's still a ways to go before I would call it usable.
I installed neofetch to prove that yes, in fact, we're using the graphics card and not
the Pi's built-in GPU.
I also installed Weston, which is a Wayland-based compositor, and that runs more stable, though
a bit slow, and it seems to lock up after a while.
But the driver is stable enough to run some light 3D benchmarks.
First I ran GLMark2, and some tests seemed to work, even giving me 60fps of 3D hardware
acceleration!
But not everything works right now.
Like the jellyfish. I can only get one frame to render then it just... stops.
I also ran glxgears just to see what would happen, and look at that!
Besides the screen looking really weird, we have spinning gears, powered by the Radeon.
During these tests, I also got radeontop running, so I could see the load on various parts of
the GPU, and that worked great.
As a final test, I tried H.264 acceleration with ffmpeg, but that part of the driver is
disabled right now, so it's not sped up at all.
So, after all this work, why is it still glitchy?
Well, it comes down to memory.
Early on, right after the Compute Module 4 was released, the Pi engineers added more
BAR space.
That was my first memory management hurdle, and when they did that, it meant a lot more
PCI Express hardware could be used.
But even with more BAR space, there are a lotta PCI Express features that graphics cards
rely on.
And on the BCM2711 at the heart of the Pi, a lot of these features act...kind of funny.
Like cache coherency and write combining.
Basically, graphics cards want to buffer data and get access to memory as fast as possible,
and they expect the CPU to deliver things to them in an intelligent way.
On the Raspberry Pi, especially if you boot into a 64-bit OS, the CPU does some funny
things.
One of the most classic is when it just cuts off a bit of the memory address when you ask
for it.
It's kinda like if you ask me where I put a bread recipe, and instead of me telling you
"It's in the recipe box in the kitchen,"
I say
"It's in the r--"
and just stop.
Really frustrating, right?
Well, that's kinda what the Pi's CPU does sometimes.
And sometimes the graphics card driver is like, "Okay, I'll, I'll do my best with that", but other
times it gets really angry and just crashes.
In the end, we found a set of functions that had to be patched or replaced, like the memcpy,
memset, and memcache IO functions.
We also had to force the Radeon driver to not use features like write combining or cache
coherence at all.
But since those features are supposed to be supported, and they are on most computers,
the work we're doing here isn't likely to get merged into Linux at any point.
And at this point you're probably wondering, can it at least run Crysis?
Well, no.
And you can probably rule out most triple-A games, but not because of the Pi's CPU.
Steam and Proton are X86-based, and probably will be for a long time, with or without graphics
card support.
You can kinda-sorta emulate things with Box86, but trying to get a hacky GPU driver to work
through emulation layers would take a lot more work, and I wouldn't bet on it happening.
What about things like GPU mining for crypto, or GPU compute, like CUDA programming or AI
and machine learning?
Well, all those things rely on features that might or might not ever work on the Compute
Module 4.
So again, I wouldn't bet on it.
But some things, like H.264 acceleration or other features these GPUs have, might work
someday.
But almost every one of the features would need to be combed through in the driver, and
fixed to work correctly on the Pi.
So yeah, if you're really dying to use a Pi to do GPU mining, and you have someone who
knows low level Linux kernel programming and has deep knowledge of AMD's drivers, you might
get something working, someday.
But probably not.
And since Nvidia's drivers aren't even open source, good luck trying to ever get something
like CUDA working on the CM4.
At least we could get AMD's engineers to help out here and there.
Nvidia completely ghosted me!
So the next question I get a lot is what about other ARM systems?
I mean, there's a ton nowadays. You have Solid-Run's Honeycomb, Rockchip and Allwinner SoCs, and
heck, even Apple's latest computers run on ARM.
The problem is standardization.
Despite all its warts, the X86 platform is a pretty darn stable target at this point in time.
In ARM, there are standards, like SystemReady, and some SoCs do work with things like graphics
cards by default.
But not every SoC vendor spends the time and investment to certify their chips.
A lot of SoC's are purpose-built for a specific task, like set top boxes or embedded devices,
and those things don't usually have beefy PCI Express graphics cards plugged in!
Even popular Rockchip SoCs, like the RK3566, have broken PCI Express support.
pgwipeout had this to say:
I'm still pretty sure there's no way to make these non-compliant PCIe controllers magically
compliant, even with a massive performance hit.
None of these chips are open source, so it's hard to predict how they'll behave until someone
can spend hours and hours debugging them.
Besides other ARM boards, a lotta people told me to try Windows 11, since it can boot
on a Pi.
But that won't help, because graphics drivers are even more obtuse on Windows, and the process
would be even harder.
And I've also done a lot of testing on the AMD RX 6700 XT since my last video.
How's it working?
Well, I've gotten a few of the 'rings' of initialization working, but it's still having
some trouble too.
So for now we're focusing on the older Radeon cards instead of the newer cards that use
AMD's amdgpu driver.
So we have some cards kinda working in Linux, but it can't play games, can't mine, and can't
make AI faster yet...
So what CAN we do with these things?
Well, I don't know about anyone else, but my first goal has always been to explore,
or as Captain Jean-Luc Picard so eloquently puts it,
"To boldly go where no one has gone before."
Maybe in the end we will be able to get hardware video decoding working.
Maybe we can get some form of compute.
I don't know. But I do know that it's been exciting to find ways to push hardware in ways it was
never meant to be pushed.
And heck, if nothing else, maybe this'll push Broadcom to make the next Pi chip's PCI Express
work perfectly out of the box!
The one thing that's certain is this has been an expensive journey!
Sponsor me if you wanna see more, and until next time, I'm Jeff Geerling!