Intel and Nvidia are still sitting in a tree in their war of facts and friction. This time, Intel snaps back by saying video encoding is better on the CPU.
Last night over dinner here in Taipei, Intel said that video encoding has always been a task designed for the CPU – and nothing will change that in the future.
We were talking about CUDA and how Nvidia’s claimed massive performance increases could potentially change the paradigm for software developers, especially with industry heavyweights like Adobe already on-board.
Intel’s representatives said that DivX uses the CPU to dynamically adjust detail across the scene to ensure that detailed areas of scenes have the detail they require.
“
When you’re encoding on the CPU, the quality will be higher because we’re determining which parts of the scene need higher bit-rates applying to them,” said François Piednoel, senior performance analyst at Intel.
Piednoel claimed that the CUDA video encoder will likely deliver poor quality video encodes because it uses a brute force method of splitting the scene up and treating each pixel the same. It’s interesting that Intel is taking this route, because one thing Nvidia
hasn’t really talked about so far is video quality.
“
The science of video encoding is about making smarter use of the bits and not brute force,” added Piednoel.
I asked Piednoel what will happen when Larrabee turns up because that is, after all, a massively parallel processor. I thought it’d be interesting to see if Intel would change its tune in the future once it had something that had the raw processing power to deliver similar application performance to what is being claimed with CUDA. Intel said that comparing this to a GPU is impossible, because the GPU doesn’t have full x86 cores. With CUDA, you can only code programs in C and C++, while x86 allows the developer to choose whatever programming language they prefer – that’s obviously a massive boon to anyone that doesn’t code in C.
Intel claimed that not every developer understands C or C++ – while that may be true to an extent, anyone that has done a Computer Science degree is likely to have learned C at some point in their careers, as the first language I learned during my Computer Science degree was, you guessed it, C. And, after learning procedural programming in C, I then applied the knowledge I gained from that to then learn to write procedural programs in other languages.
What’s more, Intel said that GPUs aren’t very good at branching and scheduling, while the execution units themselves are suited only to graphics processing – this was something I disagreed with rather vocally, because not only are today’s GPUs handling tens of thousands of threads at once, they’re also designed to be very good at branching, as it’s a part of the spec for both major graphics APIs. And that technology
definitely isn’t limited to just working in graphics workloads. From what I can make of this, Intel believes that the stream processing units in AMD’s and Nvidia’s latest graphics architectures are too dumb and not accurate enough to do anything other than push pixels – and I guess that’s why Intel is using fully functional x86 cores in its Larrabee architecture.
What do you make of all of this? Share your thoughts
in the forums.
I have an AMD CPU, and one thing that makes me cringe is other AMD users defending themselves from Intel fans by claiming that AMD 'feels smoother'. It's patently ridiculous. And before I can see some sort of tangible proof of this, this seems like just that from a different perspective.
With Photoshop soon to be nVidia-powered, and (gasp!) even a Folding@Home client on the way, let's judge the actual results.
But think about it - Adobe's Photoshop is one of the best in its class, used by image pros everywhere - why would Adobe include nVidia acceleration if it produced poor-quality pics? Can anyone tell me why a Premiere accelerator would be any different?
Intel's strategy through this entire fight has been to compare current nVidia and ATI technology to future Intel tech. (And to misrepresent current GPU tech to begin with) When they finally do release Larrabee, CUDA will have even more force behind it and even ATI cards will have jumped radically ahead of what Intel has projected.
Long story short, Intel will succeed in making their products better at doing the things they are already good at, and they'll get nowhere near pushing nVidia or ATI out of their established markets. Too bad they will have wasted time trying.
Exactly. It is like claiming that current cars are nothing compared to future flying cars. Has anyone seen Larrabee-accelerated Photoshop? Or Premiere? Or Final Cut?
Anyway, videos are made of pixels AND frames. If it splitting the frame into pixels yields "poor" results, why not send a whole frame to each stream processor?
That said, there is no reason why you can't use the CPU for the analysis and the GPU for the brute force required to run the compression algorithms afterwards. I don't see how Intel can justify a statement that the image quality of GPU encoded video will necessarily be inferior.
I'm nothing more than an amateur coder, but I personally wouldn't imagine there are many professional developers who don't have a grasp of C..
badders +1
How about GPULib, a library of mathematical functions for Very High Level Languages (Java, Python, MATLAB, IDL)?
My guess is that more examples like this will follow, that will allow the use of CUDA with Very High Level Languages (I use Perl a lot, so I would definitely make use of a "CUDA extension"...).
Moreover, here's a crazy thought: couldn't nVIDIA develop a Larrabee-like GPU using cores with ARM or Power architecture (since they don't have a x86 license)?
Intel - Jack of all trades, master in nothing
Nvidia - Master in Graphics and Parallel processing, dosn't do anything else
Why cant there be a middle ground????
Exactly. Engineers of all discipline, heck, even high school kids in India know C.
interesting info!
although the accuracy point is taken. BOINC distributed computing don't use GPU is because they say it's not accurate enough to produce reliable results.
[/offtopic]
I think this whole "battle of encoding" is pure marketing. We'll see who'll come out as a winner in this one but I have a feeling that both are right... somewhere... a bit... maybe. :)
Oh, and badders +4. ;)
as HDD sizes increase people will be asking for greater quality (therefore less compression) and could this be a realm for GPU or CPU who knows i personally beleive that the GPU is the next major leap and as soon as few freeware (along the lines of staxrip or handbrake) encoding apps are released that utilise CUDA Nvidia will start to win out.
If NViadia GPU has all the branching power, then they're wasting silicon that would have better been utilized for pushing pixels or massively parallel calculations. Intel is right in that a general processor is much better suited to branching. How much of that is required for video encoding is beyond me because I've not written any code for that type of application. I do understand Intel's point about IQ of the video as I have some understanding about what goes on during video encoding/compression. That said, any programmer worth his salt know ANSI C.
Anyway, a Hybrid approach to video encoding utilizing both types of processors is probably the best approach. The CPU for the branching and the GPU for the parallel calculations. Someone asked why not have a processor hybrid. Well you have to ask how much silicon would have to be partition for matrix type calculations and how much for branching. For every type of task the answer would be different. As is, CPUs have some degree of Single Instruction Multiple Data (SIMD). Intel calls it SSE/2/3/4/... and AMD called it 3D NOW. I think AMD adopted SSE a while ago. My point here is while Intel might be full of marketing, what they're saying isn't necessarily BS and their processor have been capable of doing similar type calculations to a GPU for quite some time (even before GPUs were marketed, although no where near as fast).