The Sandy Bridge Review: Intel Core i7-2600K, i5-2500K and Core i3-2100 Tested
by Anand Lal Shimpi on January 3, 2011 12:01 AM ESTA Near-Perfect HTPC
Since 2006 Intel’s graphics cores have supported sending 8-channel LPCM audio over HDMI. In 2010 Intel enabled bitstreaming of up to eight channels of lossless audio typically found on Blu-ray discs via Dolby TrueHD and DTS-HD MA codecs. Intel’s HD Graphics 3000/2000 don’t add anything new in the way of audio or video codec support.
Dolby Digital, TrueHD (up to 7.1), DTS, DTS-HD MA (up to 7.1) can all be bitstreamed over HDMI. Decoded audio can also be sent over HDMI. From a video standpoint, H.264, VC-1 and MPEG-2 are all hardware accelerated. The new GPU enables HDMI 1.4 and Blu-ray 3D support. Let’s run down the list:
Dolby TrueHD Bitstreaming? Works:
DTS HD-MA bitstreaming? Yep:
Blu-ray 3D? Make that three:
How about 23.976 fps playback? Sorry guys, even raking in $11 billion a quarter doesn’t make you perfect.
Here’s the sitch, most movie content is stored at 23.976 fps but incorrectly referred to as 24p or 24 fps. That sub-30 fps frame rate is what makes movies look like, well, movies and not soap operas (this is also why interpolated 120Hz modes on TVs make movies look cheesey since they smooth out the 24 fps film effect). A smaller portion of content is actually mastered at 24.000 fps and is also referred to as 24p.
In order to smoothly playback either of these formats you need a player and a display device capable of supporting the frame rate. Many high-end TVs and projectors support this just fine, however on the playback side Intel only supports the less popular of the two: 24.000Hz.
This isn’t intentional, but rather a propagation of an oversight that started back with Clarkdale. Despite having great power consumption and feature characteristics, Clarkdale had one glaring issue that home theater enthusiasts discovered: despite having a 23Hz setting in the driver, Intel’s GPU would never output anything other than 24Hz to a display.
The limitation is entirely in hardware, particularly in what’s supported by the 5-series PCH (remember that display output is routed from the processor’s GPU to the video outputs via the PCH). One side effect of trying to maintain Intel’s aggressive tick-tock release cadence is there’s a lot of design reuse. While Sandy Bridge was a significant architectural redesign, the risk was mitigated by reusing much of the 5-series PCH design. As a result, the hardware limitation that prevented a 23.976Hz refresh rate made its way into the 6-series PCH before Intel discovered the root cause.
Intel had enough time to go in and fix the problem in the 6-series chipsets, however doing so would put the chipset schedule at risk given that fixing the problem requires a non-trivial amount of work to correct. Not wanting to introduce more risk into an already risky project (brand new out of order architecture, first on-die GPU, new GPU architecture, first integrated PLL), Intel chose to not address it this round, which is why we still have the problem today.
Note the frame rate
What happens when you try to play 23.976 fps content on a display that refreshes itself 24.000 times per second? You get a repeated frame approximately every 40 seconds to synchronize the source frame rate with the display frame rate. That repeated frame appears to your eyes as judder in motion, particularly evident in scenes involving a panning camera.
How big of an issue this is depends on the user. Some can just ignore the judder, others will attempt to smooth it out by setting their display to 60Hz, while others will be driven absolutely insane by it.
If you fall into the latter category, your only option for resolution is to buy a discrete graphics card. Currently AMD’s Radeon HD 5000 and 6000 series GPUs correctly output a 23.976Hz refresh rate if requested. These GPUs also support bitstreaming Dolby TrueHD and DTS-HD MA, while the 6000 series supports HDMI 1.4a and stereoscopic 3D. The same is true for NVIDIA’s GeForce GT 430, which happens to be a pretty decent discrete HTPC card.
Intel has committed to addressing the problem in the next major platform revision, which unfortunately seems to be Ivy Bridge in 2012. There is a short-term solution for HTPC users absolutely set on Sandy Bridge. Intel has a software workaround that enables 23.97Hz output. There’s still a frame rate mismatch at 23.97Hz, but it would be significantly reduced compared to the current 24.000Hz-only situation.
MPC-HC Compatibility Problems
Just a heads up. Media Player Classic Home Cinema doesn't currently play well with Sandy Bridge. Enabling DXVA acceleration in MPC-HC will cause stuttering and image quality issues during playback. It's an issue with MPC-HC and not properly detecting SNB as far as I know. Intel has reached out to the developer for a fix.
Facebook
Twitter
RSS
283 Comments
View All Comments
dgingeri - Monday, January 3, 2011 - link
I have a really good reason for X58: I/OI have 2X GTX 470 video cards and a 3Ware PCIe X4 RAID controller. None of the P67 motherboards I've seen would handle all that hardware, even with cutting the video cards' I/O in half.
This chip fails in that one very important spot. if they had put a decent PCIe controller in it, with 36 PCIe lanes instead of 16, then I'd be much happier.
Exodite - Monday, January 3, 2011 - link
That's exactly why this is the mainstream platform, while x58 is the enthusiast one, though. Your requirements aren't exactly mainstream, indeed they are beyond what most enthusiasts need even.sviola - Monday, January 3, 2011 - link
You may want to look at the Gigabyte GA-P67A-UD5 and GA-P67A-UD7 as they can run your configuration.Nihility - Monday, January 3, 2011 - link
Considering the K versions of the CPUs don't have it.If I'm a developer and use VMs a lot, how important will VT-d be within the 3-4 years that I would own such a chip?
I know that it basically allows direct access to hardware and I don't want to get stuck without it, if it becomes hugely important (Like how you need VT-x to run 64 bit guests).
Any thoughts?
code65536 - Monday, January 3, 2011 - link
My question is whether or not that chart is even right. I'm having a hard time believing that Intel would disable a feature in an "enthusiast" chip. Disabling features in lower-end cheaper chips, sure, but in "enthusiast" chips?! Unless they are afraid of those K series (but not the non-K, apparently?) cannibalizing their Xeon sales?has407 - Monday, January 3, 2011 - link
Relatively unimportant IMHO if you're doing development. If you're running a VM/IO-intensive production workload (which isn't likely with one of these), then more important.Remember, you need several things for Vt-d to work:
1. CPU support (aka "IOMMU").
2. Chip-set/PCH support (e.g., Q57 has it, P57 does not).
3. BIOS support (a number of vendor implementations are broken).
4. Hypervisor support.
Any of 1-3 might result in "No" for the K parts. Even though it *should* apply only to the CPU's capabilities, Intel may simply be saying it is not supported. (Hard to tell as the detailed info isn't up on Intel's ark site yet, and it would otherwise require examining the CPU capability registers to determine.)
However, it's likely to be an intentional omission on Intel's part as, e.g., the i7-875K doesn't support Vt-d either. As to why that might be there are several possible reasons, many justifiable IMHO. Specifically, the K parts are targeted at people who are likely to OC, and OC'ing--even a wee bit, especially when using VT-d--may result in instability such as to make the system unusable.
If Vt-d is potentially important to you, then I suggest you back up through steps 4-1 above; all other things equal, 4-2 are likely to be far more important. If you're running VM/IO-intensive workloads where performance and VT-d capability is a priority, then IMHO whether you can OC the part will be 0 or -1 on the list of priorities.
And while VT-d can make direct access to hardware a more effective option (again, assuming Hypervisor support), it's primary purpose is to make all IO more efficient in a virtualized environment (e.g., IOMMU and interrupt mapping). It's less a matter of "Do I have to have it to get to first base?" than "How much inefficiency am I willing to tolerate?" And again, unless you're running IO-intensive VM workloads in a production environment, the answer is probably "The difference is unlikely to be noticeable for the work [development] I do."
p.s. code65536 -- I doubt Intel is concerned with OC'd SB parts cannibalizing Xeon sales. (I'd guess the count of potentially lost Xeon sales could be counted on two hands with fingers to spare.:) Stability is far more important than pure speed for anyone I know running VM-intensive loads and, e.g., no ECC support on these parts is for me deal killer. YMMV.
DanNeely - Tuesday, January 4, 2011 - link
For as long as MS dev tools take to install, I'd really like to be able to do all my dev work in a VM backed up to the corporate lan to ease the pain of a new laptop and to make a loaner actually useful. Unfortunately the combination of lousy performance with MS VPC, and the inability of VPC to run two virtual monitors of different sizes mean I don't have a choice about running visual studio in my main OS install.mino - Wednesday, January 5, 2011 - link
VMware Workstation is what you need. VPC is for sadists.Even if your budget is 0(zero), and VPC is free, KVM/QEMU might be a better idea.
Also, Hyper-V locally and (via RDP) is pretty reasonable.
cactusdog - Monday, January 3, 2011 - link
If we cant overclock the chipset how do we get high memory speeds of 2000Mhz+? Is there still a QPI/Dram voltage setting?Tanel - Monday, January 3, 2011 - link
No VT-d on K-series? FFFFUUUU!So just because I want to use VT-d I'll also be limited to 6 EUs and have no possibility to overclock?
Then there's the chipset-issue. Even if I got the enthusiast targeted K-series I would still need to get the:
a) ...H67-chipset to be able to use the HD-unit and QS-capability - yet not be able to overclock.
b) ...P67-chipset to be able to overclock - yet to lose QS-capability and the point of having 6 extra EUs as the HD-unit can't be used at all.
What the hell Intel, what the hell! This makes me furious.