GPU Accelerated H.264 Encoder

[royia]

Hello.
I have few video files I want to encode.
As far as I know x.264 would provide the best quality.
Yet, does it have a version which uses the GPU for acceleration?

Which encoder which does utilize the GPU (Open CL / CUDE / Stream) has the best quality?

Thanks.

[Midzuki]

Hi there.

Please take a look at these threads:

http://forum.doom9.org/showthread.php?t=151631

&&

http://forum.doom9.org/showthread.php?t=146209

HTH.

[royia]

Thank You for the references.

I read what's written there and I wonder about 2 things:
1. Is there a way to accelerate some parts (To the least) of x.264 using Open CL / Direct Compute? Will we ever see something like that? That would mean a lot to many users. I read the main developer said I runs solely on the CPU, my question is it some kind of built in limitation of the code or just no effort in this direction ever been made?
2. I see x.264 us much superior to any GPU Accelerated H.264 Encoder. Yet which GPU Accelerated Encoders are considered to produce legitimate quality (Let's something above xVid in the same Bitrate).

Thanks.

[aegisofrime]

Thank You for the references.

I read what's written there and I wonder about 2 things:
1. Is there a way to accelerate some parts (To the least) of x.264 using Open CL / Direct Compute? Will we ever see something like that? That would mean a lot to many users. I read the main developer said I runs solely on the CPU, my question is it some kind of built in limitation of the code or just no effort in this direction ever been made?
2. I see x.264 us much superior to any GPU Accelerated H.264 Encoder. Yet which GPU Accelerated Encoders are considered to produce legitimate quality (Let's something above xVid in the same Bitrate).

Thanks.

Rest assured the developers have considered the possibility. In fact, accelerating part of x264 is one of the projects in x264's 2010 summer of code.

Here's the excerpt:

GPU motion estimation

While porting x264 entirely to CUDA or OpenCL is an insane task, there are three possible methods that could be used to offload some work to the GPU:

* High-complexity motion search designed to get useful predictors to be used by the main motion search.
* Massively parallelized lookahead motion search, designed to do a lot of the work normally done in the lookahead thread. May also improve B-frame decision and other parts of the lookahead.
* Motion search designed to completely replace x264's main motion search: would require a lot of threading trickery to sync it perfectly with the main encoder threads.

The general algorithm that has been agreed on after a great deal of discussion is the hierarchical search method. If you have a better idea, feel free to propose it, of course. More description of this method is in the Qualification Tasks section.

This project is not recommended unless you have a very significant amount of experience with CUDA or OpenCL.

* Difficulty: Very High
* Amount of work: Medium
* Skill required: Very High

Source:

http://webcache.googleusercontent.com/search?q=cache:rgef2Gn6DSoJ:wiki.videolan.org/SoC_x264_2010+x264+summer+of+code&cd=2&hl=en&ct=clnk&gl=sg&client=firefox-a

(google cache link because of 404)

Original link:

http://wiki.videolan.org/SoC_x264_2010

[royia]

I hope someone will take it upon himself.
I wish I could help with that.

Has anyone applied for it?

[hust_xcl]

I hope someone will take it upon himself.
I wish I could help with that.

Has anyone applied for it?

i am trying it now.It is hard, so I can not promise the result

[royia]

i am trying it now.It is hard, so I can not promise the result

Crossing my fingers for you.
Just for knowledge, are you aiming for Open CL or CUDA?

I wish I could help :-).

[kemuri-_9]

i am trying it now.It is hard, so I can not promise the result

there are a group of people trying to accomplish this, they can often be found talking or conversing in #x264dev on freenode.
if you're not among this group then you're at a serious disadvantage

[hust_xcl]

Crossing my fingers for you.
Just for knowledge, are you aiming for Open CL or CUDA?
aim for cuda
I wish I could help :-).
:),i will ask for your help when i need.

[royia]

Will you be using CUDA or Open CL?

[hust_xcl]

Will you be using CUDA or Open CL?
using cuda

[hust_xcl]

there are a group of people trying to accomplish this, they can often be found talking or conversing in #x264dev on freenode.
if you're not among this group then you're at a serious disadvantage

I want to verify my algorithm before joining them.
:)

[aegisofrime]

I want to verify my algorithm before joining them.
:)

Best of luck! If you succeed you shall become very famous! :)

[mariush]

I wish you would use Open CL - why limit something only to one platform... it's like designing something to work on 3dfx Voodoo2's Glide system - yes, it may work better but who knows what will happen to nVidia in a few years.

[Dark Shikari]

I wish you would use Open CL - why limit something only to one platform... it's like designing something to work on 3dfx Voodoo2's Glide system - yes, it may work better but who knows what will happen to nVidia in a few years.On the other hand, OpenCL is missing critical features, like pointers, that are basically required (as far as we've found) to implement a lot of this...

[kieranrk]

On the other hand, OpenCL is missing critical features, like pointers, that are basically required (as far as we've found) to implement a lot of this...

How do you implement anything substantial without pointers?

[Dark Shikari]

How do you implement anything substantial without pointers?Ask a Java programmer.

[Sharktooth]

may be useful: http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=134809

[ImmortAlex]

Ask a Java programmer.
A quiet offtopic, but Java has pointers. We just call them 'references' :) What we, Java programmers, are really lost is pointer arithmetic...

[Reimar]

On the other hand, OpenCL is missing critical features, like pointers, that are basically required (as far as we've found) to implement a lot of this...

Happen to have a reference at hand? I've only used CUDA, but my impression was that you rarely really need completely general pointers, since you have to copy the data to the GPU anyway and transforming it so far that e.g. everything ends up in a single buffer is not really a problem.

[LoRd_MuldeR]

Happen to have a reference at hand? I've only used CUDA, but my impression was that you rarely really need completely general pointers, since you have to copy the data to the GPU anyway and transforming it so far that e.g. everything ends up in a single buffer is not really a problem.

See here:
http://developer.download.nvidia.com/OpenCL/NVIDIA_OpenCL_JumpStart_Guide.pdf

Search for "Pointer Traversal" and you'll find:
...pointers must be converted to be relative to the buffer base pointer and only refer to data within the buffer itself (no pointers between OpenCL buffers are allowed)

[TheImperial2004]

I'm I the only one who believes that all "minor" x264 development should be postponed and all efforts should be focused on developing a way to offload the ME "at least" to the GPU ?

One can dream , can't he ? ;)

[royia]

I'm I the only one who believes that all "minor" x264 development should be postponed and all efforts should be focused on developing a way to offload the ME "at least" to the GPU ?

One can dream , can't he ? ;)
As a user, Totally agree with you.

I wish someone would offer a significant encoding performances improvement.

[Guest]

I'm I the only one who believes that all "minor" x264 development should be postponed and all efforts should be focused on developing a way to offload the ME "at least" to the GPU ?

One can dream , can't he ? ;) Do you have any data or analysis to show that doing that would in fact result in a significant improvement in performance, or is this just something you hope is true?

[Audionut]

all "minor" x264 development should be postponed

More speed is always nice. But personally, x264 is 'fast enough' for my needs.

I would rather gain 20% more quality for the same bitrate than 20% more speed for the same options.

[Reimar]

See here:
http://developer.download.nvidia.com/OpenCL/NVIDIA_OpenCL_JumpStart_Guide.pdf

Search for "Pointer Traversal" and you'll find:
...pointers must be converted to be relative to the buffer base pointer and only refer to data within the buffer itself (no pointers between OpenCL buffers are allowed)

Sorry, I meant a pointer to the discussion why it is expected to be a problem here.
I can only think of it if you have a lot of different-sized data sets that you have to copy around continuously, but unless NVidia has significantly improved the memory fragmentation issue even there it might be better to allocate a single "max-sized" buffer and do your own memory management - which eliminates the issue even though in a really bad way.

[TheImperial2004]

Do you have any data or analysis to show that doing that would in fact result in a significant improvement in performance, or is this just something you hope is true?

I read somewhere -from Dark Shikari I believe - that the most intensive phase of encoding is Motion Estimation . Correct me if I am wrong .

I would rather gain 20% more quality for the same bitrate than 20% more speed for the same options.

More quality ? I can't even imagine how our encodes are going to be ... I mean come on ! At CRF of 18 , "ALL" my encodings are transparent to their sources (At least for my eyes) .

So I don't think we are in a rush for more quality at this point of development ;)

[Dark Shikari]

I read somewhere -from Dark Shikari I believe - that the most intensive phase of encoding is Motion Estimation . Correct me if I am wrong .That doesn't magically mean that it can be made faster on a GPU.

[TheImperial2004]

That doesn't magically mean that it can be made faster on a GPU.

At least it would be "faster" than its for now , wouldn't it ? :)

EDIT : Wait a sec !!!

Does that mean ! All CUDA encoders right now are faster just because they produce much less quality than x264 ?!

Come to think of it , How can a GPU processor be 20x faster than CPU ? They advertise that their CUDA encoders are 20x faster than regular CPU ones ... !!!

Now I see your point DS ...

[IppE]

If x264 used floating point calculations it would be a lot faster, but I'm pretty sure thats not the case.

[Dark Shikari]

At least it would be "faster" than its for now , wouldn't it ? :)

EDIT : Wait a sec !!!

Does that mean ! All CUDA encoders right now are faster just because they produce much less quality than x264 ?!

Come to think of it , How can a GPU processor be 20x faster than CPU ? They advertise that their CUDA encoders are 20x faster than regular CPU ones ... !!! Bolded the key words for you there.

A Honda Civic is 10 times faster than an Go-kart. It's easy to be "20 times faster" when you're comparing yourself to the worst encoders on the market.

I have yet to see a CUDA encoder that's faster than x264. All of them are "fast" because they use incredibly crappy encoding settings -- and if you set x264 to use comparable settings, x264 is equally (or even moreso) faster.

[TheImperial2004]

Bolded the key words for you there.

A Honda Civic is 10 times faster than an Go-kart. It's easy to be "20 times faster" when you're comparing yourself to the worst encoders on the market.

I have yet to see a CUDA encoder that's faster than x264. All of them are "fast" because they use incredibly crappy encoding settings -- and if you set x264 to use comparable settings, x264 is equally (or even moreso) faster.

Yup ! I'll never wait for this anymore . Quality comes first for sure ;)

Thanks DS . I'm now released from GPGPU torment :)

[aegisofrime]

More speed is always nice. But personally, x264 is 'fast enough' for my needs.

I would rather gain 20% more quality for the same bitrate than 20% more speed for the same options.

Well, like you said, for your needs.

I would say that speed is like money: You can never have enough of it. Nothing is ever fast enough. I would definitely say that x264 is not fast enough for HD content even if you have a i7-980X.

That said, would the AVX instructions in Bulldozer and Sandy Bridge make a huge difference in speed?

[Firebird]

Well, like you said, for your needs.
I would definitely say that x264 is not fast enough for HD content even if you have a i7-980X.


Wrong. As far as i know x264 can encode 1080p faster than realtime on ultrafast preset. You know, slow presets are supposed to be slow :)

[ForceX]

Come to think of it , How can a GPU processor be 20x faster than CPU ?
GPUs are VERY highly threaded processors which are fantastic for highly parallelized workload. However they have traditionally been made for processing only graphics data. The recent changes towards GPU programming allows you to do more General Purpose work on them (Hence GP-GPU). CPUs are general purpose processors, and although they can perform a wide variety of work, they are basically a jack of all trade but master of none. For certain tasks which are suitable for GPUs it can outperform CPUs by several orders of magnitude. Notice that "certain tasks", however.

Theoretically a radeon 5970 has 9 times as much double precision floating point calculation ability than the best core i7 980X. Several matrices can be accelerated to be processed more than 9 times faster on such GPUs. However, if the code isn't suitable for such job you can end up actually losing speed compared to a CPU.

As far as I know x264 doesn't use FP calculations and the GPGPU programming landscape is a huge mess right now, so if a port of x264 to GPU would actually bring any advantage to the speed is highly debatable. Then there is the question of optimizing it.

[TheImperial2004]

GPUs are VERY highly threaded processors which are fantastic for highly parallelized workload. However they have traditionally been made for processing only graphics data. The recent changes towards GPU programming allows you to do more General Purpose work on them (Hence GP-GPU). CPUs are general purpose processors, and although they can perform a wide variety of work, they are basically a jack of all trade but master of none. For certain tasks which are suitable for GPUs it can outperform CPUs by several orders of magnitude. Notice that "certain tasks", however.

Theoretically a radeon 5970 has 9 times as much double precision floating point calculation ability than the best core i7 980X. Several matrices can be accelerated to be processed more than 9 times faster on such GPUs. However, if the code isn't suitable for such job you can end up actually losing speed compared to a CPU.

As far as I know x264 doesn't use FP calculations and the GPGPU programming landscape is a huge mess right now, so if a port of x264 to GPU would actually bring any advantage to the speed is highly debatable. Then there is the question of optimizing it.

Totally agree . But !

I believe that the major issue here is to synth. the data between two different entities . What if the GPU is just too fast for the CPU to keep up with ? Of course we will need the CPU to do some calculations . If the CPU is 9x slower than the GPU , then whats the point ? In that case , the GPU will have to wait for the CPU to respond and complete its part of the job , *only* then the GPU will continue doing its part . Lagging is the major issue here . Feel free to correct me though ;)

[royia]

A guy comes, taking on himself a big challenge yet you take all the wind out of his sail.
Try to support this.

Worse case we'll be left with the CPU :-).

Let him explore.
There are so many smart guys here, they might come up with a solution.

[mariush]

Totally agree . But !

I believe that the major issue here is to synth. the data between two different entities . What if the GPU is just too fast for the CPU to keep up with ? Of course we will need the CPU to do some calculations . If the CPU is 9x slower than the GPU , then whats the point ? In that case , the GPU will have to wait for the CPU to respond and complete its part of the job , *only* then the GPU will continue doing its part . Lagging is the major issue here . Feel free to correct me though ;)

GPUs are indeed much faster now than CPU processors, but the trend is for CPUs to gain more cores and you can see some tendencies to integrate the GPU and CPU in a single die, thus gaining much faster communication paths between them.

As for what you're talking about, I'm not sure that it can be improved a lot if the encoder keeps the "thinking" that it's supposed to receive a series of frames and that it must process it as they come.

Sure, it's needed for real time encoding and streaming but in lots of cases, the whole content to be encoded is already physically there.

I'm imagining for example, if you have a 10 GB video you need re-encoded and an 8 core processor, you could quickly parse the first 512 MB of this content, split it into 8 smaller chunks, upload to video card, let it do calculations while the 8-12 CPU threads do calculations on each of those 8 chunks... if cpu lags behind, just store the computations performed on GPU somewhere and upload to card the next 512 MB chunk and when it's all done, do some computations to glue these chunks together.

With cards nowadays having almost all at least 512 MB of memory on them with a lot of them having 768-1GB, that's (I think) plenty of space to fill with data to be crunched through while cpu glues everything up.

Not sure how much would these gpu results would be in disk space or normal memory and if it's fast enough to dump them to disk so that it would be faster than just doing it all on cpu - I don't see otherwise really a problem of using a lot of disk space to encode something - mbtree file already uses about 200 MB to encode 3 GB of content.

[ForceX]

Totally agree . But !

I believe that the major issue here is to synth. the data between two different entities . What if the GPU is just too fast for the CPU to keep up with ? Of course we will need the CPU to do some calculations . If the CPU is 9x slower than the GPU , then whats the point ? In that case , the GPU will have to wait for the CPU to respond and complete its part of the job , *only* then the GPU will continue doing its part . Lagging is the major issue here . Feel free to correct me though ;)

Of course if you pair up the latest and greatest GPU with an obsolete slow CPU you're going to hit a bottleneck. One assumes you are not going to get the best of one component and use it with lowest end other components.

One way to avoid hitting a bottleneck would be to program the encoder to perform most of the (decoding and) encoding in GPU while the CPU is used only to maintain I/O and task scheduling. That, I don't see happening anytime soon due to technical constrains. "Running out of work" due to thread waits is already a big problem in the multicore CPU world and the people involved are investing huge amount of time to improve caching and branch prediction etc etc. It's just that, they never tried to do it that well to co-ordinate with the GPU. But as CPUs and GPUs are getting "fused" (lol math co-processor redux), using the GPUs for accelerating compression is only a matter of time.

[TheImperial2004]

GPUs are indeed much faster now than CPU processors, but the trend is for CPUs to gain more cores and you can see some tendencies to integrate the GPU and CPU in a single die, thus gaining much faster communication paths between them.

As for what you're talking about, I'm not sure that it can be improved a lot if the encoder keeps the "thinking" that it's supposed to receive a series of frames and that it must process it as they come.

Sure, it's needed for real time encoding and streaming but in lots of cases, the whole content to be encoded is already physically there.

I'm imagining for example, if you have a 10 GB video you need re-encoded and an 8 core processor, you could quickly parse the first 512 MB of this content, split it into 8 smaller chunks, upload to video card, let it do calculations while the 8-12 CPU threads do calculations on each of those 8 chunks... if cpu lags behind, just store the computations performed on GPU somewhere and upload to card the next 512 MB chunk and when it's all done, do some computations to glue these chunks together.

With cards nowadays having almost all at least 512 MB of memory on them with a lot of them having 768-1GB, that's (I think) plenty of space to fill with data to be crunched through while cpu glues everything up.

Not sure how much would these gpu results would be in disk space or normal memory and if it's fast enough to dump them to disk so that it would be faster than just doing it all on cpu - I don't see otherwise really a problem of using a lot of disk space to encode something - mbtree file already uses about 200 MB to encode 3 GB of content.

That seems a good idea . But !

" just store the computations performed on GPU somewhere "

I don't think there will be other place to store them other than HDD . And we all know what that might mean , Yes , Lag . For storing -let's say- 512MB segment every 10-30 seconds , I believe that the HDD will be the bottleneck here .

Your idea is great but I can't see it will improve encoding speed "magically" in the near future , especially when the HDD is involved .

One way to avoid hitting a bottleneck would be to program the encoder to perform most of the (decoding and) encoding in GPU while the CPU is used only to maintain I/O and task scheduling. That, I don't see happening anytime soon due to technical constrains. "Running out of work" due to thread waits is already a big problem in the multicore CPU world and the people involved are investing huge amount of time to improve caching and branch prediction etc etc. It's just that, they never tried to do it that well to co-ordinate with the GPU. But as CPUs and GPUs are getting "fused" (lol math co-processor redux), using the GPUs for accelerating compression is only a matter of time.

As you said , "Running out of work" is already an issue in the multi-core world . So adding a GPU to the same die will still suffer the same lagging . Think of it this way : If it was lagging in the CPU <--> CPU operations , what do you think of CPU <--> CPU <--> GPU ?

I'm just woundering , if we are to offload "everything" to the GPU , how can a 600-700 MHz GPU be faster than a 3.0+ GHz CPU ? Isn't everything we are looking for is clock speeds ?

Corrections are welcome ;)

[Guest]

The amount of uninformed blustering here is breathtaking.

Have you guys ever written a GPU program?

[TheImperial2004]

The amount of uninformed blustering here is breathtaking.

Have you guys ever written a GPU program?

Nope . For myself , I'm talking entirly in theories . Can be right or wrong . I'm just woundering how can we magically speed things while serving the same quality of x264 .

Dark Shikari had already state that we need to build the whole encoder from scratch . So I think it'd be best if we wait for H.265 and build x265 from the ground up to harness the GPU .

Corrections are welcome as always ;)

[mariush]

That seems a good idea . But !

" just store the computations performed on GPU somewhere "

I don't think there will be other place to store them other than HDD . And we all know what that might mean , Yes , Lag . For storing -let's say- 512MB segment every 10-30 seconds , I believe that the HDD will be the bottleneck here .

Your idea is great but I can't see it will improve encoding speed "magically" in the near future , especially when the HDD is involved .


4 GB of RAM is nowadays common, 8 GB of RAM is not that unusual and almost all motherboards support it.

SSD drives are also getting more and more common and cheap, a 40-80 GB SSD drive is now 100-150$ and can sustain 100-150MB/s writes easily. Dumping 512 MB of data to RAM and then in less than 10 seconds to a hard drive should be doable (it's doable in theory even on a regular drive, mine do 60-70MB easily, but probably won't do if you read data from it at the same time).
And, of course, this is without RAID.

But remember, I was talking about uploading 512 MB of data to video card and then dump the results of the processing... that doesn't necessarily mean it will be 512 MB of results, it could easily be just 40-50 MB of data.
Of course, if it takes less time to process the data than uploading and downloading it from the card it's not worth it.


neuron2: I never claimed to be an expert, I'm not, I'm barely able to code websites and do occasional conversions...

I'm just writing my thoughts so other can explain why it won't work or it wouldn't be feasible and I'll learn something out of it, wouldn't I?

After all, it's a forum here and that's the definition of a forum, a place where people can discuss things.

[TheImperial2004]

But remember, I was talking about uploading 512 MB of data to video card and then dump the results of the processing... that doesn't necessarily mean it will be 512 MB of results, it could easily be just 40-50 MB of data.
Of course, if it takes less time to process the data than uploading and downloading it from the card it's not worth it.

Now I see . The issue here is synth. : Coding a thread to do this and then wait for it to finish and return a value to feed other threads is a nightmare -at least for me- . I tried to code some threaded apps in C# and I pulled my hair easily . Thats about a simple app . How about an encoder with thousands of lines ? It would be a no-go , unless we made a new encoder from scratch .

I'm just writing my thoughts so other can explain why it won't work or it wouldn't be feasible and I'll learn something out of it, wouldn't I?

After all, it's a forum here and that's the definition of a forum, a place where people can discuss things.

Sure , we are all here to learn . "Never too old to learn" . Feel free to express your thoughts and correct others . :)

Corrections are welcome ;)

[LoRd_MuldeR]

Nope . For myself , I'm talking entirly in theories . Can be right or wrong . I'm just woundering how can we magically speed things while serving the same quality of x264.

You never get any speed-up for free. And certainly GPU's won't "magically" make your program faster!

Porting software to CUDA/OpenCL isn't simple at all. Getting a non-trivial software running on the GPU will be though task. Not to mention all the work that has to be done to optimize it for speed.

Also there is absolutely no guarantee that your software will run any faster (more efficient) on the GPU than it does on the CPU. It may or may not work.

If your problem isn't highly parallel, it won't fit on the GPU. But even if your problem is highly parallel in theory, then you still have to come up with a smart parallel algorithm that works on the real hardware.

See also:
http://forum.doom9.org/showpost.php?p=1353465&postcount=192

Also the this example shows how complex it is to optimize something as simple as a "parallel reduction" on CUDA:
http://developer.download.nvidia.com/compute/cuda/1_1/Website/projects/reduction/doc/reduction.pdf


Dark Shikari had already state that we need to build the whole encoder from scratch . So I think it'd be best if we wait for H.265 and build x265 from the ground up to harness the GPU.

Note necessarily the whole encoder, but a significant part.

You can't "move" a single DSP function to the GPU (even if it is a LOT faster there), because the delay for CPU -> GPU -> CPU data transfer would nullify the speed-up.

Instead you must "move" (read: re-implement) complete algorithms on the GPU, so there will be enough "calculations per data transfer" to legitimate the transfer delay.

(Furthermore we don't have any indication that H.265 will be any easier or harder to implement on a GPU)

[TheImperial2004]

Hi Mulder , long time no see ;)

You never get any speed-up for free. And certainly GPU's won't "magically" make your program faster!

Thats what commercials are advertising : "Stunning speed with crystal clearity" , and I was woundering how did they do this ? Magic ? Of course no , Speedy encoder is speedy because of less calculations --> Bad output .

You must move complete (read: re-implement) complete algorithms on the GPU.

Add to that the nightmarish API that they are providing for the developer :)

(Furthermore we don't have any indication that H.265 will be any easier or harder to implement on a GPU)

The problem is the API of the CUDA/Stream , not the Application/Specification as I see things .

[Guest]

I'm just writing my thoughts so other can explain why it won't work or it wouldn't be feasible and I'll learn something out of it, wouldn't I?

After all, it's a forum here and that's the definition of a forum, a place where people can discuss things. That's fine until people start to say things like this from a position of almost total ignorance:

Am I the only one who believes that all "minor" x264 development should be postponed and all efforts should be focused on developing a way to offload the ME "at least" to the GPU?

If people have the right to advertise their ignorance (in the sense of lack of relevant knowledge and not in any derogatory sense), then I suppose I have the right to note it.

Carry on!

[TheImperial2004]

then I suppose I have the right to note it.

Of course you do . But I wasn't advertising , I was just thinking in a loud voice ;)

[LoRd_MuldeR]

Thats what commercials are advertising : "Stunning speed with crystal clearity" , and I was woundering how did they do this ? Magic ? Of course no , Speedy encoder is speedy because of less calculations --> Bad output.

That is marketing blabber, of course. You shouldn't take it seriously at all. Instead believe only what you see with your own eyes and/or measure on your own hardware.

With all those "big" companies working on GPU-accelerated H.264 encoders and still not one of them can compete with x264 in a proper "quality per speed" comparison, there are only two conclusions:

Either all those companies are completely incompetent -or- GPU's aren't as suitable for video encoding as the GPU vendors try to make us believe. Decide yourself ;)

[TheImperial2004]

Either all those companies are completely incompetent -or- GPU's aren't the suitable for video encoding, as the GPU vendors try to make us believe. Decide yourself

I suppose the latter choice is not true to a certain extent .

[Guest]

You are misquoting me. Is it intentional?

[TheImperial2004]

You are misquoting me. Is it intentional?

No , not at all .

Sorry I'll edit my post . :)

[ForceX]

I'm just woundering , if we are to offload "everything" to the GPU , how can a 600-700 MHz GPU be faster than a 3.0+ GHz CPU ? Isn't everything we are looking for is clock speeds ?

The clockspeed war has been over since the pentium 4 days. Now it is about adding more cores, performing more instructions per clock and increasing efficiency of the programs to scale better across many cores.

One thing you must understand is that GPU and CPU are completely different architectures. GPUs are only good at some tasks and in those tasks they really excel because they are BUILT that way. On ice, your 60 mph snowmobile is always gonna outperform your 180 mph sports car because snowmobiles are built to run on snow. The MHz in these figures have little relevance, as GPUs use huge pipelines and thousands of (yes, more than a thousand) shader processors to run their task. Trying to compare that with 6 core CPU is foolishness.

Even if you completely ignore architecture differences, merely a few instruction sets for accelerating certain tasks can have huge impact.
http://images.anandtech.com/graphs/amd12core_032610044429/22224.png
The 19 fold increase in encryption performance of the 6 core intel over the older 4 core model is mainly because the AES accelerating instruction set was implemented. So even within the same architecture, clockspeed might not always be the most decisive factor of performance.

[TheImperial2004]

One thing you must understand is that GPU and CPU are completely different architectures.

I realized this . But isn't that because they are completely different architectures would make it harder for a coder to make them work in a harmoney ? After all , we are talking about what a coder may run into when he decides to port a CPU-only code into CPU-GPU one .

Also , we know -to a certain extent- that CUDA API is so difficult to code for , let alone porting existing code into it . thats what we heard from experts . How about Open-CL ? anyone experminted with it ?

[aegisofrime]

I realized this . But isn't that because they are completely different architectures would make it harder for a coder to make them work in a harmoney ? After all , we are talking about what a coder may run into when he decides to port a CPU-only code into CPU-GPU one .

Also , we know -to a certain extent- that CUDA API is so difficult to code for , let alone porting existing code into it . thats what we heard from experts . How about Open-CL ? anyone experminted with it ?

It's ridiculous how difficult CUDA is. I was flabbergasted at the complexity of a simple "Hello World" CUDA program. :(

[Guest]

It's not difficult. I wrote an NV12 to RGB24 conversion (with configurable 601/709 coefficients) plus host transfer in two days. And that was starting with very little knowledge of CUDA. The code is so simple that I'm embarrassed that it took me that long (although a lot of that time was working out the correct YUV->RGB equations and optimizing the implementation).

So speak for yourself! :)

[Maccara]

Also , we know -to a certain extent- that CUDA API is so difficult to code for , let alone porting existing code into it . thats what we heard from experts . How about Open-CL ? anyone experminted with it ?

Who are these experts claiming API makes it difficult? Overcoming API peculiarities is the trivial part (if someone is having difficulties with API already I'm sorry to say, but that's no expert).

It's the algorithms that can be hard to make efficient (not porting per se). "Anything" can be made to run on GPU, but it's a different story if it reaps any benefits (even if it runs faster on GPU).

[ForceX]

I realized this . But isn't that because they are completely different architectures would make it harder for a coder to make them work in a harmoney ? After all , we are talking about what a coder may run into when he decides to port a CPU-only code into CPU-GPU one .
Harmony is not the issue here, GPUs and graphics APIs have been made from the get go to make them work in harmony with the CPU. When you run a game, it offloads the whole graphics calculations on the GPU and runs the AI on the CPU and it is in perfect harmony as long as they are on similar tier of power. The problem is that GPUs were never made very "programmable", while CPUs are hugely so. The new APIs like CUDA and OpenCL adds that layer of programmability. The problem is doing the coding so it can run "efficiently" on the GPU. GPUs can crunch through highly parallel workload like they're nothing but when it comes to doing a lot of different operations on same data then they are crippled.

The fact is that x264 is already highly optimized for CPUs and that is because programmers have been optimizing the compilers and routines for CPUs for decades, whereas GPGPU computing is very new and frankly there are very few people who have any sort of expertise on how to optimize the code for GPU processing, and the lack of documentations and established experiments doesn't help.

The SIMD extensions in the current CPUs are tailored to accelerate media processing, while GPUs don't offer such specific optimization capabilities-yet. Using x264 on CPU is like putting on a nicely fitted dress on a not too gorgeous girl, but the dress makes her look like a princess. Putting x264 on GPU right now is like putting an overly large dress on a prettier girl, although this girl is more beautiful, she is still going to look laughable.

CUDA is not so complex, per say. It involves doing a lot of other things before you can get a result. It's like wrapping your hand around your neck and back before you put that candy in your hand in your mouth, when you could just do it straight. But that added procedures are just the facts of GPU computing now.

[Guest]

CUDA is not so complex, per say. It involves doing a lot of other things before you can get a result. It's like wrapping your hand around your neck and back before you put that candy in your hand in your mouth, when you could just do it straight. But that added procedures are just the facts of GPU computing now. Nonsense, IMHO. And your silly analogies are laughable.

[LoRd_MuldeR]

It's not difficult. I wrote an NV12 to RGB24 conversion (with configurable 601/709 coefficients) plus host transfer in two days. And that was starting with very little knowledge of CUDA. The code is so simple that I'm embarrassed that it took me that long (although a lot of that time was working out the correct YUV->RGB equations and optimizing the implementation).

So speak for yourself! :)

That really is an extremely simplistic example. And the problem fits perfectly on CUDA, as the RGB color value of a pixel only depends on the YUV color value of the same pixel, it does not depend on any other pixels. That's as "local" and "parallalizable" as it can be. I guess you didn't even use the Shared memory for that. There aren't much problems like that in the real world, unfortunately.

As soon as you do something slightly more complex and you try to do it in a way that runs "fast" on CUDA, things get much more ugly. Especially if you need to store intermediate data in "shared" memory, but shared memory is too small. Also all the "memory access pattern" things are very complex. You need to take care which threads (of a block) run in the same Warp and which memory addresses (banks) they access.

Again I want to point to this example:
http://developer.download.nvidia.com/compute/cuda/1_1/Website/projects/reduction/doc/reduction.pdf

(And remember, all they implement is a simple Vector reduction! At the end they have a bunch of code, code that really isn't trivial to understand, while in plain C this would be ~3 lines of code ^^)

[Guest]

You're knocking down a straw man. I was responding to:

"It's ridiculous how difficult CUDA is. I was flabbergasted at the complexity of a simple "Hello World" CUDA program."

That is a problem much simpler than mine. I distinguish between the difficulty of parallelizing algorithms and the difficulty of prgramming using the CUDA API. Do not conflate them.

Now show me your parallel data reduction in 3 lines of C code, or admit that you too are blustering.

[LoRd_MuldeR]

You're knocking down a straw man. I was responding to:

"It's ridiculous how difficult CUDA is. I was flabbergasted at the complexity of a simple "Hello World" CUDA program. That is a problem much simpler than mine."

I would disagree here. CUDA cannot use printf() or similar, so the "Hello world!" of CUDA looks a bit different than what a classical "Hello world!" looks like. Probably the most popular example ("Hello world!") program for CUDA that is shown as the very first example in all the "getting started" guides is the parallel matrix multiplication - already a bit more complex than your color conversion, as it isn't as "local".


I distinguish between the difficulty of parallelizing algorithms and the difficulty of prgramming using the CUDA API. Do not conflate them.

Well, obviously you do not count all the "memory access pattern" mess (different for global and shared memory!) as a part of the CUDA API. Well, I agree that this is not really part of the API itself, but it's a very important aspect of the hardware. And if you ignore that hardware aspect, your program will never run fast on CUDA. So understanding the API to get "something" running on CUDA is one thing, understanding all the hardware aspects that have to be taken into account to get your program fast (and that is all reason why we use CUDA) is a completely different thing. If we look at the CUDA programmers guide, there is about ~10% API documentation and about ~90% hardware aspects ("performance guide"). Compared to that, programming for the CPU requires MUCH less knowledge of the hardware (up to some point, of course).


Now show me your parallel data reduction in 3 lines of C code, or admit that you too are blustering.

I didn't say the C code will be parallel too ;)

For C code thread-parallelization is some kind of "extra boost", that in the optimal case will give you 2x or 4x speed-up, but still is optional. For CUDA thread-parallelization is essential. Using only a single thread on CUDA would be like making the code 1000x slower. Anyway, with C + OpenMP I would simply put a simple #pragma in front of my "3 lines" loop and the parallelization is there...

[Guest]

I didn't say the C code will be parallel too ;) That is my point, which you fail to see because you appear more interested in having a debate with me. I'm not interested in that so I'll bow out.

[hust_xcl]

Totally agree . But !

I believe that the major issue here is to synth. the data between two different entities . What if the GPU is just too fast for the CPU to keep up with ? Of course we will need the CPU to do some calculations . If the CPU is 9x slower than the GPU , then whats the point ? In that case , the GPU will have to wait for the CPU to respond and complete its part of the job , *only* then the GPU will continue doing its part . Lagging is the major issue here . Feel free to correct me though ;)

I agree too. Frequently transferring data between cpu and gpu will cost too much time.
Instead, data should be transferred by large pieces and with low frequency.

[hust_xcl]

Crossing my fingers for you.
Just for knowledge, are you aiming for Open CL or CUDA?

I wish I could help :-).

iRoyia, I have to suspend the work because the emulation mode does not support shared memory. while my old computer can only run in that mode. After I buy a new nv card, I will restart.
IMHO,
1.Interpolation can be optimized by cuda.
2. Full search is more suitable than diamond search to be used to offload me on gpu.
My algorithm is:
(1) Transfer an original frame and a reference frame to gpu
(2) For 7 search modes (16x16, 16x8, 8x16…), each one employs a full search of 8x8 search range around original point(0,0) on gpu.
(3) transfer all the mvs back to cpu
(4) in the analysis process, cpu makes use of the mvs ( predicated mv should be near 0) calculated by gpu.
If the mv is on the border of 8x8 search range, a refined search should be employed to enhance the search result.

[hust_xcl]

That doesn't magically mean that it can be made faster on a GPU.

Dark Shikari：
Is there anyone working for it ? I hope i can give some help.

[TheImperial2004]

Full search is more suitable than diamond search to be used to offload me on gpu.

I failed to see this ... How could a full search be faster than a diamond one ? Even for a GPU ... ? Unless you meant something else by "more suitable" ... :)

[ajp_anton]

Offloading a full search makes more sense than offloading a diamond search.

[TheImperial2004]

Offloading a full search makes more sense than offloading a diamond search.

So -in theory- a full search won't give a big performance hit compared to a diamond one (For a GPU) ? Or did you mean that a full search is easier to offload than other searching algorithms ?

[Sharktooth]

he means diamond search is already pretty fast and there's is little or no need to offload it to the GPU... while full search is very time consuming and offloading it to the GPU would give a much, much bigger advantage.

[TheImperial2004]

he means diamond search is already pretty fast and there's is little or no need to offload it to the GPU... while full search is very time consuming and offloading it to the GPU would give a much, much bigger advantage.

hmm . That makes sense , I've never used diamond before -Always UMH- and it is fast enough on my Q8200 . Would like to see what full search can do for quality ;)

[LoRd_MuldeR]

hmm . That makes sense , I've never used diamond before -Always UMH- and it is fast enough on my Q8200 . Would like to see what full search can do for quality ;)

Look at the built-in x264 presets. Nothing uses ESA or even TESA, except for the "placebo" preset. That should tell you what to expect from a "full" search :p

[TheImperial2004]

Look at the built-in x264 presets. Nothing uses ESA or even TESA, except for the "placebo" preset. That should tell you what to expect from a "full" search

Seems to be "less useful" for everyday encodes , even for archiving .

[Sharktooth]

ESA/TESA gain in respect to UMH is not significant and both are very slow. however, offloading the workload to the GPU would mean you get that marginal quality gain for free and you would also give some speed since no ME is done by the CPU.

[Dark Shikari]

ESA/TESA gain in respect to UMH is not significant and both are very slow. however, offloading the workload to the GPU would mean you get that marginal quality gain for free and you would also give some speed since no ME is done by the CPU.Only if the GPU is fast enough to keep up with the CPU.

[Sharktooth]

sure, otherwise it will slow it down...

[hust_xcl]

he means diamond search is already pretty fast and there's is little or no need to offload it to the GPU... while full search is very time consuming and offloading it to the GPU would give a much, much bigger advantage.

Consider parallel me for all blocks on gpu, diamond search may cost more time than full search. Eg. 10 blocks, one of them search 80 points; even other only search 5 points, gpu should wait all the blocks to finish each me. In that case, diamond search will cost more time than 8x8 full search

[schweinsz]

(4) in the analysis process, cpu makes use of the mvs ( predicated mv should be near 0) calculated by gpu.
If the mv is on the border of 8x8 search range, a refined search should be employed to enhance the search result.
I believe that the GPU for H.264 encoding matters only if the GPU can do interpolation, integer-pel and sub-pel ME, mode decision, transform and quantization.
If you only offload the integer-pel ME and interpolation, it is less significant.

[Dark Shikari]

Consider parallel me for all blocks on gpu, diamond search may cost more time than full search. Eg. 10 blocks, one of them search 80 points; even other only search 5 points, gpu should wait all the blocks to finish each me. In that case, diamond search will cost more time than 8x8 full searchThat's not the reason that diamond is the problem. You can simply limit the number of iterations to avoid that.

The reason diamond is problematic is that to get even remotely decent performance, you have to have coalesced loads for the GPU threads.

[hust_xcl]

That's not the reason that diamond is the problem. You can simply limit the number of iterations to avoid that.

The reason diamond is problematic is that to get even remotely decent performance, you have to have coalesced loads for the GPU threads.

you are right!:)

[hust_xcl]

I believe that the GPU for H.264 encoding matters only if the GPU can do interpolation, integer-pel and, mode decision, transform and quantization.
If you only offload the integer-pel ME and interpolation, it is less significant.

Sub-pel ME depend upon the interger -pel me. It will be the next step to do. Sometimes, Sub-pel ME costs more time than integer-pel ME. But, at first, we should offload interger me to gpu while mataining the encoding qulity.

[Sirber]

I came across this:

Parallelization of the x264 encoder using OpenCL
http://li5.ziti.uni-heidelberg.de/x264gpu/

[LoRd_MuldeR]

Can you please avoid including EXTREMELY large images directly in your post?

Thanks!

[kypec]

Maybe someone should inform those people that we're able to use colours to achieve better presentation on our screens. All that B&W looks like 20s' technology to me, not the third millennium we're actually in.

[deekey777]

The upcoming AMD HD7900 (SI) come with some new media processing instructions:
http://forum.beyond3d.com/showpost.php?p=1607240&postcount=1588
What do you think?

(And there will be an integrated videoencoder called VCE)

[CruNcher]

Nice :) i wonder what Nvidia will come up with im pretty sure they also worked on better Motion Estimation but AMD/ATI was first with Steady Video (Realtime Deshaking) and now enhances it 1 step further

[hajj_3]

here is some more info on AMD'S "Graphics Core Next" a.k.a GCN: http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute

[CruNcher]

Here is some new Information about the inner working of Quicksync and which parts are still related to the EU (Shaders) and how turbo boost influences this (frequency changes) http://software.intel.com/sites/landingpage/vcsource/frame.php?u=http%3A//software.intel.com/en-us/articles/using-intel-graphics-performance-analyzer-gpa-to-analyze-intel-media-software-development-kit-enabled-applications
Its a very interesting read :) it also shows that their are still ways to improve the quality on the Driver side :)


Motion Estimation Track
The Motion Estimation Track is actually the kernel software which runs on the Execution Units (EUs) of the graphics unit. This kernel is executed while adaptively invoking the motion estimation acceleration hardware. The actual behavior depends on the TargetUsage set by the application. Here we can see 4 stages inside the Motion Estimation Track with MFX_TARGETUSAGE_BALANCED mode. The performance of this track depends on the usage parameter, but it is also affected by whether graphics Intel Turbo Boost Technology is on or off.

[BlackSand]

I came across this:

Parallelization of the x264 encoder using OpenCL
http://li5.ziti.uni-heidelberg.de/x264gpu/

I found this is rather old (2010) and still rather unknown work. But encoding speed gain may be impressive:
Readme from https://github.com/jnorthrup/gpu_x264:

this appears to be a splice from libx264.67.so which was not introduced to mainline x264 development.

with some amount of manual downloading and assembly i was able to encode 600 frames of big buck bunny per the original demo script at 151 fps on a 3.3 ghz stock i980x core i7 on linux 3.1pre with radeon 6970 @ 910mhz/300Ram-Mhz + AMD APP 2.5. (typically only 1x encoding by multicore cpu alone.)

credit given to original project authors http://li5.ziti.uni-heidelberg.de/x264gpu

James Northrup

Can someone make compiled encoder from this source? There are win32 project files in the "build" folder also. I think many people would be interested in testing this encoder.

May some of the x264 devs take a look into this project also? The only comments I've found is http://doom10.org/index.php?topic=571.0

[MasterNobody]

May some of the x264 devs take a look into this project also? The only comments I've found is http://doom10.org/index.php?topic=571.0
There is nothing new here (copy of the same outdated sources with little bit changed demo.sh and configure). So that comments from the link are still valid.

[Filker]

Just found some opensource stuff to access VCE (AMD) in virtualdub (yes I still use it :P ) and a versatile screen capture util with VCE support. Gotta admit I never used AMD's utils built in the drivers (AMD Quickstream? Raptr? Gaming evolved? I dunno they just keep tossing out stuff with "user friendly" GUI's that won't get you anywhere) as they seem to be more game oriented.

OpenencodeVFW (based on AMD's openencode source):
https://github.com/jackun/openencodevfw

Open Broadcaster with VCE support:
https://obsproject.com/forum/threads/obs-branch-with-amd-vce-support.13996/

I only have VCE 1.0 equipment, so couldn't try out VCE 2.0 (kaveri, hawaii and low power am1 beema/mullins) which supports B-frames and up to 5.1 profile
It's fast (transcoding x264 720p at around 80 fps- perhaps bottlenecked by the decoder?), even on highest quality settings. But the bitrate/quality ratio isn't as good as x264.

My wishlist for VCE:
Higher quality even at the cost of speed decreases.
Dual graphics/X-fire support (use more than one dGPU and/or APU to encode/assist encoding the same stream).
hybrid GPU/x86 encoding: "software encoding" with more parts of h264 on the GPU, like OpenCL lookahead - maybe with HSA and the new H265 standard built around multi-core this will be easier to implement.