x264 development

[CarlPig]

Changelogs can always be found on x264.nl

The only change from r2309 to r2310 was this (https://github.com/DarkShikari/x264-devel/commit/76a5c3a19f97cd34b65aeff050de4042b054bc65) as mentioned in the previous post.

Thanks.

[Nazgul]

FWIW, I have spent three minutes to make a "dummy" OPENCL.DLL which people can use to make x264.exe start on their system, if no "real" OpenCL DLL is available.

It should be clear, that any OpenCL-specific functions will not actually work with this DLL. Also this DLL herewith is declared Public Domain, so please feel free to redistribute it ;)

Weird, I'm still getting the error after installing this. The system getting the error is running Radeon HD 4550 graphics, with the "legacy" Catalyst 13.1 driver suite, which according to AMD's website DOES include OpenCL support. My other system which is running Cat13.5beta on a Radeon HD7950 is working just fine without the dummy .dll. Gonna try re-installing the Cat13.1 and see if that clears it up. Seems odd this wasn't caught.

[LigH]

So it was not clear that you should not use the dummy OpenCL DLL if your system does support OpenCL?

[Nazgul]

So it was not clear that you should not use the dummy OpenCL DLL if your system does support OpenCL?

Apologies, I should have been clear as well. I got the error BEFORE I tried using the dummy .dll file, suggesting that whatever OpenCL support this computer has, x264 wasn't seeing it. So I tried putting in the dummy .dll file, to see if that would do the trick. It didn't. I have managed to get it working, however. I had to blow the video drivers off the system and reinstall them, and now x264 seems to be finding the system's OpenCL driver.

[Selur]

Just trying to get a little overview over the current state:

current x264 version 'r2310 (JEEB)' requires a OpenCL.dll to work at all.
to make it work on systems which do not support OpenCL and therefore don't have a OpenCL.dll one can use the dummy .dll posted by LoRd_MuldeR (http://forum.doom9.org/showthread.php?p=1625943#post1625943)
even with the OpenCL.dll, the 64bit version of x264 will not be able to use --opencl due to some cross-prefix problem which JEEB uses with the 64bit-builds and the OpenCL SDK.
if you want to use --opencl you need to either use the 32bit build or in example an older version from http://tmod.nmm-hd.org/x264/test/ . (with the 64bit builds you will get a 'x264 [warning]: OpenCL: Unable to find a compatible device'- or 'x264 [warning]: OpenCL: not compiled with OpenCL support, disabling '-warning)

is this about right or did I miss something?

Cu Selur

[schweinsz]

Is there the new x264 profiling results? I want to know which modules take most of the time.

[Dark Shikari]

Sorry for all the OpenCL mess; Bugmaster's written up a patch to mostly clean up the problems in the original MultiCoreWare work. It'll be in the next release.

Here's some profiling results if you want them (http://s000.tinyupload.com/index.php?file_id=42451580428007968204).

[LoRd_MuldeR]

You refer to this one?
https://github.com/DarkShikari/x264-devel/commit/520ac11909fcdfd439af376cfd2f27d3e6646dae

Looks like runtime loading of the OpenCL library is implemented now, which should make any hacks (like the dummy DLL) obsolete.

:thanks:

[Selur]

Nice, thanks for the info.

[laserfan]

And thank You, Selur! I wanted to ask "why is --opencl in the Help file but it doesn't appear to be implemented anyway" and your/Dark's posts have cleared-away the fog.

:)

[Selur]

That's because the OpenCL SDK finding code fails if you give the configuration script a cross-prefix (like I do when compiling the 64bit builds), and thus it didn't get enabled :P . A fix for that is being reviewed on #x264dev.
Any news on the fix?

[sneaker_ger]

See post #1908.

[Selur]

ah, okay :D

[LigH]

So we just need a binary release with enabled OpenCL support to test it. I believe those on x264.nl did not enable it...

Ah, no, Rev. 2310 apparently supports OpenCL in the 8-bit x86 build. But it seems to have some issues with either my card or my drivers (314.22 W7/64b)...

x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce 9600 GT
x264 [info]: Compiling OpenCL kernels...
x264 [warning]: OpenCL: kernel build errors written to x264_kernel_build_log.txt
__

(0) Error: unsupported operation

Well, according to the description in the changelog, it may not even speed up things in general, but rather limit the quality. I will probably avoid it.

[Atak_Snajpera]

I think you need GPU which supports latest OpenCL version (for example my R4850 supports only OpenCL 1.0) also 1GB is considered as minimum memory size. In order to avoid crashes people recommend even 2GB.

[Video Dude]

Quick question about OpenCL and the current x264.nl (x86) build:

I have a video card that supports OpenCL, but I do not want x264 to use OpenCL.

Is OpenCL enabled by default and if it is, is there a switch to disable it? Doing a forum search I found reference to a "--no-opencl" parameter. Is this correct?

[the_weirdo]

Is OpenCL enabled by default and if it is, is there a switch to disable it? Doing a forum search I found reference to a "--no-opencl" parameter. Is this correct?

OpenCL isn't enabled by default. To enable it, you have to add "--opencl" to settings.

[Stereodude]

Any hints of what Haswell brings to the table for x264 encoding in terms of real world performance increases over Ivy Bridge or Sandy Bridge?

It seems from the profile information that Dark Shikari uploaded he's got a Haswell system.

[the_weirdo]

Any hints of what Haswell brings to the table for x264 encoding in terms of real world performance increases over Ivy Bridge or Sandy Bridge?

It seems from the profile information that Dark Shikari uploaded he's got a Haswell system.

Maybe this: http://mailman.videolan.org/pipermail/x264-devel/2013-May/010049.html

[Dark Shikari]

That's just the gain from AVX2 though; I'm still not allowed to post actual benchmarks (i.e. gain from Ivy Bridge -> Haswell).

[Stereodude]

I'm still not allowed to post actual benchmarks (i.e. gain from Ivy Bridge -> Haswell).You'll be allowed to post them after a certain date though right?

[filler56789]

Regarding the openCL thing,
has anybody already tested r2334? :)

[Selur]

yes, 64bit build works fine here:
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660 Ti
x264 [info]: Compiling OpenCL kernels...

[MetalPhreak]

The 8 bit depth builds from x264.nl work fine but it seems OpenCL is not enabled in the 10 bit depth builds.

[mandarinka]

It's not that it is disabled, the OpenCL lookahead simply isn't made to work with 10-bit encoding, AFAIK.

[jpsdr]

Has anyone encounter with 64bits r2334 version the issues i've described here (http://forum.doom9.org/showthread.php?p=1628697#post1628697) (issues with devel version : wrong fps and warning).

[koliva]

Small question.
Would openCL support mean that I will have hardware acceleration without the need of changing/adding extra code in my encoder code part where I use libx264?

[Stereodude]

I'm still not allowed to post actual benchmarks (i.e. gain from Ivy Bridge -> Haswell).Are you allowed to post benchmarks now? I see many of the major computer centric tech sites have their Ivy Bridge intro reviews with benchmarks posted.

[Dark Shikari]

I suppose!

Performance gain in x264, per clock (roughly):

Ivy Bridge -> Haswell: 17% (~5 of which is from AVX2)
Sandy Bridge -> Haswell: 28%
Nehalem -> Haswell: 39%

[hajj_3]

what happened to the x264.nl site? I wanted to see the changelog for the latest stable build.

[CarlPig]

what happened to the x264.nl site? I wanted to see the changelog for the latest stable build.

Check this mirror: http://mirror01.x264.nl/

[LoRd_MuldeR]

what happened to the x264.nl site? I wanted to see the changelog for the latest stable build.

See here :rolleyes:
http://forum.doom9.org/showthread.php?p=1630666#post1630666

Also this has never been an "official" x264 web-site.

If you are looking the changelog, just see the official x264 Git repository:
http://git.videolan.org/?p=x264.git;a=shortlog

Or, if you prefer a plain text file:
git clone git://git.videolan.org/x264.git x264-src
cd x264-src
git log > CHANGELOG.txt

Win32 builds can be found, for example, at Komisar's site:
http://komisar.gin.by/

[Stereodude]

Performance gain in x264, per clock (roughly):

Ivy Bridge -> Haswell: 17% (~5 of which is from AVX2)
Sandy Bridge -> Haswell: 28%
Nehalem -> Haswell: 39%Thanks!

When is that performance gain realized? Is it in the first pass, second pass, both passes, a single pass CRF encode?

[Dark Shikari]

That was just a medium-preset CRF encode, and while it'll vary a little bit between presets and the like, I really doubt there's a huge difference.

[Audionut]

Sandy Bridge -> Haswell: 28%


Hmm, might be time to part with some cash.

[Reino]

I have no idea whether this is the right to report (small) issue or not, but when I tell x264 to convert the framerate, it doesn't report it's actually doing so, eventhough the endresult is correct.
When I deliberately omit the offset, at least it reports an error:
x264.exe ... --vf resize:960,540/select_every:2 -o NUL "input"
...
ffms : 1920x1080p 1:1 @ 50/1 fps (vfr)
resize [info]: resizing to 960x540
[I]select_every [error]: no offsets supplied...but when I add the offset:
x264.exe ... --vf resize:960,540/select_every:2,0 -o NUL "input"
...
ffms : 1920x1080p 1:1 @ 50/1 fps (vfr)
resize [info]: resizing to 960x540...there's no [I]"select_every [info]: converting to 25fps" to be seen anywhere.

[benwaggoner]

Performance gain in x264, per clock (roughly):

Ivy Bridge -> Haswell: 17% (~5 of which is from AVX2)
Sandy Bridge -> Haswell: 28%
Nehalem -> Haswell: 39%
Was there much Haswell-specific optimization outside of adding AVX2 support? Or are you just leaving that to the compiler and the chip's microarchitecture improvements?

Also, are the AVX2 etcetera optimizations relatively "done" at this point, or can we expect further relative improvements for Haswell in the short-medium term?

[Dark Shikari]

Haswell is not really very different from Nehalem/Sandy Bridge/Ivy Bridge architecture-wise, besides of course the larger datapaths and wider SIMD.

There'll probably be a lot of room to improve things in 10-bit, but 8-bit is probably close to done.

[J_Darnley]

there's no "select_every [info]: converting to 25fps" to be seen anywhere.

Why would there be? The filter doesn't print a line like that.

[Reino]

It should if you ask me. Printing information about framerate conversions is just as important as changing resolutions.

[denkr]

It will be great if anybody clarify me scenecut_internal detection in x264.
It uses
int icost = frame->i_cost_est[0][0];
int pcost = frame->i_cost_est[p1-p0][0];
What are values of abovementioned i_cost_est elements (SATDs between some 4x4 blocks? Which blocks?).

Thanks.

[Dark Shikari]

They represent the approximate SATD cost of the entire frame (for those choices of B-frame placement).

[Stereodude]

If I have multiple OpenCL capable display adapters in my system, how does x264 decide which one to use, or is there a way to force it to use a certain one?

For example, my PC has the Intel integrated Haswell HD4600 graphics and an Nvidia GeForce GT 440 can I force it to use one or the other for OpenCL?

[LoRd_MuldeR]

If I have multiple OpenCL capable display adapters in my system, how does x264 decide which one to use, or is there a way to force it to use a certain one?

Isn't --opencl-device exactly for that purpose?

[Stereodude]

Isn't --opencl-device exactly for that purpose?Okay, that's how you can force it to use one device over another. How does x264 decide which one to use? Does it just pick the lowest number?

Does the OpenCL performance of the video adapter make much difference in the speed of the x264 encoding? ie: should I care which one it uses?

[LoRd_MuldeR]

I guess you want it to use the fastest device. Also I guess you want to use the dedicated GPU, not the "CPU graphics", in order to keep the CPU's thermal budget free for the actual CPU calculations...

[Stereodude]

I guess you want it to use the fastest device. Also I guess you want to use the dedicated GPU, not the "CPU graphics", in order to keep the CPU's thermal budget free for the actual CPU calculations...I'm not aware that using the HD4600 integrated graphics in the Intel Haswell CPU slows it down for CPU related tasks.

[LoRd_MuldeR]

Well, modern CPU's regulate the clock speed dynamically ("turbo boost"), depending on the thermal budget. And I'm pretty sure the "processor graphics" contributes to the thermal budget. So if you put load on the "processor graphics", the CPU probably has to reduce the clock speed earlier. Also, the performance of dedicated GPU's still is much superior to the "processor graphics". And that's for "cheap" graphic cards, let alone the "high end" models. Finally, the CPU and the "processor graphics" share a single L3 cache and a single memory controller, which means that putting load on the "processor graphics" will likely hurt the memory bandwidth available to the CPU cores...

(On the other hand, the delays for uploading/downloading the data to/from the GPU, which can be quite problematic with dedicated GPU's, should pretty much fall when using the "processor graphics")

[Stereodude]

Well, modern CPU's regulate the clock speed dynamically ("turbo boost"), depending on the thermal budget. And I'm pretty sure the "processor graphics" contributes to the thermal budget. So if you put load on the "processor graphics", the CPU probably has to reduce the clock speed earlier.Perhaps, but there is thermal overhead with the heatsink/fan I'm using, so there is no reduction in clock speed.
Also, the performance of dedicated GPU's still is much superior to the "processor graphics". And that's for "cheap" graphic cards, let alone the "high end" models.Perhaps, but according to these benchmarks the HD4600 bests the GT 440 in some OpenCL tests and the GT 440 bests the HD4600 in others. GT 440 (http://clbenchmark.com/device-info.jsp?config=11983241) vs. i7-4770k (http://clbenchmark.com/device-info.jsp?config=15525698) Of course I have no idea which if any of those test are representative of the OpenCL processing done by x264.

[Stereodude]

Can I use OpenCL on the 2nd pass and not use it on the 1st pass of a 2 pass encode or will that create a problem?

OpenCL doesn't work with the Intel integrated HD 4600 graphics in my system for whatever reason, and using OpenCL on the GeForce GT 440 slows down the first pass significantly (like from 72FPS to 20-25FPS). Then again, I don't know if it will speed up the 2nd pass any.