Andrea, can yo apply thus patch, load/play/encode file with this patch applied and post output? for me it prints twice "1" and then consistently "8" (my num. of cores)
Thank you for your interest in an issue that's killing me! Applied the patch; it seems to always show cpu 16. I have an 8c/16t so it is shown fine. I attach cpu-count.txt to show output during playback and rendering operations. A video of the above operations can be found at the following address. https://www.dropbox.com/s/m4bpa0y9mk55btq/cpu-test.mov?dl=0 Note that today it went better than the average I normally have: in playback I had less freezes and in rendering I got an average of 60 fps, while normally I stay on 12 fps. Last note: from a 10 years ago laptop with a good i7 4c/8t I switched to an AMD 8c/16t with double the frequency. For example to compile CinGG (with all 8 threads in Intel and with all 16 threads in AMD, always at 100%) I went from 20 min to 5 min. Instead in playback and rendering I don't notice big differences. Using a rendering via handbrake or ffmpeg from command line is extremely more efficient.
On Saturday, July 17, 2021, Andrea paz <[email protected]> wrote:
Thank you for your interest in an issue that's killing me! Applied the patch; it seems to always show cpu 16. I have an 8c/16t so it is shown fine. I attach cpu-count.txt to show output during playback and rendering operations. A video of the above operations can be found at the following address. https://www.dropbox.com/s/m4bpa0y9mk55btq/cpu-test.mov?dl=0 Note that today it went better than the average I normally have: in playback I had less freezes and in rendering I got an average of 60 fps, while normally I stay on 12 fps.
one possible explanation, if you have cpufreq set to 'dynamic' /powersave it may not reclock cpu (and memory/bus?) fast enough.. so encoding stuck in low freq. mode (i think some games behaved similary) try to force 'performance' mode.
Last note: from a 10 years ago laptop with a good i7 4c/8t I switched to an AMD 8c/16t with double the frequency. For example to compile CinGG (with all 8 threads in Intel and with all 16 threads in AMD, always at 100%) I went from 20 min to 5 min. Instead in playback and rendering I don't notice big differences. Using a rendering via handbrake or ffmpeg from command line is extremely more efficient.
By default I had the "schedutil" (dynamic) governor. I recently changed to "ondemand" (dynamic) without noticing much improvement on geekbench. Now I put "performance" and tried load/play/encode as before. The result is always the same. See cpu-count-performance.txt. The audio errors were not in the previous attachment because this time I tried playback with "fast forward/reverse" as well as "normal fastword/reverse". The errors occurred only with fast ... Even at geekbench I don't notice much improvement: schedutil: single-core 1390 multi-core 9598 ondemand: s-c 1398 m-c 9648 performance: s-c 1388 m-c 9935
On Saturday, July 17, 2021, Andrea paz <[email protected]> wrote:
By default I had the "schedutil" (dynamic) governor. I recently changed to "ondemand" (dynamic) without noticing much improvement on geekbench. Now I put "performance" and tried load/play/encode as before. The result is always the same. See cpu-count-performance.txt.
The audio errors were not in the previous attachment because this time I tried playback with "fast forward/reverse" as well as "normal fastword/reverse". The errors occurred only with fast ...
but resulting file was with normal audio? you can try insane fast forward speed like 10, or until it broke.... (i hope it will not, but there currently no limit at how big this value can be.. because I do not know what limit i should put in) it will be amazing if you left patches in for some days of normal cin usage... something not obvious on simple usage may surface...
Even at geekbench I don't notice much improvement:
schedutil: single-core 1390 multi-core 9598
ondemand: s-c 1398 m-c 9648
performance: s-c 1388 m-c 9935
still +400 multicore points... if you do not mind power usage/temps/fan noise... thanks for patiently testing all those patch iterations!
participants (2)
-
Andrea paz -
Andrew Randrianasulu