Advanced HTPC users adopt specialized renderers such as madVR which provide better quality when rendering videos. Unlike the standard EVR-CP (Enhanced Video Renderer-Custom Presenter) which doesn't stress the GPU much, renderers like madVR are very GPU-intensive. This has often been the sole reason for many HTPC users to go in for NVIDIA or AMD cards for their HTPC. Traditionally, Intel GPUs have lacked the performance necessary for madVR to function properly (particularly with high definition streams). We did some experiments to check whether Ivy Bridge managed some improvements.

Using our testbed with the 4 GB of DRAM running at DDR3-1333 9-9-9-24, we took one clip each of 1080i60 H.264, 1080i60  VC-1, 1080i60 MPEG-2, 576i50 H.264, 480i60 MPEG-2 and 1080p60 H.264. We tabulated the CPU and GPU usage using various combinations of decoders and renderers. It is quite obvious that using madVR tends to drive up the CPU usage compared to pure DXVA mode (with EVR-CP renderer). This is because the CPU needs to copy back the data to the system memory for madVR to execute the GPU algorithms. A single star against the GPU usage indicates between 5 - 10 dropped frames in a 3 minute duration. Double stars indicate that the number of dropped frames was high and that the dropping of the frames was clearly visible to the naked eye.

  DDR3-1333 [ 9-9-9-24 ]
  madVR 0.82.5 EVR-CP 1.6.1.4235
  QuickSync
Decoder
DXVA2
Copy-Back
DXVA2
(SW Fallback)
DXVA2 QuickSync
Decoder
  CPU GPU CPU GPU CPU GPU CPU GPU CPU GPU
480i60
MPEG-2
3 74 3 74 4 74 5 28 5 28
576i50
H.264
3 59 3 58 4 58 5 25 5 27
1080i60
H.264
14 86** 11 86** 14 81* 6 42 8 48
1080i60
VC-1
13 84** 13 80* 13 80* 13 47 8 47
1080i60
MPEG-2
12 82** 12 80** 9 78** 5 44 9 48
1080p60
H.264
18 97* 20 97** 18 96** 5 44 12 50

With DDR3-1333, it is evident that 1080i60 streams just can't get processed through madVR without becoming unwatchable. Memory bandwidth constraints are quite problematic for madVR. So, we decided to overclock the memory a bit, and got the G.Skill ECO RAM running at DDR3-1600 without affecting the latency. Of course, we made sure that the system was stable running Prime95 for a couple of hours before proceeding with the testing. With the new memory configuration, we see that the GPU usage improved considerably, and we were able to get madVR to render even 1080p60 videos without dropping frames.

  DDR3-1600 [ 9-9-9-24 ]
  madVR 0.82.5 EVR-CP 1.6.1.4235
  QuickSync
Decoder
DXVA2
Copy-Back
DXVA2
(SW Fallback)
DXVA2 QuickSync
Decoder
  CPU GPU CPU GPU CPU GPU CPU GPU CPU GPU
480i60
MPEG-2
2 76 2 76 2 73 5 27 5 27
576i50
H.264
2 57 2 57 3 57 5 25 5 24
1080i60
H.264
7 77 11 74 12 74 6 40 9 40
1080i60
VC-1
7 76 11 75 12 79 12 40 8 40
1080i60
MPEG-2
6 74 6 74* 8 75* 5 39 9 40
1080p60
H.264
13 82 14 84 14 80 6 41 10 42

However, the 5 - 10 dropped frames in the 1080i60 MPEG-2 clip continued to bother me. I tried to overclock G.Skill's DDR3-1600 rated DRAM, but was unable to reach DDR3-1800 without sacrificing latency. With a working configuration of DDR3-1800 12-12-12-32, I repeated the tests, but found that the figures didn't improve.

  DDR3-1800 [ 12-12-12-32 ]
  madVR 0.82.5 EVR-CP 1.6.1.4235
  QuickSync
Decoder
DXVA2
Copy-Back
DXVA2
(SW Fallback)
DXVA2 QuickSync
Decoder
  CPU GPU CPU GPU CPU GPU CPU GPU CPU GPU
480i60
MPEG-2
2 75 2 75 2 72 5 27 5 27
576i50
H.264
2 57 2 57 3 57 5 25 5 24
1080i60
H.264
7 74 11 73 12 74 6 39 9 40
1080i60
VC-1
7 74 11 74 12 77 12 39 8 40
1080i60
MPEG-2
6 74 6 74* 8 74* 5 39 9 40
1080p60
H.264
12 84 14 84 14 80 6 41 10 42

My inference is that a low memory latency is as important as high bandwidth for madVR to function effectively. I am positive that with a judicious choice of DRAM, it is possible to get madVR functioning flawlessly with the Ivy Bridge platofrm. Of course, more testing needs to be done with other algorithms, but the outlook is quite positive.

In all this talk about madVR, let us not forget the efficient QuickSync / native DXVA2 decoders in combination with EVR-CP. With low CPU usage and moderate GPU usage, these combinations deliver satisfactory results for the general HTPC crowd.

Custom Refresh Rates Acceleration for Flash and Silverlight
Comments Locked

70 Comments

View All Comments

  • ganeshts - Tuesday, April 24, 2012 - link

    The FSE mode performed visibly worse for me compared to FSW in the few cases that I tried. I have got the rest of the settings that Andrew @ MR used. I may try it and see if it improves things. My aim was to get madVR to render without any dropped frames, and I was able to get that at DDR3-1600 (which is what Andrew used too) for almost all the clips I had (except 720p60, which I didn't try till yesterday).
  • satish0072001 - Tuesday, April 24, 2012 - link

    Video decoding and rendering benchmarks
    Can you provide the learning guide how you've got those scores? It will be very helpful for some of us... I know about hqv score.. but this one is new to me.. kindly help :)
    From where can I get these benchmarks if i have to compare my existing system with the IVB results?
  • LuckyKnight - Tuesday, April 24, 2012 - link

    In the article there is a promise of a BIOS update to fix the 23.97Hz issue. Wasn't something similar also promised for sandy bridge in the same article over a year ago!! That never happened did it. I want to build a HTPC already!
  • ganeshts - Tuesday, April 24, 2012 - link

    Well, something did happen with SNB.. they got it to 23.972 Hz :) If you think about it, video cards with AMD and NVIDIA GPUs also end up in the 23.974 - 23.978 range, and only very rarely do I actually see a GPU outputting exactly 23.976023976 Hz.

    If Intel gets between 23.974 - 23.978 in a stable manner, I will consider the matter closed.
  • Shaggie - Thursday, April 26, 2012 - link

    Is there still the problem like with SB that the driver puts color space to limited range when connecting to the tv with HDMI and resets it with every refresh rate switch/reboot with the integrated graphics?
  • Stabgotham - Monday, April 30, 2012 - link

    Is there a point to getting an H77 board with Ivy Bridge if all you are using it for is as an HTPC (sans overclock)? I can't tell what the benefit would be to justify the price increase.
  • crisliv - Wednesday, June 13, 2012 - link

    Nice article! As always.
    About the note:
    "The good news is that Intel is claiming that this issue is fully resolved in the latest production BIOS on their motherboard. This means that BIOS updates to the current boards from other manufacturers should also get the fix. Hopefully, we should be able to independently test and confirm this soon."

    What does it mean exactly? Does it mean that this BIOS update should get refresh rate closer to the 23.976 than it was in your test? And "on their motherboard" - does it mean that this BIOS update is for Intel MB only?

    True that in AMD and nVidia the out of the box refresh rate for 23 is never precisely 23.976, but the custom timings on nVidia allows you to get closer to is. There is no custom timing settings on the HD4000, right?
  • LuckyKnight - Thursday, June 14, 2012 - link

    Do we have an update regarding 23.967hz?
  • theboyknowsclass - Tuesday, July 24, 2012 - link

    it's been a while, and couldn't find any follow up
  • Hdale85 - Thursday, August 23, 2012 - link

    I've been looking at an Ivy Bridge setup with the H77/Z77 chipset but I can't find any information about the audio support? Can it bitstream TrueHD and DTS-HD tracks? The older chipsets do it so I would find it strange that the new ones don't, but I don't see it mentioned on any of the new boards or in the intel information.

Log in

Don't have an account? Sign up now