Comment # 39
on bug 102322
from Andrey Grodzovsky
(In reply to dwagner from comment #37) > In the related bug report > (https://bugs.freedesktop.org/show_bug.cgi?id=107152) I noticed that this > bug can be triggered very reliably and quickly by playing a video with a > deliberately lowered frame rate: > "mpv --no-correct-pts --fps=3 --ao=null some_arbitrary_video.webm" > > This led me to assume this bug might be caused by the dynamic power > management, that often ramps performance up/down when a video is played at > such a low frame rate. I tried exactly the same - reproduce with same card model and latest kernel and run webm clip with mpv same way you did and it didn't happen. > > And indeed, I found this confirmed by many experiments: If I use a script > like > > #!/bin/bash > > cd /sys/class/drm/card0/device > > echo manual >power_dpm_force_performance_level > > # low > > echo 0 >pp_dpm_mclk > > echo 0 >pp_dpm_sclk > > # medium > > #echo 1 >pp_dpm_mclk > > #echo 1 >pp_dpm_sclk > > # high > > #echo 1 >pp_dpm_mclk > > #echo 6 >pp_dpm_sclk > to enforce just any performance level, then the crashes do not occur anymore > - also with the "low frame rate video test". > > So it seems that the transition from one "dpm" performance level to another, > with a certain probability, causes these crashes. And the more often the > transitions occur, the sooner one will experience them. > > (BTW: For unknown reason, invoking "xrandr" or enabling a monitor after > sleep causes the above settings to get lost, so one has to invoke above > script again.)
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