Getting the Best out of an Ivy Bridge HTPC: Windows 8, madVR and More..

HTPC Decoding and Rendering Benchmarks: EVR / EVR-CP

In our Ivy Bridge HTPC review, we had covered the CPU / GPU utilization during playback of various types of clips. In the Vision3D 252B review, we had graphs of CPU and GPU loading with various renderers and codecs. Unfortunately, AMD doesn't provide similar data / sensors for use with their APUs. Hence, we had to resort to power consumed at the wall along with GPU loading in the Trinity HTPC review. In order to keep benchmarking consistent across all HTPC reviews, we started adopting the Trinity HTPC review methodology starting with the review of the ASRock Vision HT.

The tables below present the results of running our HTPC rendering benchmark samples through various decoders when using the Enhanced Video Renderer / Enhanced Video Renderer (Custom Presenter) (EVR / EVR-CP). Entries in bold indicate that there were dropped frames which indicate that the unit wasn't up to the task for those types of streams. Fortunately, none of the streams presented any problem to the system and there were no dropped frames. The recorded values include the GPU loading and power consumed by the system at the wall when playing back the streams using MPC-HC v1.6.5.6366 and LAV Filters 0.54.

Enhanced Video Renderer (EVR)

The Enhanced Video Renderer is the default renderer made available by Windows 8. It is a lean renderer in terms of usage of system resources since most of the aspects are offloaded to the GPU drivers directly. EVR is mostly used in conjunction with native DXVA2 decoding.

The GPU is not taxed much by the EVR despite hardware decoding also taking place. Deinterlacing and other post processing aspects were left at the default settings in the Intel HD Graphics Control Panel (and these are applicable when EVR is chosen as the renderer)

Enhanced Video Renderer - Custom Presenter (EVR-CP)

EVR-CP is the default renderer used by MPC-HC. It is usually used in conjunction with MPC-HC's video decoders, some of which are DXVA-enabled. However, for our tests, we used the DXVA2 mode provided by the LAV Video Decoder.

In addition to DXVA2 Native, we also used the QuickSync decoder developed by Eric Gur (an Intel applications engineer) and made available to the open source community. It makes use of the specialized decoder blocks available as part of the QuickSync engine in the GPU.

In general, using the QuickSync decoder results in a higher power consumption because the decoded frames are copied back to the DRAM before being sent to the renderer. Using native DXVA decoding, the frames are directly passed to the renderer without the copy-back step. The odd-man out in the power numbers is the interlaced VC-1 clip, where QuickSync decoding is around 5W more efficient compared to 'native DXVA2'. This is because there is currently no support in the open source native DXVA2 decoders for interlaced VC-1, and hence,  it is done in software [Clarification: This restriction is only on Intel GPUs. On both AMD and NVIDIA cards, DXVA2 native decode acceleration is supported for all VC-1 streams]. On the other hand, the QuickSync decoder is able to handle it with the VC-1 bitstream decoder in the GPU.