x264 OpenCL

[aegisofrime]

Now before you guys groan and say "Oh not another noob asking for a GPU accelerated OpenCL", take a look at this article first:

http://www.anandtech.com/show/5835/testing-opencl-accelerated-handbrakex264-with-amds-trinity-apu

Yes there actually is an implementation of x264 with the lookahead function offloaded to the GPU. And the speed difference is quite impressive actually. Now the question is where can we download it :p

[06_taro]

x264's dev IRC has been testing OpenCL lookahead for months. You can join the IRC, request for the patch, compile a binary, and test or use on your own risk.

[Dark Shikari]

It's buggy and nowhere near ready for serious usage, but you can test it if you want; ask muggs on IRC.

Buggy drivers aren't helping either.

[fields_g]

The open source community thus far hasn't been very interested in supporting Intel's proprietary technologies. As a result, Quick Sync remains unused by the applications we want to use for video transcoding.

I thought there were issues with getting useful APIs from Intel... correct me if I'm wrong.

[Dark Shikari]

Intel provides a very minimal high-level encoding API missing all but the most basic features for video encoding. The low-level API is completely undocumented and barely half existent, and they haven't shown any real interest in exposing it in any real way.

Naturally, it's unsurprising that people aren't interested in something that Intel themselves doesn't seem to care about.

[aegisofrime]

It's buggy and nowhere near ready for serious usage, but you can test it if you want; ask muggs on IRC.

Buggy drivers aren't helping either.

Thanks for the kind reply. I'm assuming that there are some technical competence requirements to be a tester? Seeing as this is beta...

[wiak]

Thanks for the kind reply. I'm assuming that there are some technical competence requirements to be a tester? Seeing as this is beta...
well beta means that is buggy, and people should send in logs/systeminfo and samples of files that fail to encode

:stupid:

nice to see x264 getting opencl support, keep up the awesome work Dark Shikari & you other awesome devs

and it might be useful to make this the offical x264 opencl thread, so people dont post yet more threads about the same subject :)

[RunningSkittle]

unfortunately catalyst driver on linux does not support latest xorg 1.12

many people will be unable to test.

[ajp_anton]

So is this largely thanks to AMD finding uses for their superior iGPU compared to Intel?

What kind of speedup is expected? I know it depends on CPU/GPU, but I'm fine with an "up to" =).

[wiak]

So is this largely thanks to AMD finding uses for their superior iGPU compared to Intel?

What kind of speedup is expected? I know it depends on CPU/GPU, but I'm fine with an "up to" =).
check anandtech arcticke :p
6.98 without OpenCL > 15.01 with OpenCL
and thats on midrange radeon 6000 series class chip, i wonder how it is on a HD 7970 or even HD 7990 when that comes
:stupid:

[ajp_anton]

Haha, forgot they actually tested it =).
But it's still not finished. Is it speed-optimized and just needs some bugs fixed, or will it get even faster?

[aegisofrime]

check anandtech arcticke :p
6.98 without OpenCL > 15.01 with OpenCL
and thats on midrange radeon 6000 series class chip, i wonder how it is on a HD 7970 or even HD 7990 when that comes
:stupid:

Actually I won't be surprised if a discrete card ends up being slower. Remember that the Radeon on Trinity is on the same die. I'm not sure how much sending data over PCI-E and back will affect the speed.

Developers please correct me if I'm saying something stupid.

[JoeH]

Is this currently working (as well as an alpha can work, of course) on NVidia as well as AMD? I know NVidia as implemented OpenCL, but I'm not sure if there implementation is as complete as AMD's.

[JEEB]

Is this currently working (as well as an alpha can work, of course) on NVidia as well as AMD? I know NVidia as implemented OpenCL, but I'm not sure if there implementation is as complete as AMD's.
When I tested the patch the last time, it compiled and worked on my 9600M GS just fine.

Also, the patch is available (http://doom10.org/index.php?topic=2247.0) for public testing by the developer over at Doom10.

[Atak_Snajpera]

I assume that it requires OpenCL 1.1 GPU at least?

[JEEB]

I assume that it requires OpenCL 1.1 GPU at least?
GPU-Z shows my GPU as "Supported profile: OpenCL 1.0" and, unless a lot has changed since I last tested it, it should work just fine :)

[sneaker_ger]

Could you share your build, JEEB?

[aegisofrime]

Could you share your build, JEEB?

Seconded. I tried to patch and compile it myself but I have no idea what to do when it asked for the file to patch :p

[aufkrawall]

Oh yes, that would really be very interesting, even though it's still "alpha".

[spawnbsd]

Could you share your build, JEEB?

I second this, even if its an alpha build, I'd be willing to play with it.

[06_taro]

A test build (http://astrataro.wordpress.com/2012/05/17/x264-test-build-with-opencl-lookahead/)

Compiled with APP's SDK. Can also run on NVidia cards, but not sure if it would be faster or not on NV cards when compiled with CUDA SDK....

[sneaker_ger]

Thx.
Crashes my graphic driver, so beware!
Radeon HD 5850, Catalyst 12.4, Win7 x64

[06_taro]

Actually crashed once in about 10 tests on my HD6770M, Catalyst 12.3, Win7 x64. :P

[sneaker_ger]

Then you have more luck than me. Mine crashes 60% of the time .... every time.
The BSOD right now was probably my PC telling me it's time to stop trying.

[06_taro]

Oops, that's terrible....

The only case it crashed was when I use Ctrl+C to terminate the process, which now I found is always crashing.
And my friends's GTX460 hadn't met crash in normal usage.
Not sure if 12.4 has any issues with APP runtime or I have any problems with my compiling configure....

[aufkrawall]

It works here but GPU load is very low.
Do I have to consider any commands?

[Audionut]

Looks like the patch has disappeared.

Quick tests on the test build, I'm finding that the higher the encoded bitrate, the lower the performance increase.

dgnv 1440x1080 source, preset veryslow

Around 60% @ 350kbps
45% @ 1500kbps
8% @ 6500kbps

preset medium (default)
12% @ 1500kbps
6% @ 5000kbps

[aegisofrime]

I just tested it. Thanks for the build, 06_taro!

The source file is 4000 frames out of a 720p H.264 file. The source filter is FFVideoSource. No crashes during the test.

Preset was --crf 21 preset "slower". That's it.

Speed wise:

OpenCL: 17.83 fps
Normal: 11.12 fps

The OpenCL version did produce a slightly bigger file, as Anandtech noted. The OpenCL file was 61.6MB and the normal file 60.8MB.

My system:

i7-2600K
16GB RAM
Radeon 7850

Edit: I'm doing more comprehensive tests to determine is the crashes are driver related, or GPU generation related. Perhaps GCN is more stable?

[06_taro]

In my tests opencl lookahead always archives lower ssim with higher bitrate. Tested with --tune ssim --ssim, and with/without --no-opencl.

[aegisofrime]

In my tests opencl lookahead always archives lower ssim with higher bitrate. Tested with --tune ssim --ssim, and with/without --no-opencl.

Could you post a short guide on how to build? I'm just stuck at the part where after I have "patch -p < "C:/x264/OpenCL.diff"", I get a prompt asking me what file I want to patch :p

[06_taro]

Here's a step-by-step guide: How to Compile x264 on 32 & 64 Bit Windows (http://doom10.org/index.php?topic=26.0). The only thing not mentioned in this article is that building x264 with opencl support needs opencl sdk installed in your system. Either CUDA SDK or AMD APP SDK is required. The opencl libs will be checked during configuring.

[aegisofrime]

Here's a step-by-step guide: How to Compile x264 on 32 & 64 Bit Windows (http://doom10.org/index.php?topic=26.0). The only thing not mentioned in this article is that building x264 with opencl support needs opencl sdk installed in your system. Either CUDA SDK or AMD APP SDK is required. The opencl libs will be checked during configuring.

In fact I did use that guide. The unclear part is the patching, because I was prompted for which file to patch. I didn't know what to fill in.

Basically what I did was to save the patch as OpenCL.diff. I then moved this file to my x264 folder.

Here's my build script:

#!/bin/bash -x
set -e
#git clone git://git.videolan.org/x264.git "C:/x264"
patch -p1 < "C:/x264/OpenCL.diff"
cd "C:/x264"
CFLAGS=-march=corei7-avx ./configure --cross-prefix=x86_64-w64-mingw32- --host=x86_64-pc-mingw32 --enable-win32thread --bit-depth=10
make fprofiled VIDS="C:/fprofile.avs"

Did I get the order correct?

Edit: Hmmm maybe my problem was that I didn't have the AMD APP SDK installed? I will install that and try again.

[Audionut]

Can someone also re-upload the patch please.

[aegisofrime]

Can someone also re-upload the patch please.

There ya go:

http://www.mediafire.com/?8qxxp7zbocqn14m

[06_taro]

In fact I did use that guide. The unclear part is the patching, because I was prompted for which file to patch. I didn't know what to fill in.

Basically what I did was to save the patch as OpenCL.diff. I then moved this file to my x264 folder.

Here's my build script:

#!/bin/bash -x
set -e
#git clone git://git.videolan.org/x264.git "C:/x264"
patch -p1 < "C:/x264/OpenCL.diff"
cd "C:/x264"
CFLAGS=-march=corei7-avx ./configure --cross-prefix=x86_64-w64-mingw32- --host=x86_64-pc-mingw32 --enable-win32thread --bit-depth=10
make fprofiled VIDS="C:/fprofile.avs"

Did I get the order correct?

Edit: Hmmm maybe my problem was that I didn't have the AMD APP SDK installed? I will install that and try again.

"cd /c/x264" before patching, then patch.exe will find the files to be patched.

Also note that opencl lookahead doesn't support high bit depth, so don't build 10-bit version.

[Bloax]

Well it's a bit faster @ --preset Medium & --crf 25.05 (and lots of other stuff) here, though with about 1 fps. (Strangely enough --rc-lookahead 80 was almost 2 fps faster than non-ocl)

Of course I just compared it to a x264 build without OCL that I had before.

My silly machine: C2D E8600 @ 3.67 Ghz and a 9800 GT.

If it crashes, then that's a bit unfortunate for it, since the video I tested it on (I was lazy, so it was a 0:29 clip) turned out to be 3 MB bigger than the normal x264.
But yeah, it's a nice feature and all - but it's far from there. :/

[JEEB]

In my tests opencl lookahead always archives lower ssim with higher bitrate. Tested with --tune ssim --ssim, and with/without --no-opencl.
Yes, it isn't using the same algorithms :)

One of the problems for GPU lookahead pretty much seems to have been the fact that you'd have to implement something completely new that would work on the GPU at least with some amount of speed (if not in the context of no such prior art, at least in the context of the application).

Should try building this version of the OpenCL patch with the nvidia's SDK, but I'm lazy to use dlltool on the dot-lib files for mingw (to create dot-a files) .-.

[Przemek_Sperling]

Is this currently working (as well as an alpha can work, of course) on NVidia as well as AMD? I know NVidia as implemented OpenCL, but I'm not sure if there implementation is as complete as AMD's.

The problem is that NV cards are pretty weak in OpenCL
http://vr-zone.com/articles/from-gtc-2012-amd-r7970-preferred-over-nvidia-kepler-in-real-gpgpu-deployments-/15903.html

[zbutsam]

I must be doing something wrong because the OpenCL build is about 2-3% slower with OpenCL activated than with the --no-opencl switch.

My PC is a Core2Duo E8200@3.4 Ghz with an Ati 5850 and Windows XP 32 Professional. I'm running the 11.12 Catalyst drivers which are the last to support OpenCL under XP. I can see my card speeding up from idle when running the OpenCL build but the load stays at 0%. I have tried OpenCL with other tools and benchmarks (to make sure it works) and the GPU load goes to 100%.

My x264 settings are
x264.exe --level 3.1 --preset slow --tune film --crf 20 --vbv-bufsize 14000 --vbv-maxrate 17500 --vbv-bufsize 14000 --vbv-maxrate 17500 -o e:\trailer.mkv e:\trailer.avs

[LoRd_MuldeR]

I must be doing something wrong because the OpenCL build is about 2-3% slower with OpenCL activated than with the --no-opencl switch.

GPUGPU, may it be implemented via OpenCL or via CUDA or via something else, is not the "magic" speed booster that many people seems to think. Just throwing your CPU code on the GPU won't work. Even if you manage to port your CPU code and make it run on the GPU, it will be slow like hell. Getting calculations done one the GPU fast usually requires completely new ideas/algorithms - and that's exactly where all those so-called "GPU Encoders" sacrifice quality for speed to get some nice FPS numbers for the marketing department! And even if you mange to get your calculations done on the GPU fast - and with "fast" I mean significant faster than on a state-of-the-art the CPU - then it's still not guaranteed that you'll see an overall speed-up! Uploading and downloading the data to/from the "device" (graphics card memory) causes a lot of overhead. Only if you still save time including that overhead then you might be able to see some overall speed-up...

In other words: It's very easy to port your CPU-based software to the GPU and get something that runs a lot slower than the original. At the same time getting something that actually runs faster is very difficult and sometimes impossible!

(There are some calculations that are "sequential" by nature and therefore will never run fast on a massively parallel processor, such as a GPU)

[aegisofrime]

GPUGPU, may it be implemented via OpenCL or via CUDA or via something else, is not the "magic" speed booster that many people seems to think. Just throwing your CPU code on the GPU won't work. Even if you manage to port your CPU code and make it run on the GPU, it will be slow like hell. Getting calculations done one the GPU fast usually requires completely new ideas/algorithms - and that's exactly where all those so-called "GPU Encoders" sacrifice quality for speed to get some nice FPS numbers for the marketing department! And even if you mange to get your calculations done on the GPU fast - and with "fast" I mean significant faster than on a state-of-the-art the CPU - then it's still not guaranteed that you'll see an overall speed-up! Uploading and downloading the data to/from the "device" (graphics card memory) causes a lot of overhead. Only if you still save time when considering that overhead you will be able to see some overall speed-up...

(In other words: It's very easy to port your CPU-based software to the GPU and get something that runs a lot slower than the original. At the same time getting something that actually runs faster is very difficult!)

And that might be part of the reason why Trinity sees such a huge speedup. That is assuming that the OpenCL code used by Anandtech is the same as what we have got here.

[mariush]

See http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope/2


Trinity still features two 64-bit DDR3 memory controllers with support for up to DDR3-1866 speeds. The controllers add support for 1.25V memory. Notebook bound Trinities (Socket FS1r2 and Socket FP2) support up to 32GB of memory, while the desktop variants (Socket FM2) can handle up to 64GB.

Hyper Transport is gone as an external interconnect, leaving only PCIe for off-chip IO. The Fusion Control Link is a 128-bit (each direction) interface giving off-chip IO devices access to system memory. Trinity also features a 256-bit (in each direction, per memory channel) Radeon Memory Bus (RMB) direct access to the DRAM controllers. The excessive width of this bus likely implies that it's also used for CPU/GPU communication as well.

IOMMU v2 is also supported by Trinity, giving supported discrete GPUs (e.g. Tahiti) access to the CPU's virtual memory. In Llano, you used to take data from disk, copy it to memory, then copy it from the CPU's address space to pinned memory that's accessible by the GPU, then the GPU gets it and brings it into its frame buffer. By having access to the CPU's virtual address space now the data goes from disk, to memory, then directly to the GPU's memory—you skip that intermediate mem to mem copy. Eventually we'll get to the point where there's truly one unified address space, but steps like these are what will get us there.

[Selur]

Gave it a short test spin with the version provided by 06_taro (http://forum.doom9.org/showthread.php?p=1574959#post1574959):
reencoding a small HD sample (8.Birds_1080p24fpsRef4-112Mbps posted by NikosD (http://forum.doom9.org/showthread.php?p=1539255#post1539255))

1st pass:
x264.exe --pass 1 --bitrate 2500 --profile high --level 4.1 --direct auto --b-adapt 2 --rc-lookahead 60 --stats "H:\Temp\sample.stats" --fps 24000/1001 --input-res 1920x1080 --output NUL -
2nd pass:
x264.exe --preset slower --pass 2 --bitrate 2500 --profile high --level 4.1 --ref 4 --vbv-maxrate 62500 --vbv-bufsize 78125 --colormatrix bt709 --stats "H:\Temp\sample.stats" --fps 24000/1001 --input-res 1920x1080 --output "H:\Temp\sample.264" -

normal 64bit version:
1st pass:
x264 [info]: kb/s:2096.56
encoded 543 frames, 17.59 fps, 2096.56 kb/s
2nd pass
x264 [info]: kb/s:2588.30
encoded 543 frames, 9.25 fps, 2588.30 kb/s

openCL 64bit version:
1st pass:
[info]: kb/s:2111.38
encoded 543 frames, 40.3178 fps, 2111.38 kb/s, 5.70 MB
2nd pass:
x264 [info]: kb/s:2571.07
encoded 543 frames, 9.3650 fps, 2571.07 kb/s, 6.94 MB

-> 2nd pass: nearly the same speed (too small difference to be sure it's caused by the mod)
-> 1st pass: more than twice the speed

=> faster 1st pass is nice :)

Cu Selur

Ps.: System I tested it with: Win7pro i7-875k@3.2Ghz, 16GB RAM, Geforce GTX 470

[Audionut]

-> 2nd pass: nearly the same speed (too small difference to be sure it's caused by the mod)
-> 1st pass: more than twice the speed

Considering all the lookahead is performed on the first pass, that's no suprise.

Also, the OpenCL test version you linked is 32bit.

[Selur]

Also, the OpenCL test version you linked is 32bit.
the x264_rev2197+666_tMod-opencl.7z I downloaded contains a 'x264_64_tMod+MixAQ+OpenCL-8bit-420' I figured that that would be a 64bit version,...

[06_taro]

You can use --no-opencl to disable opencl lookahead, and thus difference in build version should be avoided.

[Selur]

this time I took a 720p source, used crf and 2pass 1st encoding and always the opencl binary:

opencl:
x264 --preset slower --crf 18 --input-res 1280x720 --output "H:\Output\test.mp4" -
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: OpenCL: NVIDIA Corporation GeForce GTX 470
x264 [info]: profile High, level 4.0
x264 [info]: ...
x264 [info]: kb/s:1667.89
encoded 33974 frames, 24.2183 fps, 1667.89 kb/s, 270.20 MB
x264 [info]: ...
x264 [info]: encoding duration 0:23:23
normal:
x264 --preset slower --crf 18 --input-res 1280x720 --no-opencl --output "H:\Output\test.mp4" -
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: ...
x264 [info]: kb/s:1650.22
encoded 33974 frames, 23.2390 fps, 1650.22 kb/s, 267.34 MB
x264 [info]: ...
x264 [info]: encoding duration 0:24:22


I also did a 1st pass comparison.
opencl:
x264 --pass 1 --bitrate 1500 --stats "H:\Output\test.stats" --input-res 1280x720 --output NUL -
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: OpenCL: NVIDIA Corporation GeForce GTX 470
x264 [info]: profile Main, level 3.1
x264 [info]: ...
x264 [info]: kb/s:1522.79
encoded 33974 frames, 171.3133 fps, 1522.79 kb/s, 246.69 MB
x264 [info]: ...
x264 [info]: encoding duration 0:03:18


normal:
x264 --pass 1 --bitrate 1500 --stats "H:\Output\test.stats" --no-opencl --input-res 1280x720 --output NUL -
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 3.1
x264 [info]: ...
x264 [info]: kb/s:1523.24
encoded 33974 frames, 124.5961 fps, 1523.24 kb/s, 246.77 MB
x264 [info]: ...
x264 [info]: encoding duration 0:04:32

Cu Selur

[hajj_3]

we have only got opencl 1.0 on core i5 1st gen i believe. Wonder if someone could test that without a 3rd party gpu and see if there is any difference. This OpenCL support looks incredible, so much faster on 1st pass!

[wiak]

we have only got opencl 1.0 on core i5 1st gen i believe. Wonder if someone could test that without a 3rd party gpu and see if there is any difference. This OpenCL support looks incredible, so much faster on 1st pass!
it looks promising yes, lets hope they will release stable version before end of this year

[duncanvdlinden]

It still crashes on my system.
When i start encoding (with an AVS file) it don't start and my graphics driver crashed.
Invy Bridge 3770K
AMD HD6770
Win7 X64

Same encoding on an system from a friend with Nvidia GTX680, no problem at all.

Have tried:
Catalyst 12.4 and 12.5 beta
AMD APP SDK 2.6 and 2.7.
Disabled the onchip Intel HD4000 graphics
32bit and 64bit opencl version from 06_taro