<br><br>On Saturday, July 17, 2021, Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com">gamberucci.andrea@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you for your interest in an issue that's killing me!<br>
Applied the patch; it seems to always show cpu 16. I have an 8c/16t so<br>
it is shown fine.<br>
I attach cpu-count.txt to show output during playback and rendering operations.<br>
A video of the above operations can be found at the following address.<br>
<a href="https://www.dropbox.com/s/m4bpa0y9mk55btq/cpu-test.mov?dl=0" target="_blank">https://www.dropbox.com/s/<wbr>m4bpa0y9mk55btq/cpu-test.mov?<wbr>dl=0</a><br>
Note that today it went better than the average I normally have: in<br>
playback I had less freezes and in rendering I got an average of 60<br>
fps, while normally I stay on 12 fps.</blockquote><div><br></div><div>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. </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Last note: from a 10 years ago laptop with a good i7 4c/8t I switched<br>
to an AMD 8c/16t with double the frequency. For example to compile<br>
CinGG (with all 8 threads in Intel and with all 16 threads in AMD,<br>
always at 100%) I went from 20 min to 5 min. Instead in playback and<br>
rendering I don't notice big differences.<br>
Using a rendering via handbrake or ffmpeg from command line is<br>
extremely more efficient.<br>
</blockquote>