AMD Radeon PCIe graphics card tested with a Rockchip RK3588 SBC (Radxa Rock 5B)

When Rockchip first introduced the Rockchip RK3399 processor with a PCIe interface people initially hoped they could connect graphics card, but those hopes were quickly squashed due to a 32MB addressing limit.

However, the PCIe implementation on the newer Rockchip RK3588 processor does not have such a limitation, and last November, Radxa teased a demo with an AMD Radeon Pro WX 5100 PCIe graphics card connected to the Rock 5B SBC running the glxgears demo on the Radeon GPU.

AMD Radeon PCIe graphics card Rockchip RK3588 SBC

I couldn’t find any instructions to reproduce this setup, but this got Jasbir interested, and he tried to do a test of his own with the Radxa Rock 5B connected to an AMD Radeon R7 520 (XFX R7 250 low-profile) through an “M.2 Key M Extender Cable to PCIE x16 Graphics Card Riser Adapter” ($14 plus taxes on Aliexpress) and powered by an LR1007 120W 12VDC ATX board.

The experiment was mostly successful as he managed to run kmscube, glmark2-drm, and glmark2-es2-drm 3D graphics demos successfully in his setup as you can see from the 3 minutes video embedded below.

It did not exactly work out of the box however, as first he had to build a custom kernel with graphics card drivers and fixes and updated Radxa’s Debian image with it. This did not work at first because of two main reasons:

  1. Memory allocation is limited to 32-bit for PCIe DMA transfers and while a board with 4GB RAM might not see an issue, the 8GB board used for testing likely picked an address range above 4GB.
  2. AMD cards rely on PCIe snooping and there is no CPU snooping on the RK3588 interconnect. So any cache copies of the same device memory block won’t get updated to remain in sync.

After implementing workarounds for the two issues above, kmstest sample ran successfully, but kmscube ended up with an error:


Another fix was required as explained by Jasbir:

To fix the Radeon kernel driver we are ensuring the cards memory is mapped as ‘Device memory’ type Device-nGnRnE. If it were ‘Normal Memory’ then unaligned access is allowed. This implies fixing up userspace drivers/applications as these errors are encountered as these applications can directly manlipulate the cards memory. For this particular bus error it was caused by a memcpy in the radeon gallium driver and fixed applied there and as shown in the video kmscube runs

A fix enabled all graphics samples showcased in the video to run fine. However, running startx ended with a shader compiler error, and would require more work. Video playback with VAPPI was unsuccessful either. So while it looks promising, it’s still not possible to use a PCIe graphics card with a Rockchip RK3588 SBC the way you’d use an eGPU with an x86 mini PC, but it might be in the future.

You’ll find more details in Jasbir’s post. Note that he does not provide the fixes and workarounds, and just goes through the steps and explains the errors, so you would not be able to easily reproduce his demo without some serious work.

Share this:

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
4 Comments
oldest
newest
m][sko
11 months ago

GIC version is r1p6-00rel0, RK356x interconnect does not support
GIC and CPU snoop to each other, hence the GIC does not support the
shareability feature. The read of register value for shareability 
feature does not return as expect in GICR and GITS, so we have to
workaround for it.

It is interesting that intel use same PCI IP from dw (we don’t know version)
for a very long time and don’t have this problems

Some ARM processor have this fixed and it looks like when enterprise customer ask to fix that, they are able to fix that 🙂

Jeff Geerling
11 months ago

Aww, I’d love to see the work he did on the drivers in his fork, so we could compare it to the changes required for radeon on the Pi CM4… https://github.com/geerlingguy/linux/pull/6

varok
varok
11 months ago

Not sure if you’ve covered it but it is related via wootyb github, he got Radeon GPU’s running on the Solidrun HoneyComb LX2K and posted all of the instructions to make it happen and get box86 running.
https://github.com/Wooty-B

He has videos of PC games playing on his Youtube, so its already possible at least for Arm UEFI PC’s.

Pete
Pete
11 months ago

When it’s all set up, benchmarks against the internal Mali GPU would be interesting.

if AMD did ever release drivers for ARM64, the highly contested Windows port might gain some traction. 🙂

Khadas VIM4 SBC