x264 64-bit version,when? [Archive]

yokem55

19th July 2005, 03:44

Sharktooth

19th July 2005, 11:53

If you want a 64 bit version of x264, setup 64-bit linux and compile x264 on it. It is unlikely (unless MS fixes the problems on thier end) that there will be a 64 bit version on windows that is any faster than the 32 bit version.
What? It's already faster... read the 64 bit xvid thread or other 64 bit software benchies done by various websites on Win64...

Kostarum Rex Persia

19th July 2005, 15:05

Ok,but I expect a 64 bit version of x264 until the november.I hope that is possible.

Sharktooth

19th July 2005, 15:12

expectations leads to rumors... and rumors are usually bad...
dont expect a win64 x264 version until (and IF!!!) it gets announced.

Doom9

19th July 2005, 15:22

Ok,but I expect a 64 bit version of x264 until the november.If you have a signed and paid for contract I'm sure you can expect that to happen.. but since you're not paying anything you cannot expect anything ;)

yokem55

19th July 2005, 16:32

What? It's already faster... read the 64 bit xvid thread or other 64 bit software benchies done by various websites on Win64... The problem is that Win64 does not support 64-bit fpu and mmx instructions, only 32 bit ones. The only architecture extensions that Win64 supports in 64-bit mode is sse/2/3 code. As the current AMD64 asm (as is the 32-bit x86 asm) is heavily dependent on the fpu and mmx units, the current situation in Win64 is not conducive to a port of x264. If x264 does get going in 64-bit mode on win64, it will require the asm to be rewritten for sse, which would be very difficult to get worthwhile performance out of....

Sharktooth

19th July 2005, 17:01

Well... forget about FP and MMX coz the MS plan is to NOT SUPPORT them in future OSes (including Longhorn).
Once the transition to 64bits is complete even Intel wont support them in the future chips... they will keep SSEx only and remove MMX and FP stuff (even 32 bit support) to spare $$$ and avoid heat (and other) problems...
That's why win64 supports only SSEx...

yokem55

19th July 2005, 17:11

Intel wont support them in the future chips...Oh, Intel will support them, but they will be simply implimented with the sse units, but we are still at least a couple of years out from that. Intel won't completly get rid of x87 fp and mmx support for quite a long time as there is still a LOT of software out there that depends on it. In the meantime, linux handles 64-bit fp and mmx code just peachy...

Sharktooth

19th July 2005, 17:15

Latexxx

19th July 2005, 17:22

well... the story is: DRM. Intel wont support Linux anymore...( http://www.theinquirer.net/?article=24638 )
This is getting completely hilarious. Of course Intel knows that they can't afford to cut out Linux from their processors because it would make every Linux user buy an amd rig. Content protection using drm is completely different than locking out an operating syste.

Sharktooth

19th July 2005, 17:23

AMD has the same locking mechanisms... or it wont be able to run Longhorn and future MS OSes...
DRMed software will run ONLY on DRMed hardware and vice versa.
This is the (in)famous Palladium...

http://www.epic.org/privacy/consumer/microsoft/palladium.html
http://www.microsoft.com/presspass/features/2002/jul02/0724palladiumwp.mspx (hah... they removed it but it's still on google...)
http://www.theregister.co.uk/2002/06/28/ms_palladium_protects_it_vendors/
...

dinolib

19th July 2005, 17:45

It seems that DRM will not be included in Windows Longhorn. But it is just a delay...

http://punto-informatico.it/p.asp?i=54160&r=PI (italian)

http://www.eff.org/deeplinks/archives/003804.php#003804

Sirber

19th July 2005, 17:45

DRMed hardware will only talk (LAN, internet) with other DRMed hardware. So old servers and ols WS will not be able to communicate with the new ones.

Futur is filled with crap.

Revgen

19th July 2005, 18:08

...Until that you can always compile your own builds with 64bit support. ;)

COOL!

I'll have it done by tommorow. :D

Sharktooth

19th July 2005, 18:09

COOL!

I'll have it done by tommorow. :D
... for linux/BSD ...

bill_baroud

20th July 2005, 08:29

Intel wont support them in the future chips...

we still have a 8-bits mode inherited from the first x86 and they are still using this crap, so i don't see Intel dropping that easily a feature from their cpu... at least it doesn't go along the policy they seem to have for years now.

Sharktooth

20th July 2005, 12:16

bill_baroud

20th July 2005, 14:34

yeah, and that's for win64, i'm talking about cpu. And, well, i don't trust anything coming from "theinquirer".

But i'll stop here, because there is too much to say on the subject and the world-taking-over-by-microsoft-and-intel-feaar!

Latexxx

20th July 2005, 17:26

bill_baroud: the point is the non "certified" software wont run on those systems, so old software will not be supported at all, and the same end is planned for the 8, 16 and even 32 bit modes...
however if there will ever be a win64 version of x264 it will run only on non DRMed systems/OSes...
The point is that certified software will run in sandbox which no other program can access. Current software will run just as nowadays. The only change will be that non-certified software can't access the drm components and keys stored by the operating system.

Revgen

20th July 2005, 21:03

... for linux/BSD ...

I was just kidding.

I guess I'll have to work on my joking skills.

Sharktooth

21st July 2005, 15:36

doh!!!

Sharktooth

21st July 2005, 19:40

The point is that certified software will run in sandbox which no other program can access. Current software will run just as nowadays. The only change will be that non-certified software can't access the drm components and keys stored by the operating system.
Well that's for the fist palladium implementation... let's wait and see...

Kostarum Rex Persia

22nd July 2005, 01:46

Another question from me? What about SSE2 and SSE3 implementation in future 64-bit version of x264.Is it possible,and if the answer is yes,how much time is need for this work.

Sirber

22nd July 2005, 02:00

Having them in 32-bit could be a start... but is it usefull?

bill_baroud

22nd July 2005, 08:24

not much, it had already discussed somewhere (remember the "fake" SSE3 optimized build ?)

Sirber

22nd July 2005, 12:25

yeah, was just ICL compiled.

Kostarum Rex Persia

22nd July 2005, 23:17

But guys,remember that Intel compilers can't work very well on AMD processors.What you need is AMD compiler,and then SSE2 and SSE3 instructions should behave much better.

Episode

22nd July 2005, 23:47

There is no such thing as AMD compiler. If you are referring to patches that AMD has commited to GCC project, I can tell you that even with those patches Intel compiler is still faster than GCC on AMD.

Kostarum Rex Persia

22nd July 2005, 23:50

Perhaps,but a difference is certanly much smaller.

Episode

22nd July 2005, 23:54

No, actually GCC is really really slow when compared to Intel compiler on AMD platform. Even Microsoft's compiler is much faster.

Yes, Intel compiler is not optimizing code as much as it could for AMD, but it's still a lot better than other alternatives.

ChronoReverse

22nd July 2005, 23:57

Intel's compiler compiles excellent code for AMD chips in fact.

Albeit, the CPU detection routine is broken (doesn't detect SSE and SSE2 on the Athlon64s) but still by far the fastest code. (actually I'd say that Intel purposefully crippled the code generation for AMD too but the code is still faster)

However, ICL also produces broken code for me sometimes so I guess it depends on what you're compiling.

Kostarum Rex Persia

23rd July 2005, 14:35

Albeit, the CPU detection routine is broken (doesn't detect SSE and SSE2 on the Athlon64s) but still by far the fastest code. (actually I'd say that Intel purposefully crippled the code generation for AMD too but the code is still faster)

Yes,I agree with you.I hope that AMD will cruch Intel on court later this year.Intel is failed in many ways,so far.

Sharktooth

23rd July 2005, 15:11

The "excellent" code produced by Intel Compiler is still suboptimal (a wanted behaviour).
That's one of the advantage you (intel in this case) may gain from being in a monopoly...

Kostarum Rex Persia

23rd July 2005, 15:33

Yes.But I am suprised that AMD doesn't have own compiler for AMD64 processors.Someone told me that AMD have this compiler,but it cost too much.

Doom9

23rd July 2005, 15:57

Well, it takes time and resources to develop an optimized compiler. Intel reaps huge benefits every year because almost everybody buys their chips.

Kostarum Rex Persia

24th July 2005, 00:11

Well, it takes time and resources to develop an optimized compiler. Intel reaps huge benefits every year because almost everybody buys their chips.

Yes,unfortunately,you are right.One notice for all members of Doom9 forums.I just send a e-mail to AMD developer support,and I think that,perhaps,one or more AMD people will join us as members of Doom9 forums.Well,I hope that they are interested.

squid_80

24th July 2005, 05:16

Just getting back to the start of the thread...
I want to know when will arrive a 64-bit version of x264 codec.In September,or sooner.

I think I'm up to the challenge. Are you talking about a version for windows 64, using the vfw interface?

Doom9

24th July 2005, 09:54

I think that,perhaps,one or more AMD people will join us as members of Doom9 forumsThat may just be wishful thinking. I remember the days of Flaskmpeg idct optimizations just too well.. both Intel and AMD got into it a little but quickly lost interest.
Basically somebody needs to write a patch for ICL that performs a proper CPU identification.. that still doesn't yield perfect AMD optimized code, but it'll be faster anyway. And you cannot expect Intel to spend time to write optimized code for the main competitor's platform.. that's really up to AMD, and AMD's strategy has always been a bit different from Intel. Intel has an entire platform: cpu, chipset, flash, wireless chipset, and a lot of other stuff (they are into telephony for instance). AMD only has cpu and flash. In a perfect world, AMD could exactly match Intel's offering but that's just wishful thinking and we're lucky to have NVidia to create very good chipsets for the AMD platform.

Kostarum Rex Persia

24th July 2005, 14:59

Just getting back to the start of the thread...

I think I'm up to the challenge. Are you talking about a version for windows 64, using the vfw interface?

Yes,certanly.I mean x264 vfw 64-bit for Windows XP 64-bit edition.What can you tell me about that.Can you contribute in developing of x264 64-bit edition.

Sharktooth

24th July 2005, 15:12

I think I'm up to the challenge. Are you talking about a version for windows 64, using the vfw interface?
the vfw interface needs cli to be compiled first. also the vfw interface is entirely made in C... what needs to be ported are the ASM routines.
some MMX stuff was already ported to SSE2 ( http://forum.doom9.org/showthread.php?t=97683 ) and there's already a SSE2 patch for amd64 (in the same thread: http://forum.doom9.org/showthread.php?t=97683&page=3&pp=20 ) but some MMX stuff is still there...

Kostarum Rex Persia

24th July 2005, 16:31

Sharktooth,I need your opinion on this.Can you tell me,how x264 will behave,if x264 code is written in Delphi,or even Microsoft Visual Studio.

ChronoCross

24th July 2005, 16:36

Sharktooth,I need your opinion on this.Can you tell me,how x264 will behave,if x264 code is written in Delphi,or even Microsoft Visual Studio.

The only difference between writing C code in Ms visual Studio and notepad(then being compiled by gcc using make is that the Ms compiler will be used. You can use additional compiler flags in MS Visual Studio same as in gcc and possibly in theory the compiler might produce a tiny bit more speed on the windows platform. Additionally I think the coding environment is much to my liking and could be more organized if one wanted. But other than that the program used to code plays almost a non-esential role in the actual speed an performance of ones program.

Sharktooth

24th July 2005, 16:47

well... however C is faster than delphi.
for what concerns Visual Studio, it is not a programming language but a development suite.
The actual code can be already compiled with Visual Studio...

plonk420

24th July 2005, 19:07

well... the story is: DRM. Intel wont support Linux anymore...( http://www.theinquirer.net/?article=24638 ) and from longhorn on, MS OSes will be 64bit only...so they dont care about the old software...
oh.. and that's not "a couple of years"... it's in 2006.

that is so entirely stupid. i work in customer service for a cable/isp/telephony company and a majority (over half) of the internet installs are on computers running win98 or me. we only cover 4 states, but i'm SURE there'll at least be 1/3 or 1/4 of users not using even 2000 or xp in 2-4 years, even in the rest of the states, let alone world. and they can't force vendors to stop supporting those OSes as the business of support for those OSes would go elsewhere and maybe even increase in cost/value... wtf.

Yes,unfortunately,you are right.One notice for all members of Doom9 forums.I just send a e-mail to AMD developer support,and I think that,perhaps,one or more AMD people will join us as members of Doom9 forums.Well,I hope that they are interested.

until a year or two ago, i didn't even know they had CLASSES to program compilers. i hate programming as it is, but programming a compiler... :X that's GOTTA be a bitch...

squid_80

24th July 2005, 23:00

the vfw interface needs cli to be compiled first. also the vfw interface is entirely made in C... what needs to be ported are the ASM routines.
some MMX stuff wes already ported to SSE2 ( http://forum.doom9.org/showthread.php?t=97683 ) and there's alread a SSE2 patch for amd64 (in the same thread: http://forum.doom9.org/showthread.php?t=97683&page=3&pp=20 ) but some MMX stuff is still there...

Porting the MMX stuff is really not a problem... It's sort of preferable because the registers have no restrictions, unlike SSE2 where xmm6 & xmm7 are non-volatile in 64-bit mode (unlike 32-bit mode). MS really screwed up portability by doing that, IMO.
If the MMX code is easy enough to comprehend I might make my own SSE2 functions, implemented using intrinsics (does GCC handle intrinsics?). Whole program optimization should then be able to pick the best registers to use, which in my experience produces faster code than using external assembly compiled with yasm.

I want to try and keep the asm files OS independent, so the same files can be used to compile for linux or windows. But once it's done someone will need to check that it still works on linux, since I don't a 64-bit distro installed.

Kostarum Rex Persia

26th July 2005, 14:43

Good work squid_80,you are right.But writing a 64-bit version of x264 is, certanly,much harder than 32-bit.

Sharktooth

26th July 2005, 14:45

i dont think using intrinsics is a good idea coz gcc is not as good as Visual Studio.
Using intrinsics could lead to a huge drop in performance nullifying the speed advantage.
a proper xp64 implementation using yasm is the best choice.
also if your implementation works it could be submitted to the svn.