Disabling PSR as per Leo's reply seems to have done the trick!
Stock 6.12-rc1 (without revert): BROKEN
/sys/kernel/debug/dri/0000:c1:00.0/eDP-1/psr_state:
6
/sys/kernel/debug/dri/0000:c1:00.0/eDP-1/psr_capability:
Sink support: yes [0x03]
Driver support: yes
With amdgpu.dcdebugmask=0x800: BROKEN
With amdgpu.dcdebugmask=0x10: FIXED! Performance is as it was on 6.11.
/sys/kernel/debug/dri/0000:c1:00.0/eDP-1/psr_state:
0
/sys/kernel/debug/dri/0000:c1:00.0/eDP-1/psr_capability:
Sink support: yes [0x03]
Driver support: no [0xffffffff]
I have the older Framework 13 panel (BOE 0x0BCA, 2256x1504 @ 59.999 Hz) so I assume PSR isn't supported according to Mario, yet psr_{state,capability} above seem to indicate otherwise?
Thanks.
On 01/10/2024 21:16, Mario Limonciello wrote:
> On 10/1/2024 15:07, Leo Li wrote:
>>
>>
>>
>> On 2024-10-01 15:10, Mario Limonciello wrote:
>>> On 10/1/2024 14:09, John Rowley wrote:
>>>> I was using power-profiles-daemon version 0.23 in balanced mode.
>>>>
>>>> I also tested TLP, and vanilla kernel without any power daemons running. Without any daemons I use the following:
>>>>
>>>> energy_performance_preference: balance_power
>>>>
>>>> scaling_driver: amd-pstate-epp
>>>>
>>>> scaling_governor: powersave
>>>>
>>>
>>> Thanks as long as it can reproduce in 'balanced' mode that should exclude PPD from being the cause and it most likely a pure kernel bug.
>>>
>>
>> I'm curious if you have a PSR supported panel. Does setting
>> amdgpu.dcdebugmask=0x10 on your kernel cmdline help? This force disables PSR.
>>
>> Another flag to try is amdgpu.dcdebugmask=0x800, which allows PSR but disables
>> idle power optimizations. I wonder if that may be causing extra latency.
>>
>> - Leo
>
> Do you have the "new" 2.8k high res panel on your Framework 13? If so; can you please check your logs to see if PSR is even getting enabled?
>
> IE it might be enabling panel replay which is new to enable again in 6.12-rc1, and if so; this could be where the issue is too.
>
> The lower res display shouldn't support it.
