Crashing on Battery Power Solution

[TechProgenitor]

Hi @kingo132,

For the past few months I've been dealing with this issue, and was wondering if you've encountered it before? Essentially you have to boot up the computer on battery power and never plug it in. Eventually a kernel panic gets triggered which makes the internal display go black. This appears to have started in macOS Monterey, and my guess is that it began around the time when people claimed that the ATY,bin_image device property wasn't needed anymore in order to maximize GPU performance.

The problem appears to go away when choosing a custom framebuffer. I've been using ATY,Python lately which gives incredibly smooth performance (especially in 3D modeling apps). The other framebuffer that attaches to this computer is ATY,Adder, but I don't think it's properly optimized for this configuration because it's written for the desktop GPUs within Apple's iMacs instead of the mobile ones within MacBook Pros. God knows what the default framebuffer is written for, but I don't believe it's designed for laptops.

Unfortunately, Adder/Python kernel panic on wake, and it appears to have something to do with SMU in regards to PowerPlay:

In ioreg, there's a device property at the bottom of GFX0 called SWIP_Error_msgs which lists TTL errors such as this SMU one before they end up kernel panicking the computer.

Adding CFG_NO_PP = True to my config.plist fixes wake but kills performance and for some reason crashes DRM content. (Disabling PowerPlay also empties the SWIP_Error_msgs device property.) I don't know what SMU is, but I see that both ATY,Python and ATY,Adder have identical SMU-related device properties. Is there a vanilla-based method that we can use in order to remove them? (Unless you'd know how to optimize them?)

Also, do you happen to know which properties within the info.plist file for AMDRadeonX6000Framebuffer correspond to ATY,RadeonFramebuffer (the default one)? It might give us a hint on which device properties to enable/disable/edit regarding this specific problem if the proposed method above doesn't work.

[TechProgenitor]

UPDATE

According to the WEG Radeon FAQ, SMU is related to power management on newer AMD GPUs. By adding the Force_Load_FalconSMUFW device property, I'm able to to empty the SWIP_Error_msgs property within IOreg but wake is still broken with the exact same error.

I'm starting to also wonder if there's an older operating system that wakes properly with ATY,Python and SMU enabled? If so, perhaps we can grab an IOreg dump from the older OS, and transfer one or more properties over in order to fix wake on Ventura.

[TechProgenitor]

I’ve just now made a breakthrough! Changing the device-id of the GPU seems to affect the SMU firmware that's uploaded by the framebuffer!

Injecting 0x7360 fixes wake, but produces graphical artifacts. I still have yet to try out all of the Navi GPU device ids, but it proves that we hopefully don’t need to patch the info.plist for AMDRadeonX6000Framebuffer.kext. We either need a non-glitchy/wake-friendly device-id, or if there's a corresponding device property that's injected within IOreg.

This wake problem plagues actual MacBooks, and appears to get resolved when owners replace the logic board. While I can't confirm it, I'm guessing that the device-id of the graphics card gets changed in the process.

[TechProgenitor]

Figured it out!!! Wake is fixed!!!

You have to enable PP_PhmUseDummyBackEnd. It was the only difference between the IOregistries of the 0x731F and 0x7360.

The PP_PhmUseDummyBackEnd property appears to enable/disable the PP_PhmSoftWTTTable property. This table doesn’t change between framebuffers, and it doesn’t make sense why the DummyBackEnd property can be disabled on the default framebuffer without affecting wake.

I’m not sure if any of this relates to the PP_PhmSoftPowerPlayTable device property, or if enabling DummyBackEnd affects performance and/or stability, but so far everything seems good. Considering that we have a mobile graphics card, and that the 0x7360 is used in the MacBookPro16,4 I think we’re in good shape!

Here’s a screenshot of my device properties that I’ve added for the 5700M within my config.plist:

[TechProgenitor]

Alienware Area 51m-R2 GPU Fixes for Windows 10

Figured to add this here since the macOS graphics issues have been fixed and I recently just fixed them within Windows.

Ghost Image Glitch at Bottom of Internal Display: Caused by faulty implementation of PSR on the B173HAN04.4 display. PSR needs to be disabled within the registry by going to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000 and creating the DWORD DalPSRFeatureEnable with a value of 00000000

AMD Driver Crashes while Browsing the Internet: Caused by Multi-Plane Overplay problems (thanks to Nvidia for this solution). Disable MPO within the registry by going to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm and creating the DWORD OverlayTestMode with a value of 00000005

[TechProgenitor]

I’ve attached the device properties that I’m currently using in order to improve the performance/stability of the GPU and fix DRM: 5700M.plist.zip

• CFG_LINK_FIXED_MAP fixes DRM, but it causes a brief startup glitch and I’m not sure if/how to solve it.
• ATY,DeviceName and ATY,FamilyName make the GPU model show up in the Activity Monitor GPU Activity window.
• Setting PP_WorkLoadPolicyMask to 1 appears to reduce coil whine from the graphics card.
• Setting PP_PhmUseDummyBackEnd to 1 resolves SMU-related TTL errors and fixes wake for custom framebuffers.
• Finally, I added the original unmodified PowerPlay tables to the device properties from the vBIOS of our graphics card.