6.18: PCIe GPU testing (AMD and Intel Xe)#7113
Conversation
|
Also just to keep the breadcrumbs going:
|
popcornmix
force-pushed
the
rpi-6.18.y
branch
2 times, most recently
from
d9f2960 to
4a4ea03
Compare
6by9
force-pushed
the
rpi-6.18.y-pcie-gpu
branch
from
2ef2bea to
b17e55e
Compare
|
Branch rebased to keep it relevant. I've just noted https://lore.kernel.org/dri-devel/20250613-upstream-xe-non-4k-v2-v2-0-934f82249f8a@aosc.io/ I don't see it having been merged, so at some point it would be useful to test it as the thread appears to have stalled. |
popcornmix
force-pushed
the
rpi-6.18.y
branch
4 times, most recently
from
d003d86 to
dff72a6
Compare
6by9
force-pushed
the
rpi-6.18.y-pcie-gpu
branch
from
b17e55e to
6bf3935
Compare
|
Branch rebased. |
|
I guess you don't want noise and user testing here. But just as a thumbs up, I've installed this kernel on a rpi5 with oculink-connected RX 6800 XT, and the combo seems rock-solid from a user perspective. I've run multiple games and benchmarks, as well as Jeffs llama examples both in chat- and in web-server mode. Not a single hickup. The card even seems to go into suspend mode and recovers on use. |
|
With the old PR on 6.17.x, I was able to get the AI Pro R9700 working. With this PR on 6.18.x, I get: Maybe the AMD driver in 6.18 has a new thing where it forces a BAR resize, and that's currently failing? The only thing I could find that's remotely related is this patch. Or could be related to this post: [REGRESSION] amdgpu fails to load external RX 580 since PCI: Allow relaxed bridge window tail sizing. The RX 7900 XT is loading fine, however. |
|
@pigong I haven't really the time to dig into these @geerlingguy There were other patches around for resizing the BAR and releasing the old allocation before creating the new one. I don't know if those would help in this situation. They seem to be referenced in #6621 |
|
@6by9 - With a fresh rebuild of the entire OS, I was able to get the R9700 working again, not sure why it wasn't before... but that previous install was about a month old at this point, and I generally rebuild things weekly, oops :) It's nice to have just one or two commands to run, and not have to wait for a kernel recompile! |
popcornmix
force-pushed
the
rpi-6.18.y
branch
from
aa8e7a1 to
e132677
Compare
|
@6by9 - FYI @mariobalanica has a set of 5 patches for nouveau for Nvidia cards; I haven't had time to take a look yet, but something else interesting to note! https://github.com/mariobalanica/arm-pcie-gpu-patches/tree/nvidia-wip/linux/6.17 |
6by9
force-pushed
the
rpi-6.18.y-pcie-gpu
branch
from
40759d3 to
0deed8f
Compare
|
Branch rebased to keep it vaguely current. I'd seen that mariobalanica had some patches before, but had registered them for NVidia's proprietary drivers and not nouveau. I'll grab those patches and see whether it works with my old GT710 (too old to be supported by the latest proprietary drivers - I did try). |
|
Erm, I've just got kmstest producing a sensible output on a GT710! The framebuffer emulation is messed up - that's odd as XR24 (RGBX8888) works fine through kmstest. kmscube doesn't render correctly. It reports renderer "NV106", OpenGL ES 3.2, but flashes a vaguely recognisable variant of what kmscube should be producing as if the stride is wrong. Frame rate of 5.4fps @ 1080p, or 1.4fps @ 4k30. The kernel log has messages -22 being -EINVAL. That falls out from
There is a log line Start X and run Seeing as this PR is still being batted around, I've pushed those patches to the branch so others can give it a try without having to rebuild the kernel. |
6by9
force-pushed
the
rpi-6.18.y-pcie-gpu
branch
from
672b98e to
5652cd2
Compare
6by9
force-pushed
the
rpi-6.18.y-pcie-gpu
branch
2 times, most recently
from
317c5c0 to
392fdfd
Compare
Well that puts the kibosh on using this particular card for labwc or other current window manager, same as the |
|
Understanding this is a WIP. But I have decided to try my hands at getting an Intel Arc Pro B50 working. Following Jeff's excellent guide: https://www.jeffgeerling.com/blog/2025/all-intel-gpus-run-on-raspberry-pi-and-risc-v/ I'm able to get display out and Performed the steps outlined here: https://www.jeffgeerling.com/blog/2025/resizeable-bar-support-on-raspberry-pi/ Also posted here with a couple more details: geerlingguy/raspberry-pi-pcie-devices#779 (comment) |
popcornmix
force-pushed
the
rpi-6.18.y
branch
2 times, most recently
from
ec7cf0f to
9ea9c76
Compare
popcornmix
force-pushed
the
rpi-6.18.y
branch
from
5d874ad to
970bf07
Compare
popcornmix
force-pushed
the
rpi-6.18.y
branch
2 times, most recently
from
e2361ee to
e7fec0d
Compare
popcornmix
force-pushed
the
rpi-6.18.y
branch
2 times, most recently
from
96ee9b0 to
f02621a
Compare
popcornmix
force-pushed
the
rpi-6.18.y
branch
2 times, most recently
from
2e9acf3 to
6ad963a
Compare
popcornmix
force-pushed
the
rpi-6.18.y
branch
2 times, most recently
from
8fa1bed to
5970220
Compare
|
Hi, I have been using a command from Jeff Geerling sudo rpi-update pulls/7113, this now returns 404. Please help I am losing my mind. |
CI build artifacts are only kept for 90 days (the longest that Github allows). We're now passed that point, so they've been automatically deleted. |
6by9
force-pushed
the
rpi-6.18.y-pcie-gpu
branch
from
392fdfd to
baf52e3
Compare
|
Branch rebased, but I haven't retested. I've dropped the Nouveau patches from this PR as they really were hacking. They're on https://github.com/6by9/linux/tree/rpi-6.18.y-pcie-gpu-nouveau if anyone wants them. |
|
Working on another project right now but I can pull these changes and test on my SI card again later this month (I do remember SI refused to boot with this patch set so I could have a PR coming in a few weeks) |
|
Quick test on my 2GB RX460 is all working fine. My Intel A380 is enumerating and works with kmstest, but I haven't rebuilt Mesa with the Xe support enabled, so it won't work with labwc at present. kmscube drops back to llvmpipe so is incredibly slow. |
Hi. I'm getting 404 error when trying to run rpi-update. Does it need to be rebased again? Thanks |
Various PCIe controllers on ARM64 platforms don't support cache snooping, which leads to numerous issues when attempting to use PCIe graphics cards. Switching ttm_prot_from_caching to return pgprot_dmacoherent for ttm_cached pages solves the issue, albeit with a performance hit. There is a second check in ttm_prot_from_caching that also needs updating. Signed-off-by: Yang Bo <bo.yang@smail.nju.edu.cn> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Also includes SND_HDA_* modules for audio on AMD GPUs. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Taken from https://github.com/chimera-linux/cports/blob/master/main/linux-stable/patches/xe-nonx86.patch Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
6by9
force-pushed
the
rpi-6.18.y-pcie-gpu
branch
from
ae60da2 to
486a8f1
Compare
|
What was the full error from rpi-update? Storage for CI builds was getting a little silly, so the mainline builds are now discarded after 5 days, and bcm2711_rt after 30 days. The "useful" builds should be retained for 90 days. I wonder if rpi-update is still looking for the bcm2711_rt build which has disappeared. You can override that by adding |
Thanks for the reply. Just tried sudo WANT_64BIT_RT=0 rpi-update pulls/7113 and this is what I get - *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom Updating a system with initramfs configured is not supported by rpi-update. Would you like to proceed? (y/N) Downloading bootloader images gzip: stdin: unexpected end of file Thanks |
Just tried again and its now working great! Thanks for your help. |
8 participants
PR to create CI artifacts supporting AMD and Intel Xe GPUs.