Thats interesting as I have 32gb memory and experienced the glitches as well. However, rather than disabling scatter/gather I set UMA_GAME_OPTIMIZED to lock the gpu memory size and this has proven stable as well.
I’m not sure which method is preferred but it definitely seems like a subtle memory leak or overflowed buffer happening around the shared memory region.
I have only used the UMA_GAME_OPTIMIZED method, and never have any glitches when it’s enabled.
Btw, after recent BIOS update, I got more available ram. 29 GB vs 27 GB.
3.02 to 3.03 or 3.03 to 3.03b?
Also, after the BIOS update, is UMA_GAME_OPTIMIZED still set?
sorry I should’ve specified… it’s 3.03 to 3.03b
UMA_GAME_OPTIMIZED still set, without it the system is more prone to glitch
Thanks. Weird that an EC only update, focused on power/charging, would change available memory…
I disabled UMA_GAME_OPTIMIZED today. Btw its called “Gaming” after 3.05.
I tried to trigger the corruption, like I did last time… open many tabs running YouTube, Totem running 1080p video, and plugging and unplugging my usb-c dock with monitor connected.
I opened 30 tabs in the background and plug/unplug dock, close/open lid, on/off fractional scaling, open/close lid - didn’t trigger white graphical corruption.
I used mine whole day without any issue.
worth noting, I’m on kernel 6.8, bios 3.05. no amdgpu.sg_display=0
So the setting for iGPU memory is as follow:
Auto: Allocate 512MB to FPU if system memory is below 64GB. else 2GB.
Gaming: Allocate 2GB to GPU if system memory is between 8-24GB. 4GB if system memory is 24GB and above.
Is 512MB enough for normal use?
When S/G is on absolutely it is. Once that 512 is exhausted the kernel driver will pull from GTT.
After more than a day of using it, I will fairly confidentially say that bios 3.05 (still in beta, officially) + kernel 6.8.x fixes all corruption problems!
No more restarts and workarounds 
So we can turn scatter gather back on?
Uhu! Provided you update your bios, ofc.
Gotta try that at some point then.
Well looks like a in to me, just ran the cyberpunk benchmark with sg on and on igpu memory auto and it ran fine with none of the artifacts that needed turning off sg.
I’ll leave it on for now.
Has someone tried to reproduce this issue using beta BIOS 3.05 ?
What about the multi-monitor video surface corruption? (appears as windows become polarized/black white) when moving between eDP and external monitors etc?
Has someone tried to reproduce this issue using beta BIOS 3.05 ?
Yeah, you liked the post where I said I did. As said, I can’t reproduce with BIOS 3.05 (beta).
What about … when moving between eDP and external monitors etc?
I’m not entirely sure we are talking about the same thing, but while just using/unplugging an external monitor would, before, often trigger the graphical glitches of the sort described in this thread, this has still never happened for me on beta 3.05 (going on 3-4 days now).
It was possibly a variation ; but unlike the case where the external became completely whited out and unusable until a reboot. It was observable when you dragged a window half between the eDP and external DP monitor.
If looked like colour surface related to my uneducated eyes. But otherwise didn’t result in an unusable external display.
I was only able to observe this running Plasma6 (Nobara and Fedora 40) and various 6.8 and 6.9 kernels.
@Rijnder_Wever
Do you also not see anymore in dmesg logs :
[199821.668560] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
[199821.668715] [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
Could you also tell us your kernel version please for future reference ?
While this is on gnome/wayland, I did have issues with external displays prior to this bios. I attributed it to the scatter/gather issues we’ve been seeing.
Using 6.8.4-300.fc40.x86_64 and 3.05b I can reliably use my external monitor which exposes a usb4 connection with displayport.
Is there anything that you do specifically that could provoke the behavior?
Coolermaster gp27u.
@Mario_Limonciello would you have any idea what fixed the issue in the latest bios release, was there an AMD AGESA bump ?