Support us on Patreon: https://www.patreon.com/hardwareunboxedJoin us on Floatplane: https://www.floatplane.com/channel/HardwareUnboxedBuy relevant products ...
The example you chose is a terrible one, as for those that dont know that behavior is INTENDED by the Handbrake developers, This has been a known thing since Alder Lake’s launch. The developers didnt ever want Handbrake to use 100% of your system, so its flagged as a low priority process so you can still use your PC without it being lagged out while encoding. So the scheduler sees that and will free up the P-cores when you put another window in focus, so you can use your system without lag, while the e-cores encode in the background.
If you go through the github you’ll see the developers tell people they can override this manually, but the current implementation is exactly how its supposed to work.
You cant blame Thread Director or Windows scheduling for this specific case with Handbrake as its what the developers intended.
The example you chose is a terrible one, as for those that dont know that behavior is INTENDED by the Handbrake developers, This has been a known thing since Alder Lake’s launch. The developers didnt ever want Handbrake to use 100% of your system, so its flagged as a low priority process so you can still use your PC without it being lagged out while encoding. So the scheduler sees that and will free up the P-cores when you put another window in focus, so you can use your system without lag, while the e-cores encode in the background.
If you go through the github you’ll see the developers tell people they can override this manually, but the current implementation is exactly how its supposed to work.
You cant blame Thread Director or Windows scheduling for this specific case with Handbrake as its what the developers intended.