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