Interference Between QuickSync/VAAPI encoding and CPU

[William_K_2]

Hello,

I have an interesting issue on my research system with a Xeon E3-1285LV4. I am comparing various H.264 encoders, including the QuickSync encoder in this chip (using VAAPI), and the x264 software encoder. All testing is through GStreamer plugins.

I am seeing some "interesting" behavior when turboboost is enabled, and am trying to explain it.

- When transcoding the same movie/segment repeatedly, I see repeatable performance, both on VAAPI and x264. This is as expected.
- When a VAAPI transcoder is run *simultaneously* with x264, the x264 encode slows down slightly (expected, as the VAAPI encode is using some cycles to keep buffers full).
- When turboboost is disabled, the VAAPI encode always takes the same amount of time, regardless of how busy the CPU is with the x264.
- When turboboost is enabled, the CPU activity actually slows down the VAAPI encode.

Any idea what could be causing this? Is it some sort of power gating to the QuickSync unit? Insight would be much appreciated.

Thanks!
-Bill Katsak

[Surbhi_M_Intel]

Hi William, 

Glad to know you are testing some of the h264 encoders available publicly. The comparison you are making is between x264 software encoder vs vaapi hardware accelerated encoder (open source driver not same as Media SDK, Media SDK/Media Server Studio uses Intel iHD/i915 closed source driver). Experts from Intel on this forum can provide advice on i915/iHD driver here. 
For vaapi support, please contact this forum - https://01.org/linuxgraphics/community/vaapi 

My understanding - when turboboost is enabled, system is working on higher frequency which is shared btw CPU and GPU and if both are fully loaded for cases like streaming, gaming. turbo boost automatically figures out the optimized solution to get the best performance which in your case is slowing the VAAPI encode. I will suggest to check with VAAPI experts on above forum. 

Thanks,
Surbhi