x264 compilation

[bob0r]

I have put all revisions online.
I have setup a script to check, compile and mirror the latest version.
The script will check for a new revision every hour.
Generic version of x264vfw.dll is compiled, default compile settings from x264.
A full changelog can be found in changelog.txt :eek:
Read the readme.txt for info about the builds and more info.

url: http://x264.nl

[Sharktooth]

I added some cflags that should give some speed in general:
Added -O3 in vfw
Added -march=pentium3 -mmmx -msse -mfpmath=sse
Removed -ffast-math due to crashes with sse.

The (in)famous compiler bug was generated by -fomit-frame-pointer (that was removed as well).

[LigH]

Only P3 (, P4?) and AXP builds would kick me out of business: I only have a Duron 800, which supports only MMX and ISSE. So please: Do not turn down vanilla builds, if possible.

[Sharktooth]

Vanilla builds can be downloaded at the celtic druid site or bob0r site.

[bob0r]

Originally posted by LigH
Only P3 (, P4?) and AXP builds would kick me out of business: I only have a Duron 800, which supports only MMX and ISSE. So please: Do not turn down vanilla builds, if possible.

My builds are for any 386 or higher CPU.
The default Makefile doesn't force any cpu-specific optimizations, and gcc defaults to 386-compatible.
My compiled versions ( http://x264.nl/x264/readme.txt ) only adds no debug, so it should work just fine for you.
I just did a test on a Intel Pentium II, 334MHz, 512KB and it works fine.

I think adding cpu optimalisations and not offering the default version is not very smart, as indeed some people want to test and don't have the luxury of a great new CPU, or other reasons!
As x264 is still in early development (although progress is great),
Puting more specific cpu versions online also limits the feedback from users, which at this stage seems always welcome!


@Sharktooth
Yup edit is our friend :D
Agreed!


Grab my version from:
||
\/

[Sharktooth]

Ppl who doesnt own a P3 class CPU can always download your builds or celtic druid ones. That's the reason i added the links to my original post. It's quite useless to have 3 persons doing the same things, don't you think?

[LigH]

"I love you all!" :D

[LigH]

Stooopid question: An entry like "10L" in the changelog makes me wonder if the fixed bug was too embarassing to mention...

[el divx]

Has anyone noticed that the mirror is down? Tried to download the Athlon XP build a couple of minutes ago and nothing.

[Sirber]

WFM :o

[Sharktooth]

The mirror is overloaded. Just try again later.

[buzzqw]

rundll32.exe x264vfw.dll, Configure

isn't fuction or at last in 158 for p4 and p3

BHH

[Sharktooth]

It's no longer patched.
I restarted to compile from CVS again coz b-frame pyramid and weighted prediction was added to the vfw GUI.
Maybe i can re-enable the configure option for future builds.

[LigH]

Was it necessary or useful to remove the deblocking "Threshold" slider, and leave only the "Strength"?

[Sharktooth]

The vfw gui needs a heavy restyling coz there is no space for new options.
So if someone offers to make an "akupenguin proof" redesigning of the vfw GUI, it's more than welcome since there are already some options that are left out.
Btw, i'm designing my own...

[LigH]

Indeed - inside MeGUI, there are a hell of special advanced features revealed, which have not yet be seen in x264vfw.

[WelloBanir]

Concerning the ahlon-xp- build, I guess (MMX+SSE+3DNOW required) means

CFLAGS="... -m3dnow -msse -mmmx"

or is it

CFLAGS="... -march=athlon-xp"

or is it (for nasm)

DHAVE_SSE DHAVE_MMX DHAVE_3DNOW

(as in the x264-Makefile, sorry, don't have one here now).

Maybe it is a bit of everything.
Most of these flags do not seem to make that much of a difference yet, the framerates seem to be not much higher or lower (on Linux again only).

I am just asking, because i want to build it on Linux, and therefor i am searching for Flags (C, nasm) where i can get optimal performance.

Maybe i test gcc-4.0-beta with x264.

[planet1]

Hey Sharktooth, you can also add some AMD Durons to your build list.

The Durons 0.9-1.3 GHz (Morgan Core) & 1.4-1.8 Ghz (Applebred Core) should work with all AthlonXP "accelerations", as they support MMX, SSE & 3DNow!.

The old Durons < 950 MHz (Spitfire Core) can only cope with MMX & 3DNow!.


http://www6.tomshardware.com/cpu/20040601/images/cpu_history_big.gif


Last but not least, does GCC / MinGW make any use of the MMX+ or 3DNow!+ "Extended" instructions ?

[LigH]

My Duron works well with the Tbird builds of Mplayer/Mencoder. I guess they don't use too many 3Dnow!-Ext opcodes...

[akupenguin]

There are two ways to support all these cpu extensions:
There's the hand-optimized dsp functions (e.g. motion compensation, DCT) that come in several versions. Usually all versions are included in the executable, and it decides at runtime which to use. These will never cause compatibility problems. Currently there are no SSE or 3DNOW functions used in x264 (they're just known by the cpu recognition code), only MMX and Altivec.
Then there's compiler flags, which tell gcc that it can use the extra opcodes for the C part of the program. This is where cpu-specific builds come in. Since most of the parallelizable computations are in said dsp functions, cpu extensions don't make so much difference here.

[Sharktooth]

Originally posted by WelloBanir
Concerning the ahlon-xp- build, I guess (MMX+SSE+3DNOW required) means

CFLAGS="... -m3dnow -msse -mmmx"

or is it

CFLAGS="... -march=athlon-xp"

or is it (for nasm)

DHAVE_SSE DHAVE_MMX DHAVE_3DNOW

(as in the x264-Makefile, sorry, don't have one here now).

Maybe it is a bit of everything.
Most of these flags do not seem to make that much of a difference yet, the framerates seem to be not much higher or lower (on Linux again only).

I am just asking, because i want to build it on Linux, and therefor i am searching for Flags (C, nasm) where i can get optimal performance.

Maybe i test gcc-4.0-beta with x264.
i added -march=athlon-xp -mmmx -msse -m3dnow to the athlonxp compile. asm flags are unchanged.

[Sharktooth]

Originally posted by planet1
Hey Sharktooth, you can also add some AMD Durons to your build list.

The Durons 0.9-1.3 GHz (Morgan Core) & 1.4-1.8 Ghz (Applebred Core) should work with all AthlonXP "accelerations", as they support MMX, SSE & 3DNow!.

The old Durons < 950 MHz (Spitfire Core) can only cope with MMX & 3DNow!.


http://www6.tomshardware.com/cpu/20040601/images/cpu_history_big.gif


Last but not least, does GCC / MinGW make any use of the MMX+ or 3DNow!+ "Extended" instructions ?
You can use the athlon-xp optimized version for the morgan core durons, i also added an athlon tbird and a P2 build.
CPU optimized builds may be discontinued since there's no real big speedup (optimizations are only for the C code, not the asm), only few %.

EDIT: Updated with the new builds.

[Sharktooth]

P4 prescott build with SSE3 available.
Those new builds (p2, athlon tbird, prescott) have been patched to enable the "Configure" again (rundll32.exe x264vfw.dll,Configure).

[WelloBanir]

@Sharktooth: Thanks for the information. BTW. I have a duron, 1400 MHZ, "mobilized" (mobile), with 3dnow, mmx, sse, 3dnowext.

@akupenguin: Thanks for the information, too.

[Sirber]

duron don't have SSE IIRC

[Sharktooth]

Morgan core Durons have SSE coz they're derived from the Palomino core.
If you google for "duron morgan" you will find some info and specs :)

[LigH]

I'll check what my "Spitfire" can do, one moment...
__

The TBird compile seems to work well.
The P2 build, too (as expected).
Even the Athlon XP build works... well, so it probably isn't too optimized, yet.

[Sharktooth]

Spitfire is the first duron core version. So it supports MMX+3DNOW(+), so the tbird compile should work well.
The AXP build shouldnt work coz SSE is used... weird.

[planet1]

Originally posted by Sharktooth
You can use the athlon-xp optimized version for the morgan core durons, i also added an athlon tbird and a P2 build.


I knew that, by "adding the Durons to you build list" - i meant that you could mention that the AthlonXP build was for Durons as well :p .

e.g. AMD Build {MMX,SSE,3DNow!} -> (all AthlonXPs, Duron (Morgan,Applebred), other mobile or multiprocessor CPUs)

@ Sirber

The last two core revisions of the Duron (Morgan and Applebred) have SSE functionality - only the first Duron (Spitfire core) lacks this feature.
Btw the Applebred is actually an Athlon clone but yet labeled Duron.

@LigH

in order to find all your CPUs featuresets (your Spitfire might as well support MMX+) I recommend using WCPUID:

http://www.h-oda.com

;)

[Sharktooth]

GCC does not have explicit options for MMX+/iSSE/3DNOW+ etc.
but i found that 3dnow cpus supports SSE addressing that's why maybe the SSE builds seem to work or maybe GCC didnt use SSE at all on athlon-xp builds but preferred 3dnow.

[LigH]

I know what a Duron Spitfire (800 MHz, Family 6, Stepping 1) can do: http://www.sandpile.org/80x86

Mencoder reports it verbosely, too: http://forum.doom9.org/showthread.php?s=&threadid=87567&perpage=20&pagenumber=16

[Sharktooth]

Then there are 2 possibilities as i said in my previous post.

[LigH]

Indeed, I don't care too much why it surprisingly works. Probably the compiler didn't need to use SSE instructions anywhere.

If the source authors once may decide to use highly CPU specific assembler optimized parts for optimum speed-ups, and don't rely on C compiler optimizations anymore, this may indeed change then, and Athlon XP builds won't run on my Duron anymore. But I will be prepared then.

[TripleA]

First, the disclaimer:

It's been quite a while since I used this particular bit of info or anything related to it, so it is very likely it's not accurate. Indeed, it is more likely to be inaccurate than accurate. But perhaps someone can check if it's accurate, if it's important enough to them, for whatever reason.

Now, I believe the Spitfire had a partial SSE implementation. Termed iSSE or some such, I believe. "Integer SSE", perhaps. I believe there must be posts on the forum here dealing with this from back then.

Please don't base anything substantial on this piece of info without first verifying it since it would be likely to collapse, K?

BTW, there existed 1GHz and maybe even 1.1GHz Spitfires. So the clockspeed alone is not enough to decide which is which. Use CPU-Z or something.

Also BTW, I found the reference to an x264 CODEC that would run on 386 quite funny. What unit would you measure the encoding speed on that archaic piece of silicon? FPD? :)

[LigH]

Well, e.g. "hdot264" is that slow. Nevertheless, such implementations work at all. ;)

[dragongodz]

Now, I believe the Spitfire had a partial SSE implementation. Termed iSSE or some such, I believe. "Integer SSE", perhaps
correct, just as the thunderbird Athlons also had ISSE. a little info on ISSE here
http://www.avisynth.org/IntegerSSE

BTW, there existed 1GHz and maybe even 1.1GHz Spitfires.
sorry but no there didnt. 1GHZ is when AMD decided to switch to the Morgan core for Durons. actually from what i understand there was a small amount of 950mhz Morgan core cpus made aswell but they were abandoned quickly in favour of the 1ghz chip.

[Sharktooth]

Rev 167 is coming soon.
I'm "fighting" with yasm and asm code to make 64bit vfw compiles too :)

[MacAddict]

Is it possible to put the compile information the 'about' dialog box(ie. Athlon 64 build)? I've been trying a few of the optimized builds and then get confused as to which I have installed since only the core and date are shown:)

[Sharktooth]

I dont think i will compile CPU optimized build anymore since i had only few feedbacks about the compiles speed and the differences were not so big (only few % points).
I will keep a generic build (MMX only or SSE... i have to decide) and a 64 bit build.

[IgorC]

It´s very hard to do a few compilations for each new revision. But people appritiate that a lot for example as Xvid (P4 x64 etc) (not like commercial codecs VP7 Divx). Difference between compile p2 and p4 isn´t big but it is. Each minute is important. Don´t discriminate P4, athlonXP ;) since they are mainstream ;)

[TripleA]

Originally posted by dragongodz
sorry but no there didnt. 1GHZ is when AMD decided to switch to the Morgan core for Durons. actually from what i understand there was a small amount of 950mhz Morgan core cpus made aswell but they were abandoned quickly in favour of the 1ghz chip.

I took a look at the latest datasheets and they support what you are saying. But they haven't been updated since A.D. 2001, on the other hand.

And, I clearly remember that when my 700MHz Spitfire sputtered for the last time way back when Morgan was pretty new, I could only find 1GHz Spitfires in the local market and ended up getting a 1.1GHz Duron from the States to ensure it's a Morgan.

The local market parts *could* have been remarked. But if ever the difference between a Morgan and a Spitfire is significant, I would suggest not relying on clock speed to tell which is which.

[loni_blues]

Well, as I own an Athlon Thunderbird, I would love a generic build I could use. The last p2 generic build worked like charm.
Regards!

[Sirber]

Originally posted by Sharktooth
I will keep a generic build (MMX only or SSE... i have to decide) and a 64 bit build. I'd love to have the amd64 32bit builds. It works great! :D

[pest]

my athlon thunderbird cries for a generic mmx-compile :rolleyes:

[Sharktooth]

the P2 version IS a generic MMX compile...

[pest]

thanks very much sharktooth

regards

[DeathTheSheep]

Perhaps you should correct me if I'm wrong, but each "revision" is actually changing one small aspect of the encoder, right? So, essentially, if you don't much care for the improvement listed in the log, it would be OK to skip an upgrade, correct? Or do the incremental improvements often stretch beyond those recorded in the log?

Pardon me, but I'm asking this because x264 is being upgraded one HECK of a lot more frequently than I ever had mind to expect ( ;-) holy cow-- ppl must be towin' down on this baby!!! ), and this would help a lot. Thanks:)

[Sharktooth]

Every update reflects a committed change in the source.
The changes are reported in the log, so when build xxx is made it contains that change.
So if revision xxx has no significant improvement (for example, sometimes there are revisions that affect only the CLI encoder) you can skip it.

PS - Rev. 171 is coming... :)

[Sirber]

How about 178? ;)

[Sharktooth]

Done.
178 has only minor changes and doesnt change the codec efficiency.