Hi, I’m unable to get my dGPU to work properly. Launching any program with DRI_PRIME=1 results in the application being chock full of artifacts. I’m able to reproduce this on Fedora 39, as well as NixOS 23.11 and Unstable. On KDE Plasma 5 and 6, as well as Gnome 45. With kernel 6.7.7 and 6.8-rc6. With and without the amdgpu.sg_display=0 boot parameter.
Everything works great on Windows.
Interestingly running glmark2 --fullscreen routinely shows my iGPU delivering ~4x the FPS of the dGPU (3461 vs 976).
Does anyone have any ideas on how I could further diagnose this problem? I don’t see anything suspicious in dmesg or journalctl. Thank you
Still trying to nail this down. I tried a few games from Steam and they worked flawlessly on the dGPU (Death Stranding, Elden Ring).
Firefox works well on the dGPU if and only if I set it to use its software fallback renderer instead of the OpenGL-based WebRender (toggle gfx.webrender.software in about:config). When running in this mode, WebGL demos appear to work correctly, and I can see appropriate load on the dGPU in nvtop.
I suspect it’s a separate issue, but native Linux games (SuperTuxKart, OpenArena) tend to crash when entering fullscreen, logging “amdgpu: The CS has been rejected (-22)” to the console, and these errors in the system journal:
kernel: [drm:amdgpu_dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer with error -22
gnome-shell[2512]: Direct scanout page flip failed: drmModeAtomicCommit: Invalid argument
OpenArena only crashes 2/3 of the time; occasionally it will successfully open in fullscreen and everything renders correctly. Anything that takes it out of fullscreen (alt-tab, hitting Super to trigger GNOME’s overview, etc.) has a 2/3 chance of crashing it.
Superposition worked perfectly. The 1080p Medium preset gave me 22fps on iGPU, 113fps on dGPU. I did have to use DRI_PRIME=1. Solid 45fps on the dGPU and 1080p Extreme.
So I assumed it was running on the dGPU because when I startup Superposition without a DRI_PRIME=1 it shows 8GB as the video memory. But in fact running with DRI_PRIME=1 does indeed let 1080p extreme run and everything run much better.
I was able to repro this myself. Ideally, I would only use DRI_PRIME=1 %command% in Steam, per game launcher as described in the docs.
That said, the quip about using it for Cheese needs to be updated. In my most recent testing, it is best to use your non-dGPU graphics (default mode) for Firefox, etc.
For gaming, when I run Cyberpunk 2077 or Guardians of the Galaxy, this script when I run it, run my game in steam, then alt/tab out to this script running, will show my dGPU as active.
I have not had time to test games outside of a Steam environment.
@Mario_Limonciello may be able to chime in regarding using DRI_PRIME with applications. My testing with it outside of steam was limited, with most of the focus being with Steam.
Regarding Cheese… for a non-contrived use case, try running Blender. The 3D scene is rendered correctly, but there’s corruption on resize and the menu bar is virtually unusable due to the way repainting / compositing is failing.
I see similar issues with Steam’s GUI, especially menus.
Both Steam and Blender’s .desktop files include PrefersNonDefaultGPU=true so they’ll launch on the dGPU by default and fail to work correctly.
The Cheese application is pre-installed in most distributions or at least available in the repositories, so I think it’s a good application to demonstrate how to use DRI_PRIME.
This should be addressed by OS or firmware update, not by modifying the documentation. A user who bought a dGPU should be able to run any application on it, even applications for which it doesn’t make logical sense, such as an application for taking webcam pictures or Sudoku etc.
As far as a web browser is concerned, there are web applications that might make sense to run on a dGPU. For example, the Godot game engine has a web version.
When it comes to non-Steam games, I think it would be worth testing the Minecraft Java Edition. I’m not sure, when you start the launcher using DRI_PRIME=1, if DRI_PRIME=1 will carry over to the game. There used to be a special way to run thist game on dGPU. I would test it myself, but I don’t currently own a multi-GPU laptop.
It appears to be an AMDGPU bug. This is not at all uncommon as bugs can and do happen.
I will be reaching out to AMD to get their thoughts on a path forward, likely this will be a bug report. I will also be testing this against later kernels to see what steps are needed to get this figured out.
In the near-term, running games from the Steam launch box in the Steam client has been rock solid in my testing for a number of titles ranger from Cyberpunk to Helldivers 2.
Spoke with AMD, we are putting together an internal ticket. We don’t have an ETA, but it is getting top shelf focus.
In the meantime, running games as described in the guide on Steam works (spent the weekend playing games), but for the AMD issue with the other applications, we’re working on it.
Thanks for that update. It’s exciting that this forum is such a great place to express issues and have them surfaced to the likes of AMD, etc.! Thanks again for what you guys do.
I’m experiencing a very similar issue on Fedora 39 and Rawhide. At full resolution I experience artifacting coming off of the icons and screen elements at the bottom of my monitor. I use KDE and replicate it every time there but have not been able to reproduce it in GNOME. I’m not in a position to collect logs/info at the moment. If my issue should be a separate thread please let me know. Thanks.
Can confirm that this is the case. I am now experiencing a different issue where bluetooth devices do not properly connect after reboot on Fedora 40 (Stable Update channels) and must be repaired every single boot.
Edit: Whoops, I thought this was my bug report thread. Whoops
Hmm, I have no problem with bluetooth reconnecting after reboot. I’m using a Logitech MX Ergo mouse and Sony headphones, and both reconnect just fine. My installation is stock Fedora 40 release, updated BIOS 3.03 and Mediatek card. I haven’t had any of the problems with the card that other folk claim to have.
