x264 Sharktooth compile with SSE3?

[3ngel]

Hi,
i don't know if it's right to open a new thread for this, but i see the pinned thread is clean.

Actually i see in the Sharktooth build

x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!

I have a CPU that has SSE3 code.

It's possible Sharktooth, in the next versions to build with SSE3 support?

Thanks

[Sharktooth]

:search:

[3ngel]

ATM i read here and there some SSE3 words, but can't find any related. It's already been implemented and it's a problem of mine? In the first case from what rev?
It the latter, sorry delete the thread :)

[RaynQuist]

limit your search to this sub-forum and select show posts

[3ngel]

WT..:eek: i was typing the search word the wrong way!
In the end i understood SSE3 is useless.
Thanks btw :)

[Romario]

But, SSE4 will be implemented, next year, if devs gets some Penryn cores soon.

Expect 50 % speed-up, at least.

[Sharktooth]

50% speedup... sure... why not 500%?!? why not 10000%? ...

[Dark Shikari]

But, SSE4 will be implemented, next year, if devs gets some Penryn cores soon.

Expect 50 % speed-up, at least.
50% ?

Yeah, right.

The only particularly "useful" instruction is the SAD ESA instruction, I believe... and x264's SEA algorithm is already far more efficient than that could possibly be :rolleyes:

[JohnnyMalaria]

It's better to think of SSE3, SSSE3 and SSE4 as service packs for SSE2 :p

IMHO, SSE2 was the last really useful SIMD extension. I've trolled through the Intel development docs and have yet to find anything mind-blowingly useful with >SSE2. There are things I desperately wish for but never see....:(

[Inventive Software]

Avery Lee on his blog said something about SSE4 finally giving us dot products. Not sure what they're good for in encoding! :confused:

[Sharktooth]

SSE4 are quite useless. Maybe SSE5...

[Romario]

I don't think so, is Intel fool then when talking about SSE4 as a revolution in video encoding and decoding!!! Be careful when you talk about SSE4, please.

Look DivX with their massive 115 % improvment when they implement SSE4 code, only alpha version for now. Can you explain that, Sharktooth?

[Sharktooth]

yes, they're fool and you too... the divx thing was not a REAL comparison since they used 2 special algos, one ultra slow and the other completely optimized.
the real difference with divx 6.6 is less than 10%.
:search: before speaking! you even made a post in that thread!
It's just a trick however. As it was said elsewhere on this forum, the DivX 6.6 version was modded to include an unefficient & slow ME algorithm that could however greatly be sped up with SSE4. So SSE4 doesn't speed up DivX 6 by 115%. ( in other words, it's a commercial stunt )

A penryn in itself, however, will speed up a program in comparison to a conroe. And SSE4 is usefull for video encoding, but don't expect anything more than 5 to 10% speed up, in the best cases.
the discussion follows here: http://forum.doom9.org/showthread.php?t=124881&page=2
pay particular attention to this statement:
the experimental motion search can not be directly compared to the normal encoding modes with DivX codec versions 6.6 or prior
so... dont expect anything astonishing from SSE4...

[Romario]

So, you mention AMD SSE5? You think SSE5 will improve encoding greatly, or...

Of course, AMD will deliver SSE5 in year 2009, in future Bulldozer cores.

Info:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3073
http://developer.amd.com/sse5
http://www.ddj.com/hpc-high-performance-computing/201803067

[Manao]

In addition, even for exhaustive search, the new SSE4 instructions aren't necessarily better than a more intelligent algorithm. See the commit log going with the introduction of SEA :
Successive elimination motion search: same as exhaustive search, but 2-3x faster.
So, without any SSE4, you can get the same results as exhaustive search but 2-3 times faster, which is almost the speed gain brought by SSE4. And the new SAD instruction can't be used with that algorithm.

[Dark Shikari]

In addition, even for exhaustive search, the new SSE4 instructions aren't necessarily better than a more intelligent algorithm. See the commit log going with the introduction of SEA :

So, without any SSE4, you can get the same results as exhaustive search but 2-3 times faster, which is almost the speed gain brought by SSE4. And the new SAD instruction can't be used with that algorithm.
The new SAD ESA instruction might be able to be used with Akupenguin's --hadamard --me esa algorithm, which requires a full 16-bit SAD ESA.

But that's a pretty special case, considering that you're probably not going to reach 1 FPS at standard definition resolution without quadcore machine if you go for --hadamard --me esa. Though the speed boost would definitely be impressive.

[Manao]

AFAIK, there aren't any 16-bits SAD, only a 8-bits one. SSE4 adds a parallelized SAD : it does 8 4SADs in parallel

[Dark Shikari]

AFAIK, there aren't any 16-bits SAD, only a 8-bits one. SSE4 adds a parallelized SAD : it does 8 4SADs in parallelThere's no 16-bit SAD operation in SSE4?

Well there goes that idea :rolleyes:

[LoRd_MuldeR]

SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, SSE4a, AMB, SSE5...

When will they finally add SSE264, which includes a hardware implementation of x264, so we need to call only one single instruction per frame ??? :p

[RaynQuist]

http://forum.doom9.org/showthread.php?t=124885

SSE4 will be implemented as soon as I get access to a SSE4 cpu, or someone else with such decides to write it.

...

What's your source for "40%"? This one (http://softwarecommunity.intel.com/articles/eng/1246.htm) says "Motion estimation ... often accounts for about 40% of the total CPU cycles consumed by an encoder. ... This white paper will describe how video encoders can benefit from the Intel SSE4 instructions, achieving 1.6x to 3.8x performance speedups in integer motion vector search." Then they go on to describe ESA. And their results are probably correct for ESA. But the fast integer motion searches in x264 are more like 10-15% of the total cpu-time, plus SSE4 won't help them as much as it helps ESA. And even x264's successive-elimination ESA might be as fast as Intel's brute-force SSE4 ESA.

Other quotes pulled from all over the place:

SSE4.1 contains some useful instructions. However, I'm not sure the instruction touted as being designed for video compression (mpsadbw) is among the useful ones.

MPSADBW is designed for exhaustive search, not for diamond/hex. And even for exhaustive, I'm not sure it's any better than x264's successive elimination search, which is a higher level algorithm to losslessly eliminate most of the blocks before they even get to SAD.

It's interesting to note that this instruction mostly helps for integer pel exhaustive search. But for x264, with m6 / m7 and hex/umh, it wouldn't help that much.

Other instructions are more versatile - blendxx, pmovxxx, packusdw, pmulld, pmax/minxx - and imho more interesting. They'll certainly ease the writing of simd optimized functions, once SSE4 becomes mainstream.

Also:

SSE4A contains only a few instructions, none of which are useful to x264.

Initial review of the instructions to be included in SSE5. Note that I'm only discussing the functionality, I have no idea of the speeds of the instructions yet. There were some SSSE3 instructions that looked interesting, and reduced the instruction count of some functions, but when run on a Core2 turned out to be much slower than the equivalent multiple SSE2 instructions.

First, discard all the floating-point instructions, because video codecs don't use floating-point.

PCMOV: generally useful anywhere the scalar version of the algorithm has branches, e.g. deblocking.
PCOM*: might save a MOV or a negation over PCMP*, if one wants a predicate other than EQ or LE.
PPERM: zigzag scan in 1 instruction.
PHADD*: useful in all the pixel comparison functions. (but I said the same of SSSE3's PHADD* ...)
PMADCSSWD: SSD and SSIM.

I also remember reading about how the single-cycle shuffle implementation in Penryn will help x264 a lot, but I can't find it.