aWarpSharp2 – rewrite of aWarpSharp

[SEt]

Current version: 2012.03.28 (http://www.mediafire.com/?7bu46ab33dwex0o)

Previous versions:
2009.06.19 (http://pavelsx.googlepages.com/aWarpSharp_20090619.rar)
2009.05.24 (http://pavelsx.googlepages.com/aWarpSharp_20090524.rar)

aWarpSharp by MarcFD is nice plugin (especially for tasks like halo removing), but has some bugs and like to produce green artifacts on the image borders. Other WarpSharp plugins produced worse results for me, so i decided to rewrite aWarpSharp algorithm with better handling of borders and optimization for modern CPUs.

Besides complete algorithm aWarpSharp2, its parts are also available as aSobel, aBlur, aWarp and aWarp4. This way you can do advanced edge mask filtering (like MDegrain) before passing it to warp stage to get more stable result.

Good usage examples:

aWarp4(Spline36Resize(width*4, height*4, 0.375, 0.375), aSobel().aBlur(), depth=3)
aWarp4(nnedi3_rpow2(rfactor=2).Spline36Resize(width*4, height*4, 0.25, 0.25), aSobel().aBlur(), depth=3)
aWarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2), aSobel().aBlur(), depth=2)

Note that upsampling for aWarp4 should be left-top aligned, so Spline36Resize(width*4, height*4) or nnedi3_rpow2(rfactor=4) won't produce correct results.

For options explanation and values mapping from used in aWarpSharp by MarcFD - read the included aWarpSharp.txt.

Binary patched Toon-v1.0 to use aWarpSharp2 instead of aWarpSharp: Toon-v1.1 (http://pavelsx.googlepages.com/Toon-v1.1.7z)

[ChaosKing]

wow nice...

Just made a quick test.

awarpsharp(154,2,20)#new
awarpsharp(20,2,0.6)#old (marcFD)

1. new, 2. old
http://img43.imageshack.us/img43/6274/awarpsharpnew.th.png (http://img43.imageshack.us/my.php?image=awarpsharpnew.png) http://img223.imageshack.us/img223/815/awarpsharpold.th.png (http://img223.imageshack.us/my.php?image=awarpsharpold.png)

As you can see, the border is no longer green. The pictures look very similar and the plugin seems to be about 20% faster on my Pentium D.

Very good job SEt, i waited so long for a bug free awarpshap :D

[Adub]

You wouldn't happen to have tested the speed now would you, ChaosKing?

I would do it my self, but my rig is currently encoding a Bluray and will be doing so for at least the next 17 hours.

[7ekno]

Thanks SEt !!

Tried it for a drop in for the original aWarpSharp.dll, but MCTDenoise is giving errors with it not supporting some of the paramters passed (and dropping the original aWarpSharp.dll back in resolves it) ...

It's seems to be about 20-30% faster, so well done !!

Tek

[7ekno]

.double post.

[SEt]

All parameters of original aWarpSharp are supposted, but some are renamed - read aWarpSharp.txt for the mapping.

[lansing]

thanks for the rewrite, and I think sticking with the out naming would be more convenience for us

[Dark Shikari]

movdqu xmm2, [esi-1]
movdqa xmm3, [esi]
movdqu xmm4, [esi+1]
movdqu xmm5, [esi+edx-1]
movdqa xmm6, [esi+edx]
movdqu xmm7, [esi+edx+1]
...
movdqu xmm1, [esi+eax-1]
movdqu xmm3, [esi+eax+1]This is what palignr was made for; SSSE3-ifying this with palignr will avoid all the unaligned loads nicely. If you retain loads between loop iterations, you can reduce the number of memory accesses, too.

movdqu xmm6, [esi-6]
movdqu xmm0, [esi+6]
pavgb xmm6, xmm0
movdqu xmm5, [esi-5]
movdqu xmm7, [esi+5]
pavgb xmm5, xmm7
movdqu xmm4, [esi-4]
movdqu xmm0, [esi+4]
pavgb xmm4, xmm0
movdqu xmm3, [esi-3]
movdqu xmm7, [esi+3]
pavgb xmm3, xmm7
movdqu xmm2, [esi-2]
movdqu xmm0, [esi+2]
pavgb xmm2, xmm0
movdqu xmm1, [esi-1]
movdqu xmm7, [esi+1]
pavgb xmm1, xmm7
movdqa xmm0, [esi]Did someone say made for palignr ;)

movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi], 0
pinsrw xmm4, [eax+edx], 0
movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi+1], 1
pinsrw xmm4, [eax+edx+1], 1
movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi+2], 2
pinsrw xmm4, [eax+edx+2], 2
movd eax, xmm2
pinsrw xmm3, [eax+esi+3], 3
pinsrw xmm4, [eax+edx+3], 3
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+4], 4
pinsrw xmm4, [eax+edx+4], 4
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+5], 5
pinsrw xmm4, [eax+edx+5], 5
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+6], 6
pinsrw xmm4, [eax+edx+6], 6
movd eax, xmm7
pinsrw xmm3, [eax+esi+7], 7
pinsrw xmm4, [eax+edx+7], 7
mov eax, [esp]I'm going to have to start killing kittens if I keep seeing things like this.

movq xmm7, qword ptr [edi+ebx-1] // one line above actual position, but it gives 1.4x speedupHow about you figure out why it does? ;)

[owais]

Help!! with this new updated famous plugin i m geting kind of like this image :(

i used aWarpSharp(depth=12,blur=4,thresh=51,chroma=1)

Am i doing something wrong?

the colours are dancing

http://i276.photobucket.com/albums/kk1/owiowais/error.jpg


with old plugin i m getting normal, yeah but having green lines

i used aWarpSharp(depth=12,blurlevel=4,thresh=0.2,cm=1)

http://i276.photobucket.com/albums/kk1/owiowais/greenwidnoclordance.jpg

Edited

i hav found little bit that it is due to chroma=1 bascally i don know wat is chroma cause i m new to video (just started on march and learn a lot :p)

for me till now chroma= 2or 3 works well and 4 also, problem is with 1 for me .. 0 was giving me black and white colour hehe

[SEt]

Dark Shikari, i know not everything is optimally written, but i thought better release working version now than super-optimized never. I know that horizontal blur is made for palignr and will look into this when i have time, but i have no idea how to save kittens or why loading correct line gives 1.4x speed drop for the whole function, including those awful pinsrw that should be much more time consuming than just unaligned load from additional memory location.

owais, have you tried to read all the aWarpSharp.txt? There explained that cm=1 of original aWarpSharp is chroma=4 in mine and what chroma values mean.

[Dark Shikari]

Dark Shikari, i know not everything is optimally written, but i thought better release working version now than super-optimized never. I know that horizontal blur is made for palignr and will look into this when i have time, but i have no idea how to save kittens or why loading correct line gives 1.4x speed drop for the whole function, including those awful pinsrw that should be much more time consuming than just unaligned load from additional memory location."Should be much more time consuming?"

Does that imply you tested it, and found it to be faster?

If it's faster, I'm going to be inclined to blame cacheline-split. Test on an AMD chip or Nehalem and watch the penalties melt away.

[SEt]

I'm already on Nehalem and when i change
movq xmm7, qword ptr [edi+pitch*0-1]
movq xmm4, qword ptr [edi+pitch*0+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]
to
movq xmm7, qword ptr [edi+pitch*1-1]
movq xmm4, qword ptr [edi+pitch*1+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]
i see 1.4x slowdown in profiler for the whole function.

[Dark Shikari]

I'm already on Nehalem and when i change
movq xmm7, qword ptr [edi+pitch*0-1]
movq xmm4, qword ptr [edi+pitch*0+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]
to
movq xmm7, qword ptr [edi+pitch*1-1]
movq xmm4, qword ptr [edi+pitch*1+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]
i see 1.4x slowdown in profiler for the whole function.I was referring to the pinsrw with regard to the cacheline split.

If you're getting such a large slowdown merely by changing that, you should try to figure out why. Performance counters might be useful for analyzing that.

[Fizick]

Can I ask, why do you change parameters meaning? It is confusing, and not "fully compatible with original aWarpSharp".
If you prefer new parameters, please use new parameters names (or new name of plugin).

[SEt]

Played with performance counters for some time and here is what i found (removed all pinsrw for tests as they don't change the situation):
global slowdown is produced by
movq xmm7, qword ptr [edi+pitch*1-1]
but not by
movq xmm4, qword ptr [edi+pitch*1+1]
It results in spike of L1D.REPL and huge spikes of L1D.M_REPL, L1D.M_EVICT, L1D.M_SNOOP_EVICT in that area (also ILD_STALL.ANY, but i don't think it's interesting).
I've tried to change the only writing instruction here from movq to movdq2q,movntq but that changed nothing.


Fizick, i think the situation is similar to MVTools 1-2 :) It's fully compatible in terms of available functionality and effective ranges of parameters are supersets of the original ones. I know i should probably change the name to aWarpSharp2, but it looks kind of strange with aSobel, aBlur, aWarp. In truth it's more like a beta release to me due to mentioned wrong offsets in Warp and saturated multiplication by 6 at the end of Sobel that i don't like at all.

[IanB]

I'm already on Nehalem and when i changemovq xmm7, qword ptr [edi+pitch*0-1]
movq xmm4, qword ptr [edi+pitch*0+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]tomovq xmm7, qword ptr [edi+pitch*1-1]
movq xmm4, qword ptr [edi+pitch*1+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]i see 1.4x slowdown in profiler for the whole function.
Consider the memory address each is referencing and which cache line each uses. I have colour coded 3 different memory areas. In the fast case only 2 areas are used. Also accessing data not aligned to 64 bits has a penalty. And a very big penalty when you cross a cache line (64 byte) boundary. For the [edi+pitch*1-1] you maybe slipping into the previous cache line (what address is in EDI ?)

[SEt]

The code reads 3 lines of one frame while writing one line to another frame in simple loop. edi is global counter increased by 8 that is used as offset for all sources and destination. It's not cache line split problem as [edi+pitch*1+1] and [edi+pitch*0-1] are ok but not [edi+pitch*1-1], also the order of impact is too big and on Nehalem such penalties are small. It seems like some kind of cache (address?) conflict as the descriptions of performance counters that produce spikes:
REPL - Counts the number of lines brought into the L1 data cache.
M_REPL - Counts the number of modified lines brought into the L1 data cache.
M_EVICT - Counts the number of modified lines evicted from the L1 data cache due to replacement.
M_SNOOP_EVICT - Counts the number of modified lines evicted from the L1 data cache due to snoop HITM intervention.

But the code linearly reads from one location and linearly writes to another in simple loop.

EDIT: It's indeed seems like cache address conflict as lower 16 bits of [edi+pitch*1] and [output] are the same, but it doesn't give me any idea how to fix it besides caching [edi+pitch*1-1] from previous iteration (as both memory locations are what i get from avisynth).
EDIT2: And it seems to be L2-3 problem with scenario something like:
Cache lines in L1 are allocated independently, but when output L1 line is written to L2+ it mistakes next reference to [edi+pitch*1-1] as accessing the same location for that single -1 byte which results in the L1 cache lines ping-pong hell as seen by counters.

[IanB]

What does adding this:-mov al, byte ptr [edi+pitch*1-8]a few lines earlier into your code do?

And is pitch a constant or a register, i.e. are your hiding relevant code from us?

[Leak]

And is pitch a constant or a register, i.e. are your hiding relevant code from us?
Well, the code is in the archive he linked to in his first post, so I'd think he'd have a hard time really hiding it from you... ;)

np: Plastikman - I Don't Know (Closer)

[IanB]

@Leak <- :devil:,

I asked because
movq xmm7, qword ptr [edi+pitch*1-1]
does not appear in the code, but
movq xmm7, qword ptr [edi+ebx-1]
does appear in the code.

And when people want help, I like to make sure nothing is clouding the issue.

[SEt]

Problem solved. Thanks to Dark Shikari for kicking me to actually go see performance counters and IanB for idea what can help.
Placing earlier
mov al, byte ptr [edi+pitch*1-8]
changed nothing, but gave me idea that worked - i moved problem loads before write of previous iteration. A few more optimizations and new code works as fast as old one and sometimes even a bit faster. Will post it later when other things are done.

IanB, i started to use pitch*? instead of registers because included source had no register for pitch*1.

[Chainmax]

This is awesome, one of my favorite plugins to use on animated content finally updated and bug-free! Thank you so much, SEt :).

One question: in order to achieve the same effects as aWarpSharp(depth=16,cm=1) in MarcFD's original one would have to use aWarpSharp(depth=16,chroma=4) on your version, right?

[SEt]

Yes, and both are defaults btw.
It's not bug free yet - as described here it uses incorrect position in edge map. Next version will be correct one.

I'm interested in usefulness of bm=0/1/2 parameter (choice of internal blur type for edge map) - is it really needed now when you can use external one? There are probably enough blurs for AviSynth already.

[sh0dan]

movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi], 0
pinsrw xmm4, [eax+edx], 0
movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi+1], 1
pinsrw xmm4, [eax+edx+1], 1
movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi+2], 2
pinsrw xmm4, [eax+edx+2], 2
movd eax, xmm2
pinsrw xmm3, [eax+esi+3], 3
pinsrw xmm4, [eax+edx+3], 3
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+4], 4
pinsrw xmm4, [eax+edx+4], 4
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+5], 5
pinsrw xmm4, [eax+edx+5], 5
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+6], 6
pinsrw xmm4, [eax+edx+6], 6
movd eax, xmm7
pinsrw xmm3, [eax+esi+7], 7
pinsrw xmm4, [eax+edx+7], 7
mov eax, [esp]I'm going to have to start killing kittens if I keep seeing things like this.

I completely agree - while this might seem fast, it isn't. Movd r32,xmm has a latency of 6 cycles on Core2, pinsrw has a latency of 4. Both are eons.

Store the content of xmm2 and xmm7 into memory, do lookups in scalar assembler and read them back:


movdqa [temp1], xmm2 ; Store all pixels

; push eax, ebx, ecs on the stack, if you use them already

xor eax, eax
xor ebx, ebx
xor ecx, ecx

mov ax,[temp1]
mov bx,[eax+esi]
mov cx,[eax+edi]
mov [temp2], bx
mov [temp3], cx

mov ax,[temp1+2]
mov bx,[eax+esi]
mov cx,[eax+edi]
mov [temp2+2], bx
mov [temp3+2], cx

(you get the picture -use a macro, for nice code)

movdqa xmm3, [temp2]
movdqa xmm4, [temp3]

This way you only get the performance hit of the cache lookups, and a Store->Load Forward size mismatch penalty. And for please, use palignr, it is much faster on Core2.

[SEt]

I completely agree - while this might seem fast, it isn't. Movd r32,xmm has a latency of 6 cycles on Core2, pinsrw has a latency of 4. Both are eons.
Your numbers seems too high even for Core2. According to http://www.agner.org/optimize/ tables movd has latency/throughput of 2/0.33 on both Core2 and pinsrw 6/1.5 on 65nm and 2/1 on 45nm. On my Nehalem Everest measures "MOVD r32, xmm+MOVD xmm, r32" to have latency 4, "PEXTRW + PINSRW r32" latency 1, movd throughput 0.4, pinsrw throughput 0.66.

For speed of this part it's actually the other way around - at the beginning i thought it to be painfully slow too, but profiler says it's quite fast. Changing even movd/psrldq into movdqa/mov [+0/4/8/12] gives me 10% speed drop for the whole function. Changing pinsrw would likely cost even more. Of course it's measured on Nehalem and not on Core2 that everyone seems to love for reason that's beyond me. Modern CPUs taught me to believe only profiler when optimizing and not what you think is faster, so i'm not going to write something that "maybe better for Core2" when i have no means of confirming it by testing there.
And for please, use palignr, it is much faster on Core2. palignr is definitely great for some cases, but guess how much difference i measure between old unaligned hell of
movdqu xmm6, [esi-6]
movdqu xmm0, [esi+6]
pavgb xmm6, xmm0
movdqu xmm5, [esi-5]
movdqu xmm7, [esi+5]
pavgb xmm5, xmm7
movdqu xmm4, [esi-4]
movdqu xmm0, [esi+4]
pavgb xmm4, xmm0
movdqu xmm3, [esi-3]
movdqu xmm7, [esi+3]
pavgb xmm3, xmm7
movdqu xmm2, [esi-2]
movdqu xmm0, [esi+2]
pavgb xmm2, xmm0
movdqu xmm1, [esi-1]
movdqu xmm7, [esi+1]
pavgb xmm1, xmm7
movdqa xmm0, [esi]
pavgb xmm6, xmm5
pavgb xmm4, xmm3
pavgb xmm2, xmm1
pavgb xmm6, xmm4
pavgb xmm2, xmm0
pavgb xmm6, xmm2
pavgb xmm6, xmm2
movntdq [esi+edi], xmm6

and new (to be released)
movdqa xmm7, [esi+10h]
movdqa xmm0, xmm6
movdqa xmm2, xmm7
palignr xmm0, xmm5, 10
palignr xmm2, xmm6, 6
pavgb xmm0, xmm2
movdqa xmm3, xmm6
movdqa xmm4, xmm7
palignr xmm3, xmm5, 11
palignr xmm4, xmm6, 5
pavgb xmm3, xmm4
pavgb xmm0, xmm3
movdqa xmm1, xmm6
movdqa xmm2, xmm7
palignr xmm1, xmm5, 12
palignr xmm2, xmm6, 4
pavgb xmm1, xmm2
movdqa xmm3, xmm6
movdqa xmm4, xmm7
palignr xmm3, xmm5, 13
palignr xmm4, xmm6, 3
pavgb xmm3, xmm4
pavgb xmm1, xmm3
pavgb xmm0, xmm1
movdqa xmm1, xmm6
movdqa xmm2, xmm7
palignr xmm1, xmm5, 14
palignr xmm2, xmm6, 2
pavgb xmm1, xmm2
movdqa xmm3, xmm6
movdqa xmm4, xmm7
palignr xmm3, xmm5, 15
palignr xmm4, xmm6, 1
pavgb xmm3, xmm4
pavgb xmm1, xmm3
pavgb xmm1, xmm6
movdqa xmm5, xmm6
movdqa xmm6, xmm7
pavgb xmm0, xmm1
pavgb xmm0, xmm1
movntdq [esi+edi], xmm0

? The second version is only 10% faster (of course, on Nehalem again).

[Dark Shikari]

Of course it's measured on Nehalem and not on Core2 that everyone seems to love for reason that's beyond me.Maybe because that's what they own? It will be years before the Nehalem has a higher install base than the Core 2.Modern CPUs taught me to believe only profiler when optimizing and not what you think is faster, so i'm not going to write something that "maybe better for Core2" when i have no means of confirming it by testing there.Then ask someone for SSH access, there are billions of Core 2s.

? The second version is only 10% faster (of course, on Nehalem again).Try running the first set of code when you're not on a cacheline, and the second set when you are, perhaps?

[SEt]

Maybe because that's what they own? It will be years before the Nehalem has a higher install base than the Core 2. I suspect there is higher install base for P4/D than Core2 now, but does it mean we should optimize primary for P4? If care for something else it would be Phenoms and i suspect them to behave similar to Nehalem, not Core2.
Then ask someone for SSH access, there are billions of Core 2s.
Good idea, but i'd rather spend my time now for more important stuff, like actually releasing something.
Try running the first set of code when you're not on a cacheline, and the second set when you are, perhaps?
I'm not quite get your point here. I bench the code on real video processing. Also notice the 'movdqa' in the only memory load of second variant.

[Dark Shikari]

I suspect there is higher install base for P4/D than Core2 now, but does it mean we should optimize primary for P4? If care for something else it would be Phenoms and i suspect them to behave similar to Nehalem, not Core2.People who care about video processing speed are not using Pentium 4s.Good idea, but i'd rather spend my time now for more important stuff, like actually releasing something.Why is it that I can release code optimized for multiple modern CPUs while you can't?I'm not quite get your point here. I bench the code on real video processing. Also notice the 'movdqa' in the only memory load of second variant.And? x264 performs "real video processing" and has separate code paths for when the loads fall across a cacheline.

[SEt]

People who care about video processing speed are not using Pentium 4s.
People who really care about video processing speed would use Nehalem.
Why is it that I can release code optimized for multiple modern CPUs while you can't?
It's a matter of preference. I think optimization is important, but comes behind the features. I'd love to see in next x264 option to be 2x slower but produce 5% better quality/smaller file size instead of even 10% overal speed up.
And? x264 performs "real video processing" and has separate code paths for when the loads fall across a cacheline.
How can dq loads aligned on 16 bytes be across a cacheline?

[Dark Shikari]

How can dq loads aligned on 16 bytes be across a cacheline?You said that your palignr-based code is only 10% faster.

What if it was 70% faster when on a cacheline, and 10% slower otherwise? This would average out to 10% faster overall.

In that case, you'd want to use the unaligned code when not on a cacheline, and the palignr code when on a cacheline.

[SEt]

Ok, now i understand you. Profiled such case and it turned out that old and new code have exactly the same speed when not on a cacheline. So, those 10% are what palignr wins on cacheline split.

[Dark Shikari]

Ok, now i understand you. Profiled such case and it turned out that old and new code have exactly the same speed when not on a cacheline. So, those 10% are what palignr wins on cacheline split.By the way, the reason it's only 10% faster on Nehalem is because the Nehalem has only a 2-cycle penalty for cacheline splits.

The Core 2 Penryn has a ~12-14-cycle penalty, which will probably mean that SSSE3 code will go massively faster on Penryn; I'd guess at least 50% benefit.

[SEt]

I know that much about my Nehalem. :) But would love to read something like http://www.agner.org/optimize/ about its microarchitecture and instruction timings (regrettably, information there is only up to Core2 now).

[Dark Shikari]

I know that much about my Nehalem. :) But would love to read something like http://www.agner.org/optimize/ about its microarchitecture and instruction timings (regrettably, information there is only up to Core2 now).Intel's latest optimization guide has Nehalem documentation, but not timings.

Mubench (http://akuvian.org/src/mubench_results.txt) has mostly-accurate Nehalem timings.

[Gokumon]

Why is it that I can release code optimized for multiple modern CPUs while you can't?

Because you get paid to work on x264 while SEt doesn't get paid to work on his aWarpSharp rewrite?

[SEt]

Finally an update:

renamed main filter from aWarpSharp to aWarpSharp2 for less confusion with original aWarpSharp
fixed wrong offsets in Warp
added new blur type - produce better quality, but around 2.5x slower
blur will be more precise around frame borders if SSSE3 is available
some optimizations, mostly noticeable on Core2
removed support for undocumented parameters of original aWarpSharp

[Dark Shikari]

Because you get paid to work on x264I do? That's news to me, because I haven't gotten a check.

[LoRd_MuldeR]

I do? That's news to me, because I haven't gotten a check.

What about your (previous) engagement at Avail Media? :p

[Dark Shikari]

What about your (previous) engagement at Avail Media? :pAs it happens, summer internships end at the end of the summer ;)

[Gokumon]

As it happens, summer internships end at the end of the summer ;)

Okay, from what I read from your posts it seemed to be an actual full-time position not an internship. Let's put it this way instead then, some people don't necessarily have as much time and effort to spend to write assembly for many multiple CPUs as other people may be able to.

[SEt]

Rebuilt version 2009.06.19 with new header to correct threading problems.

[MyCometG3]

SEt
Thank you for your effort.
I have ported this plug-in to GCC. Impemented into my CoreVF framework, under MacOS X env. It runs well. Great!

One thing, Warp() function seems to check CPU is SSSE3 ready every line inside asm, is this required?
I have split SSSE3 loop and SSE2 loop, seems to run well. It could be faster.

(I am not sure, but original code does not run well under CoreDuo - no SSSE3 support; Of course not original, but gas rewritten code though. Splitting loops works well both on Core2Duo and CoreDuo)

[SEt]

There should be no problem with that conditional jump - any modern cpu should be able to always correctly predict it so it will consume no time at all. And even mispredicted once per line is very small cost. What you are observing might be cache related - it has far more serious impact on performance. But of course it's only a theory.

[Monamona]

Is there any chance that the filter will be modified to work under YUY2?

[lych_necross]

I like the rewritten aWarpSharp. Now, if only Toon.dll would get updated to support the new version...

[SEt]

I'm not going to add YUY2 support, but probably will add YV16.

[Lynx Pardinus]

You mean YV16, wich won't be supported until Avisynth 2.60, or the planar YUY2 supported by MVTools, masktools and many others ?

[SEt]

YV16 of Avisynth 2.60+.

[lych_necross]

Supporting yv16 instead of yuy2 is odd, but okay. I waited 1+ years for for 2.58, whats another couple of years ;)

[thewebchat]

In the awarpsharp.txt file included with your filter, you mention that the mapping between "thresh" in aWarpSharp2 and aWarpSharp is "aWarpSharp2 value * 256" but the aWarpSharp documentation says that thresh goes from 0.0 to 1.0. How does this work?

Edit: Oh, sorry, read the equation the wrong away around. Sorry about that. Someone can delete this post.

Edit2: I am getting an access violation (reading from 0x0 at 0xfaa1415) when setting blur to "1". The documentation says that values from 0 to 100 are supported.

Edit3: Oh wait, that's just a mod16 error.