OpenCL lookahead beta testing

[sborho]

Hello,

Below is a patch which adds an OpenCL lookahead to x264.

OpenCL is disabled by default at runtime, you must specify "--opencl" to enable it. When OpenCL is enabled, x264 will generate an x264_lookahead.clbin file in its working directory, this is a cached copy of the lookahead kernels compiled for your GPU. You will also see a line such as this in the output log:

x264 [info]: OpenCL acceleration enabled with Advanced Micro Devices, Inc. Pitcairn (SI)

The OpenCL lookahead supports all chroma formats, but does not support pixels larger than 8 bits (it disables itself if you compile for high bit support). It also disables itself if your frame size is less than 32x32.

We're looking for beta testers to give this a try on their GPUs and report troubles. Please update your video drivers before testing.

The OpenCL lookahead should run on any modern AMD or NVIDIA (OpenCL capable) GPU. However, you may not see any performance improvement if your CPU is a lot more powerful than your GPU. There is also typically a small quality loss seen when using the OpenCL lookahead, caused by the iterative nature of the OpenCL motion search and H.264's data dependencies. The relative performance gain typically shrinks with the frame size because CPU performance improves as the data sets fit better within its large caches.

Patch: http://privatepaste.com/download/61d6dd7334
Prebuilt binaries:
https://bitbucket.org/sborho/files/downloads/x264-x64-opencl.exe
https://bitbucket.org/sborho/files/downloads/x264-x86-opencl.exe

[Keiyakusha]

Is this something new? Or at least new version that is like 500 revisions ahead?
If not, I believe there was thread about it, even with some benchmarks. And it didn't proved to be useful...

EDIT: taking that aside. does anyone have good quality comparison vs. normal x264 builds? I'm interested in answer to the following question:
Does the final quality with opencl-lookahead build is the same/better or worse compared to vanilla build assuming other settings are the same?
At first opencl-lookahead resulted worse quality, later someone reported it nearly the same. So how it is with most recent build?

Also what if at the same time you run different pretty heavy opencl app? Can they conflict somehow? For example if all gpu memory will be filled with other app, what will happen to opencl-lookahead? (if it uses gpu memory at all, I have no idea...)

[Selur]

1. here's a link to the existing x264 OpenCL (http://forum.doom9.org/showthread.php?t=164960)-thread
2. at least for 2pass encoding OpenCL did help from my last findings,.. (+ speed, quality the same)

[sborho]

The OpenCL lookahead typically loses about 0.02 PSNR compared to the C lookahead. YMMV

[easyfab]

Here my result CPU : i2600k GPU : GTX 560TI Sample : park_joy_1080p50.y4m

f:fps s:SSIM k:kb/S

x264-x86-opencl.exe :

Medium : f 16.48 s 11.672 k 32566
Medium --opencl : f 17.19 s 11.623 k 32251

faster : f 29.10 s 11.591 k 30915
faster --opencl : f 31.14 s 11.546 k 30651

slower : f 3.95 s 11.786 k 30674
slower --opencl : f 4.08 s 11.735 k 30351

x264-x64-opencl.exe

Medium : f 18.71 s 11.670 k 32568
Medium --opencl : f 19.48 s 11.627 k 32259

So 4 to 7% faster with opencl but how much power consumption more (CPU+GPU vs CPU) ?
After lookahead is there others parts that could be port to opencl ?

[Keiyakusha]

Nice. Well any speedup is good.

Is there any plans to add 10bit support?

[Hiritsuki]

It's I've been test.
my test is faster 6% than without OpenCL

@Keiyakusha
now have no 10bit.

[Keiyakusha]

now have no 10bit
Yes, I can see that (>_<)>

[Dark Shikari]

I'd like to get some more testing of the latest version (with more specifics on different cards and such... making sure things don't crash and so forth) before pushing this to trunk.

[noee]

I just did a quick test with the x64 version listed above on an SD source and it seems to have worked fine. Don't know about any benchmarking, I'm testing on a severely underclocked AthlonII with an HD6570 and AthlonII 620.

CCC 12.8, Win7 Ult, running x64 with AVISynth x64

x264 [info]: OpenCL acceleration enabled with Advanced Micro Devices, Inc. Turks

AVS:
SetMTmode(5,4)
Mpeg2Source("empire_short.d2v")
return last

CL:
"C:\Users\....\applications\x264\x264_64_OpenCL.exe" --preset fast --tune Film --crf 22 --opencl --fps 24000/1001 --sar 8110080:6842880 -o "E:\temp\empire_ocl.h264" e:\output\empire_short.avs


**EDIT:

So, I clocked up the Athlon II 620 to 3.5Ghz, here are some numbers:

OpenCL version: encoded 6954 frames, 120.48 fps, 537.67 kb/s
2216 Jeebs build: encoded 6954 frames, 142.46 fps, 536.00 kb/s

Again, this is an MPEG2 SD source. Should I try HD sources? Any specific x264 options I should try?

[cyberbeing]

--opencl still crashes if you abort encoding with CTRL+C



1280x720 8bit MKV (avs ffms2 input)

i5-3570K @4.4Ghz + GT 440 DDR5 1GB 864Mhz/1728Mhz (306.23 WHQL Driver)
_
x264-x86-opencl.exe --opencl --crf 18
63.36 fps
_
x264-x86-opencl.exe --opencl --preset veryslow --crf 18
12.12 fps


i5-3570K @4.4Ghz - CPU Only
_
x264-x86-opencl.exe --crf 18
68.44 fps
_
x264-x86-opencl.exe --preset veryslow --crf 18
13.78 fps
_



1920x1080 8bit MKV (avs ffms2 input)

i5-3570K @4.4Ghz + GT 440 DDR5 1GB 864Mhz/1728Mhz (306.23 WHQL Driver)
_
x264-x86-opencl.exe --opencl --crf 18
33.35 fps
_
x264-x86-opencl.exe --opencl --preset veryslow --crf 18
6.84 fps


i5-3570K @4.4Ghz - CPU Only
_
x264-x86-opencl.exe --crf 18
36.26 fps
_
x264-x86-opencl.exe --preset veryslow --crf 18
7.42 fps
_

[Bloax]

Unfortunately my old as dirt 9800 GT doesn't support compiling the OpenCL stuff. ;[

[Atak_Snajpera]

I think you need at least OpenCL 1.1 compatible card. My R4850 supports only basic 1.0 :(

[Filker]

No one has a cpu with integrated gpu/opencl to test? So far discrete cards have turned up short or little ahead of x86/cpu only.

Maybe one of those review sites putting out A10-5800K articles today could test it? Most are using x264 benchmark from techarp.

[vucloutr]

Core 2 Quad Q9550 @ 3.4GHz
GeForce GTX 460 1GB @ 715/900/1430 MHz
Win7 x64, NVidia 306.23

~3.5% faster with --opencl
PS C:\> .\x264-x86-opencl.exe --crf 24 --frames 1600 -o out.mkv test.mkv
avs [info]: 1920x800p
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:130 Avg QP:19.57 size: 31261
x264 [info]: frame P:881 Avg QP:23.13 size: 7571
x264 [info]: frame B:589 Avg QP:25.17 size: 1834
encoded 1600 frames, 30.95 fps, 1416.36 kb/s

PS C:\> .\x264-x86-opencl.exe --crf 24 --frames 1600 --opencl -o out.mkv test.mkv
avs [info]: 1920x800p
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 460
x264 [info]: profile High, level 4.0
x264 [info]: frame I:131 Avg QP:19.21 size: 31102
x264 [info]: frame P:884 Avg QP:23.10 size: 7581
x264 [info]: frame B:585 Avg QP:25.13 size: 1922
encoded 1600 frames, 32.04 fps, 1426.72 kb/s

With other CRF values always ~3.1% faster except high CRF values (40) up to 8.7% faster.
Interestingly GPU load only spikes up to 40% even for 8.7% faster encodes, in other words my GPU is bored.
Sometimes encoding crashes, I cannot reproduce it, seems random to me.
With --rc-lookahead 120 --keyint 120 more than 900MB GPU RAM get used.

[wkr]

Q9400
Sapphire 7770 standard edition
Vista

Test 1
x264-x86-opencl.exe --crf 24 -o out.mkv hw.MKV
-encoded 33566 frames, 42.23 fps, 726.40 kb/s

x264-x86-opencl.exe --opencl --crf 24 -o out.mkv hw.MKV
x264 [info]: OpenCL acceleration enabled with Advanced Micro Devices, Inc. Capeverde (SI)
-encoded 33566 frames, 42.12 fps, 741.58 kb/s

About the same speed..

Test 2
x264-x86-opencl.exe --preset fast -o out.mkv test-1080p.mpg
-encoded 2953 frames, 20.42 fps, 3095.47 kb/s

x264-x86-opencl.exe --preset fast --opencl -o out.mkv test-1080p.mpg
x264 [info]: OpenCL acceleration enabled with Advanced Micro Devices, Inc. Capeverde (SI)
-encoded 2953 frames, 21.11 fps, 3044.53 kb/s

About the same speed..

[lar1r]

8 Core FX Processor and HD 7870
I used noee's command line with the mpeg2 file in x264 5.01 benchmark

--preset fast --tune Film --crf 22 --opencl --fps 24000/1001 --sar 8110080:6842880 -o "test.h264" 1080p-test.avs

50 fps vs 54 fps

Awesome !!!!

[Filker]

8 Core FX Processor and HD 7870
I used noee's command line with the mpeg2 file in x264 5.01 benchmark

--preset fast --tune Film --crf 22 --opencl --fps 24000/1001 --sar 8110080:6842880 -o "test.h264" 1080p-test.avs

50 fps vs 54 fps

Awesome !!!!

Cool! any crashes? Which bulldozer model?

[lar1r]

Core i5 3570K with HD7870
x264-x86-opencl.exe --preset slow

13.9 fps with OpenCL
12.3 fps without

Used the mpeg2 file in x264 5.01 benchmark again as test

When using HD 7870, I've had no crashes. Either on the AMD FX system or Intel System.

Intel system crashes with Intel graphics and opencl command line. Works without it. Who uses Intel graphics anyways...

[benwaggoner]

Whenever I see these threads, I wonder if threaded lookahead really the best place for OpenCL in the media pipeline.

I'd think GPU accelerated decode of source and then acceleration of preprocessing (scaling, deinterlacing, color space conversion) would be a lot easier to pipeline, and are algorithms a lot easier to implement on a GPU.

Although if the final YV12 bitmaps were already on the GPU, maybe the lookahead speedup could be even greater.

How saturated is the GPU during the lookahead, versus how much time is it just waiting for frames to get transferred from main memory?

[akupenguin]

Although if the final YV12 bitmaps were already on the GPU,
Then they'd have to be transferred back for the CPU parts of the encoder. Isn't that even slower?

[Filker]

Whenever I see these threads, I wonder if threaded lookahead really the best place for OpenCL in the media pipeline.

I'd think GPU accelerated decode of source and then acceleration of preprocessing (scaling, deinterlacing, color space conversion) would be a lot easier to pipeline, and are algorithms a lot easier to implement on a GPU.

Although if the final YV12 bitmaps were already on the GPU, maybe the lookahead speedup could be even greater.

How saturated is the GPU during the lookahead, versus how much time is it just waiting for frames to get transferred from main memory?

AMD's APUs seem to get boosts of up to 100% in handbreak at least...
http://prohardver.hu/dl/cnt/2012-10/90356/results/handbrake.png

laptop apu
http://images.anandtech.com/graphs/graph5835/46687.png
http://www.anandtech.com/show/5835/testing-opencl-accelerated-handbrakex264-with-amds-trinity-apu

GPU/CPU load:
http://prohardver.hu/dl/cnt/2012-10/90356/picz/AMD_sysmon.gif

http://prohardver.hu/teszt/amd_trinity_apu_ujratoltve_a10_a8/computemark_luxmark_v2_0_handbrake_opencl.html
http://translate.google.pt/translate?sl=hu&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fprohardver.hu%2Fteszt%2Famd_trinity_apu_ujratoltve_a10_a8%2Fcomputemark_luxmark_v2_0_handbrake_opencl.html


Also read somewhere that best case scenario for OpenCL vs x86 was a downscale (like 1080p->720p) done in OpenCL followed by compression with OpenCL lookahead...

[Atak_Snajpera]

why do people always compare x86 instead of x64 vs opencl?

speed up in amd apu is amazing however i would personally wait for next generation of apu with gpu based on CGN architecture. trinity despite gpu name still uses older VLIW architecture. this means that you can not use dual graphics mode with external R7xxx.

[J_Darnley]

I'd think GPU accelerated decode of source and then acceleration of preprocessing (scaling, deinterlacing, color space conversion) would be a lot easier to pipeline, and are algorithms a lot easier to implement on a GPU.

x264 already can decode, deinterlace and scale on the GPU, if you can call DGDecNV part of it. I believe it has shown some gain.

why do people always compare x86 instead of x64 vs opencl?

Because everyone has a 32-bit OS?

[Asmodian]

Because everyone has a 32-bit OS?

Still? :( I hope the next windows (9?) will not have a 32bit version.

[benwaggoner]

Then they'd have to be transferred back for the CPU parts of the encoder. Isn't that even slower?
It probably depends :)? Ideally if the GPU is that slow, the final bitmaps could get cached on the HD during the analysis pass so they'd be already done and local for the second pass.

That's a lot to cache for a long movie at 1080p, of course.

x264 already can decode, deinterlace and scale on the GPU, if you can call DGDecNV part of it. I believe it has shown some gain.
DGDecNV is a seperate commercial project, no? Has it been more tightly integrated with x264?

[J_Darnley]

DGDecNV is a seperate commercial project, no? Has it been more tightly integrated with x264?

Nothing has changed in that regard, what were you expecting?

Still? :( I hope the next windows (9?) will not have a 32bit version.

If you have a working 32-bit Windows, why would you pay for another one? I can't see a day when I will change what version of Windows I'm running.

[burfadel]

Well, 32-bit Windows is limited to 4GB RAM (video+system), meaning if I were on 32-bit OS I'd be limited to 2GB (or just under) of RAM (2GB video card) instead of 16GB. Also, x64 performs better. The workaround hack (PAE) is just that, a hack, and shouldn't be used.

Any new computer with total RAM of 4GB or more should be on 64-bit, which is pretty much most computers sold today. I'm not talking ARM tablets, that's different! Windows 8 should never have been released with a 32-bit version.

[Asmodian]

If you have a working 32-bit Windows, why would you pay for another one? I can't see a day when I will change what version of Windows I'm running.

Huh? Windows 3.11 all the way. :p

At least on an i7 3770 I don't understand using a 32-bit open-cl x264. If you want the fastest encode you can get 64-bit offers increased performance.

[benwaggoner]

Nothing has changed in that regard, what were you expecting?
I wasn't expecting anything. The post I was responding to sounded like maybe there was deeper integration than I was aware of.

[Przemek_Sperling]

Well, 32-bit Windows is limited to 4GB RAM (video+system), meaning if I were on 32-bit OS I'd be limited to 2GB (or just under) of RAM (2GB video card) instead of 16GB. Also, x64 performs better. The workaround hack (PAE) is just that, a hack, and shouldn't be used.

Any new computer with total RAM of 4GB or more should be on 64-bit, which is pretty much most computers sold today. I'm not talking ARM tablets, that's different! Windows 8 should never have been released with a 32-bit version.


Ditto. Moreover, there are no PC 64-bit CPUs without SSE2. It makes life easier in many cases and I believe so does in case of video apps.

[Blue_MiSfit]

Whenever I see these threads, I wonder if threaded lookahead really the best place for OpenCL in the media pipeline.

I'd think GPU accelerated decode of source and then acceleration of preprocessing (scaling, deinterlacing, color space conversion) would be a lot easier to pipeline, and are algorithms a lot easier to implement on a GPU.

Although if the final YV12 bitmaps were already on the GPU, maybe the lookahead speedup could be even greater.

How saturated is the GPU during the lookahead, versus how much time is it just waiting for frames to get transferred from main memory?

This is the approach that Telestream has taken with Vantage Lightspeed. It combines GPU decode, scaling, and filtering with x264 encoding. I'm in process of evaluating, but initial impressions are very positive!

[Groucho2004]

Moreover, there are no PC 64-bit CPUs without SSE2.
Although this statement is probably true, you're just stating the obvious. I also can't see how this is related to 32 bit address space limitations. What's your point?

[mandarinka]

Some hardware might lack drivers for 64bit mode, also you can't run legacy 16bit apps in 64bit windows. There are probably other reasons why somebody might stick to 32bit, but the main one is going to be the "why upgrade a working system".

[Filker]

I wrote x86 as "cpu side" not as 32bit system. I have no idea if they used x86 or x86-64 OS for the benchmarks.
The hungarian review site used Windows 7 Ultimate SP1 64 bit OS.

Oh and if Win98SE didn't have a couple of persistent bugs and they added support for newer DirectX I'd still be running it... from XP to windows 8 it's been a bloatware trip of useless eyecandy. Wish Linux was just a tad more "unified".

[Atak_Snajpera]

Oh and if Win98SE didn't have a couple of persistent bugs and they added support for newer DirectX I'd still be running it... from XP to windows 8 it's been a bloatware trip of useless eyecandy. Wish Linux was just a tad more "unified".
You can still set Windows 7 to look like Win9x crap. I would not say that a windows 7 is bloatware. Win7 ran very well even on my ancient laptop with AMD Turion 64 1.8Ghz 1GB ram and Radeon x700 128MB. Zero problems with Aero interface.
Besides Win9x was not very stable. I don't remember how many times I had to reinstall Win9x. I've had almost all OS'es and Win XP was alot better in terms of stability than that pseudo OS from Win9x family. Windows 7 is even more stable than XP. The same installation since the release! Blue-screen? What's that?!

However I must say that incoming "Tiles 8" is a pure joke for desktop users!

[Blue_MiSfit]

Let's not have this thread devolve into arguments about which OS is superior. It's neither productive, nor relevant to the topic of discussion: OpenCL lookahead in x264.

Please stay on topic, and take your debate to PM if you feel the need to continue.

Thanks.

[sborho]

I have updated the patch to improve performance for b-adapt trellis mode, and to improve CTRL-C recovery on NVIDIA devices.

http://privatepaste.com/download/f49bf82227
https://bitbucket.org/sborho/files/downloads/x264-x86-opencl-2.exe

[sborho]

Quick updated patch, removed some cruft from the Makefile, no changes to the code so no new executable

http://privatepaste.com/download/465d0fde5a

[vucloutr]

Core 2 Quad Q9550 @ 3.4GHz
GeForce GTX 460 1GB @ 715/900/1430 MHz
Win7 x64, NVidia 306.97

Seems to be a little faster with --b-adapt 2 and --trellis 2 :
--b-adapt 1 --trellis 1 : --b-adapt 2 --trellis 2 :
--opencl --opencl
x264-x86-opencl.exe 29,06 fps 30,04 fps +3,37% 20,38 fps 22,70 fps +11,38%
x264-x86-opencl-2.exe 29,10 fps 30,08 fps +3,37% 20,44 fps 22,96 fps +12,33%


PS: How about a x64 build ?

[hajj_3]

AMD are the ones funding this btw so i'd expect the opencl patch will provide a better speed improvement on AMD gpu's i would have thought. Its nice that all OpenCL capable gpu's could potentially benefit though :)

[Vesdaris]

i dont see almost any increase on my 7970. i monitor it via gpu-z and i clearly see that it is being used yet i find no advantages whatsoever atm

[benwaggoner]

This is the approach that Telestream has taken with Vantage Lightspeed. It combines GPU decode, scaling, and filtering with x264 encoding. I'm in process of evaluating, but initial impressions are very positive!
Please keep us all posted on your results!

Elemental has a similar approach as well. They'll use GPU for pretty much everything but lower-bitrate H.264 encoding, where they use x264. Although they are also doing a CPU-only version as well for the cloud; I'm curious to see how the performance there compares. That could be our first really compelling GPU/CPU perf/quality comparison.

Expression Encoder would also do all source decode in DXVA, and optionally could use QuickSync and/or CUDA H.264 codec acceleration, but still did all software preprocessing.

[Blue_MiSfit]

In short, it's awesome. I'm very much sold on both Lightspeed and Elemental. Both products have their strengths and weaknesses, but they've both come a LONG way.

[Balling]

The author wants to remove OpenCL from x264. I am against it.
https://code.videolan.org/videolan/x264/-/merge_requests/66

In particular giant work in ffmpeg will be gone for opencl integration.

[rwill]

The author wants to remove OpenCL from x264. I am against it.
https://code.videolan.org/videolan/x264/-/merge_requests/66

In particular giant work in ffmpeg will be gone for opencl integration.

OpenCL is bad for CPU video encoders. Please Remove.

If someone comes up with some novel idea how to use OpenCL GPU Acceleration with a CPU encoder, patches welcome ?

[benwaggoner]

OpenCL is bad for CPU video encoders. Please Remove.

If someone comes up with some novel idea how to use OpenCL GPU Acceleration with a CPU encoder, patches welcome ?
x265 has extensive reuse functionality that can take a prior encode to improve performance of derivatives. It can even use a H.264 input to accelerate HEVC output. Backporting that to x264 would provide bigger perf gains than OpenCL ever could, and should be simpler to maintain once done.

The value of improved lookahead in x264 could very well be a lot more valuable to x264 users than retaining OpenCL.