Facts and Fiction of GPU-Based H.264 Encoding

notthatwillsmith writes "We've all heard a lot of big promises about how general-purpose GPU computing can greatly accelerate common tasks that are slow on the CPU — like H.264 video encoding. Maximum PC compared the GPU-accelerated Badaboom app to Handbrake, a popular CPU-based encoder. After testing a variety of workloads ranging from archival-quality DVD rips to transcodes suitable for play on the iPhone, Maximum PC found that while Badaboom is significantly faster than X264-powered Handbrake in a few tests that require video resizing, it simply can't compare to the X264-powered Handbrake for archival-quality DVD backups."

Comments

makes sense to me

[perlchild]

Wouldn't archival-quality backups be actual MPEG instead of H.2 or whatever? I mean if you're archiving, why go lossy?
Is it just a badly-designed test?

Re:makes sense to me

[Silverlancer]

In my experience HCEnc, a freeware encoder (not open-source though), tends to beat CCE quality-wise. Most of Doom9 seems to agree, though I don't think the differences were too dramatic.

Obvious

[evilviper]

This is the most obvious and boring insight they could possibly offer... Everyone with the slightest interest knows this already.

The low quality of hardware-based video encoder cards is a very well-known fact, and those MPEG encoders cards are just ASICs on a PCI card, almost exactly the same hardware as your video card.

The point of offering up APIs for GPUs, and AMD's attempt to integrate the GPU ASIC with the CPU via HyperTransport, is aimed at improving things, however.

x264 does a good job because it's an open source project, with several skilled and interested individuals continually tweaking the code to improve quality and performance. Once hardware-based video encoding routines aren't hidden in closed-source firmware on a dedicated card, the same development effort can step up and improve HARDWARE encoding now, exactly as they have with software.

Not only can quality be significantly improved, you can expect performance to improve significantly as well, even with greater quality. The initial implementation of any codec is always relatively poor performing, and low quality, so this wouldn't even be an insightful observation if it was comparing x264 with any other software based encoder... The only difference is that a new software h.264/AVC encoder would be SLOWER than x264, as well as being much lower quality.

Apples and Oranges

[Louis Savain]

Comparing a GPU, an SIMD (single instruction, multiple data) vector processor, to a CPU, a superscalar sequential processor, is like comparing apples and oranges. Sure, they are both fruits but they don't taste the same. Using the term 'general-purpose' to describe a GPU is pushing the limits of what a GPU is. Certainly, it can run general-purpose programs but much faster at running what it was designed to run, data-parallel applications. A GPU does not have to have a fast clock because it makes up for it by doing a lot of operations in parallel.

A CPU, OTOH, can have a very fast clock but even if it has a superscalar architecture, it cannot come close to the performance of a GPU on data-parallel apps.

It is obvious that neither the GPU nor the CPU are universal processors and, IMO, that is an unforgivable sin. Having both of these types of processors in the same machine is asking for trouble. They require two incompatible programming models. Programming such a beast is like pulling teeth with a crowbar. Only a few are good at it and that is not good for the industry. What is needed is a fast vector processor that can run in MIMD (multiple instruction, multiple data) mode. This way, it would have no trouble running general-purpose apps just as fast as data-parallel apps. The problem is that such a processor would need a radically different programming model, one that is specifically designed for fine-grain MIMD prosessing. None of the current programming tools would work with it. Still, that's the future of parallel computing. There is no getting around this.

Herading the Impending Death of the CPU

Re:Apples and Oranges

[Silverlancer]

This isn't 1990 anymore; CPUs have SIMD just as graphics cards do. A modern CPU doing even a brute-force exhaustive motion search can come out on par with a GPU in terms of performance. And if you use sequential elimination instead of a brute-force search (which gives a mathematically equivalent output), a single Core 2 Quad can outperform a quad-SLI set of top-end graphics cards. Sequential elimination, however, despite being SIMD-able, is not well-suited to the threading model of CUDA and similar APIs, and so probably cannot be implemented reasonably on a GPU.

This concept applies to many algorithms--the brute-force method is easily implementable on a GPU, but a faster and algorithmically smarter method is not well-suited to such an architecture.

Re:Not a valid comparison

[Silverlancer]

LGPL vs GPL is not actually a very big issue in my experience. I spent the summer working at Avail Media, a company that uses x264 for real-time 1080i/720p broadcast encoding for IPTV and cable television (and also funds a large portion of x264 development). They use x264 in their encoding boxes--yet their main application is proprietary! This is done by having an extremely simple open-source wrapper which is statically linked to x264; the raw frames to be encoded are passed to it over a pipe by the main program. This completely bypasses the limitations of the GPL without violating the spirit of it, since anyone who wants to can still read the source code of the wrapper, modify it, and recompile it as necessary and still use it with the main application.

Re:Not a valid comparison

[Dr_Barnowl]

Their wrapper is required to be GPL ; but since they don't distribute it, the source distribution clauses are not in effect.

Their commercial software pipelines frames into their wrapper ; they are separate processes, not linked, and thus their use does not violate GPL.

Otherwise you could argue that because you opened a Word document in OOo, that Word was now required to be GPL because it had emitted data that was now being consumed by a GPL application.