DiAVC decoder, yet another fast H.264 high profile decoder

[LigH]

Then I can even check it on an AMD Duron-800...

[CruNcher]

I hope it doesn't get compiled with Intels Compiler as this is still causing performance issues on AMD CPUs (going less efficient compilation paths) ? the issue is very well known
but i guess for those parts that create the speed for a Video Decoder case (the hand optimized ASM) it makes not such a big difference on the pure communication level between Windows and the Decoder that are non hand optimized ?

[schweinsz]

Originally Posted by CruNcher

I hope it doesn't get compiled with Intels Compiler as this is still causing performance issues on AMD CPUs (going less efficient compilation paths) ? the issue is very well known
but i guess for those parts that create the speed for a Video Decoder case (the hand optimized ASM) it makes not such a big difference on the pure communication level between Windows and the Decoder that are non hand optimized ?

The DiAVC is compiled by vc2008, and the icl is never used.
But I plan to use it for speed on intel cpu.

some performance-critical parts are optimized by asm such as motion-compensation, idct, deblock, cabac, while the pure communication level between Windows and the Decoder use the functions in run-time library, for example, _beginthreadex.

[kemuri-_9]

Originally Posted by CruNcher

I hope it doesn't get compiled with Intels Compiler as this is still causing performance issues on AMD CPUs (going less efficient compilation paths) ? the issue is very well known
but i guess for those parts that create the speed for a Video Decoder case (the hand optimized ASM) it makes not such a big difference on the pure communication level between Windows and the Decoder that are non hand optimized ?

what?
Intel's compiler is faster than MSVC which is faster than gcc when targeting x86 or x86_64, even on my AMD.

ICL defaults to general SSE2 generation,
you have to specifically specify an option to optimize for intel cpus, and that would only cause it to crash on AMD cpus which don't have the corresponding instruction set.
doing something like
/arch:sse /QaxSSSE3 would have it use sse and then make a special SSSE3 cpu path.

[LoRd_MuldeR]

It should be noted that builds compiled with "/arch:see" or "/arch:see2" (default) won't run on non-SSE2 capable CPU's. So people will complain

As "/Qax" can be used more than once, the combination "/arch:ia32 /QaxSSE /QaxSSE2 /QaxSSSE3" should produce a build that runs on any CPU and still uses optimized SSE/SSE2/SSSE3 code, if supported.

Also it seems the fastest builds for Intel CPU's can only be achieved with "/QxSSE2" or "/QxSSSE3", but that is only feasible if you want to offer special "Intel only" builds.

[schweinsz]

Originally Posted by kemuri-_9

what?
Intel's compiler is faster than MSVC which is faster than gcc when targeting x86 or x86_64, even on my AMD.

ICL defaults to general SSE2 generation,
you have to specifically specify an option to optimize for intel cpus, and that would only cause it to crash on AMD cpus which don't have the corresponding instruction set.
doing something like
/arch:sse /QaxSSSE3 would have it use sse and then make a special SSSE3 cpu path.

Good news for me! The DiAVC will be free of two version for amd and intel. I recently plan to use icl, but is it feasible that some files use msvc while others use icl? Is it consistant about the link-time code generation between msvc and icl?
The current DiAVC requires SSE2.

[LoRd_MuldeR]

There is an explicit warning to NOT link code with Intel-specific optimizations ("/Qx") against code that doesn't use those optimizations.

I think that's because it would bypass Intel's CPU check they add to the main() function. So the binary would run Non-Intel CPU's although it contains Intel-only code.

This can lead to "undefined" behavior. Normally a binary with Intel-specific optimizations will exit with error message on Non-Intel CPU's.

[CruNcher]

http://www.brightsideofnews.com/news...substance.aspx <- im referring to this lawsuit

[roozhou]

Originally Posted by CruNcher

http://www.brightsideofnews.com/news...substance.aspx <- im referring to this lawsuit

And a good article about this:

Intel's "cripple AMD" function

[LoRd_MuldeR]

Originally Posted by Agner`s CPU blog

Sounds nice, but the truth is that the CPU dispatcher didn't support SSE or SSE2 or any higher SSE in AMD processors

Which probably was intentional and perfectly legitimate, because of:

Originally Posted by Dark Shikari

The Athlon 64's SSE unit is so slow that it's generally worse than MMX. Most operations are done by splitting the instruction in half and sending them off to the MMX unit, making the whole thing a complete waste of time.

And who still claims ICC doesn't support SSE2 for Non-Intel CPU's probably used "/QxSSE2", which indeed won't work for AMD CPU's, instead of "/arch:SSE2"

However the latter is the default in the current ICC version, so I assume such claim would date back to an old outdated version...

See also:
http://software.intel.com/sites/prod...tm#option_arch

[clsid]

ICL can be patched to skip the GenuineIntel checks so that it also uses SSE/SSE2/etc on AMD CPUs.

I suggest not to worry about compilers. Just make one generic build with your own assembly optimizations for all performance critical parts. This also allows making your own choices about which function implementations get used on which processors.

[schweinsz]

Could somebody help me the test on single-core old cpu such as PentiumM, athlon64?
http://di-avc.com/testd.7z.
Download the file and uppack it, run the run.bat and feedback the results.

Recently I have finished all yuv scaling and yuv2rgb functions and am working on the bug about the seeking and timestamp.

[the_corona]

nothrd.exe   basketball720x576.264
99 frames decoded totally.
3928067 counters used by decoder and 13161 counters used by others.

Decoding speed: 90 fps

sglthrd.exe   basketball720x576.264
99 frames decoded totally.
4263451 counters used by decoder and 14818 counters used by others.

Decoding speed: 83 fps

nothrd.exe   basketball720x576.264
99 frames decoded totally.
3918364 counters used by decoder and 13008 counters used by others.

Decoding speed: 90 fps

sglthrd.exe   basketball720x576.264
99 frames decoded totally.
4124521 counters used by decoder and 12798 counters used by others.

Decoding speed: 85 fps

pause

AMD Sempron 3000+ (Single Core 1800mhz)

[ForceX]

Single thread Athlon64

nothrd.exe   basketball720x576.264
99 frames decoded totally.
3684944 counters used by decoder and 12321 counters used by others.

Decoding speed: 96 fps

sglthrd.exe   basketball720x576.264
99 frames decoded totally.
3545769 counters used by decoder and 12152 counters used by others.

Decoding speed: 99 fps

nothrd.exe   basketball720x576.264
99 frames decoded totally.
3406643 counters used by decoder and 12143 counters used by others.

Decoding speed: 104 fps

sglthrd.exe   basketball720x576.264
99 frames decoded totally.
3523578 counters used by decoder and 12225 counters used by others.

Decoding speed: 100 fps

pause

[clsid]

The test fails (with Illegal Instruction error) on an old AMD Athlon Thunderbird (1.33 Ghz). That CPU only has MMX and MMXext, but no SSE1.

[schweinsz]

Originally Posted by clsid

The test fails (with Illegal Instruction error) on an old AMD Athlon Thunderbird (1.33 Ghz). That CPU only has MMX and MMXext, but no SSE1.

The DiAVC requires SSE2.

[horvathd]

d:\Letöltések\testd>nothrd.exe basketball720x576.264
99 frames decoded totally.
5409485 counters used by decoder and 18457 counters used by others.

Decoding speed: 65 fps

d:\Letöltések\testd>sglthrd.exe basketball720x576.264
99 frames decoded totally.
5520247 counters used by decoder and 16373 counters used by others.

Decoding speed: 64 fps

d:\Letöltések\testd>nothrd.exe basketball720x576.264
99 frames decoded totally.
5454162 counters used by decoder and 16909 counters used by others.

Decoding speed: 64 fps

d:\Letöltések\testd>sglthrd.exe basketball720x576.264
99 frames decoded totally.
5669338 counters used by decoder and 16629 counters used by others.

Decoding speed: 62 fps

On Intel Celeron M 330

[CruNcher]

Athlon 64 X2 (Toledo) SSE (1,2,3) 3DNOW(+) MMX(+)

C:\testd\testd>nothrd.exe basketball720x576.264
99 frames decoded totally.
3066867 counters used by decoder and 8285 counters used by others.

Decoding speed: 115 fps

C:\testd\testd>sglthrd.exe basketball720x576.264
99 frames decoded totally.
2034767 counters used by decoder and 7709 counters used by others.

Decoding speed: 174 fps

C:\testd\testd>nothrd.exe basketball720x576.264
99 frames decoded totally.
3203470 counters used by decoder and 7944 counters used by others.

Decoding speed: 110 fps

C:\testd\testd>sglthrd.exe basketball720x576.264
99 frames decoded totally.
1995043 counters used by decoder and 7543 counters used by others.

Decoding speed: 177 fps

[dZeus]

nothrd.exe   basketball720x576.264
99 frames decoded totally.
3754152 counters used by decoder and 17488 counters used by others.

Decoding speed: 94 fps

sglthrd.exe   basketball720x576.264
99 frames decoded totally.
3986075 counters used by decoder and 17523 counters used by others.

Decoding speed: 88 fps

nothrd.exe   basketball720x576.264
99 frames decoded totally.
3927613 counters used by decoder and 17756 counters used by others.

Decoding speed: 90 fps

sglthrd.exe   basketball720x576.264
99 frames decoded totally.
3995219 counters used by decoder and 17091 counters used by others.

Decoding speed: 88 fps

Pentium M dothan 2GHz (single core)

[schweinsz]

A new beta version is available.
Changes:
20100112
fix two bugs on timestampt.
Only using the main thread for old intel cpu.

The functions about scaling and yuv2rgb are finished for some days, but I must firstly add a propertypage before I integrate them.

I heard that using the same thread in frame parallel instead of creating new thread for every frame can improve performance, I will try it.

As regarding to the compatibility with the elecard splitter, I found that the elecard splitter sends half-baked nalu to the decoder. Fixing it is easy, but a buffer is needed to buffer the nalues. As the bug influences raw 264 bitstreams only, I don't fix it in this release.