To the XviD developers

[rui]

To the Xvid developers:

First i want to say that i am not a programmer. I don’t know if Xvid codec is already optimized to SSE1, SSE2, 3Dnow or MMX. I am just the average user, that likes to make divx (or XviD) encodings.
But i just want to say this:
I hope that you guys don’t make the same “mistake” the divx4 guys did, that is optimizing the codec to SSE2 first.
Doom9 said something like this a few days ago, one must count the number of people that has Celerons, Pentiums 3 and now AMD XP’s, all supporting SSE1.
What i am saying is that if you guys will be supporting some instructions, and you are deciding between SSE1 and SSE2, then let it be SSE1 first. This way, all could benefit, including the Pentium4 guys.
Thanks and the best of luck to XviD, this codec has a great future :)

[Nic]

If you haven't already, try:
http://www.videocoding.de/forum/viewtopic.php?topic=201&forum=3&7

That gives a brief rundown of things, SSE2 is very useful for video coding & gives big improvements, hence the state of DivX4

Cheers,
-Nic

[rui]

"mmx: used in all known code hot spots. further optimizations are possible: alignment, pipeline efficiency, etc.

xmm (mmx enstions, integer-sse): used in the sad. the unsigned-word-mul might help in quant/dequant.

3dnow: while 3dnow is floating point, it gives us some additional mmx functions. these are currently used for interpolation

sse: ? floating point only. it probably wont help much

sse2: TODO; should give a 2x improvement over plain mmx code. none of the developers have p4 hardware, so its not high-priority. intel have published sse2 video-compression code; we basically need someone(s) to convert this to nasm syntax and perform testing. that said, the sse2 instruction set looks very "easy" to work with"


If i understood this correctly, besides SSE2, only integer SSE1 could be of some use?
Gess we AMD users are going to have to wait for Hammer :(

[-h]

Yup - the only large increases in speed are going to be seen by P4 owners, the rest of us are are pretty much seeing our CPU's potential saturated.

It's possible that motion estimation could get smarter, thus allowing us to use faster modes to reach the same file size, but nothing amazing.

-h

[int 21h]

I believe SSE2 is most often used is because of the relatively high yields gained for relatively low amount of work. Not only that, but Intel is usually very helpful if you need help with optimizations (involving SSE2).

[-h]

SSE2 "works" because it gives developers more useful instructions for the task at hand - here's an example from XviD's SAD code:

SAD16 code in MMX:

movq mm0, [esi] ; ref
movq mm1, [edi] ; cur

movq mm2, [esi+8] ; ref2
movq mm3, [edi+8] ; cur2

movq mm4, mm0
movq mm5, mm2

psubusb mm0, mm1
psubusb mm2, mm3

psubusb mm1, mm4
psubusb mm3, mm5

por mm0, mm1 ; mm0 = |ref - cur|
por mm2, mm3 ; mm2 = |ref2 - cur2|

movq mm1,mm0
movq mm3,mm2

punpcklbw mm0,mm7
punpcklbw mm2,mm7

punpckhbw mm1,mm7
punpckhbw mm3,mm7

paddusw mm0,mm1
paddusw mm2,mm3

paddusw mm6,mm0 ; sum += mm01
paddusw mm6,mm2 ; sum += mm23

This does exactly the same thing, but uses XMM:

movq mm0, [esi] ; ref
movq mm2, [esi+8] ; ref2

psadbw mm0, [edi] ; mm0 = |ref - cur|
psadbw mm2, [edi+8] ; mm0 = |ref2 - cur2|

paddusw mm6,mm0 ; sum += mm01
paddusw mm6,mm2 ; sum += mm23

Guess which runs faster ;)

The improvement from MMX to XMM is pretty much what you can expect from XMM to SSE2 - given that SSE2 instructions have twice the throughput of equivalent MMX instructions, it's just a better set of instructions for processing the data we want to. There aren't MMX/XMM/SSE instructions that can compete with the throughput of SSE2 when it comes to video.

-h