Intel's Ivy Bridge: An HTPC Perspective

Intel provided us with a Core i7-3770K processor and Asus was kind enough to supply the HTPC friendly P8H77-M Pro motherboard for our test drive. Purists might balk at the idea of an overclockable 77W TDP processor being used in tests intended to analyze the HTPC capabilities. However, the Core i7-3770K comes with Intel HD Graphics 4000, the highest end GPU in the Ivy Bridge lineup. Using this as the review platform gives readers an understanding of the maximum HTPC capabilities of the Ivy Bridge lineup.

The table below presents the hardware components of our Ivy Bridge HTPC testbed:

The Asus P8H77-M PRO makes for a nice HTPC / general purpose board for consumers not interested in overclocking their CPU. It also has two PCI-E x16 slots (one operating in x16 with PCI-E 3.0, and the other in x4 with PCI-E 2.0) and two PCI-E x1 slots for those interested in adding gaming cards or TV tuners / video capture cards.

Readers might wonder about the two different flavours of DRAM being used in the testbed. It must be noted that at any given point of time, only one of the flavours was being used.

As readers will see in a later section, it is possible that the memory bandwidth and latency can play a very important role in the video post processing performance. Towards this, we actually ran our decode / post processing tests with three distinct configurations. The ECO modules were run at DDR3 1333 (9-9-9-24) and also at DDR3 1600 (9-9-9-24). The Ripjaws Z modules were overclocked to DDR3 1800 (12-12-12-32). The ability to overclock the G.Skill DRAM modules was quite useful in trying to find some insights into the effect of memory bandwidth and latency on video post processing using the integrated GPU.

The software setup for the Ivy Bridge HTPC testbed involved the following:

The madVR renderer settings were fixed as below for testing purposes:

1. Decoding features disabled
2. Deinterlacing set to:
   • automatically activated when needed (activate when in doubt)
   • automatic source type detection (i.e, disable automatic source type detection is left unchecked)
   • only look at pixels in the frame center
   • be performed in a separate thread
3. Scaling algorithms were set as below:
   • Chroma upscaling set to default (SoftCubic with softness of 100)
   • Luma upscaling set to default (Lanczos with 4 taps)
   • Luma downscaling set to default (Lanczos with 4 taps)
4. Rendering parameters were set as below:
   • Start of playback was delayed till the render queue filled up
   • A separate device was used presentation, and D3D11 was used
   • CPU and GPU queue sizes were set to 32 and 24 respectively
   • Under windowed mode, the number of backbuffers was set to 8, and the GPU was set to be flushed after intermediate render steps as well as the last render step. In addition, the GPU was set to wait (sleep) after the last render step.

Exclusive mode settings were not applicable to our testbed, because we found the full screen exclusive mode to be generally bad in performance compared to the full screen windowed mode. Also, none of the options to trade quality for performance were checked.