x264 OpenCL

[deadrats]

@cyberbeing and Hiritsuki

perhaps you guys should try a different test, namely in addition to testing with different rc-lookahead values you should also play with lookahead-thread values.

in Hiritsuki's test he set lookahead-thread=3, i'm left to wonder why.

as was pointed out gpu's have hundreds of "cores", why launch only 3 threads with which to process lookahead.

if you guys can, try repeating the tests with the following parameters:

everything as you tested the first time but for the cpu test set the number of lookahead threads equal to the number of cpu threads that each one's processor can simultaneously handle (for cyberbeing it would be 4 and for Hiritsuki it would be 12) and for the opencl test set the rc-lookahead to 60 and the lookahead threads to 100 and see if that greatly shifts the performance data to the gpu's advantage.

also, if you guys are testing with uncompressed sources that's also skewing the results somewhat as most people re-encode already compressed content and so most people would also have a software decoder working in addition to the encode.

[Hiritsuki]

I'd try --lookahead-thread 480
http://i.imgur.com/2Rahj.png

it's limit to 16?

but it's maybe faster.

[cyberbeing]

in Hiritsuki's test he set lookahead-thread=3, i'm left to wonder why.
He has a 6-core CPU with 12 threads through hyper-threading. On his CPU, lookahead-threads=3 likely speeds up encoding.

I have a 4-core CPU with 4 threads without hyper-threading. On my CPU, x264 defaults to lookahead-threads=1. Using more would likely make encoding slower on this CPU because of lack of available threads.

What you're suggesting doesn't sound like a fair test. Setting lookahead-threads=4 on my CPU would result in x264 using 10 threads total (4 lookahead + 6 encoding) which is more than double the threads available on my CPU. And as far as I know, lookahead-threads only affect CPU lookahead and should have no effect on OpenCL lookahead.

--preset veryslow --crf 16 --opencl = 12.75 fps
--preset veryslow --crf 16 --opencl --lookahead-threads 4 = 12.74 fps (margin of error)

--preset veryslow --crf 16 = 14.72 fps
--preset veryslow --crf 16 --lookahead-threads 4 = 14.58 fps (1% slower)

also, if you guys are testing with uncompressed sources that's also skewing the results somewhat as most people re-encode already compressed content and so most people would also have a software decoder working in addition to the encode.

My testing was done with a ~2Mbps 720p 8-bit h.264 source, ffms2 r712-2 software decoding, and astrataro's 32-bit x264 opencl build.

[deadrats]

i think lookahead thread is limited to 100:

http://mailman.videolan.org/pipermail/x264-devel/2012-May/009354.html

normally it defaults to 1/6 the number of threads

also try playing with sync-lookahead as well:

sync-lookahead
Default: auto (bframes+1)
Sets the number of frames to be used as a buffer for threaded lookahead. Maximum Value is 250. Automatically disabled during the 2nd or greater pass or when using sliced threads.
Setting this to 0 disables threaded lookahead, which allows lower latency at the cost of reduced performance.

[deadrats]

What you're suggesting doesn't sound like a fair test. Setting lookahead-threads=4 on my CPU would result in x264 using 10 threads total (4 lookahead + 6 encoding) which is more than double the threads available on my CPU. And as far as I know, lookahead-threads only affect CPU lookahead and should have no effect on OpenCL lookahead.


according to http://mailman.videolan.org/pipermail/x264-devel/2012-May/009354.html lookahead-thread splits rc-lookahead into multiple threads, if rc-lookahead is being processed by the gpu then it stands to reason that you need to increase lookahead-thread to big numbers in order to extract maximum performance from a gpu's ability to handle lots of threads simultaneously.

it seems to me that if you're going to make a fair analysis of what ocl brings to x264 the test should be lookahead-thread=100 and rc-lookahead should be at least 100, maybe even maxed out at 250.

[Dark Shikari]

lookahead-threads is about CPU threads for lookahead slice threading; it has nothing to do with GPUs at all.

[Hiritsuki]

@deadrats

no... it's limited to 16
http://i.imgur.com/AKnIi.png

and ... it's really should be optimized ...

480 and 670 is same fps ...

[Hiritsuki]

if set --sync-lookahead 0
cl will be not accelerat x264

[Hiritsuki]

if set rc-lookahead 250
the gddr will be overused and make error
http://i.imgur.com/U3fH4.png

[Hiritsuki]

rc-lookahead set 0 it's will not to use gddr and gpu's opencl efficacy...

[Kurtnoise]

you know that you can edit your posts ?

[deadrats]

hmm, maybe nvidia's gaming drivers aren't properly optimized for OpenCL applications.

i seem to recall someone speculating of the possibility that discrete graphics gpu's wouldn't benefit all that much from this patch, that only gpu integrated onto the cpu die would really benefit ala AMD's apu's and intel's SB/IB processors.

bummer.

[Hiritsuki]

@Kurtnoise
sorry i forgot it...

@deadrats
i means the software x264 opencl should be optimized....
Not graphic card's driver....
now the x264 opencl is only accelerated the rc-lookahead,it's accelerate a little of all x264's processing.

[Sagittaire]

euh ... OpenCL for lookahead is really out of interest. lookahead is not really important setting for quality. OpenCL for CABAC or RDO will be really more interessing to compare interest with CPU if it's possible to make massive GPU theading for that ... ?

[Hiritsuki]

@Sagittaire
hi, if possible i hope it can accelerat for me&subme

[mandarinka]

I think that the general consensus among people who understand the matter is that RDO and CABAC are *precisely* the parts that cannot be successfully converted into OpenCL to run on GPUs.

[SassBot]

hmm, maybe nvidia's gaming drivers aren't properly optimized for OpenCL applications.

I've run it on both Quadro and GeForce cards. The difference is not nearly as much as you're thinking it would be. The drivers really aren't the issue. With all GPGPU involving discrete GPUs, the latency and transfer speed of the PCI-E bus is the overriding factor since even the peak theoretical rate of a PCI-E 2.0 x16 bus is 8GB/sec. This pales in comparison to the internal memory bandwidth of, for example, a GTX 460 which based on the brand and model I've seen range from 80+GB/sec to over 120GB/sec.

i seem to recall someone speculating of the possibility that discrete graphics gpu's wouldn't benefit all that much from this patch, that only gpu integrated onto the cpu die would really benefit ala AMD's apu's and intel's SB/IB processors.

bummer.

Which is only obvious since they are designed in a way to remove the interconnect bottleneck between the CPU and discrete GPU.

[Sagittaire]

I think that the general consensus among people who understand the matter is that RDO and CABAC are *precisely* the parts that cannot be successfully converted into OpenCL to run on GPUs.

If it's true then OpenCL is definitively out of interest for high quality encoding ...

[Filker]

A10 4600M with Opencl compressing close to i7 2760qm speeds
http://www.youtube.com/watch?v=uOOOTqqI18A&feature=relmfu

Stable x264 opencl release "a couple of months away"

[sneaker_ger]

AMD Catalyst 12.9 (beta) (http://support.amd.com/us/gpudownload/windows/Pages/radeonaiw_vista64.aspx) seems to fix opencl encoding.
between 3% and 4% speed-up for preset medium and preset slower on 1920x816p with HD 5850 and Core-i7 860 in a short test.
(taro's 2216+688: x264_64_tMod+MixAQ-8bit-420-opencl.exe)

[hajj_3]

AMD Catalyst 12.9 (beta) (http://support.amd.com/us/gpudownload/windows/Pages/radeonaiw_vista64.aspx) seems to fix opencl encoding.
between 3% and 4% speed-up for preset medium and preset slower on 1920x816p with HD 5850 and Core-i7 860 in a short test.
(taro's 2216+688: x264_64_tMod+MixAQ-8bit-420-opencl.exe)

Very nice, it will be nice to see a stable version of x264 and a stable new amd driver with a proper review comparing amd, nvidia and intel.

[aegisofrime]

AMD Catalyst 12.9 (beta) (http://support.amd.com/us/gpudownload/windows/Pages/radeonaiw_vista64.aspx) seems to fix opencl encoding.
between 3% and 4% speed-up for preset medium and preset slower on 1920x816p with HD 5850 and Core-i7 860 in a short test.
(taro's 2216+688: x264_64_tMod+MixAQ-8bit-420-opencl.exe)

Unfortunately, the performance speed-up does not justify the power usage of the GPU :(

[hajj_3]

Unfortunately, the performance speed-up does not justify the power usage of the GPU :(

for a standalone gpu maybe but who knows about amd's llano and trinity apu's.

[Atak_Snajpera]

it seems that opencl is only useful for apu. only apu gets noticiable speed up. this is good news for amd because cheaper cpu can be as fast as intel's solution.

[aegisofrime]

for a standalone gpu maybe but who knows about amd's llano and trinity apu's.

That's true...

it seems that opencl is only useful for apu. only apu gets noticiable speed up. this is good news for amd because cheaper cpu can be as fast as intel's solution.

As fast as if only pure transcoding if going on. If one is doing, for example, deinterlacing with QTGMC, the Trinity solution would be slower over. Perhaps much slower.

OF course, I haven't forgotten the price difference. But still, with a quad-core mobile Ivy Bridge going for only US$150 more than a top end Trinity laptop, I would gladly pay the difference.

[Vesdaris]

i tried the latest build from here
http://astrataro.wordpress.com/category/encode/x264/x264-bin/ (x264_rev2216+688_tMod-opencl.7z (test only) )

and though i see that my GPU is being used while encoding process is active ( 7970) but fps is the same if not lower. maybe im doing something wrong

i generally use crf17, slower preset, dxva compatibility custom number of b frames and ref frames(which i select based on a sample encoding), -me tesa --subme 11 --no-fast-pskip . and leave it for a night.

What number of lookahead should i set when using opencl x264 ? i tried standard for this preset 60 and increasing them- didnt see any difference between non opencl and opencled x264

[hackeron]

i tried the latest build from here
http://astrataro.wordpress.com/category/encode/x264/x264-bin/ (x264_rev2216+688_tMod-opencl.7z (test only) )

and though i see that my GPU is being used while encoding process is active ( 7970) but fps is the same if not lower. maybe im doing something wrong

i generally use crf17, slower preset, dxva compatibility custom number of b frames and ref frames(which i select based on a sample encoding), -me tesa --subme 11 --no-fast-pskip . and leave it for a night.

What number of lookahead should i set when using opencl x264 ? i tried standard for this preset 60 and increasing them- didnt see any difference between non opencl and opencled x264

What difference in FPS do you get if you use the ultrafast preset?

[Vesdaris]

i've yet to test it in ultrafast preset, but i did some tests encoding a dvd and there is absolutely no difference or it is quite negligible.(2pass and crf encode, a bit tweaked placebo preset)
GPU load sits at about 35-50% depending on a number of lookahead frames .Having opencl acceleration enabled which in turn helps to reduce CPU load is the only positive side i see about this opencl stuff.

maybe it is supposed to work much better on AMD's APU .

[MMrrTT]

Could someone tell me which one should I use for my i7 and AMD 7950?
http://clip2net.com/clip/m70200/1355454347-clip-2kb.png

Why does it uses my GPU only during first pass? :(

[Blue_MiSfit]

@ MMrrTT: because lookahead only happens in the first pass. The OpenCL patch specifically accelerates lookahead only.

[MMrrTT]

Blue_MiSfit, that is so sad ;( Are there any codecs or encoders that fully supports AMD Stream like others fully support CUDA?

[Racer]

What I really don't unterstande why they always want to boost the performance for the encoding part. In my opinion it would be much better to focus first on decoding what the GPUs can already pretty well. So if there would be something like DGDecNV (right now only for Nvidia) for frameserving/decoding in x264 you would have significantly better performance with less effort.
If also switched from software decoding to DGDecNV and could improve my encoding speed by about 30%.

[sneaker_ger]

30% speed improvement from switching to hardware decoding is very very seldom. Typical speed-ups are in the (low) single digit range. You've either been doing something wrong or have encountered a corner case. The more cpu intensive the x264 settings, the more minor the improvement becomes. And for very fast settings CPU decoding can actually be faster because many hardware decoders were designed with real-time playback in mind.

[Racer]

Yes, I'm using very fast x264 encoding; this was the reason why ffdshow couldn't deliver enough frames on my AMD X6 1045T and x264 never reached 100% cpu load. Right now I'm encoding at 80FPS with DGDecNV and a GT520 (VP5; maximum about 120fps for decoding).
I also had to set the x264 threads to 12 for my AMD X6 as per default it would only use one lookahead thread. I actually need 2 to get 100% cpu load.

[sneaker_ger]

Yes, I'm using very fast x264 encoding; this was the reason why ffdshow couldn't deliver enough frames on my AMD X6 1045T and x264 never reached 100% cpu load.

Which could probably be easily fixed by using multi-threaded source filters like ffms2.

Right now I'm encoding at 80FPS with DGDecNV and a GT520 (VP5; maximum about 120fps for decoding).

Yes, those VP5s are decently fast. Intel hardware decoding is even faster, IIRC.

I also had to set the x264 threads to 12 for my AMD X6 as per default it would only use one lookahead thread. I actually need 2 to get 100% cpu load.

Maybe the devs should consider changing this?
I don't know the exact code, but 6 cores should result in 6 * 1.5 = 9 threads and in return make lookahead threads 9/6 = 1.5 threads which then should be rounded to 2?
Is this not happening?

[itsonlyjustincase]

If you guys want, I can test on a Core i3 540 machine with an AMD Radeon HD 7770 graphics card.
This would probably be the best chance for a discreet GPU to give a speedup.

Just need some rudimentary directions, and possibly a test clip representative of the average movie.

Oh, and I have the patience for Placebo too. 40-hour encodes aren't new to me :)

[Bleck]

If you guys want, I can test on a Core i3 540 machine with an AMD Radeon HD 7770 graphics card.
This would probably be the best chance for a discreet GPU to give a speedup.

Just need some rudimentary directions, and possibly a test clip representative of the average movie.

Oh, and I have the patience for Placebo too. 40-hour encodes aren't new to me :)

Don't waste your time with placebo seriously. Visual difference is 0,001 %. Same with filesize. Placebo was made because people would asked for a maximum settings preset.

[Racer]

What is the status now for x264 OpenCL. Is it already dead?

[MMrrTT]

Would like to try to use x264 with GPU support in Sony Vegas.
Does GPU acceleration work in single pass quantizer based presets?
Are there VFW+OpenCL versions of x264?

[Blue_MiSfit]

@MMrrTT: Why would you ever want to use constant qp mode? This is literally a terrible idea for anything other than developer testing IMO.

I'm not sure if there are VFW + OpenCL builds. I haven't tried to use a VFW build for a few years now...

In Vegas, your best bet is probably to render out lossless and then transcode with x264.

[MMrrTT]

@MMrrTT: Why would you ever want to use constant qp mode? This is literally a terrible idea for anything other than developer testing IMO.That was a stupid advice. Still with low quants it gives very-very good picture. But uses enormous bitrate.

I'm not sure if there are VFW + OpenCL builds. I haven't tried to use a VFW build for a few years now...What do you do to edit video, edit audio and encode the result? Or you just convert videos using console?

In Vegas, your best bet is probably to render out lossless and then transcode with x264.That requires terabytes of storage for my 60-70 minutes video + too much time for encoding. I used to use 2-pass encoding with slow preset, but that takes too much time for me - up to x10 times of video duration. Now I'm looking for the way to get the best possible quality at YouTube and the least time spent for encoding and uploading.

[Sagittaire]

That was a stupid advice. Still with low quants it gives very-very good picture. But uses enormous bitrate.

What do you do to edit video, edit audio and encode the result? Or you just convert videos using console?

That requires terabytes of storage for my 60-70 minutes video + too much time for encoding. I used to use 2-pass encoding with slow preset, but that takes too much time for me - up to x10 times of video duration. Now I'm looking for the way to get the best possible quality at YouTube and the least time spent for encoding and uploading.

- crf mode will be really better.

- x264.exe have directly spliter and decoder filter now. You can use ffmpeg.exe if you want more complete video filtrer.

- what are your source type? I will post the good command line for x264. For 1080p encoding I have half real time encoding (for complete encoding at 2 pass) with my old Q6600 in slowest mode.

[MMrrTT]

- x264.exe have directly spliter and decoder filter now. You can use ffmpeg.exe if you want more complete video filtrer.I don't understand why, but I don't have x264 option in ffdshow.
http://clip2net.com/clip/m70200/1357475866-clip-30kb.png

- what are your source type? I will post the good command line for x264. For 1080p encoding I have half real time encoding (for complete encoding at 2 pass) with my old Q6600 in slowest mode.I use 1080p@30fps MJPEG video, about 180 Mbps bitrate.

[Sagittaire]

I don't understand why, but I don't have x264 option in ffdshow.
http://clip2net.com/clip/m70200/1357475866-clip-30kb.png

I use 1080p@30fps MJPEG video, about 180 Mbps bitrate.

encoding profil please? (resolution, bitrate)

[MMrrTT]

The one I use to prepare video for YouTube upload? I don't have one, cause I'm trying out different ones in order to get maximum quality at appropriate encoding speed. And the limitation is about 20 Gb per file. I don't make videos more than 70-90 minutes and don't upload files larger than 20 Gb. I believe it will be 1080p@30fps, x264, 5.1 high profile, ~15-20 Mbps bitrate @ fast or faster preset.

[Sagittaire]

You upload video at youtube with 1080p30 at 20 Mbps. It's really overkill for streaming, no ... ???

[sneaker_ger]

ffmpeg and ffdshow are not the same. x264 encoding (and probably others, too) has been removed from the latter because no one wanted to maintain them anymore and VfW h.264 encoding is not really recommended anyways. I don't think anyone bothered to make an OpenCL VfW build of x264, but if you really want to use it there should be a Vegas frameserver (->google) which lets you combine Vegas with CLI encoders. But don't expect anything great, as you can see from the results posted here the speed-up will probably not exceed low single digit %.

[Sagittaire]

well try this profil with your 1080p30 MJPEG source. You can expect IMO half real time speed encoding with your i7 at 3.5 Ghz with really good quality (Blu Ray quality)

@REM -----------------------------------------------------------
@REM
@REM Profil BluRay Ripp 1080p BD9 64 bits
@REM
@REM -----------------------------------------------------------


x264\x264_64.exe --video-filter resize:1280,720 --demuxer lavf --slow-firstpass --bframe 3 --b-pyramid "strict" --b-adapt 1 --weightp 1 --ref 1 --direct auto --deblock -1:-3 --bitrate 15000 --pass 1 --stats "x264\test.log" --qcomp 0.80 --ipratio 1.00 --pbratio 1.00 --min-keyint 1 --partitions "none" --me "dia" --subme 5 --deadzone-inter 4 --deadzone-intra 4 --psy-rd 1.0:0.25 --aq-mode 1 --aq-strength 0.5 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 300 --open-gop --slices 1 --sar 1:1 -o NUL sample\sample.avi

x264\x264_64.exe --demuxer lavf --bframe 3 --b-pyramid "strict" --weightp 1 --ref 3 --direct auto --deblock -1:-3 --bitrate 15000 --pass 3 --stats "x264\test.log" --qcomp 0.80 --ipratio 1.00 --pbratio 1.00 --min-keyint 1 --partitions "all" --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --deadzone-inter 4 --deadzone-intra 4 --trellis 1 --psy-rd 1.0:0.25 --aq-mode 1 --aq-strength 0.5 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 300 --open-gop --slices 1 --sar 1:1 --psnr --ssim -o sample\1080p_64.mp4 sample\sample.avi

[MMrrTT]

You upload video at youtube with 1080p30 at 20 Mbps. It's really overkill for streaming, no ... ???At first I though I could reach some threshold of bitrate which YouTube won't convert and will just show directly. But YouTube converts everything. So, I've decided to upload videos at maximum quality. The more bitrated videos I upload the less squares I see after YouTube convertion. So, when I use 2-pass bitrate based encoding I choose it ~20 Mbps or something like 20-50 in Premiere. By the way, I've to test CFR encoding.

ffmpeg and ffdshow are not the same. x264 encoding (and probably others, too) have been removed from the latter because no one wanted to maintain them anymore and VfW h.264 encoding is not really recommended anyways. I don't think anyone bothered to make an OpenCL VfW build of x264, but if you really want to use it there should be a Vegas frameserver (->google) which lets you combine Vegas with CLI encoders. But don't expect anything great, as you can see from the results posted here the speed-up will probably not exceed low single digit %.My bad. Now I see.
I think I'm giving up trying to use OpenCL - it's too complicated and unsupported. It doesn't worth it for now.
The latest stable build, I believe, is in the MeGUI and it uses CLI version of x264. So, it is the best variant to encode videos in order to use the latest CLI x264?

[sneaker_ger]

well try this profil with your 1080p30 MJPEG source. You can expect IMO half real time speed encoding with your i7 at 3.5 Ghz with really good quality (Blu Ray quality)
--slow-firstpass? vbv buffer at 30000 with average bitrate 15000, even though this is only for uploading to youtube?
I don't think that's a good profile and it is overly complicated on top of that.

Just use CRF or ABR with a preset of your choice and no vbv.

The latest stable build, I believe, is in the MeGUI and it uses CLI version of x264. So, it is the best variant to encode videos in order to use the latest CLI x264?

Yes, those builds in MeGUI are the de-facto official builds from x264.nl (http://x264.nl) IIRC and are recommended for 99% of all users.