x264 - 32bit and 64bit different image result?

[Traps]

Earlier I was doing a small test to compare speed of x264 32bit, x264 64bit through avs4x264mod, and x264 64bit with avisynth64.

I used MeGUI for x264 32bit and x264 64bit through avs4x264mod and MeGUI64bit for x264 64bit, same avisynth script and x264 slowest preset was used.

The speed results weren't surprising, but i was surprised to see that 32bit produced a different image result compared to x264 64bit through avs4x264mod and x264 64bit which were identical.

32bit x264:
http://i.imgur.com/328m6.png

x264 64bit through avs4x264mod:
http://i.imgur.com/Q14dW.png

x264 64bit:
http://i.imgur.com/1M6HG.png

32bit x264:
http://i.imgur.com/7WFmA.png

x264 64bit through avs4x264mod:
http://i.imgur.com/90CI9.png

x264 64bit:
http://i.imgur.com/0gGyv.png

The differences are really small so they're best viewed in an image viewer but they're definitely there.

So i'm just wondering if there is a specific reason why 32bit result differs from 64bit results?

[CarlEdman]

Interesting question. Looking at the differences between the 32-bit and the 64-bit images shows small, but real deviations (the two 64-bit versions appear identical). For what it is worth, I also think the 32-bit versions look better by a tiny amount (e.g, the banding around the red hat in the second series of images). Were the encoded video streams the same length?

[Traps]

Yes, they were. Same source, avisynth script, settings were used for all 3 encodes.

[LoRd_MuldeR]

I'm not quite sure, but 32-Bit and 64-Bit builds might use different assembler functions on the lowest level.

Remember: For many functions, x264 provides multiple implementations and thus can pick the one that works best on the individual CPU.

And, as the 64-Bit capabilities of your CPU are only "unlocked" when running a 64-Bit build, x264 may very well choose different functions in 64-Bit mode.

These different implementations may differ slightly(!) in output, due to different rounding and stuff...

(You may want to try "--cpu-independent" or even "--no-asm", if you really need to get the identical output from both builds)

[burfadel]

A recent patch (last couple of months or so) intentionally had different output on different CPU's. Since the optimisation path for x86 and x64 is different, this can account for the output difference... I had a quick look but can't find which commit I am referring to.

This is just a complete guess, I was thinking the difference was probably just small differences in the output stream and not something that would be noticeable.

[LoRd_MuldeR]

You are referring to that one?

commit b7fa2ff50ef74eb8a27e675f8e418754965115e2 r2080
Author: Loren Merritt <pengvado@akuvian.org>
Date: Mon Aug 15 18:18:55 2011 +0000

SSSE3/SSE4 9-way fully merged i4x4 analysis (sad/satd_x9)

i4x4 analysis cycles (per partition):
penryn sandybridge
184-> 75 157-> 54 preset=superfast (sad)
281->165 225->124 preset=faster (satd with early termination)
332->165 263->124 preset=medium
379->165 297->124 preset=slower (satd without early termination)

This is the first code in x264 that intentionally produces different behavior
on different cpus: satd_x9 is implemented only on ssse3+ and checks all intra
directions, whereas the old code (on fast presets) may early terminate after
checking only some of them. There is no systematic difference on slow presets,
though they still occasionally disagree about tiebreaks.

For ease of debugging, add an option "--cpu-independent" to disable satd_x9
and any analogous future code.