[RESPONDED] Severe artifacts and poor performance with dGPU

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 :slight_smile:

1 Like

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.

Here are some fun screenshots.

When OpenArena crashes, it tries to show this warning on the next startup:

However, if it crashes and I try to re-launch it with DRI_PRIME=1, that dialog box is corrupted:

The corruption is persistent and survives things like opening GNOME’s overview, or clicking and dragging it around:

Hitting Tab to focus one of the buttons on the dialog forces the whole thing to redraw, and it looks correct from that point on.

I’m on Fedora Silverblue.

Do you get artifacts running something like Superposition?

For me superposition defaulted to the 7700 without the need for DRI_PRIME.
I can run 1080p medium without any issues holding mostly between 30-45fps.

1080p High / Extreme will not run but of course this is a mid-teir GPU so I didn’t really expect it to.

Are you sure? :wink:

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.

A clue! I only see corruption in Wayland.

So this seems like a compositing issue, and likely software rather than hardware?

Here’s a video showing the issue:

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.

A few folks in the community Discord were able to reproduce the corruption, so it seems it’s not unique to my hardware. Video at Discord

Welcome to the community @callahad.

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.

Thanks for confirming!

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.

1 Like

I can reproduce this trivially as well. Would like to see it fixed.

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.

Agreed, ideally this would be the case.

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.


I’m bummed to hear of trouble running Blender. Hopefully it can still use the dGPU for cycles rendering.

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.

1 Like

Things seem better (possibly entirely fixed?) as of kernel 6.8