CUDA support for x264 CLI

[Anakunda]

Hello, is a CUDA encoding support intended in future versions of x264? If so, what speedup I can expect? Thank you.

[sneaker_ger]

No, it's not. In short: the devs don't find CUDA very useful for the task.
It has been discussed quite often, do a forum search if you need more info.

[CruNcher]

Yep and adding CUDA support in form of any other Encoder would be blatantly absurd the same absurdness as the Intel guy suggested to implement their Encoder via their API :P
If you want x264 with CUDA support you should try Arcsofts MediaConverter they use a modified X264 with GPU support for Nvidia, though some revisions ago it was very buggy especially @ High Quantizers ;)

[deadrats]

Yep and adding CUDA support in form of any other Encoder would be blatantly absurd the same absurdness as the Intel guy suggested to implement their Encoder via their API :P
If you want x264 with CUDA support you should try Arcsofts MediaConverter they use a modified X264 with GPU support for Nvidia, though some revisions ago it was very buggy especially @ High Quantizers ;)

you know, i promised myself i would never visit this site again, let alone post in it, but today i find myself breaking both promises to myself.

why is it "absurd" to accelerate video encoding on a gpu via CUDA? on one hand the claim is that it can't be done, then we're told that it would be ridiculous/absurd/not-worth-the-trouble, then you say that arcsoft uses a modified x264 with gpu support.

well if arcsoft is using a modified version of x264 with gpu support enabled then it can be done, no one ever said run the entire encoder on the gpu (though that is possible) what has been suggested is that portions of the more intensive calculations, such as motion estimation, be calculated on the gpu thus freeing the cpu to perform other encoding related tasks, such as entropy coding.

nothing "absurd" about that.

[sneaker_ger]

I also have to go back on my previous comment. While it is true that x264 devs have denied usefulness of GPU acceleration for x264 in the past, there's actually a proposition on their Summer of Code site:
http://wiki.videolan.org/SoC_x264_2011

I don't know if anyone actually took up the task, though.

[J_Darnley]

why is it "absurd" to accelerate video encoding on a gpu via CUDA? on one hand the claim is that it can't be done, then we're told that it would be ridiculous/absurd/not-worth-the-trouble, then you say that arcsoft uses a modified x264 with gpu support.

Read the post. He said it was absurd to make x264 use another API for the encoding. The guy from Intel was suggesting that the Sandy Bridge API should be used. It would then be Intel's encoder, not x264 doing the work. It would be similar in effect to creating xvp8 by using libvpx.

[nevcairiel]

What most people seem to be suggesting is actually use the CUDA encoder device to do encoding - this is absurd and insane, as it would completely work around x264, and significantly lower the quality, as you're at the mercy of the hardware.

What the GSoC task mentioned above is about is implementing some parts of x264 using CUDA algorithms. It would *not* use the hardware encoder, it would just use the immense power a CUDA GPU can offer for some tasks that can be properly (and massively) parallelized and take full advantage of CUDA. CUDA in itself is only useful for tasks that can run hundreds of threads at the same time.

Don't confuse CUDA with the hardware encoder in NVIDIA GPUs, sadly its a *very* common mistake. CUDA is just a toolkit to run extensive floating point calculations on the GPU - given enough parallelism to make sense.

[sneaker_ger]

Are you sure? From all I've read encoding is actually done on the GPU and not separate like decoding.

[nm]

Yep, a hardware encoder block in Nvidia GPUs would be news for me too. Can you link to a technical paper or other documentation that describes it? There's the VPx decoder, sure, but I've understood that nvcuenc is implemented as a CUDA program, not relying on dedicated video encoding hardware.

[nevcairiel]

You can access the hardware encoder through CUDA, but thats not really using CUDA then - you just use some CUDA APIs to get access to the encoder device - if its hardware or just some hardwired CUDA application is irrelevant. For NVIDIA it might be a CUDA application, if we extend this to QuickSync, i think its actual hardware there (I'm not 100% on that, anyhow)

The point is that its certainly possible to speed up *parts* of x264 using CUDA/OpenCL, as mentioned above, for example, by implementing Motion Compensation algorithms in CUDA. The encoding is still done all in x264, just instead of a algorithm that runs on your CPU, it runs on the GPU. You do *not* use the hardware encoder, you just use CUDA to speed up one algorithm - potentially without a quality loss.

CUDA in itself is just a piece of software that allows you to run algorithms on the GPU. For this to make sense, the algorithms have to fill some specific criteria, but if they do, the result will be the same as if you would run them on the CPU - except potentially faster.

Just don't mix up "using CUDA for your own algorithms" with "using CUDA to access NVIDIAs CUDA encoder"

[nm]

Just don't mix up "using CUDA for your own algorithms" with "using CUDA to access NVIDIAs CUDA encoder"

Sure, I don't see anyone mixing them in this thread. And when talking about x264's GPU encoding support in general, people always ask for custom algorithm implementations, not an nvcuenc wrapper.

[nevcairiel]

Sure, I don't see anyone mixing them in this thread. And when talking about x264's GPU encoding support in general, people always ask for custom algorithm implementations, not an nvcuenc wrapper.

The OP surely sounds like it, "CUDA encoding support", so did cruncher - but anyway, just wanted to make sure.

[kemuri-_9]

I don't know if anyone actually took up the task, though.

No, one took the task this year. (I can't remember if the task from 2010 or 2009 was accepted and then the implementer flunked out or if no one just took the task hough)

others have tried implementing some GPU assistance (i remember both CUDA and OpenCL attempts) outside of GSoC, the general result is that they either
A) disappeared into the oblivion
B) gave up

which is understandable IMO, as this is by far no easy task.

[burfadel]

CUDA is definitely pointless, not for the argument of GPU possibly not being suitable for x264, but because CUDA is too limited. CUDA limits the benefits to Nvidia GPU's & Windows, and on the assumption that CUDA will stay around for a long time.

On the other hand OpenCL is cross platform, it supports Nvidia, AMD, Intel etc, and Windows, Linux etc. It is a definitive thing that won't possibly finish like CUDA.

[nm]

CUDA limits the benefits to Nvidia GPU's & Windows, and on the assumption that CUDA will stay around for a long time.

CUDA is also available on Linux and OS X, but yes, I agree that a framework that supports multiple hardware platforms is preferable.