Discussion Regret Intel 13th Gen Build (mini-Rant)

[Nighthawk117]

I am now on my 13500 - I made the Priority change to High. With this browser window open, only the 8 E cores are running Handbrake; the 12 threads associated with the 6 P cores are largely idle. Either the priority has no interaction with thread director or it doesn't take effect until the application is re-launched.

I'm not really sure how Thread Director works tbh.

Note - with your 10850K, YOU WILL NOT SEE THE ISSUE I"M DESCRIBING. The 10850K should be a great platform for Handbrake.

I realise that, what I was testing for was to see if High priority had any negative impact on my ability to use the PC while it was encoding.

FWIW - I only use the Handbrake GUI and encode in H265 10-bit preset Slower RF 19-21. My priority is quality followed by filesize - All my content is played on various 4K TVs (65" or larger) with 5.1 and higher audio systems from a media server. I'm happy to get an output file that is one-third the size of the original content. This fits my needs of never having to worry about quality and having 1200+ movies online.

That's a lot of movies, you must need a lot of storage. I use H.264 personally, I could use trimming down my file size though as I'm running short on hard drive space.

 

[Nighthawk117]

Good news - I've found a workaround that solves most of the issue.

I have a 27" 4K monitor so I can fit quite a bit on the screen.

If I keep the Handbrake Queue window partially visible, the system works normally.

Basically, if I open a browser full screen, Handbrake is immediately shuffled off to the E cores leaving the P cores idle and overall CPU usage drops to 45%.

If I reduce the browser window so most of the HB Queue window is visible, the system ramps back up to 90%+ CPU utilization.

It doesn't matter what keyboard centric work I'm doing in the alternative screens (browser, Word, Excel, Outlook, etc), Handbrake keeps humming along so long as a good portion of the Queue window is visible - doesn't need focus, just to be visible.

Quirky yes but I'll take it.

That's interesting you've found a solution. It would make me think twice though about what CPU to upgrade to next time. I don't know whether this would affect other applications as well. I don't know if your familiar with it, but I regularly use Topaz Labs Video AI to enhance videos encoded with Handbrake while I'm working. My CPU is heavily utilised while doing it to keep the GPU fed with data. If it was run on just E cores that may impact the rendering time. It might not be an issue on the top end chips that have so many of them, but it would perhaps make me gravitate towards AMD.

 

[wyliec2]

I realise that, what I was testing for was to see if High priority had any negative impact on my ability to use the PC while it was encoding.

I closed and reopened Handbrake after setting priority to High - it didn't seem to have any effect - on other interactive tasks or on the issue of throwing HB over to the E cores.

I switched back to Below Normal as that is the norm when running long, compute intensive tasks concurrent with interactive tasks requiring minimal resources. As long as I maintain the Queue window visibility, the system operates as expected.

That's a lot of movies, you must need a lot of storage. I use H.264 personally, I could use trimming down my file size though as I'm running short on hard drive space.

I've gone from storing all my movies as the original full ISO with menu to pared down ISO with only the movie and single audio track to mostly H264 and now re-encoding from the source to H265. Re-encoding to H265 is more of a hobby effort than to achieve significant file size reduction. On my 5950X, it may take 2 hourse to encode in H264 and 12 hours in H265 with the H265 file coming out 10-15% smaller. Not really worthwhile from a practical standpoint which is why I consider it a hobby endeavor. My server has 30 TB of storage.

Some people report significantly greater file size reductions with H265 - my theory on this is that H265 is more efficient at higher compression levels (lower quality) which I don't use. When using very high quality settings, less data is being thrown out and the respective output file sizes don't differ as much.

That's interesting you've found a solution. It would make me think twice though about what CPU to upgrade to next time. I don't know whether this would affect other applications as well. I don't know if your familiar with it, but I regularly use Topaz Labs Video AI to enhance videos encoded with Handbrake while I'm working. My CPU is heavily utilised while doing it to keep the GPU fed with data. If it was run on just E cores that may impact the rendering time. It might not be an issue on the top end chips that have so many of them, but it would perhaps make me gravitate towards AMD.

When doing searches on this issue, I found a user running 3D rendering having the exact same issue as I have with Handbrake. I suspect that any long-running, compute-intensive task will experience this behavior if other tasks are being used which hide the compute-intensive window.

You mentioned not seeing this issue in reviews – Reviews typically benchmark performance of a particular game or application. They intentionally report application performance without anything else running so they get comparative results. The issue here shows up in the real world user experience when you have long-running tasks and wish to do other activities while they run.

Now that I have a reasonable solution, I’m able to fully utilize the 13500 all-core performance. Keeping the requisite portion of the HB Queue window visible takes up only about 1/8 of my desktop and I can easily work around that. If you have an activity that requires full screen display, I’m not sure what a good option is aside from having two (or more) monitors where you can keep a portion of the Queue window visible.

Thanks for your suggestions and discussion!!

 

[TerryLaze]

If you have an activity that requires full screen display, I’m not sure what a good option is aside from having two (or more) monitors where you can keep a portion of the Queue window visible.

If you press the windows key + tab it opens the task view where you can create a new virtual desktop, try putting handbrake on a virtual desktop maximized and see if it keeps full speed when you are on the first/normal desktop.

 

[wyliec2]

If you press the windows key + tab it opens the task view where you can create a new virtual desktop, try putting handbrake on a virtual desktop maximized and see if it keeps full speed when you are on the first/normal desktop.

I just tried that but as soon as I go back to the first desktop the same thing happens - Handbrake is shifted off to E cores and P cores left idle.

Thanks for your suggestions by the way!!

FWIW here is a comment from the Handbrake forum:
---------
At least for Windows 11, it's the standard QOS applied to the processes.
When Handbrake is minimized, the load is moved only to e-cores, leaving the p-cores with nothing to do.
If you keep the windows application in foreground then the load will be shared across all threads.

Another option is to tweak Windows QOS scheduler setting the OS to disable the throttling of a single application (in this way it's possible to minimze Handbrake windows, continuing all p-cores and e-cores loaded)
powercfg /powerthrottling disable /path "c:\Program Files\HandBrake\HandBrake.Worker.exe"
powercfg /powerthrottling list
--------

If this works, I would think it would work for other applications too. I'll likely just stick with the keeping the Queue window partially visible.

 

[wyliec2]

Found a couple better methods to avoid Windows 11 throwing background tasks over to the E cores leaving the P cores unused:

1) Keep portion of the background task window visible - assumes the task has some sort of GUI. Previoously discussed.
2) Windows defaults to Balanced power plan - change this to Performance plan (I prefer Balanced as I want my PC's to sleep when not in use). This is an easy fix though and prevents the shift leaving P cores idle.
3) Run the application as Administrator - I like this one best of all.

My primary purpose was to solve for long-running (12+ hour) Handbrake encodes, however, I would think the above would work for any similar application/situation.

I no longer regret my 13th gen build!