The Real Conroe Successor: Clarkdale & All You Need to Know about Westmere
by Anand Lal Shimpi on September 24, 2009 6:00 PM EST- Posted in
- CPUs
Bitstreaming TrueHD/DTS-HD MA: Yep, Here too
The Radeon HD 5870 was the first graphics card to properly support bitstreaming of high definition Blu-ray audio codecs. Clarkdale/Arrandale is the second.
These CPUs come with an on-package GPU and that GPU supports the appropriate protected audio path to enable bitstreaming of Dolby TrueHD and DTS-HD MA. Of course 8-channel LPCM output is also still an option.
If you remember the G45 launch, Intel had serious issues enabling 8-channel LPCM output, HDCP and H.264 decode acceleration in general. I grilled Intel on what was going to make this round different and they are much more confident in their abilities.
They've increased the number of receivers they test with (originally it was at a whopping two, now they're up to…7). They've also expanded their test scenarios as well. The combination of the two, Intel believes, will result in a fully functional set of HTPC features at launch.
The first time I went by Intel's Clarkdale demo, Intel couldn't get bitstreaming working. A day later I got an email telling me to drop by again - they fixed it.
I got to see TrueHD bitstreaming from a Clarkdale system to a Sony receiver. I also confirmed that full two stream decode acceleration was working:
Intel had it working with Arcsoft's player, but is working with all of the major software vendors to hopefully enable full support on everything. Intel does seem to be taking this much more seriously than with G45.
The Clarkdale launch is still a couple of months away so there is definitely time for Intel to work out the kinks.
This is a serious feature. The fact is that in a couple of years every single PC shipped will have the ability to bitstream these audio codecs without any additional hardware. We're finally getting there folks.
Facebook
Twitter
RSS
96 Comments
View All Comments
mczak - Thursday, September 24, 2009 - link
Hmm, clarkdale beating c2q in specfp:"You can see that thanks to a competitive clock speed, aggressive turbo modes and Hyper Threading the 3.33GHz Clarkdale outperforms both the Q9400 and the E8500."
I'll fix this for you:
"Thanks to the low memory bandwidth available to the c2q due to FSB limitations, c2q scales terribly and is hardly any faster than c2d which allows clarkdale to beat c2q"...
Still, performance is certainly solid. There's no way however that Clarkdale will beat this core 2 quad in more typical multithreaded applications which aren't as bandwidth limited as specfp, for instance video encoding. But at least it will be somewhat close.
CajunArson - Saturday, September 26, 2009 - link
Wow, I'm so glad you are such a genius and are correcting those dumb Anandtech guys who waste all their time researching and benchmarking CPU technology! [/sarcasm]Seriously, the FSB has never been a bottleneck on consumer systems, particularly on notebooks where the CPU is not clocked up the wazoo to begin with. The FSB was a limitation in 2+ socket systems which is why Nehalem came out... as Anand and many others pointed out when Nehalem was new, the primary reason for abandoning the FSB was that it did not scale to multiple CPU sockets. Now the point-to-point architecture is superior, but it's like having 200mph racing tires on a car that can't take advantage of them anyway: nice to have, but they don't make you any faster.
Just go back and look at the original benchmarks of the supposedly "superior" Barcelona when it came out: Using an on-die L3 cache to transfer data between cores on Barcelona was a blazing 2% (yes two whole percent) faster than the quad-core desktop conroes swapping data over the FSB... not much of a bottleneck.
mczak - Sunday, September 27, 2009 - link
I'm not saying FSB is really that much of a bottleneck on consumer systems, the problem is that IN THIS SPECIFIC CASE with specFP it is (of course, specfp isn't exactly relevant for consumer systems) indeed a problem. Hence clarkdale with its two cores will not, as specfp would indicate, beat c2q in more typical multithreaded workloads.Merely pointing out the comment about why clarkdale is faster than c2q in specFP indeed is bogus - sure clock rate, turbo (not much as specfp rate will use 4 threads) etc. help but fact is this would give the impression that clarkdale could achieve c2q performance which it will not (for multithreaded workloads) unless they are heavily memory limited like specfp, which is unlikely. Not that this is really a bad thing as that would be too good to be true anyway (the core of a core2 duo and clarkdale is very similar so this would be very much a miracle indeed).
Inkie - Saturday, October 3, 2009 - link
PCMark Vantage comparitive scores are even better than SFP...GeorgeOu - Saturday, September 26, 2009 - link
"Thanks to the low memory bandwidth available to the c2q due to FSB limitations, c2q scales terribly and is hardly any faster than c2d which allows clarkdale to beat c2q"...Even a Core 2 quad no matter the GHz with a single socket isn't going to flood a north bridge controller and the FSB. Even a sub 2 GHz dual-socket Harpertown quad-core isn't really hitting the FSB/NB wall for the most part. Where Intel gets into trouble with the FSB is when they're running two sockets with two high clocked quad-cores.
mczak - Saturday, September 26, 2009 - link
That's generally true but not in all cases. In fact you can easily see some performance degradation even with dual-cores (the pentiums with only 800Mhz FSB) with specific apps (or of course any synthetic memory benchmark) so it's not surprising to see this issue come up with specfp. Fact is, if you've got enough memory bandwidth, specFP rate should scale perfectly with core count. According to results published at spec.org, a C2D E8400 scores ~30. A C2Q QX9650 (same clock) scores ~45. Clearly, that's not good scaling, and AFAIK this is solely due to lack of memory (or rather FSB) bandwidth.It is incorrect to say the cpu isn't going to saturate the FSB. Even a 2Ghz C2D can already do that very easily as any memory benchmark will show, thankfully most applications aren't really in need of that much memory bandwidth, but specFP IS a memory bandwidth hog.
mdbusa - Thursday, September 24, 2009 - link
I dont know about anyone else but I am thoroughly confused by all the different nomenclature used by intel. We have thees nams clarksdale, etc... then we have chip names? I5, i7 etc...., then we have 45 nm etc. P55 etc. blah blahNow ill go read the article
SenorB - Saturday, September 26, 2009 - link
Just guessing, but note that Field = 4, Dale = 2. Cloverfield was a quad-core proc too (before it was a monster movie).SenorB - Saturday, September 26, 2009 - link
My bad, it was Clovertown, not Cloverfield. Still, I always thought it was a sly little joke on Intel's part: quad core, clover... or am I giving them too much credit?the zorro - Friday, September 25, 2009 - link
intel graphics?no thanks.