SSE2 patch for x264

[bond]

i have been asked to post this here as the dev, AlexI, just registered and cant post till now:

grab the patch here (http://www.geocities.com/x264hack/sse2-pixel-routines.diff.txt)

sad/ssd 16x16, 16x8 and satd of all sizes greater than 8x4 are sse2'ed with this patch

would be great if someone (sharktooth ;) ) can compile x264 with this patch and people could test what performance this has on various cpus

there is also http://www.geocities.com/x264hack/minibench.c and http://www.geocities.com/x264hack/minibench.sh.txt for some help with benchmarking just those functions

enjoy!

[Sharktooth]

on my way...

[Sirber]

I could try on my AMD64 3000+. With SSE2 compiled, would x264 detect CPU extensions and enable / disable SSE2 automaticly? Or it's at compile time.

[Sharktooth]

I have some temporary problems with my ISP so i cant upload the new builds right now.
I'll make them available ASAP.

[ArcticFox]

Awesome, hope it speeds up encoding a bit.

[yokem55]

The pactch applies cleanly, but when compliling natively under 64-bit linux, the build does not complete. It dumps out in an error at the final linking stage. When building in 32-bit mode (linux32 ./configure --extra-cflags="-m32" --extra-ldflags="-m32" && linux32 make) The compile builds and links cleanly. I haven't done any testing with this build to see if there are any performance improvements...

[yokem55]

Some initial tests seem to show the patched version to be slower than the unpatched....I'll have full benches in a few.

[Sirber]

What is your CPU?

[ChronoCross]

Some initial tests seem to show the patched version to be slower than the unpatched....I'll have full benches in a few.

This is impossible.

[yokem55]

Okay here are the benches. I encoded the first 300 seconds of The Incredibles using my usual setup (mencoder frameserving a raw yuv stream into a fifo that is then read and encoded by x264). The full command is here: mencoder inc.vob -endpos 300 -of rawvideo -ovc raw -vf swapuv,crop=720:352:0:64 -noskip -skiplimit 0 -nosound -o inc.raw -ofps 24000/1001 & x264 -p 2 -B 869 -b 3 -r 3 -m 6 --me umh -f --b-pyramid -w -A all -8 --sar 427:360 --fps 24000/1001 -o inc.264 inc.raw 720x352 I then ran this with three different builds of x264: 1) 32-bit without being patched; 2) 32-bit with the new patch; 3) 64-bit without the patch. As I said above, it does not compile in 64-bit with the patch applied.

Here are the results:
32-bit-no patch
encoded 7191 frames, 7.10 fps, -4759.81 kb/s

32-bit-with patch
encoded 7191 frames, 7.10 fps, -4759.81 kb/s

64-bit-no patch
encoded 7191 frames, 8.25 fps, -4759.81 kb/s

There was no difference between the patched and unpatched version. This could be caused by a couple of things. 1) The features I've enabled could be bottlenecking the codec in a place other than the areas optimized in the patch or 2) The asm generated by gcc is just as fast as hand coded asm. My guess is the first situation. I will disable rdo, 8x8dct, ref frames, etc. and try this again.

Someone else asked about my cpu: Its an Athlon 64 3000+ running at 2.4 ghz and x264 reports the following extensions being present: CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1

[yokem55]

I ran through the above again with much lighter settings:mencoder inc.vob -endpos 300 -of rawvideo -ovc raw -vf swapuv,crop=720:352:0:64 -noskip -skiplimit 0 -nosound -o inc.raw -ofps 24000/1001 & x264 -p 1 -b 1 -r 1 -m 1 --me dia -w -A none --sar 427:360 --fps 24000/1001 -o inc.264 inc.raw 720x352

I got:

32-bit without patch:
encoded 7191 frames, 31.08 fps, -3645.03 kb/s

32-bit with patch:
encoded 7191 frames, 31.39 fps, -3645.03 kb/s

64-bit without patch:
encoded 7191 frames, 35.03 fps, -3645.03 kb/s

The patch makes for a very minor speedup in this particular situation (about one percent).

[Sirber]

well.... sad conclusions...

[Revgen]

@yokem

I believe that I read somewhere that SSE compilers released by Intel puposely make SSE code run slower on AMD cpu's.

Do you use an AMD cpu?

[CiNcH]

I believe that I read somewhere that SSE compilers released by Intel puposely make SSE code run slower on AMD cpu's.

Interesting, directly had to look it up... hope to be allowed to post links...

http://techreport.com/onearticle.x/8547


Yokem used GCC, not Intel...

[Kostarum Rex Persia]

Zes,but what about SSE3 implementation in x264.It's well known that one instruction of SSE3 can significant improve compression speed.LDDQ,I think.

[thed33p]

Interesting, directly had to look it up... hope to be allowed to post links...

http://techreport.com/onearticle.x/8547

here (http://yro.slashdot.org/comments.pl?sid=155593&threshold=5&commentsort=0&tid=142&tid=118&tid=123&mode=nested&cid=13044057) is a link to the workaround. Courtesy of slashdot

[ChronoReverse]

Zes,but what about SSE3 implementation in x264.It's well known that one instruction of SSE3 can significant improve compression speed.LDDQ,I think.

Newer revisions of the Athlon64 fully support SSE3 (the HT related instructions are just ignored since they don't actually "do" anything but are for optimizing HT).


Probably not an issue since getting SSE and SSE2 optimization done would probably be a higher priority...

[Sirber]

Currently testing it. Doesn't seem faster :( Maybe ~1 FPS more...

[bond]

am i right that you, sirber and yokem55, have the same cpu? any results with other ones? pentium4?

the author writes:
They are considerably faster, but I don't know exactly how much in a typical setup, because the only SSE2-capable machine I have is a 4-way Xeon box which produces very anomalous timing results. The instruction count is certainly lower, from 1268 to 852 in the case of satd16x16. I would really appreciate numbers for a single-processor Pentium-4 and Athlon-64/Opteron.did anyone use the minibench tool i link to in the first post, the author wrote for running the benchmark?

[azsd]

I can't get the x264 binarary complied by VC 7.1 + ICL9.

only libx264.lib generated.

[superdump]

From our tests in #x264 it is slower.

Chronocross: It is possible. It's just that the new SSE2 asm is slower than the other asm available. It's no big deal, AlexI is working on it to come up with something else. :)

[bond]

Chronocross: It is possible. It's just that the new SSE2 asm is slower than the other asm available. It's no big deal, AlexI is working on it to come up with something else. :)and here it is:
http://www.geocities.com/x264hack/sse2-pixel-routines-v3.diff.txt (patch the clean source)

[Latexxx]

I don't want to be a pain in the arse but FSF states in their GPL FAQ that it isn't enough to make changes available as patch files. Full snapshots should be used instead of.
I don't really care but somebody could.

[Doom9]

on the other hand unified diff is what's used for patch submission, so using patch you can integrated it into the source snapshot.

[Latexxx]

And this can be part of the official development instead of fork so I can't really see any reasons for releasing full snapshots either.

[Doom9]

patches first need to be reviewed (and possibly tested) before being committed.. That ensures that nothing is broken, that the patch fits into the existing framework, and that only features the project maintainer wants to be added, will be added.

[nm]

I don't want to be a pain in the arse but FSF states in their GPL FAQ that it isn't enough to make changes available as patch files. Full snapshots should be used instead of.
I don't really care but somebody could.

Could you point out the specific phrase stating this? As far as I know, GPL only requires one to provide full source code corresponding to binaries provided. Here there are no binaries at all. If someone makes them available, that person should take care to also supply the full source code. One can freely take any GPL'ed code, modify it and only release the modified parts under GPL.

Edit:
By the way, GPL doesn't actually require one to give out the source code with the binary (on a website or other medium). Section 3 (b) states that it is enough to accompany the binary with a written offer to supply the source code if asked to.

[Sharktooth]

x264 r280 CLI + SSE2 patch (http://www.webalice.it/f.corriga/x264/X264CLI_rev280+SSE2.7z)
x264 r280 VFW + SSE2 & SAR patches (http://www.webalice.it/f.corriga/x264/X264VFW_rev280+SSE2.exe)
Sources (with patches applied) (http://www.webalice.it/f.corriga/x264/X264_rev280+sarfix+ss2.src.7z)

[CiNcH]

Not much of an improvement (if any) here either with an Intel Pentium M 1.6 GHz (Dothan Core, 2 MByte L2-Cache, SSE2).

[bond]

any numbers? what about the minibench tool?

[Kostarum Rex Persia]

Sirber and Sharktooth,I must ask you,because I don't have a SSE2 capable proccesor(Athlon XP 3200+,SSE only).Can SSE and SSE2 instructions improve speed of x264 compression,of course,if these instructions are good impemented in the source.I assume that SSE and SSE2 curently can't implement without hard work.

Boys,can you improve SSE2 implementation in x264.I think that this is crucial for compression speed in future,because SSE3 can't work properly without SSE and SSE2 instructions.I mean if SSE and SSE2 are implement properly,then SSE3 shows full power.

[Sharktooth]

dont think sse2 will do any good. however, even if there's no speed change, it could be usefull to keep the SSE2 code coz future chips may have parallel SSEx processing.

[Sirber]

I'm not the one who created SSE2 patches, and I'm not very good in assembly :). From what I read, a good SSE2 implementation can boost speed by ~25% on top of MMX improvements.

[CiNcH]

CPU: Intel Pentium M 725 (1.6 GHz)
SIMD: MMX, SSE, SSE2


Test 1: 3 ref. frames, 3 cons. b-frames, adaptive b-frame decision, wighted b prediction, deblocking -2/-2, CABAC, all mb subpartition for ME, Rate-Distortion opt. mb subpartion decision, Hexagon ME, Chroma ME, 8x8 DCT

1st pass: 5.551 fps
2nd pass: 6.093 fps


SSE2 optimized

1st pass: 5.633 fps
2nd pass: 6.094 fps


Test 2: 1 ref. frame, 1 cons. b-frame, adaptive b-frame decision, deblocking -2/-2, CAVLC, all mb subpartition for ME, always QPel [4] mb subpartion decision, Diamond ME

1st pass: 12.993 fps
2nd pass: 14.822 fps


SSE2 optimized

1st pass: 12.997 fps
2nd pass: 14.820 fps

[Latexxx]

Could you point out the specific phrase stating this? As far as I know, GPL only requires one to provide full source code corresponding to binaries provided. Here there are no binaries at all. If someone makes them available, that person should take care to also supply the full source code. One can freely take any GPL'ed code, modify it and only release the modified parts under GPL.
As I said, it's in the Faq, not in the license itself.
http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceIsInconvenient

[nm]

As I said, it's in the Faq, not in the license itself.
http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceIsInconvenient

Yes, I understood that. And as I said, this only concerns binary distribution, and even then it suffices to attach only a written offer to supply the full code when requested.

[AlexI]

Thanks to everyone who is helping test this!

A few comments:

Don't expect too much right away. What we have here is a correctly working SSE2 implementation which is a significant achievement in itself ;) It can and will become faster as I get more of a feel for what instruction scheduling is optimal. And yes, SSE3 is relatively easy based on this.

So far, the early indications are that the Athlon64 implementation of SSE2 is quite slow *when running code optimized for a P4*. This may be just latency, or it could be a throughput limitation, or it could be other things like unfavorabe register-file effects. I don't have such a box available at the moment, so I can't work on that. Maybe later.

In my tests (on a 2.4GHz Xeon) the latest versions of the SSE2 routines are 25 to 30% faster than MMX. The overall speedup will be half of that at best.

As people have raised various concerns about GPL and so forth: all of these patches are released under the GPL. I don't think there are any license issues at all. It is my intention to have this merged into the main x264 source *when it is ready* and if other developers approve of course. I am not going to start a new branch.

I really need minibench results. Some of these routines may be slower and some may be faster on a particular CPU, but I need to know which is which. If you run an overall encoding speed test, the two will probably cancel out. Minibench and the latest patch are here:
http://www.geocities.com/x264hack/minibench.c
http://www.geocities.com/x264hack/minibench.sh.txt
http://www.geocities.com/x264hack/sse2-pixel-routines-v3.diff.txt

Enjoy.

[Sirber]

Cool!!!! Thanks for your excellent work! :D

[ChronoReverse]

Are some of the builds done using GCC instead of ICL? I wonder if the Intel detection subroutine could behaving a hand in this.


Nonetheless, getting SSE2 ASM to be as fast as the optimized (relatively) MMX routines is rather good =)

[Kostarum Rex Persia]

Sharktooth,can you,please,soon post a new revision of x264 with further improvments in SSE2 code.I really think that curently SSE2 code can be significantly optimised for AMD processors.

I will send mail directly to AMD internet site,with question about SSE, SSE2 and SSE3 implementation in Athlon64 processors.Perhaps they help us to improve our work in such things,as properly optimizations in x264 codec.

[Sirber]

Sharktooth is compiling, not creating the SSE code. Don't mix :)

[nm]

I ported the SSE2 patch to amd64. No additional SSE registers used or any other fancy tricks made, so no speedup. The amd64 diff must be applied on top of AlexI's patch. You can get it from here:
http://www.cs.helsinki.fi/u/mikkila/patches/x264/sse2-pixel-routines-v3-amd64.diff

Some of you will probably ask if this works on 64-bit Windows. I've heard there are problems with compiling/executing MMXEXT code, so probably not yet. The SSE2 code should be portable, but since it only replaces part of the MMXEXT code, it won't make things easier than before.

And then my minibench results on an Athlon64 2800+ 64-bit mode:

cpuspeed = 1804139000.000000
loops = 100000000
emptyloop time = 2.6500 cpl = 47.810

x264_pixel_sad_16x16_mmxext time = 6.2500 cpl = 64.949
x264_pixel_sad_16x8_mmxext time = 4.7500 cpl = 37.887
x264_pixel_sad_8x16_mmxext time = 4.8200 cpl = 39.150
x264_pixel_sad_8x8_mmxext time = 3.6900 cpl = 18.763
x264_pixel_sad_8x4_mmxext time = 3.2800 cpl = 11.366
x264_pixel_sad_4x8_mmxext time = 3.7300 cpl = 19.485
x264_pixel_sad_4x4_mmxext time = 3.2800 cpl = 11.366
x264_pixel_ssd_16x16_mmxext time = 18.730 cpl = 290.11
x264_pixel_ssd_16x8_mmxext time = 10.650 cpl = 144.33
x264_pixel_ssd_8x16_mmxext time = 11.190 cpl = 154.07
x264_pixel_ssd_8x8_mmxext time = 7.3200 cpl = 84.253
x264_pixel_ssd_8x4_mmxext time = 5.2800 cpl = 47.449
x264_pixel_ssd_4x8_mmxext time = 5.5900 cpl = 53.042
x264_pixel_ssd_4x4_mmxext time = 4.5400 cpl = 34.098
x264_pixel_satd_16x16_mmxext time = 41.480 cpl = 700.55
x264_pixel_satd_16x8_mmxext time = 22.200 cpl = 352.71
x264_pixel_satd_8x16_mmxext time = 22.170 cpl = 352.17
x264_pixel_satd_8x8_mmxext time = 12.310 cpl = 174.28
x264_pixel_satd_8x4_mmxext time = 7.8700 cpl = 94.176
x264_pixel_satd_4x8_mmxext time = 7.8700 cpl = 94.176
x264_pixel_satd_4x4_mmxext time = 5.4100 cpl = 49.794

x264_pixel_sad_16x16_sse2 time = 7.3100 cpl = 84.073
x264_pixel_sad_16x8_sse2 time = 5.2400 cpl = 46.727
x264_pixel_ssd_16x16_sse2 time = 15.740 cpl = 236.16
x264_pixel_ssd_16x8_sse2 time = 9.6600 cpl = 126.47
x264_pixel_satd_16x16_sse2 time = 44.800 cpl = 760.44
x264_pixel_satd_16x8_sse2 time = 23.880 cpl = 383.02
x264_pixel_satd_8x16_sse2 time = 23.920 cpl = 383.74
x264_pixel_satd_8x8_sse2 time = 13.740 cpl = 200.08
x264_pixel_satd_8x4_sse2 time = 8.7000 cpl = 109.15

Apparently SSE2 versions of ssd_16x16 and ssd_16x8 run a bit faster than MMXEXT. Other functions are slower.
In a quick encoding test the SSE2 version was about 4% slower overall.

[bond]

some interesting info about sse2 on amd64 with intels compiler:
http://forum.doom9.org/showthread.php?t=87299

basically the discusion was about Intel C++ compiler not using SSE2 on an Athlon64 even though it has SSE2 when using the QxN or QaxN options. these both cause a check for real Intel cpu aswell as SSE2 capability.

[Sharktooth]

Sharktooth is compiling, not creating the SSE code. Don't mix :)
exactly :)

[Kostarum Rex Persia]

[QUOTE=nm]I ported the SSE2 patch to amd64. No additional SSE registers used or any other fancy tricks made, so no speedup.
QUOTE]

Nm,I am greatful for your work,but listen me.If we want a significant speedup of x264 compression,then you must try to implement all that "other fancy tricks and additional SSE registers".Can you do it.

[Sirber]

[QUOTE=nm]I ported the SSE2 patch to amd64. No additional SSE registers used or any other fancy tricks made, so no speedup.
QUOTE]

Nm,I am greatful for your work,but listen me.If we want a significant speedup of x264 compression,then you must try to implement all that "other fancy tricks and additional SSE registers".Can you do it.
First, be polite. Second, don't harras developpers. They devellop in their free time, is all meaning of the word free. Developping takes time, free time. Take a beer and relax.

[Kostarum Rex Persia]

Sirber,I didn't want to harras anybody.I am just ask nm can he do it.Nothing more.I don't expect from him to finish new code tommorow.

[Doom9]

I don't know if it's the language, but I'm afraid many of your recent post come across as very demanding. Since none of these people owes you anything, you need to seriously work on your communication skills.

[nm]

Nm,I am greatful for your work,but listen me.If we want a significant speedup of x264 compression,then you must try to implement all that "other fancy tricks and additional SSE registers".Can you do it.
I'm afraid this is really not my piece of cake. I'm more interested in algorithmic improvements than hand-coding some tight loops. And anyways, I don't think we can expect more than a 20% speedup (12 fps instead of 10) from fully amd64-optimized code compared to the existing MMX implementation. Of course, there is the carrot of getting 64-bit x264 running on Windows, but since my interest on that platform is zero, I wouldn't count on myself getting it done.
Perhaps now is the time for you to go to the local library and fetch a good book on assembly programming ;)

[yokem55]

I tested the amd64 code, and while it compiled alright, common/pixel.c had a ton of warnings with it and the resulting build segfaulted upon usage. The warnings are here: gcc -Wall -I. -O4 -ffast-math -D__X264__
-DHAVE_MALLOC_H -DHAVE_MMXEXT -DHAVE_SSE2
-DARCH_X86_64 -DSYS_LINUX -DMP4_OUTPUT -s
-fomit-frame-pointer -DHAVE_GETOPT_LONG=1 -c -o
common/pixel.o common/pixel.c
common/pixel.c: In function `pw_x264_pixel_sad_16x16_mmxext':
common/pixel.c:66: warning: implicit declaration of function `printf'
common/pixel.c:66: warning: cast from pointer to integer of different size
common/pixel.c:66: warning: cast from pointer to integer of different size
common/pixel.c:66: warning: cast from pointer to integer of different size
common/pixel.c:66: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_sad_16x8_mmxext':
common/pixel.c:67: warning: cast from pointer to integer of different size
common/pixel.c:67: warning: cast from pointer to integer of different size
common/pixel.c:67: warning: cast from pointer to integer of different size
common/pixel.c:67: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_sad_8x16_mmxext':
common/pixel.c:68: warning: cast from pointer to integer of different size
common/pixel.c:68: warning: cast from pointer to integer of different size
common/pixel.c:68: warning: cast from pointer to integer of different size
common/pixel.c:68: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_sad_8x8_mmxext':
common/pixel.c:69: warning: cast from pointer to integer of different size
common/pixel.c:69: warning: cast from pointer to integer of different size
common/pixel.c:69: warning: cast from pointer to integer of different size
common/pixel.c:69: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_sad_8x4_mmxext':
common/pixel.c:70: warning: cast from pointer to integer of different size
common/pixel.c:70: warning: cast from pointer to integer of different size
common/pixel.c:70: warning: cast from pointer to integer of different size
common/pixel.c:70: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_sad_4x8_mmxext':
common/pixel.c:71: warning: cast from pointer to integer of different size
common/pixel.c:71: warning: cast from pointer to integer of different size
common/pixel.c:71: warning: cast from pointer to integer of different size
common/pixel.c:71: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_sad_4x4_mmxext':
common/pixel.c:72: warning: cast from pointer to integer of different size
common/pixel.c:72: warning: cast from pointer to integer of different size
common/pixel.c:72: warning: cast from pointer to integer of different size
common/pixel.c:72: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_ssd_16x16_mmxext':
common/pixel.c:74: warning: cast from pointer to integer of different size
common/pixel.c:74: warning: cast from pointer to integer of different size
common/pixel.c:74: warning: cast from pointer to integer of different size
common/pixel.c:74: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_ssd_16x8_mmxext':
common/pixel.c:75: warning: cast from pointer to integer of different size
common/pixel.c:75: warning: cast from pointer to integer of different size
common/pixel.c:75: warning: cast from pointer to integer of different size
common/pixel.c:75: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_ssd_8x16_mmxext':
common/pixel.c:76: warning: cast from pointer to integer of different size
common/pixel.c:76: warning: cast from pointer to integer of different size
common/pixel.c:76: warning: cast from pointer to integer of different size
common/pixel.c:76: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_ssd_8x8_mmxext':
common/pixel.c:77: warning: cast from pointer to integer of different size
common/pixel.c:77: warning: cast from pointer to integer of different size
common/pixel.c:77: warning: cast from pointer to integer of different size
common/pixel.c:77: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_ssd_8x4_mmxext':
common/pixel.c:78: warning: cast from pointer to integer of different size
common/pixel.c:78: warning: cast from pointer to integer of different size
common/pixel.c:78: warning: cast from pointer to integer of different size
common/pixel.c:78: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_ssd_4x8_mmxext':
common/pixel.c:79: warning: cast from pointer to integer of different size
common/pixel.c:79: warning: cast from pointer to integer of different size
common/pixel.c:79: warning: cast from pointer to integer of different size
common/pixel.c:79: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_ssd_4x4_mmxext':
common/pixel.c:80: warning: cast from pointer to integer of different size
common/pixel.c:80: warning: cast from pointer to integer of different size
common/pixel.c:80: warning: cast from pointer to integer of different size
common/pixel.c:80: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_satd_16x16_mmxext':
common/pixel.c:82: warning: cast from pointer to integer of different size
common/pixel.c:82: warning: cast from pointer to integer of different size
common/pixel.c:82: warning: cast from pointer to integer of different size
common/pixel.c:82: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_satd_16x8_mmxext':
common/pixel.c:83: warning: cast from pointer to integer of different size
common/pixel.c:83: warning: cast from pointer to integer of different size
common/pixel.c:83: warning: cast from pointer to integer of different size
common/pixel.c:83: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_satd_8x16_mmxext':
common/pixel.c:84: warning: cast from pointer to integer of different size
common/pixel.c:84: warning: cast from pointer to integer of different size
common/pixel.c:84: warning: cast from pointer to integer of different size
common/pixel.c:84: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_satd_8x8_mmxext':
common/pixel.c:85: warning: cast from pointer to integer of different size
common/pixel.c:85: warning: cast from pointer to integer of different size
common/pixel.c:85: warning: cast from pointer to integer of different size
common/pixel.c:85: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_satd_8x4_mmxext':
common/pixel.c:86: warning: cast from pointer to integer of different size
common/pixel.c:86: warning: cast from pointer to integer of different size
common/pixel.c:86: warning: cast from pointer to integer of different size
common/pixel.c:86: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_satd_4x8_mmxext':
common/pixel.c:87: warning: cast from pointer to integer of different size
common/pixel.c:87: warning: cast from pointer to integer of different size
common/pixel.c:87: warning: cast from pointer to integer of different size
common/pixel.c:87: warning: cast from pointer to integer of different size
common/pixel.c: In function `pw_x264_pixel_satd_4x4_mmxext':
common/pixel.c:88: warning: cast from pointer to integer of different size
common/pixel.c:88: warning: cast from pointer to integer of different size
common/pixel.c:88: warning: cast from pointer to integer of different size
common/pixel.c:88: warning: cast from pointer to integer of different size
common/pixel.c: At top level:
common/pixel.c:66: warning: 'pw_x264_pixel_sad_16x16_mmxext' defined but not used
common/pixel.c:67: warning: 'pw_x264_pixel_sad_16x8_mmxext' defined but not used
common/pixel.c:68: warning: 'pw_x264_pixel_sad_8x16_mmxext' defined but not used
common/pixel.c:69: warning: 'pw_x264_pixel_sad_8x8_mmxext' defined but not used
common/pixel.c:70: warning: 'pw_x264_pixel_sad_8x4_mmxext' defined but not used
common/pixel.c:71: warning: 'pw_x264_pixel_sad_4x8_mmxext' defined but not used
common/pixel.c:72: warning: 'pw_x264_pixel_sad_4x4_mmxext' defined but not used
common/pixel.c:74: warning: 'pw_x264_pixel_ssd_16x16_mmxext' defined but not used
common/pixel.c:75: warning: 'pw_x264_pixel_ssd_16x8_mmxext' defined but not used
common/pixel.c:76: warning: 'pw_x264_pixel_ssd_8x16_mmxext' defined but not used
common/pixel.c:77: warning: 'pw_x264_pixel_ssd_8x8_mmxext' defined but not used
common/pixel.c:78: warning: 'pw_x264_pixel_ssd_8x4_mmxext' defined but not used
common/pixel.c:79: warning: 'pw_x264_pixel_ssd_4x8_mmxext' defined but not used
common/pixel.c:80: warning: 'pw_x264_pixel_ssd_4x4_mmxext' defined but not used
common/pixel.c:82: warning: 'pw_x264_pixel_satd_16x16_mmxext' defined but not used
common/pixel.c:83: warning: 'pw_x264_pixel_satd_16x8_mmxext' defined but not used
common/pixel.c:84: warning: 'pw_x264_pixel_satd_8x16_mmxext' defined but not used
common/pixel.c:85: warning: 'pw_x264_pixel_satd_8x8_mmxext' defined but not used
common/pixel.c:86: warning: 'pw_x264_pixel_satd_8x4_mmxext' defined but not used
common/pixel.c:87: warning: 'pw_x264_pixel_satd_4x8_mmxext' defined but not used
common/pixel.c:88: warning: 'pw_x264_pixel_satd_4x4_mmxext' defined but not used

[CREXbzh]

I tested the amd64 code, and while it compiled alright, common/pixel.c had a ton of warnings with it and the resulting build segfaulted upon usage.
What's the version of gcc that you used? (gcc --version)

[nm]

I tested the amd64 code, and while it compiled alright, common/pixel.c had a ton of warnings with it and the resulting build segfaulted upon usage.
The warnings are harmless, they come from an unused debugging function, which Alexl probably uses to measure something. The segfault doesn't sound very nice though. Can you run minibench.sh successfully (copy minibench.c and minibench.sh to the x264 source directory and run sh minibench.sh)? Also check that you don't get a segfault on a vanilla source tree.

[yokem55]

The gcc version is gcc-3.4.4, yasm-0.4.0.

My dmesg output inludes the following:
x264[17981] general protection rip:43d2d3 rsp:7fffffa91ea0 error:0
Minibench does complete properly:
joe@yokem ~/x264 $ ./minibench.sh.txt
make: Nothing to be done for `default'.
minibench.c: In function `predict_16x16':
minibench.c:26: warning: use of cast expressions as lvalues is deprecated
cpuspeed = 2400034000.000000
loops = 100000000
emptyloop time = 1.9500 cpl = 46.801
x264_pixel_sad_16x16_mmxext time = 4.6100 cpl = 63.841
x264_pixel_sad_16x8_mmxext time = 3.1600 cpl = 29.040
x264_pixel_sad_8x16_mmxext time = 3.5000 cpl = 37.201
x264_pixel_sad_8x8_mmxext time = 2.7100 cpl = 18.240
x264_pixel_sad_8x4_mmxext time = 2.4200 cpl = 11.280
x264_pixel_sad_4x8_mmxext time = 2.7600 cpl = 19.440
x264_pixel_sad_4x4_mmxext time = 2.4300 cpl = 11.520
x264_pixel_ssd_16x16_mmxext time = 13.350 cpl = 273.60
x264_pixel_ssd_16x8_mmxext time = 7.8600 cpl = 141.84
x264_pixel_ssd_8x16_mmxext time = 8.2700 cpl = 151.68
x264_pixel_ssd_8x8_mmxext time = 5.4200 cpl = 83.281
x264_pixel_ssd_8x4_mmxext time = 3.9000 cpl = 46.801
x264_pixel_ssd_4x8_mmxext time = 4.1900 cpl = 53.761
x264_pixel_ssd_4x4_mmxext time = 3.3600 cpl = 33.840
x264_pixel_satd_16x16_mmxext time = 30.610 cpl = 687.85
x264_pixel_satd_16x8_mmxext time = 16.400 cpl = 346.80
x264_pixel_satd_8x16_mmxext time = 16.350 cpl = 345.60
x264_pixel_satd_8x8_mmxext time = 9.0800 cpl = 171.12
x264_pixel_satd_8x4_mmxext time = 5.8100 cpl = 92.641
x264_pixel_satd_4x8_mmxext time = 5.8300 cpl = 93.121
x264_pixel_satd_4x4_mmxext time = 3.9800 cpl = 48.721
x264_pixel_sad_16x16_sse2 time = 5.3900 cpl = 82.561
x264_pixel_sad_16x8_sse2 time = 3.8700 cpl = 46.081
x264_pixel_ssd_16x16_sse2 time = 11.610 cpl = 231.84
x264_pixel_ssd_16x8_sse2 time = 7.1200 cpl = 124.08
x264_pixel_satd_16x16_sse2 time = 33.040 cpl = 746.17
x264_pixel_satd_16x8_sse2 time = 17.630 cpl = 376.33
x264_pixel_satd_8x16_sse2 time = 17.640 cpl = 376.57
x264_pixel_satd_8x8_sse2 time = 10.130 cpl = 196.32
x264_pixel_satd_8x4_sse2 time = 6.4100 cpl = 107.04

[nm]

My dmesg output inludes the following:
x264[17981] general protection rip:43d2d3 rsp:7fffffa91ea0 error:0

Most likely there is a bug in my ported code that didn't come up in my tests. Can you reproduce the error on some publicly available source video file? Post your command-line (x264 parameters) too.

If you're up to the task, you could try to find out, which function(s) causes the problem. You can do this by brute-force testing (so you don't need to learn to use debugging tools). First comment out lines 483-493 in common/pixel.c and recompile. This disables all SSE2 functions, and therefore x264 should work. Next uncomment one or two of the functions and try again. Continue until you find the function causing your problems. This requires a bit of work, but someone has to do it anyway ;)

Note: If you are using some external tool that is statically linked with x264 (like mencoder), you'll also need to rebuild that tool each time you recompile x264.

[riggits]

[QUOTE=nm]I ported the SSE2 patch to amd64. No additional SSE registers used or any other fancy tricks made, so no speedup.
QUOTE]

Nm,I am greatful for your work,but listen me.If we want a significant speedup of x264 compression,then you must try to implement all that "other fancy tricks and additional SSE registers".Can you do it.

Hi Kostarum, maybe you can talk to your beotch like that, but other people will take offense. This applies doubly in areas where you obviously know next to nothing (ie, this entire thread). Show some respect.

@Sharktooth: thanks for the builds, mate!

[bill_baroud]

some interesting info about sse2 on amd64 with intels compiler:
http://forum.doom9.org/showthread.php?t=87299

well, that's when you use the Intel (or other) compiler to generate auto-vectorized code ... if you put some hand-made assembly in a program, this has nothing to do with the compiler. Hence, if the SSE2 code is slower on AMD is just because their SSE2 units isn't as good as Intel one's (and it has been well know)

[dragongodz]

well, that's when you use the Intel (or other) compiler to generate auto-vectorized code ... if you put some hand-made assembly in a program, this has nothing to do with the compiler. Hence, if the SSE2 code is slower on AMD is just because their SSE2 units isn't as good as Intel one's (and it has been well know)
could everyone here please read the whole of the thread bond linked to. it goes beyond just the Intel compiler. expecially read from trbarry's post please.

[bill_baroud]

i read it (and re-read it after your post), he's just talking about the problems you can encounter (16-bytes alignement...) when using SSE2 over MMX, which are problems well described in various place (Intel Optimization Guide...) and more likely why this first SSE2 code is x264 is slower than MMX. I was just reacting (a little late, i admit) to all the buzz around Intel compilers and why it's not revealant in the present case, the reason why SSE2 is slower on AMD(64) than on Intel lies elsewhere than in the compiler (which only auto-vectorize 2 non-critical loops in x264 if you didn't try).

[Sharktooth]

well, that's when you use the Intel (or other) compiler to generate auto-vectorized code ... if you put some hand-made assembly in a program, this has nothing to do with the compiler. Hence, if the SSE2 code is slower on AMD is just because their SSE2 units isn't as good as Intel one's (and it has been well know)
Not true. The AMD SSEx units perform pretty well (their efficiency is higher than the P4 units) but they're heavily penalized by the much lower CPU clock speed.

[bill_baroud]

so they are slower, and that's what matter.... no ?

http://www.x86-secret.com/articles/cpu/a64_3000/a64_3000-4.htm
(a bench is a bench, but ...)

[Sharktooth]

Yes, the bench is right. as i said SSEx are strictly correlated with the clock speed, that's why SSEx on AMD chips are slower in comparison to INT and FP.

[squid_80]

so they are slower, and that's what matter.... no ?


Not exactly. It can depend on the instructions being used - the Athlons for example tend to dislike pshufd, and their pipelines clog up pretty quick with a few pmaddwd ops. But most other instructions they do quicker than pentiums.
SSE3 can eleviate the need for these ops but I don't know how well AMD has implemented it - I'd be very interested to see how well they can do horizontal adding.

[dragongodz]

i read it (and re-read it after your post), he's just talking about the problems you can encounter (16-bytes alignement...) when using SSE2 over MMX, which are problems well described in various place (Intel Optimization Guide...) and more likely why this first SSE2 code is x264 is slower than MMX.
which was the point. the assumption that simply adding SSE2 code is going to make it faster,no matter what compiler or cpu, is false. sometimes you will get the same speed, sometimes a little faster, sometimes a lot faster and sometimes its actually slower. SSE2 is not the magic bullet Intel made it out to be and sometimes you will have to work hard tweaking your code to gain that little extra speed and sometimes you may not be even able to gain anything worthwhile even then.

sorry for interupting.

[708145]

About SSE(2) optimization there are 2 things I'd like to note:

1) For optimal results, different code paths for AMD64, Pentium4 and Pentium-M are needed.
2) For memory latency dependent code even different code paths for various clockspeeds are neccessary.

I have no idea if there was ever such an optimization taking place for any project. Most of the time a compromise is sought which runs well on all target CPUs. ;)

bis besser,
Tobias

[bond]

btw a new patch is up:
http://www.geocities.com/x264hack/sse2-pixel-routines-v4.diff.txt


Hello,

The SSE2 patch is getting there, I'd like to propose this version as a
candidate to be committed. It is the same speed or slightly slower
on Athlon64, but noticeably faster on P4 or Xeon. Some benchmark
results are here: http://www.firstmiletv.nl/vlc/x264/ (courtesy of
Trax).

It should be theoretically possible to speed it up on the Athlon64 as
well but I don't expect to make any progress on that without having
such a box available. It would be nice to have it off by default on
Athlon64 until it is actually faster there as well, but I'm not sure
how to best do that.

I reorganized it into a separate file, would you prefer that or would
you rather have it in the same file?

Regards,
-Alex Izvorski

[Sharktooth]

It should be the same as the one i use in my builds. However V4 is 2/3 weeks old?!?

[CiNcH]

Testing SSE2 optimized pixel routines v4 on an Intel Pentium M Dothan 1.6 GHz (SSE2, 2M L2 Cache) @ 1.1V using minibench utility:

cpuspeed = 2088000000.000000
loops = 100000000
emptyloop time = 2.0830 cpl = 43.493
x264_pixel_sad_16x16_mmxext time = 8.3520 cpl = 130.90
x264_pixel_sad_16x8_mmxext time = 4.5360 cpl = 51.219
x264_pixel_sad_8x16_mmxext time = 5.0470 cpl = 61.888
x264_pixel_sad_8x8_mmxext time = 3.5850 cpl = 31.362
x264_pixel_sad_8x4_mmxext time = 3.3850 cpl = 27.186
x264_pixel_sad_4x8_mmxext time = 3.8360 cpl = 36.603
x264_pixel_sad_4x4_mmxext time = 3.1740 cpl = 22.780
x264_pixel_ssd_16x16_mmxext time = 19.949 cpl = 373.04
x264_pixel_ssd_16x8_mmxext time = 9.9340 cpl = 163.93
x264_pixel_ssd_8x16_mmxext time = 11.958 cpl = 206.19
x264_pixel_ssd_8x8_mmxext time = 8.2710 cpl = 129.21
x264_pixel_ssd_8x4_mmxext time = 4.9580 cpl = 60.030
x264_pixel_ssd_4x8_mmxext time = 6.9800 cpl = 102.25
x264_pixel_ssd_4x4_mmxext time = 6.1380 cpl = 84.668
x264_pixel_satd_16x16_mmxext time = 52.266 cpl = 1047.8
x264_pixel_satd_16x8_mmxext time = 28.471 cpl = 550.98
x264_pixel_satd_8x16_mmxext time = 27.129 cpl = 522.96
x264_pixel_satd_8x8_mmxext time = 15.372 cpl = 277.47
x264_pixel_satd_8x4_mmxext time = 9.2630 cpl = 149.92
x264_pixel_satd_4x8_mmxext time = 9.8940 cpl = 163.09
x264_pixel_satd_4x4_mmxext time = 6.2090 cpl = 86.151
x264_pixel_sad_16x16_sse2 time = 8.3320 cpl = 130.48
x264_pixel_sad_16x8_sse2 time = 5.4780 cpl = 70.888
x264_pixel_ssd_16x16_sse2 time = 18.106 cpl = 334.56
x264_pixel_ssd_16x8_sse2 time = 12.498 cpl = 217.47
x264_pixel_satd_16x16_sse2 time = 54.008 cpl = 1084.2
x264_pixel_satd_16x8_sse2 time = 28.981 cpl = 561.63
x264_pixel_satd_8x16_sse2 time = 28.001 cpl = 541.17
x264_pixel_satd_8x8_sse2 time = 15.452 cpl = 279.14
x264_pixel_satd_8x4_sse2 time = 9.3330 cpl = 151.38

[Sirber]

Doesn't seems faster to me :confused:

[squid_80]

To enable it for Pentiums and not Athlon64s you could use:
if((cpu&X264_CPU_SSE2)&&!(cpu&X264_CPU_3DNOW))
in pixel.c, to determine if the function pointers get assigned to the SSE2 functions. Should work because the Pentiums don't have 3DNow, and I *think* the Athlon64s were the first line of AMD chips with SSE2.

By the way, has that minibench utility been modified to use buffers that are not 16-byte aligned? I did that when I was using it for testing the AMD64 routines and it turned up a few surprises.

[708145]

I love to quote myself ;)

Given the recent Pentuim M results it seems that I was right, huh?

About SSE(2) optimization there are 2 things I'd like to note:
1) For optimal results, different code paths for AMD64, Pentium4 and Pentium-M are needed.
2) For memory latency dependent code even different code paths for various clockspeeds are neccessary.


bis besser,
Tobias

[CiNcH]

Here's how SSE instructions perform on my Intel Pentium M 1.6 GHz:

cpuspeed = 2088000000.000000
loops = 100000000
"mm: movq" time = 4.1050 cpl = 85.712
"mm: paddw" time = 8.1420 cpl = 170.00
"mm: psrlw" time = 10.655 cpl = 222.48
"mm: punpcklwd" time = 8.8430 cpl = 184.64
"mm: pmulhw" time = 8.5020 cpl = 177.52
"mm: pmaddwd" time = 8.4930 cpl = 177.33
"mm: psadbw" time = 8.6220 cpl = 180.03
"mm: paddw, movq" time = 4.1160 cpl = 85.942
"mm: paddw, psrlw" time = 8.1320 cpl = 169.80
"mm: paddw, punpcklwd" time = 8.1310 cpl = 169.78
"mm: paddw, pmulhw" time = 5.0780 cpl = 106.03
"mm: movq, paddw, movq, paddw" time = 4.1050 cpl = 85.712
"mm: movq, paddw, movq, psrlw" time = 4.0960 cpl = 85.524
"mm: movq, paddw, movq, pmulhw" time = 4.5970 cpl = 95.985
"mm: movq, paddw, pmulhw, psrlw" time = 4.5160 cpl = 94.294
"movq, paddw, movq, punpcklwd" time = 4.0960 cpl = 85.524
"xmm: movdqa" time = 10.766 cpl = 224.79
"xmm: paddw" time = 16.223 cpl = 338.74
"xmm: psrlw" time = 16.153 cpl = 337.27
"xmm: punpcklwd" time = 16.144 cpl = 337.09
"xmm: pmulhw" time = 16.483 cpl = 344.17
"xmm: pmaddwd" time = 16.504 cpl = 344.60
"xmm: psadbw" time = 16.684 cpl = 348.36
"xmm: paddw, movdqa" time = 13.499 cpl = 281.86
"xmm: paddw, psrlw" time = 17.496 cpl = 365.32
"xmm: paddw, punpcklwd" time = 13.529 cpl = 282.49
"xmm: paddw, pmulhw" time = 16.203 cpl = 338.32
"xmm: movdqa, paddw, movdqa, paddw" time = 13.490 cpl = 281.67
"xmm: movdqa, paddw, movdqa, psrlw" time = 13.469 cpl = 281.23
"xmm: movdqa, paddw, movdqa, pmulhw" time = 13.510 cpl = 282.09
"xmm: movdqa, paddw, pmulhw, psrlw" time = 14.801 cpl = 309.04
"xmm: movdqa, paddw, movdqa, punpcklwd" time = 12.157 cpl = 253.8
"xmm: movaps" time = 10.776 cpl = 225.00
"xmm: addps" time = 16.484 cpl = 344.19
"xmm: mulps" time = 16.213 cpl = 338.53
"xmm: addps, mulps" time = 16.203 cpl = 338.32
"xmm: movaps, addps" time = 13.399 cpl = 279.77
"xmm: movaps, addps, movaps, mulps" time = 13.490 cpl = 281.67
"xmm: movapd" time = 10.785 cpl = 225.19
"xmm: addpd" time = 16.484 cpl = 344.19
"xmm: mulpd" time = 32.276 cpl = 673.92
"xmm: addpd, mulpd" time = 16.224 cpl = 338.76
"xmm: movapd, addpd" time = 13.379 cpl = 279.35
"xmm: movapd, addpd, movapd, mulpd" time = 13.499 cpl = 281.86

[AlexI]

Hello,

Just a quick heads up, there is a new version of the SSE2 patch here:

http://www.geocities.com/x264hack/sse2-pixel-routines-v5.diff.txt

Pentium 4 users will see a 10-18% overall speedup depending on settings. No speedup for Pentium M or Athlon 64, sorry. It will only enable the new routines on CPUs on which they are faster. The new patch also fixes a small bug and fixes building in 64-bit mode.

This is getting ready to merge with the main branch in svn. Probably the last pre-merge version, actually. Enjoy.

-A.

[Sharktooth]

It's already included in my builds since revision 286 :)

[Revgen]

Pentium 4 users will see a 10-18% overall speedup depending on settings. No speedup for Pentium M or Athlon 64, sorry.

-A.

Thats not true for me. I estimate that I got about a 3% to 5% boost when encoding some of my Garfield cartoons about a week ago. It's not as much as what the P4 gets, but it is something.

Say a boost from 5fps to 5.25fps.

I'm comparing the difference between the 186 version and the 170 version.

[squid_80]

Thats not true for me. I estimate that I got about a 3% to 5% boost when encoding some of my Garfield cartoons about a week ago. It's not as much as what the P4 gets, but it is something.

Must be the SSD functions... Which can actually be made faster. Expand from bytes to words before subtracting and use two registers to accumulate results, adding them together at the end. Also when moving the final result do xmm->mem, mem->eax and it'll knock a few ms off (this could help all the functions).

[Kostarum Rex Persia]

I don't understand,how is possible to Intel get 10-18 % speed-up,and Athlon 64 only 3-5 %.

There is something very strange in that.But,all new Athlon 64 have SSE,SSE2 and SSE3 instructions.

[Sirber]

Intel and AMD doesn't implement those the same way. They have the same instruction set, but phisicaly they are not the same. A fast path for Intel might not be for AMD64.

[Kostarum Rex Persia]

Well,that explain a lot of things.Intel purposely do that.AMD is right about Intel.

[CiNcH]

Well,that explain a lot of things.Intel purposely do that.AMD is right about Intel.

You should probably have better background information before saying something like that.

A time ago I have seen some benchmarks, testing per clock SSE performance. AMD won over Intel. But as SSE performance seems to scale pretty well with clock speed Intel has an advantage here.

[Sirber]

Intel developed SSE/SSE2/SSE3 and implemented them first. AMD implemented them after. Guess who's more right :p

[CiNcH]

Overall SSE/SSE2 performance:

http://www.tecchannel.de/imgserver/bdb/341800/341839/29005CE123F42F0AC8D6CC22090F951B_1000x700.jpg http://www.tecchannel.de/imgserver/bdb/341800/341841/C6741FC6EED7939F6D18C4ADE3D33B3E_1000x700.jpg


Per clock SSE/SSE2 performance:

http://www.tecchannel.de/imgserver/bdb/341800/341840/E87DCF003AF6D893AAA7419C0F0F9B0D_1000x700.jpg http://www.tecchannel.de/imgserver/bdb/341800/341842/208361C9899B910E1BBA9B8D67C91155_1000x700.jpg


It becomes apparent that AMD's SSE implementation performs pretty well clock-wise.

[squid_80]

Don't know exactly what their tests involve, but note how the SSE2 tests are slower than SSE.

[Rash]

Well noted Squid. It is almost twice as faster.

[Sirber]

Not the same "calculs". Like comparing bananas and apples :)

[squid_80]

Not that I'm saying SSE2 can't go faster... It just needs to be tweaked appropriately. Here's how the SSE2 functions I developed for my AMD64 build perform with unaligned data (closer to real encoding situation):
cpuspeed = 2088000000.000000
loops = 100000000
emptyloop time = 0.00000 cpl = 0.00000

x264_pixel_sad_16x16_mmxext time = 3.9690 cpl = 82.873
x264_pixel_sad_16x16_sse2 time = 3.7500 cpl = 78.300

x264_pixel_sad_16x8_mmxext time = 2.1720 cpl = 45.351
x264_pixel_sad_16x8_sse2 time = 2.2650 cpl = 47.293

x264_pixel_ssd_16x16_mmxext time = 13.563 cpl = 283.20
x264_pixel_ssd_16x16_sse2 time = 10.609 cpl = 221.52

x264_pixel_ssd_16x8_mmxext time = 7.0160 cpl = 146.49
x264_pixel_ssd_16x8_sse2 time = 5.5310 cpl = 115.49

x264_pixel_ssd_8x16_mmxext time = 7.1410 cpl = 149.10
x264_pixel_ssd_8x16_sse2 time = 5.5000 cpl = 114.84

x264_pixel_ssd_8x8_mmxext time = 3.8440 cpl = 80.263
x264_pixel_ssd_8x8_sse2 time = 2.9840 cpl = 62.306

Trying to optimize SAD is a waste of time because it's too basic, which is a shame because it seems to take up most of the encoding time. The smaller SSD functions won't gain much over MMX either. The SATD functions I haven't done yet.

[CREXbzh]

Not that I'm saying SSE2 can't go faster... It just needs to be tweaked appropriately. Here's how the SSE2 functions I developed for my AMD64 build perform with unaligned data (closer to real encoding situation):
Are your patches available somewhere? :D

[squid_80]

Not yet, they're not finished. Also they take advantage of AMD64 specific features and won't translate easily to regular x86 code.

[Sirber]

AMD64 32-bit?

[Kostarum Rex Persia]

Not yet, they're not finished. Also they take advantage of AMD64 specific features and won't translate easily to regular x86 code.

squid_80,you are a fantastic man.I really hope that your SSE2 patch will came out soon.I also hope that Sharktooth will include your future SSE2 patch in next revision of x264 codec.

[squid_80]

AMD64 32-bit?
64-bit mode only. I use store to load forwarding to get data out of the xmm registers and into the general purpose registers quickly. Store to load forwarding will fail in 32-bit mode since the GPRs aren't 64-bits wide. So results have to be accumulated in another xmm register (clogging the FPU pipelines with more paddd instructions) and horizontally summed at the end...
It's do-able but won't be as fast.

[Sirber]

Well, you can still add the 64bit SSE2 code to x264 64bit asm :D Keep the good work!

[Rash]

Not the same "calculs". Like comparing bananas and apples :)
Why? We are comparing speed. Whoever is faster wins. ;)

[Sirber]

If the bench is not about SSE vs SSE2 on the same tasks, then it's useless. Beware, I'm prepared to fight to death to keep my opinion ;)

[foxyshadis]

The point wasn't comparing SSE to SSE2, it was comparing the relative performance of each on various high-end procs. I'd assume it was obvious that optimizing one particular application for SSE vs SSE2 tests would not be remotely applicable to applications in general, let alone any other specific application. (Much like the above mmx vs. sse results alone don't mean anything if they were brought up in the context of, say, a 3d renderer.)

Also the flops/clock ratio is absolutely useless, since Intel and AMD have wildly different architectures, which affects their relative clock speeds. It's obvious when they're stacked like that, I don't know why they bothered to list it. Maybe just to show clock speed comparison isn't important? Flops/price would be useful, and to a lesser extent, flops/PR-rating.

[Rash]

If the bench is not about SSE vs SSE2 on the same tasks, then it's useless. Beware, I'm prepared to fight to death to keep my opinion ;)
But that's the bench I was talking about. I thought he did the test on the same tasks.

[Sirber]

I don't know if it's the same task. CiNcH?

[Sharktooth]

"Double precision matrix multiply" for both tests.
However as you can see, athlon CPUs have better relative efficiency than P4s for both SSE and SSE2 but since they have a lower clock frequency the absolute speed is slower than those intel counterparts.
Now you know why Intel pushed for removing FP and MMX from WinXP 64 and from future versions of Windows...

[Kostarum Rex Persia]

Well,that's confirm my attitude that Intel is a monopoly company.And Microsoft too.

[riggits]

Well,that explain a lot of things.Intel purposely do that.AMD is right about Intel.

OK, I'm sick of your uninformed and prolific commentary on subjects you have no clue about.
Please visit arstechnica.com and read EVERY f*cking article there before posting again.
Here are some easy and obvious places to start:
[/url]
http://arstechnica.com/articles/paedia/cpu/ppc-1.ars (http://arstechnica.com/articles/paedia/cpu/amd-hammer-1.ars)
READ THIS!!! (http://arstechnica.com/articles/paedia/cpu/pipelining-1.ars)
[url]http://arstechnica.com/articles/paedia/cpu/pentium-1.ars
http://arstechnica.com/articles/paedia/cpu/pentium-m.ars
this one is verrrry interesting (http://arstechnica.com/articles/paedia/cpu/p4andg4e.ars)
http://arstechnica.com/articles/paedia/cpu/g4vsk7.ars

Well,that's confirm my attitude that Intel is a monopoly company.And Microsoft too.
Please TAKE A CLASS IN LOGIC!!! Holey crap. How do you function in society??!

(sorry all, but it needs to be said..)

[Sirber]

Arsh but needed :)

[Kostarum Rex Persia]

I don't know what is going on with you riggits,but you are crossing the line.You don't have right to insult me in that way,there is no need for that.

Everyone knows all about I***l behaviour,why then Amd sued Intel?

[Sirber]

Everyone sue everyone. That's business :)

[ChronoReverse]

Although it's _likely_ from the scant evidence so far that Intel is in fact doing something that's hindering AMD, it's completely up in the air whether or not it's _legal_ or not (I suspect it's legal).

In any case, whether or not Intel and MS are monopolistic have no place in this thread.

[bond]

yes and the next one writing a flame will get striked!

this thread is about the sse2 patch, better invest your power to test it!

[Sirber]

@bond, how about some deleting? :)