x264 64-bit version,when?

[Kostarum Rex Persia]

Have anybody try to measure x264 64-bit version encoding speed in program XMpeg 5.03 32-bit version, under Windows XP 64-bit edition? I only hope that Xmpeg 5.03 will work under 64-bit Windows.

So, Dark Knight, try testing x264 64-bit in this way, load any MPEG2 file into XMpeg 5.03 and try to test 64-bit version of x264.

[Death Knight®]

There was a little error which I corrected...( dolbydigital egyps is faster with 64 bit, not 32 bit, sorry for that)...

For testing...
Firstly, I have to use UNCOMPRESSED DATA SOURCE... Why? Because If I re-encode MPEG data, than it's not show us x264-x64's speed gain. But It shows mpeg2 decode and x264-64 encode gain...

Because of that, a measuring program must be use "uncompressed data". If you consist about using MPEG2 for input, than you cannot mesause x264-64 gain. It's clear....

"Kostarum Rex Persia" told about use of XMpeg...But I couldn't use that program for test 64 bit vfw driver.
"ONLY 64 BIT programs are compatible with 64BIT x264" like Virtual Dub AMD64.

But If you wonder MPEG2->x264 performance gain, I can calculate it via AviStynth64 and DGDecode64.dll (Special thanks for squid_80)

[Death Knight®]

I don't know where is the problem but I CANT VERIFY TESTS...

I tried same source with same programs now, but results are different. (32 bit and 64 bit had one or two seconds difference.). I have to warn to you my previous test MIGHT be wrong...

I will make detailed test when I stabilize my windows...

[Sharktooth]

Originally Posted by Kostarum Rex Persia

Have anybody try to measure x264 64-bit version encoding speed in program XMpeg 5.03 32-bit version, under Windows XP 64-bit edition? I only hope that Xmpeg 5.03 will work under 64-bit Windows.

So, Dark Knight, try testing x264 64-bit in this way, load any MPEG2 file into XMpeg 5.03 and try to test 64-bit version of x264.

stop asking for the impossible. a 32bit program using a 32bit interface to a 64bit codec is not possible. stop it please.

[Kostarum Rex Persia]

Originally Posted by Sharktooth

stop asking for the impossible. a 32bit program using a 32bit interface to a 64bit codec is not possible. stop it please.

Calm down, I didn't know that. Too bad, xmpeg from www.xmpeg.net don't have, yet, 64-bit edition.

Death Knight®, can you test x264 64-bit in some other encoding program, not only in VirtualDub 1.6.11?

[squid_80]

Originally Posted by Death Knight®

There was a little error which I corrected...( dolbydigital egyps is faster with 64 bit, not 32 bit, sorry for that)...

Um, the number are still say the opposite

For testing...
Firstly, I have to use UNCOMPRESSED DATA SOURCE... Why? Because If I re-encode MPEG data, than it's not show us x264-x64's speed gain. But It shows mpeg2 decode and x264-64 encode gain...

Because of that, a measuring program must be use "uncompressed data". If you consist about using MPEG2 for input, than you cannot mesause x264-64 gain. It's clear....

"Kostarum Rex Persia" told about use of XMpeg...But I couldn't use that program for test 64 bit vfw driver.
"ONLY 64 BIT programs are compatible with 64BIT x264" like Virtual Dub AMD64.

But If you wonder MPEG2->x264 performance gain, I can calculate it via AviStynth64 and DGDecode64.dll (Special thanks for squid_80)

You're exactly right - using uncompressed source (preferably using the CLI) is the best way to test the performance of x264 by itself. As soon as you start involving other programs that aren't as optimised (avisynth in particular) the speed gain disappears. The problem with avisynth is that is uses lots of inline assembly code which isn't allowed by microsoft's compiler. So I have to rewrite it and it ends up slower. I have heard that Intel's x64 compiler does support inline assembly so I've been trying to download an evaluation copy but their website always gives me a 404. I might just end up forking out US$399 and buy the damn thing.

[Sirber]

I'm tempted to install XP64 and release 64bit RealAnime LE... Can all sharktooth patch be applied to 64bit x264?

[squid_80]

Originally Posted by Sirber

I'm tempted to install XP64 and release 64bit RealAnime LE... Can all sharktooth patch be applied to 64bit x264?

Yes, the patches can easily be applied if you want me to.

Not sure how you'd go with a 64-bit version of RealAnime... There's the issue of audio for one thing (though if you're just passing a commandline it would probably work) plus avisynth64 isn't really up to scratch... DirectShowSource isn't available since there's no codecs, and you'd be pretty restricted with filtering - undot for noise reduction, only the core resizers are available, no sharpening (I might do warpsharp soon), and decomb for deinterlace/ivtc.

My tests give a rough 4% increase with uncompressed input and default settings. It seems more complex settings (-m and --me in particular) give a greater gain.

[Shinigami-Sama]

it's strange they give so little gain, if it's 64 bit they should beable to access the data faster, and ad 64bit numbers fast, which is correct me of I'm wrong, the majority of filters and encoding?

either way, I might get win64 runing on this lil laptop soon, depends how much I have to pay or if theres still betas around

[jvrobert]

Originally Posted by Shinigami-Sama

it's strange they give so little gain, if it's 64 bit they should beable to access the data faster, and ad 64bit numbers fast, which is correct me of I'm wrong, the majority of filters and encoding?

either way, I might get win64 runing on this lil laptop soon, depends how much I have to pay or if theres still betas around

Actually I would expect little change, the SSE* instruction sets are better at this stuff than native x86-64 instructions, no?

Unless the developer isn't playing fair(*), I would expect only a marginal general speed improvement in a native 64-bit compiled binary due to more registers, and of course the ability address more than 2-3G of memory per process. Some apps will benefit more than others, but I don't think encoding apps would be one of them.

* Witness the recent game, can't remember the name, where the developer made this laughable attempt to make it look like the 32-bit version didn't look nearly as good as the 64-bit version. Since this was all done in the GPU, they had obviously and blatantly just crippled the 32-bit version.

[squid_80]

Originally Posted by jvrobert

Actually I would expect little change, the SSE* instruction sets are better at this stuff than native x86-64 instructions, no?

Took me a second to work out what you meant there - yes the majority of the code is done by SSE (mmxext) instructions which don't gain much from x64 mode. But there are a few little tricks e.g. a MMX register can be dumped into a GPR and multiplied by a constant to get the horizontal sum instead of doing movq-shift-add.

Unless the developer isn't playing fair(*), I would expect only a marginal general speed improvement in a native 64-bit compiled binary due to more registers, and of course the ability address more than 2-3G of memory per process. Some apps will benefit more than others, but I don't think encoding apps would be one of them.

* Witness the recent game, can't remember the name, where the developer made this laughable attempt to make it look like the 32-bit version didn't look nearly as good as the 64-bit version. Since this was all done in the GPU, they had obviously and blatantly just crippled the 32-bit version.

How could I not be playing fair when the 32-bit versions aren't provided by me?

[akupenguin]

updated patch.
Just a few lines broke on linux 64bit, but I'm not too sure of my fixes (particularly %macro pad), so I want to check that it still works on windows.

Also: I see that you've removed a bunch of lines like

movsxd rsi, esi  ; i_stride

These lines are theoretically needed: At least in gcc's calling convention, any unused MSBs are allowed to contain garbage. It just so happens that when I compile x264 as is, it works. But I don't want to depend on whims of the optimizer. If you still want to remove them, the alternative is to change all strides everywhere to "long".

[squid_80]

Originally Posted by akupenguin

updated patch.
Just a few lines broke on linux 64bit, but I'm not too sure of my fixes (particularly %macro pad), so I want to check that it still works on windows.

That pad macro's a bitch. It's there because functions under windows are meant to have 6 bytes padding between them - theoretically for hot patching but seems like it's just laying out the red carpet for hackers if you ask me. It gives warnings "trailing garbage after macro name ignored" (or something like that) because I couldn't come up with a cleaner way.

Also: I see that you've removed a bunch of lines like

movsxd rsi, esi  ; i_stride

These lines are theoretically needed: At least in gcc's calling convention, any unused MSBs are allowed to contain garbage. It just so happens that when I compile x264 as is, it works. But I don't want to depend on whims of the optimizer. If you still want to remove them, the alternative is to change all strides everywhere to "long".

That wouldn't work on windows - a long is still 32 bits in 64-bit mode (yet the compiler starts spewing errors if you try and mix longs and ints). I know if the parameters are passed in memory not to touch the MSBs (hence the parm1q vs parm1d macros) but I couldn't find any definite information on parameters passed in registers, just assumed that any int operations on a register would use the 32-bit name (eax instead of rax) hence zero out the high dword. It would be pretty bad form for the compiler to act any other way but like you said it's bad to assume... I did find some information at x86-64.org (page 23) that seems to imply the registers don't need zero-extending but it's not crystal clear. I think I'll leave it up to you

[squid_80]

Has anyone tried testing multiple threads on a X2 chip? I just realised today the code wasn't being included, so there's a new build available.

[Death Knight®]

I have re-test x264-vfw-x64...

Problem is UNCOMPRESSED data takes much area from harddisk. Due defragmantation, results shows highly unstable values... Solution is using RAMDrive for testing

I used Dolby Digital's Rain for uncompressed source (807 MB) @ RamDrive...
I want slower compression than I set settings to:
500K one pass, Partition Decision: 6 - RDO ( Slowest) , Method: Exhaustive Search , Range 16, Chroma ME enabled...
Used higher priority. virtual dub.

32 Bit VirtualDub with x264-vfw: 2:04.6 = 124.5 seconds
64 Bit VirtualDub with x264-vfw: 1:53.0 = 113 secconds

x64 version is nearly %10 faster than x32 one at theese settings...

[Sharktooth]

Originally Posted by squid_80

Has anyone tried testing multiple threads on a X2 chip? I just realised today the code wasn't being included, so there's a new build available.

please send the patch to akupenguin so we can compile and test it.

[akupenguin]

Originally Posted by Death Knight

Method: Exhaustive Search

Which means you're essentially timing SAD and nothing else, since exhaustive search takes the majority of the CPU-time. And yes, 64bit SAD is 10% faster than 32bit SAD, just due to the calling convention.

Originally Posted by Sharktooth

please send the patch to akupenguin so we can compile and test it.

What patch? Surely x264's current multithreading works on X2?

[Sharktooth]

the one used for the "new build":

Originally Posted by squid_80

Has anyone tried testing multiple threads on a X2 chip? I just realised today the code wasn't being included, so there's a new build available.

[Death Knight®]

squid_80, can you tell me how can I compile for Windows X64 Bit?
I have nasm,yasm, VC 2003, cygwin tools...

I can compile 32 version with cygwin, but I think 64 bit version is different from it.
(I am trying to compile original version 341, because after 336 native code is compatible with win X64, isn't it?..)

[squid_80]

Originally Posted by Sharktooth

please send the patch to akupenguin so we can compile and test it.

Easy, just add __WIN32__ to the preprocessor definitions for libx264. (Sorry, I probably confused things by saying there was code missing when it was really just a #define.) It does seem to work under windows x64 but I don't have a dual core so I can't test properly.