Intel's Ivy Bridge: An HTPC Perspective
by Ganesh T S on April 23, 2012 12:01 PM EST- Posted in
- Home Theater
- Intel
- HTPC
- Ivy Bridge
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.
Facebook
Twitter
RSS
70 Comments
View All Comments
Midwayman - Wednesday, April 25, 2012 - link
Have you ever seen a 4k display on a uncompressed signal? The clarity is just astounding.I'm more concerned about the ability to deliver content with that kind of bandwidth requirements. We already get hdtv signals that are so compressed that they're barely better than a really really good SDTV signal.
MobiusStrip - Friday, April 27, 2012 - link
Most of what you see labeled "HD" (or variants thereof) is marketing bullshit. You're not getting HD when the bitrate is 3 megabits per second, especially when anything on the screen is moving.You can blow a VHS picture up to "HD" resolution, and it won't be HD. That's exactly what's happening in most consumer devices today.
"4K" is rapidly emerging as the next fraud. We'll see the same crap blown up to 3840 x whatever (barely even 4K by any standard), but containing 1K of real resolution if you're lucky.
The era of increasing quality is over, as consumers prove over and over that they don't care about quality.
A5 - Monday, April 23, 2012 - link
"Otherwise, the Ivy Bridge platform has everything that a HTPC user would ever need."I'd like an open-source (or at least) free encoder that supports QuickSync and not having to be picky with my DRAM purchase to use GPU-accelerated decoders before I say that.
Other than that, it seems to be good enough for the basic HTPC functionality - can't wait for the new i3s and Pentiums to see if the low-end parts are good enough!
ganeshts - Monday, April 23, 2012 - link
You can use GPU accelerated decoders even with DDR3-1333 DRAM. You need to go high speed / low latency only if you want rendering through madVR.Use QuickSync Decoder or DXVA2 Native in LAV or MPC Video Decoder + EVR-CP to get full decode and rendering acceleration without worry about the DRAM.
babgvant - Monday, April 23, 2012 - link
DVRMSToolbox (DTB) has included a QS capable transcoding solution for over a year. The main benefit to using it vs. the other retail options is that it supports EDL files during transcoding.DTB is FOSS, the QS dlls are just FSS.
A5 - Monday, April 23, 2012 - link
Cool stuff. Hadn't heard of your tool before today, I'll make sure to check it out when I get my HDHR Prime from Woot.shawkie - Monday, April 23, 2012 - link
I've experimented with madVR a bit but in the end the problems with playing back DVDs and Blu-rays with menus has so far stopped me from using it seriously. However, I've seen reports claiming that Ivy Bridge includes higher quality upscaling within Windows Media Player (as part of the EVR I suppose). Any evidence of this?ganeshts - Monday, April 23, 2012 - link
You can take a look at the PowerDVD chroma upscaling screenshots linked in the text. I was really surprised at the quality (until I zoomed to 300%, I couldn't actually decipher the difference between PowerDVD and madVR!). Similar behavior with MPC-HC using MPCVideoDec.Btw, can you link me to the reports that you mention?
shawkie - Monday, April 23, 2012 - link
http://www.intel.com/content/www/us/en/architectur...This was one of them. I also found a comment from one of the engineers that explained that they were using a higher quality upsampling algorithm too but I can't find it now.
ganeshts - Monday, April 23, 2012 - link
Andrew @ MissingRemote just refreshed my memory about this post by Eric Gur: http://forum.doom9.org/showthread.php?p=1551981#po...