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 .