FTurn and SangNom2 - plugins for faster antialiasing

[TurboPascal7]

I've been doing lots of antialiasing on HD content and most current implementations are insanely slow. Hence these two plugins.

FTurn
GitHub repo (binaries)
This is a simple plugin that contains faster TurnLeft/TurnRight/Turn180 implementations (all with F prefix). Only Y8, YV12 and YV24 are supported.

I wouldn't mind seeing these optimizations in Avisynth core, but since contributing to it is not the easiest task, we're going with a separate plugin for now.

SangNom2
GitHub repo (binaries)
This is a rewrite of the old SangNom filter. Its output is mostly identical to the old version on default settings.

In addition to huge speed improvements thanks to threading, it also supports additional colorspaces (such as Y8) and processes borders in a more correct manner.
SangNom (scaled x2 with PointResize)

SangNom2

Please note that SangNom2 is still in "beta" stage so I might change some parameters and defaults in the future. For instance, I consider migrating to avstp.

Example usage
line0 wrote a maa mod that uses both these plugins and works on Y8 in some cases for maximum performance.

Note
All plugins work only with Avisynth 2.6 alpha 4. Older versions also support older Avisynth, so get them if you need it. Both plugins require SSE2-compatible CPU.

All binaries and additional info are available on GitHub. All future releases will also be posted there. I might forget to update this thread later so check the repos out if you want the latest version.

[wOxxOm]

Tested on a progressive 1920x1080 video, loaded with FFVideoSource, no other filters except the following:

Original maa(): 4.75 fps
New maa2(): 17 fps - 3.5 times faster
New maa2() with setmtmode(2,4): 24.5 fps - 5.15 times faster - realtime!
Original maa() with setmtmode(2,4): 10 fps

p.s. i7-3770k @ 4.4GHz

[real.finder]

nice, I was waiting for something like this for a long time, I'll try it as soon as possible

Thank you very much

[Overdrive80]

Great!! Thanks for your effort.

[TurboPascal7]

I just released a new version of FTurn. It now requires only SSE2 so can be used on older Intel processors and AMDs.

There were no functional changes so you don't have to update if it worked for you to begin with.

[bxyhxyh]

What is the difference between fturn2x-icc.dll and fturn2x.dll ?

[wOxxOm]

Originally Posted by bxyhxyh

What is the difference between fturn2x-icc.dll and fturn2x.dll ?

ICC stands for Intel C Compiler, I guess, though I'm more accustomed to -icl suffix.
Well, the difference is that -icc dll should run faster on Intel CPUs. Test both and choose the fastest for you.

[Groucho2004]

Originally Posted by wOxxOm

ICC stands for Intel C Compiler

Correct but ICC is actually the free version for Linux. Maybe the author does indeed mean ICL...

[TurboPascal7]

From wiki:

Intel C++ Compiler, also known as icc or icl

So I don't really see any problems.
Also apparently it's faster on AMDs too so I'll remove the vc110 build in the future version.

[TheProfileth]

Any plans to add 16bit (stacked) support for either filter?

[TurboPascal7]

I don't think it's reasonable. 16-bit sangnom doesn't make much sense to me, and turning is easier to implement as a script, since plugin would do exactly the same things anyway.
I will add interleaved 16-bit support to FTurn if other plugins' devs switch to it.

[Motenai Yoda]

Any chance to have a x86-64 version too (like for SEt's 2.5.8 MT x64 by JoshyD)?

[TurboPascal7]

Originally Posted by Motenai Yoda

Any chance to have a x86-64 version too (like for SEt's 2.5.8 MT x64 by JoshyD)?

No. Avisynt x64 is useless.
It should be possible to compile it for x64 without/with few source modifications though, you can try it yourself.
Oh and do note that SangNom2 doesn't support avisynth 2.5.8, you'll have to replace avisynth.h header and change colorspaces handling a bit.

[Stereodude]

Originally Posted by TurboPascal7

No. Avisynt x64 is useless.

It's unfortunate everyone seems to think this. 32-bit AVIsynth has serious issues when handling high resolution content that's got a lot of processing being done on it. Accessing only 2GB of RAM just isn't enough. Just because it's possible to pipe 32bit AVIsynth to a 64-bit encoder doesn't mean there's no need for 64-bit AVIsynth or that it's useless.

Do you think 64-bit encoders like x264 are worthless too?

[TurboPascal7]

Originally Posted by Stereodude

It's unfortunate everyone seems to think this. 32-bit AVIsynth has serious issues when handling high resolution content that's got a lot of processing being done on it. Accessing only 2GB of RAM just isn't enough. Just because it's possible to pipe 32bit AVIsynth to a 64-bit encoder doesn't mean there's no need for 64-bit AVIsynth or that it's useless.

Do you think 64-bit encoders like x264 are worthless too?

Where did that x264 line even come from?
x64 is quite useful, but there might be a reason why almost no one uses avs x64, you know (hint: it's slower than x86 as most asm code in both avs core and external plugins is not portable).

[Stereodude]

Originally Posted by TurboPascal7

x64 is quite useful, but there might be a reason why almost no one uses avs x64, you know (hint: it's slower than x86 as most asm code in both avs core and external plugins is not portable).

I suspect very few people use it because it's poorly supported by plugin authors like yourself. If you're correct about it being slower, a small speed tradeoff can be well worth it when it actually works and doesn't crash.

[TurboPascal7]

Originally Posted by Stereodude

I suspect very few people use it because it's poorly supported by plugin authors like yourself. If you're correct, a small speed tradeoff can be well worth it when it actually works and doesn't crash.

The problem is: most core filters and external plugins use inline MSVC assembly for asm-optimized code paths. This assembly code usually gives, say, 4-10 times better performance than plain C version (number are random). And this assembly path is not portable since MSVC cannot compile inline asm in x64 mode.

So if anyone wants to actually make x64 avisynth useful, he'd need to rewrite insane amount of assembly code to either use a real assembler as YASM, or use intrinsics (like Firesledge's, Chikuzen's, and my plugins do). There is no one crazy enough to do this. So we go without x64 for now and it most likely will never happen.

Anyway, some plugins are not that hard to port to x64, you just need to recompile them yourself (also downgrade most of them to 2.5.8. avisynth, as I explained earlier), because asking people to do something they don't care about is wrong.

[Groucho2004]

Originally Posted by Stereodude

I suspect very few people use it because it's poorly supported by plugin authors like yourself.

The Avisynth x64 version floating around is an unreliable hack. Look around, people rarely get it to work properly.
Blaming the plugin author(s) for not supporting this makes no sense.

[Stereodude]

Originally Posted by Groucho2004

The Avisynth x64 version floating around is an unreliable hack. Look around, people rarely get it to work properly.

Well, that certainly hasn't been my experience with it. Aside from a lack of 64-bit plugins I haven't found it to be any less robust or more problematic than the 32-bit version. Heck, I was even able to get QTGMC working in 64-bit. I pretty much use 64-bit AVIsynth + MP Pipeline (for 32-bit filters that aren't available in 64-bit and enhanced "multithreading") exclusively.

[the_weirdo]

Originally Posted by Stereodude

Well, that certainly hasn't been my experience with it. Aside from a lack of 64-bit plugins I haven't found it to be any less robust or more problematic than the 32-bit version.

Then you must be a very lucky person