Cuda Challenge for x264 ... ?

[the_corona]

Just stumbled upon this bit longer article about "Elemental's GPU Accelerated H.264 Encoder".

http://www.anandtech.com/video/showdoc.aspx?i=3339

Maybe its off interest to some, although It seems x264 has decided against GPU (or do I interprete the responses incorrectly?). I couldn't really figure out what FPGA's are (does any consumer have them?)

[cogman]

Just stumbled upon this bit longer article about "Elemental's GPU Accelerated H.264 Encoder".

http://www.anandtech.com/video/showdoc.aspx?i=3339

Maybe its off interest to some, although It seems x264 has decided against GPU (or do I interprete the responses incorrectly?). I couldn't really figure out what FPGA's are (does any consumer have them?)

Its not that they are against it, its just that it would be hard to make something good that doesn't just work on people with nvidia GPUs. I think that OpenCL would be much more promising for x264.

FPGA is basically reprogramable hardware. they aren't extremely expensive but I imagine most consumers don't have them (though they have access to them). They are great for training CompEngineers as you just have to make the schematic and then plug in the board.

[Dark Shikari]

An update for those who care; if the numbers we have now are correct, the FPGA currently being designed can do about 6 billion 16x16 SADs per second using a 64x64 exhaustive motion search on one reference frame.

No GPU can even come close to that order of magnitude :devil:

[Inventive Software]

Compare that with a conventional CPU. ;)

[akupenguin]

x264's ESA takes about 8 cycles per 16x16 SAD. On an 8core 3GHz box, that's 3 billion SADs per second. Of course the FPGA is much cheaper than such a beefy CPU. Otoh, ESA isn't really what you want, it's just what's easy to implement on a FPGA.

[cogman]

An update for those who care; if the numbers we have now are correct, the FPGA currently being designed can do about 6 billion 16x16 SADs per second using a 64x64 exhaustive motion search on one reference frame.

No GPU can even come close to that order of magnitude :devil:

What kind of bandwidth will that thing need? Could you put it on a USB stick, or would it need something like a PCI express 1x slot (or 16x)

[Dark Shikari]

What kind of bandwidth will that thing need? Could you put it on a USB stick, or would it need something like a PCI express 1x slot (or 16x)PCI-Express. 1x is probably sufficient.

The price of a board would probably on the order of magnitude of $200-$400.

[nekrosoft13]

http://www.techarp.com/editorials/img/0823_PhysX_05.png

this is the performance we might expect from well written Cuda app.

I wonder how my GTX 280 does ;)

[Dark Shikari]

http://www.techarp.com/editorials/img/0823_PhysX_05.png

this is the performance we might expect from well written Cuda app.

I wonder how my GTX 280 does ;)I can make great charts if I completely make up numbers too. ;)

All comparisons I have seen of this sort are utter bullshit that probably is doing something on the order of comparing the graphics card to the JM encoder, because their speeds for CPU encoding are usually off by at least a factor of 16 if not more. Its quite easy to beat the competition if you lie about their encoding speed.

[Gabriel_Bouvigne]

Come on, we don't even know how the resulting video looks like...

[cogman]

I can make great charts if I completely make up numbers too. ;)

All comparisons I have seen of this sort are utter bullshit that probably is doing something on the order of comparing the graphics card to the JM encoder, because their speeds for CPU encoding are usually off by at least a factor of 16 if not more. Its quite easy to beat the competition if you lie about their encoding speed.

Its not lieing, its marketing! But yeah, your point is completely valid. We have no Idea what the results look like, what settings where used for the encodes. Heck we don't even know if they where encoding to the H.264 standard or cutting corners.

[Dark Shikari]

Also, you notice in their graph that a 3Ghz quadcore is barely more than twice as fast as a 1.2Ghz dualcore--meaning the encoder they tested with was singlethreaded :rolleyes:

Here's a slightly more accurate graph using x264 numbers (assuming HD is defined as 720p, which appears to be what they're going for):

http://i31.tinypic.com/2nvs9dh.png

[Zep]

Also, you notice in their graph that a 3Ghz quadcore is barely more than twice as fast as a 1.2Ghz dualcore--meaning the encoder they tested with was singlethreaded :rolleyes:

Here's a slightly more accurate graph using x264 numbers (assuming HD is defined as 720p, which appears to be what they're going for):

http://i31.tinypic.com/2nvs9dh.png

I have a 3.4GHz quad core and I can't even get 110 FPS on the first pass on 720p. More realistic rates are 80 on first pass and 25 on second using

x264.exe --pass 1 --bitrate #### --stats "some.stats" --threads auto │
│ --keyint 240 --min-keyint 24 --bframes 3 --b-pyramid --me dia --subme 1 │
│ --partitions none --progress --no-psnr --no-ssim --output NUL │
│ "some.avs" │
│ │
│ x264.exe --pass 2 --bitrate #### --stats "some.stats" --threads auto │
│ --keyint 240 --min-keyint 24 --ref 3 --bframes 3 --b-pyramid --bime │
│ --weightb --subme 6 --trellis 1 --8x8dct --progress --no-psnr --no-ssim │
│ --output "some.mkv" "some.avs"



with an avs doing a basic straight feed. i.e. no resize, no decimate etc... from a HDTV 720p source and all 4 cores maxed out on both passes.

[Dark Shikari]

I have a 3.4GHz quad core and I can't even get 110 FPS on the first pass on 720p.Yes, because you're actually using half-decent settings ;)

If you skimp much more on your settings and drop to baseline profile, you can do better.

Actually, if you're willing to completely trash your settings (Baseline, dia, low merange, subme1, no dct decimate, no partitions, no scenecut, no deblocking, no AQ, constant quantizer), you can get about 56 FPS, singlethreaded, on a 3Ghz Core 2 on 64-bit Linux (and probably slightly higher on a Penryn). Assuming perfect scaling, which is expected with no B-frames or scenecut, you could reach about 240FPS or more on a quadcore.

Fun fact: Xvid only gets 54FPS on fastest settings on one core of that machine.

With four threads, that completely trashes the 9800GTX. We have no idea what quality the GPU encoder produces, of course; I'm guessing its awful, but we won't know for sure until they stop posting bullcrap benchmarks and post actual streams.

[MfA]

An update for those who care; if the numbers we have now are correct, the FPGA currently being designed can do about 6 billion 16x16 SADs per second using a 64x64 exhaustive motion search on one reference frame.
Is that with SEA?

[Dark Shikari]

Is that with SEA?No, SEA is not practical to implement on an FPGA as far as I know. Its just raw ESA.

[MfA]

Hmm, it has been said that on large FFTs the new AMD Firestream could get 170 GFLOPs throughput (which is outrageously fast when compared to CUFFT, nearly an order of magnitude faster than 8800s). If that's really true you could do a 128x128 fast full SSD search about as fast as with the FPGA full SAD search.

Of course initial ME is only half the battle (if that). RDO mode optimization and MV refinement are just as much performance killers ... and slightly harder to implement on FPGAs or GPUs.

[Dark Shikari]

Hmm, it has been said that on large FFTs the new AMD Firestream could get 170 GFLOPs throughput (which is outrageously fast when compared to CUFFT, nearly an order of magnitude faster than 8800s). If that's really true you could do a 128x128 fast full SSD search about as fast as with the FPGA full SAD search.SSD is a worse motion search metric than SAD.Of course initial ME is only half the battle (if that). RDO mode optimization and MV refinement are just as much performance killers ... and slightly harder to implement on FPGAs or GPUs."Slightly" is the understatement of the century.

[akupenguin]

Hmm, it has been said that on large FFTs the new AMD Firestream could get 170 GFLOPs throughput (which is outrageously fast when compared to CUFFT, nearly an order of magnitude faster than 8800s).
... and still slower than a plain old CPU. Remember where I said that a decent 8core does 3 billion SAD-equivalents per second? (SEA, so not all of those are real, but you're not planning to implement SEA on GPU either) 1 SAD is 768 arithmetic ops, so a brute force implementation would need 2.3 TFLOPS to match that CPU.

[MfA]

Only most of the time :) It's fixed time complexity as opposed to SEA. My point was to compare it to the FPGA though, not the CPU.

[slavickas]

I can make great charts if I completely make up numbers too. ;)

All comparisons I have seen of this sort are utter bullshit that probably is doing something on the order of comparing the graphics card to the JM encoder, because their speeds for CPU encoding are usually off by at least a factor of 16 if not more. Its quite easy to beat the competition if you lie about their encoding speed.
I think they compare quicktime or is it slowtime, at least in youtube video from GT200 presentation they talked about quicktime

[Snowknight26]

http://www.guru3d.com/news/download-ati-avivo-xcode-pack-for-hd4800-series/

Apparently it uses the GPU, even though I've been lead to believe that Avivo does it with the CPU.

[d0ORk]

Any news on the Cuda Support for x264?

[Blue_MiSfit]

If there was, it would be all over the boards :)

So, no.

It doesn't matter though.

~MiSfit

[LoRd_MuldeR]

Any news on the Cuda Support for x264?

The facts remain the same: Despite all the marketing blabber, CUDA isn't the perfect platform to do video encoding.
All those "CUDA H.264 encoders" that are available on the market sacrifice a whole lot of quality in order to reach fast encoding speed.
If CUDA really was that great for video encoding, we would have seen at least one competitive product. But so far they all have been disappointing!
The upcoming "Fermi" generation has some nice improvements, but it isn't available yet. We'll see if it makes CUDA encoding more attractive...

[aegisofrime]

The facts remain the same: Despite all the marketing blabber, CUDA isn't the perfect platform to do video encoding.
All those "CUDA H.264 encoders" that are available on the market sacrifice a whole lot of quality in order to reach fast encoding speed.
If CUDA really was that great for video encoding, we would have seen at least one competitive product. But so far they all have been disappointing!
The upcoming "Fermi" generation has some nice improvements, but it isn't available yet. We'll see if it makes CUDA encoding more attractive...

Both Fermi and the Radeon 58xx series feature DX11 and OpenCL. Do Fermi have any advantages with regards to GPU encoding?

[LoRd_MuldeR]

Both Fermi and the Radeon 58xx series feature DX11 and OpenCL. Do Fermi have any advantages with regards to GPU encoding?

The interfaces (API's) they support aren't that important.

OpenCL basically is CUDA, or at least heavily inspired by CUDA. They just renamed a few things and changed the API calls a bit here and there ;)

While I have no idea about the "ComputeShaders" of DX11, I assume they aren't much different. That's because the capabilities and limitations of the underlying GPU hardware are the same.

Fermi has some huge advantages. Memory accesses to the "global" GPU memory are now cached - for reading and writing. Before only the read-only "texture" memory was cached.

However one fundamental limitation of GPGPU processing remains: The GPU can only access the GPU memory. So all input data that is processed on the GPU needs to go through the slow PCIe bus first.

Also results must go the same way back. Hence moving only a small function to the GPU is useless, even if it is 100x faster there. The delay for moving the data would simply be too long!

That's exactly the reason why you cannot take x264 as-is, move a few functions to the GPU and expect speed-up. Instead complete algorithms would have to be re-implemented on the GPU.

In some cases you even need to invent completely new algorithms, because your existing algorithms simply don't scale well on the GPU ...

[hajj_3]

It would be cool if the x264 team could manage to put some of the functions of x264 to be done by a fermi gpu, i'm sure alot of us would appreciate, especially as the low end nvidia cards come out at around £40 when launched and lower to about £30 after a few months.

[LoRd_MuldeR]

It would be cool if the x264 team could manage to put some of the functions of x264 to be done by a fermi gpu, i'm sure alot of us would appreciate, especially as the low end nvidia cards come out at around £40 when launched and lower to about £30 after a few months.

As explained in the previous post, you cannot simply pick individual functions and move them to the GPU :rolleyes:

Furthermore it's not guaranteed at all that the GPGPU improvements of the 'Fermi' generation will actually be relevant for x264.

Last but not least, you would have to expect a significant lower encoding performance from those cheap "low end" graphics cards!

That's different from decoding, where a dedicated decoder chip (which is identical on all cards) does the job...

[CruNcher]

You shouldn't except such work from the X264 team but im sure we gonna see some Fermi enhanced stuff by Nvidias sponsored Elemental Technologies :) they practically also worked on those Encoding enhancements with Nvidia.

[Dark Shikari]

For reference, there is a company working on a custom proprietary codec (sponsored by ATI) designed specifically for GPUs, i.e. making compression sacrifices in the specification to make it more amenable to GPU parallelization. They can currently get about 120fps @ 4K resolution on a top-end ATI card, which is about 4-6 times faster than x264 on ultrafast on a top-end Core i7. This is a pretty reasonable performance boost to expect from such an "ideal situation" in which the spec itself can be modified to suit the GPU.

[hajj_3]

will the spec be open sourced so that you can see it's code and copy good bits into x264 code?

[LoRd_MuldeR]

will the spec be open sourced so that you can see it's code and copy good bits into x264 code?

1) I highly doubt they will release the source code of their encoder under an OpenSource license. They probably prefer selling a commercial encoder software ;)

2) However they may make the specs for their new video format available (but not necessarily for free), so others can implement their own encoders or decoders for that format.

3) Even if they did make their code/specs public, it would be completely irrelevant for x264, because x264 is H.264 encoder. Not an encoder for ATI's video format!

[popper]

OC as Bridgeman the AMD executive in charge of linux code and docs reminds us "IIRC the Evergreen family (HD54xx and up) includes a few Sum of Absolute Differences shader instruction variants so one obvious task would be using those instructions to speed up motion estimation... details in the Evergreen shader instruction doc on our Stream site.
"

and yet no one capable seems that interested in making any proof of concept code available to test this GPU SAD speeds to see if that could be a useable option for any future part offload options to date.
http://developer.amd.com/gpu/ATIStreamSDK/assets/AMD_Evergreen-Family_ISA_Instructions_and_Microcode.pdf

http://developer.amd.com/gpu/ATIStreamSDK/pages/Documentation.aspx
http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=124677&enterthread=y&startpage=1
"There is also a detailed document describing the shader instruction set. Look for the "AMD Evergreen Family ISA Microcode and Instructions" document at :

http://developer.amd.com/gpu/ATIStreamSDK/pages/Documentation.aspx
"

[aegisofrime]

For what it's worth, nVidia bundles a CUDA encoding plugin for Adobe Premiere and After Effects with their Quadro GPUs. You would think that logically, since they are targeting this bundle at professionals, it should, at least, *not suck so hard*.

Incidentally its made by Elemental, the same people behind Badaboom, so it remains to be seen if its any better than Badaboom.

nVidia ad for the plugin:

http://www.youtube.com/watch?v=BZkK9HoxUvo

Unfortunately the Internet is chock full of news reports about this piece of software, but not much in the way of reviews...

[edison]

For what it's worth, nVidia bundles a CUDA encoding plugin for Adobe Premiere and After Effects with their Quadro GPUs. You would think that logically, since they are targeting this bundle at professionals, it should, at least, *not suck so hard*.

Incidentally its made by Elemental, the same people behind Badaboom, so it remains to be seen if its any better than Badaboom.

nVidia ad for the plugin:

http://www.youtube.com/watch?v=BZkK9HoxUvo

Unfortunately the Internet is chock full of news reports about this piece of software, but not much in the way of reviews...


here is a Chinese review on it:

http://www.pcinlife.com/article/graphics/2009-08-05/1249460047d833_1.html

[julius666]

The GPU can only access the GPU memory. So all input data that is processed on the GPU needs to go through the slow PCIe bus first.

Also results must go the same way back. Hence moving only a small function to the GPU is useless, even if it is 100x faster there. The delay for moving the data would simply be too long!

That's exactly the reason why you cannot take x264 as-is, move a few functions to the GPU and expect speed-up. Instead complete algorithms would have to be re-implemented on the GPU.

And what about Intel's new Clarkdale architecture with the integrated GPU? The PCIe bus can't be the bottleneck in that case. And in the future (almost) all CPU will carry a GPU, so it's probably worth the effort.

[LoRd_MuldeR]

And what about Intel's new Clarkdale architecture with the integrated GPU? The PCIe bus can't be the bottleneck in that case. And in the future (almost) all CPU will carry a GPU, so it's probably worth the effort.

Those "on board" GPU's avoid the PCIe bottleneck, indeed. But those are "low end" GPU's. You can't expect any noteworthy encoding performance from them.

Even the cheapest PCIe graphics card will outperform those "on board" chips easily! And Intel's "on board" chips are even much weaker than NVidia's "on board" chips.

Furthermore I'm not aware of any efforts to support OpenCL or DirectX ComputeShaders by Intel...

Again decoding performance is a different topic, because most "on board" chips have dedicated hardware for BluRay (H.264/VC1) decoding now.

[aegisofrime]

And what about Intel's new Clarkdale architecture with the integrated GPU? The PCIe bus can't be the bottleneck in that case. And in the future (almost) all CPU will carry a GPU, so it's probably worth the effort.

Those GPUs have only replaced the previously rubbish Intel IGPs with a slightly less rubbish Intel HD Graphics. In fact, why Intel would move the IGP off the motherboard onto the CPU package is beyond me, since it doesn't have have GPGPU motivations, unlike AMD Fusion (I think)

[Deinorius]

In fact, why Intel would move the IGP off the motherboard onto the CPU package is beyond me That's easy. It makes production cheaper, power consumption goes down as you could already see with Lynnfield. Maybe even graphics performance gets a boost like general performance itself because of the memory-controller/iGPU directly on the package (lower latencies).

And, of course Intel can dominate the chipset market for their own cpus but that's more a nice side effect.

[aegisofrime]

That's easy. It makes production cheaper, power consumption goes down as you could already see with Lynnfield. Maybe even graphics performance gets a boost like general performance itself because of the memory-controller/iGPU directly on the package (lower latencies).

And, of course Intel can dominate the chipset market for their own cpus but that's more a nice side effect.

Thanks for the explanation. That actually makes a lot of sense, from the standpoint of a budget user actually :D

I just hope that Fusion is something different. AMD bought ATI precisely for Fusion, and if it's just another Clarksdale...

[Deinorius]

Fusion is quite the same like Clarkdale, just more developed. In combination like Optimus you can use a nvidia card for anything you need, but when you don't need it, you get the low power consumption like Clarkdale delivers.

[MfA]

and yet no one capable seems that interested in making any proof of concept code available to test this GPU SAD speeds to see if that could be a useable option for any future part offload options to date.
The version of the SDK with the SAD instruction actually exposed is only a couple days old ... also there are not a lot of people who are comfortable with CAL IL programming.

Just for reference this is the instruction (for 4x4 SAD) :
Instructions SAD4

Syntax sad4, scr0, src1, src2

Description Sad8(src, src1) forms the sum of absolute differences, treating sr0 and src1 as a vector of eight-bit unsigned integers. This is a special instruction for multi-media video dst.xyzw = sad8(sr0.x,src1.x) + sad8(sr0.y,src1.y) + sad8(src0.z,src1.z) + sad 8(src0.w, src1.w) + r2.x . The 32-bit result is replicated to all four vector output slots. Valid for Evergreen GPUs and later.

Just put a number to the madness, purely looking at the SAD instruction that means a 5870 can hit a peak of 320*850 MHz = 272 GigaSAD/s (4x4). For comparison an I7 at 3 GHz does peak 4*2*3 GHz = 24 GigaSAD/s (4x4 using mpsadbw).

[jakor]

For reference, there is a company working on a custom proprietary codec (sponsored by ATI) designed specifically for GPUs, i.e. making compression sacrifices in the specification to make it more amenable to GPU parallelization. They can currently get about 120fps @ 4K resolution on a top-end ATI card, which is about 4-6 times faster than x264 on ultrafast on a top-end Core i7. This is a pretty reasonable performance boost to expect from such an "ideal situation" in which the spec itself can be modified to suit the GPU.

How do they deliver this amount of raw data to the processing unit ?
it is 4,000 * 2,000 * 1.5 (case of YV12) * 120 = 1,440,000,000 bytes per sec.
also for x264 case 5 times lower it is close to SATA limit of 3 Gbps...
Are these calculations correct ?

[mariush]

Well, I'd imagine they probably have a custom ATI card with some HDMI input like the Blackmagic cards... or they'd just get 2 gigabit network cards and team them up so they'd have 2gbps input from network.... with 8-16 GB of DDR3 memory you'd have enough to cache...

Now I don't know the throughput, uploading to the video card may be slower but as far as I know the PCI Express slots have tons of bandwidth...of course, if they have hdmi input port straight on the cards it's moot point.

Just guesses, I'm no expert...

[jakor]

Well, I'd imagine they probably have a custom ATI card with some HDMI input like the Blackmagic cards... or they'd just get 2 gigabit network cards and team them up so they'd have 2gbps input from network.... with 8-16 GB of DDR3 memory you'd have enough to cache...

Now I don't know the throughput, uploading to the video card may be slower but as far as I know the PCI Express slots have tons of bandwidth...of course, if they have hdmi input port straight on the cards it's moot point.

Just guesses, I'm no expert...

1.440.000.000 bytes per sec is 14 Gbps. HDMI upper limit is just 10.2 (judging from wiki). Anyway - what's on the other end of the HDMI or network cable ? which device is capable of producing this kind of data ?
or maybe those guys just generate some textures onboard...

[Disabled]

Or they only reencode bitstreamed videos. Ie upload an h264 to the card and get a reencoded file back.

[Dark Shikari]

Or they only reencode bitstreamed videos. Ie upload an h264 to the card and get a reencoded file back.Not possible, the card can't decode 4K at 120fps.

[ExSport]

Maybe noob question but it is possible to use cuda for decoding part so x264/mencoder/ffmpeg can save some cycles with decoding and use it for encoding part?
Are there some theoretical/practical limitations?
Could this have some performance gain or it will be unnoticable?
Many thanks!
P.S.
I did some testing with MEncoder from Sherpya and CoreAvc and for some movies speedup was about 25%, for other files no difference or slower...
But compression was done to MPEG2, not x264.
Original file was h264 from Blu-Ray.

[LoRd_MuldeR]

Maybe noob question but it is possible to use cuda for decoding part so x264/mencoder/ffmpeg can save some cycles with decoding and use it for encoding part?

You don't need CUDA to decode H.264 in hardware, because all up-to-date graphics cards contain dedicated decoding hardware for H.264, VC-1 and MPEG-2. And there are many solutions available to use your graphics card's hardware decoder. DXVA is playback only, so it's not an option for encoding tasks. However DirectShowSource+CoreAVC or DGAVCIndexNV can be used to decode the source in hardware and feed it into x264. But don't get confused: "CUDA decoding" in CoreAVC/DGAVCIndexNV does NOT mean they implemented a H.264 in CUDA. They simply use the "CUDA Video API" to access the graphic's card VP2 decoder chip. While "real" CUDA kernels run on the actual GPU, the hardware H.264/VC-1/MPEG-2 decoder is separate/specialized hardware that doesn't do anything else but decoding video...