Current Patches, Where to get them, How they affect speed/output

[MasterNobody]

Originally Posted by rack04

**removed until I can figure out why avi output format wasn't working**

For correct compiling with AVI-output you need to configure ffmpeg with such additional options:

--enable-muxer=avi --enable-protocol=file

or simply take komisar's libpack from this page

[LoRd_MuldeR]

Originally Posted by burfadel

I tried lots of different settings, and in each case I got borked output in CRF mode with mb-tree on. I just tried the amdfam10 build of x264 r1323 from xvidvideo.ru and that has the exact same problem as outlaw.78's build, borked output with mb-tree on, whereas with the core2 build from xvidvideo.ru it works fine.

Some testes from my Intel Core2 Q6600 machine:

File                                            Size            RIPEMD-160
parkrun.1280x720.crf20.gcc345.generic.avi       41.164.020      B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc450.generic.avi       41.164.020      B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc450.core2.avi         41.164.020      B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc450.pentium3.avi      41.164.020      B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc450.amdfam10.avi      53.389.452      E6BDE3785594AD489583F88D88F3307581B7AA9D
parkrun.1280x720.crf20.gcc443.generic.avi       41.164.020      B54683EEFF99DF9032951E69A20372B9769F9860
parkrun.1280x720.crf20.gcc443.amdfam10.avi      53.389.452      E6BDE3785594AD489583F88D88F3307581B7AA9D

x264 version:

version: 0.92.1523M 25ca5b0

Settings that were used:

options: 1280x720 fps=50/1 timebase=1/50 cabac=1 ref=8 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.15 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-3 threads=6 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=16 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 wpredb=1 wpredp=2 keyint=750 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=crf mbtree=1 crf=20.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

[Dark Shikari]

If the amdfam version used an instruction incompatible with Intel chips, it would crash, not give incorrect output.

It's likely, given gcc's track record, that the build is just broken.

[burfadel]

Interestingly enough, for me it went in the other direction, around 25 percent smaller output file not 25 percent larger! Anyways, looks as though the last few GCC builds (as it happens with 1310 as well) is broken, I think earlier GCC 4.5.0 builds worked, but how far back that was I have no idea!

Is there any reason why it would only occur with mb-tree on? if there is an instruction used there and not elsewhere? at least a bug report can be submitted to the GCC development team if the cause is known

[LoRd_MuldeR]

Originally Posted by burfadel

Is there any reason why it would only occur with mb-tree on? if there is an instruction used there and not elsewhere? at least a bug report can be submitted to the GCC development team if the cause is known

Obviously GCC either miscompiled the MB-Tree code itself or it miscompiled something else that becomes apparent with MB-Tree enabled.

Also: Even if the miscompilation can be tracked down to MB-Tree, it doesn't mean you will be fine with MB-Tree disabled. Other more subtle things may be miscompiled too.

(Looking at the output from the amdfam10-optimized build I see some kind of "flickering" that isn't there in the output from the other builds)

[outlaw.78]

hmmmmm, i will try to compile using gcc 4.4.3 from komisar and post as soon as i am done

[LoRd_MuldeR]

Originally Posted by outlaw.78

hmmmmm, i will try to compile using gcc 4.4.3 from komisar and post as soon as i am done

Exactly same result with GCC 4.4.3 (Komisar's build). Please see this post.

[outlaw.78]

Originally Posted by LoRd_MuldeR

Exactly same result with GCC 4.4.3 (Komisar's build). Please see this post.

i see...
i wonder if that has something to do with -ffast-math switch

[burfadel]

Originally Posted by LoRd_MuldeR

Some testes from my Intel Core2 Q6600 machine:

Tests with that extra 'e' means something completely different

It would be good to get to the bottom of the issue, it would be bad for someone trying x264 for the first time using a miscompiled build...

[MasterNobody]

It seems this is not the miscompilation. This builds probably correctly work only on AMD K10 CPU (which support SSE4A / AMD SSE4). Because gcc generates LZCNT instruction which seems to be incorrectly interpretated as BSR without crash on CPUs without support of SSE4A.

[LoRd_MuldeR]

Originally Posted by MasterNobody

It seems this is not the miscompilation. This builds probably correctly work only on AMD K10 CPU (which support SSE4A / AMD SSE4). Because gcc generates LZCNT instruction which seems to be incorrectly interpretated as BSR without crash on CPUs without support of SSE4A.

[Dark Shikari]

A miscompilation check for this case has been added to x264. The next release will error out loudly if an amdfam10 build is run on any non-Phenom CPU.

[LoRd_MuldeR]

Originally Posted by Dark Shikari

A miscompilation check for this case has been added to x264. The next release will error out loudly if an amdfam10 build is run on any non-Phenom CPU.

EDIT: Even on an older AMD machine (Athlon64) the "amdfam10" build produced different output than the generic build.

[Dark Shikari]

Originally Posted by LoRd_MuldeR

EDIT: Even on an older AMD machine (Athlon64) the "amdfam10" build produced different output than the generic build.

Obviously, it will do so on any machine that doesn't have SSE4a.

[LoRd_MuldeR]

Originally Posted by Dark Shikari

Obviously, it will do so on any machine that doesn't have SSE4a.

Help me understand this: AMD re-used opcodes in SSE4a that they already had used for something else on their own processors before? How braindead is this?

Anyway, if you add the aforementioned miscompilation the check for "amdfam10" and "non-Phenom", will there be a way to disabled/skip this check in the "fprofiling" phase?

Otherwise I wouldn't be able to fprofile "amdfam10" builds anymore

[J_Darnley]

Originally Posted by LoRd_MuldeR

So AMD re-used opcodes in SSE4a that they already had used for something else on their own processors before? How braindead is this?

Anyway, if you add the aforementioned miscompilation the check for "amdfam10" and "non-Phenom", will there be a way to disabled/skip this check in the "fprofiling" phase?

Otherwise I wouldn't be able to fprofile "amdfam10" builds anymore

The result is not wrong when you have this instruction. See: http://pastebin.org/142635
[EDIT] Oh, do you mean you want to run one of these on an problematic cpu?

[LoRd_MuldeR]

Originally Posted by J_Darnley

Oh, do you mean you want to run one of these on an problematic cpu?

I don't want to use an "amdfam10" optimized build on my Intel CPU and it's good that x264 normally won't let me do that. But: I still want to be able to fprofile those builds on my CPU. But if it always aborts, I cannot run fprofile for "amdfam10" on Non-Phenom CPU's. And I don't have a Phenom available. Getting "borked" output from fprofiling shouldn't be a big deal, as we discard that output anyway...

[kemuri-_9]

Originally Posted by LoRd_MuldeR

I don't want to use an "amdfam10" optimized build on my Intel CPU and it's good that x264 normally won't let me do that. But: I still want to be able to fprofile those builds on my CPU. But if it always aborts, I cannot run fprofile for "amdfam10" on Non-Phenom CPU's. And I don't have a Phenom available. Getting "borked" output from fprofiling shouldn't be a big deal, as we discard that output anyway...

let those of us with phenom pcs worry about getting our fprofiled -march=amdfam10 builds, ok?
I think it's better that x264 prevents the situation with an error to prevent those who don't know better than to allow those who do know better to be able to fprofile it.
there are more who don't know better than those who do.

[LoRd_MuldeR]

Sure. I was more thinking about something like a "#ifdef FPROFILE_GENERATE ... #endif" around the miscompilation check(s)

[aegisofrime]

So... the conclusion is the amdfam10 builds are fine to use, but only if you have a K10 CPU?