Comment # 10
on bug 97260
from Kai
(In reply to Alex Deucher from comment #9) > (In reply to Kai from comment #8) > > (In reply to Alex Deucher from comment #6) > > > Does reverting 5e031d9fe8b0741f11d49667dfc3ebf5454121fd (drm/radeon/pm: > > > update current crtc info after setting the powerstate) help? > > > > No, it does not for me (I fetched the patch from > > <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/ > > ?id=5e031d9fe8b0741f11d49667dfc3ebf5454121fd> and applied it with patch -p1 > > -R < /path/to.patch). The Talos Principle is still down to 43 FPS, haven't > > tested XCOM 2 or anything else. > > > > Btw, not sure if it can help tracking down the cause: the GPU doesn't seem > > to go into its highest performance mode or at least the fan is not reaching > > its highest RPM when I'm on 4.7.0 (with or without the revert). > > You can check by running apps and monitoring the content of > /sys/kernel/debug/dri/64/radeon_pm_info > Do you see it scaling up under load on the problematic kernels? Does > forcing the clocks to high via sysfs work ok? While the clocks *do* scale up on 4.7.0, it doesn't go as high as 4.6.4. On 4.6.4 I'm reaching the maximum clocks for my GPU (power level avg sclk: 98000 mclk: 125000). With 4.7.0 the highest I'm seeing is "power level avg sclk: 90843 mclk: 125000" and the overall level is way lower (lots of sclk values starting with a 3) compared to 4.6.4 where most values are > 60000 for sclk. Note: I used watch to dump /sys/kernel/debug/dri/64/radeon_pm_info every five seconds to a file. Between runs the actual numbers logged vary, but the general trend stays the same. Writing "high" to /sys/class/drm/card0/device/power_dpm_force_performance_level locks the clock indeed to the highest values (sclk: 98000 mclk: 125000) on 4.7.0 and recovers almost all of the lost performance. There's still a small hit to performance. Note: I've only tested "The Talos Principle" so far, if you need me to test XCOM 2 or other titles as well, let me know. Do you still need the bisect?
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
