amdgpu: Fix raphael support - #478
Open
lbartoletti wants to merge 3 commits into
Open
Conversation
The Raphael APU gfx ring (gfx_0.0.0) stalls shortly after init and enters a GPU reset loop when GFXOFF is enabled: the GFX engine is power-gated on idle and the SMU wake handshake does not work under LinuxKPI, so the ring times out (signaled seq < emitted seq). Clear PP_GFXOFF_MASK for IP_VERSION(10, 3, 6) in gfx_v10_0_check_gfxoff_flag(), mirroring the existing Navi10 handling. Guarded with __FreeBSD__ as this is a FreeBSD/LinuxKPI-specific quirk. This removes the idle gfx ring timeout; a separate ring stall under sustained GFX load remains under investigation.
amdgpu_device_init() unconditionally set have_atomics_support = false on FreeBSD, bypassing the gfx9+ APU case the __linux__ path already handles. APUs from gfx9 onward do not rely on PCIe atomics; they use an internal path with native atomics support. With the flag left false, the userspace GFX submission path stalls: kernel submissions complete but the first Mesa/radv submission hangs the gfx_0.0.0 ring (signaled seq < emitted seq), followed by a GPU reset loop under any real load (e.g. a Wayland session). Mirror the __linux__ APU handling: set have_atomics_support = true for IP_VERSION(GC) > 9.0.0 APUs, otherwise keep the previous false default. Fixes the Raphael (gfx 10.3.6) gfx ring timeout under GPU load.
On Raphael (gfx 10.3.6) under FreeBSD/LinuxKPI, GPU-scheduler submissions made after the engines go idle were never fetched: the gfx ring timed out with signaled seq < emitted seq and no VM protection fault, the CP rptr frozen at the kernel->userspace boundary. The first ~14 boot-time submissions complete (the CP still polls the write pointer during the post-idle window), then the CP stops polling and waits for a doorbell ring that never wakes it on this APU under LinuxKPI. Anything doorbell-driven afterwards (KIQ, the async gfx queue, every Mesa frame) stalls. The doorbell mapping itself is correct (VM_MEMATTR_DEVICE / UC, single 64-bit store) and the writes reach BAR 2; the problem is purely the idle CP/MEC not acting on them. Sidestep the doorbell wake by keeping the engines polling the queue write pointer from memory: point the GFX-pipe wptr poll at the gfx ring's wptr writeback, max out CP_RB_WPTR_POLL_CNTL IDLE_POLL_COUNT, and enable CP_PQ_WPTR_POLL_CNTL for the MEC (each queue's poll address is already programmed in its MQD). With this, a Wayland (sway) session runs on the iGPU; the gfx ring no longer times out.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Disclosure: this branch was produced largely by an AI assistant (Claude).
Resume (generated by Claude Code):
Since I can't guarantee the work and you'll likely need to take the code over, I'm glad to run every test you need on the hardware. Thanks
Fixes: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268394
maybe #330 ?