FFT3DFilter 2.6

[pinterf]

There are so many options and sub-filters that it is impossible to test all cases and choose one "best" compiler.
E.g. there are a tons of possible branches by processor types: SSE2, SSE4, AVX, AVX2, plus 24 modes in RgTools, plus repair option. Many hundred different scenarios.
Then it was a real case that msvc produced 10% faster code in AVX2 for Removegrain mode X while it was 10% slower at mode Y, compared to clang.
Let the user choose, if user is a power-user and have inifinite time to test, he will know why this or that version is chosen. All other user just choose by sympathy (MS rulez, clang inside yeah).

[tormento]

And you forgot Intel Parallel XE too xD

Work colleagues told me miracles of that.

[MeteorRain]

As a programming noob as I am, may I ask why some of AVS contributors started to provide both compiles? I mean, which are differences and advantages? Speed on different CPUs? I am really curious.

A few reasons.

1) clang does lots of optimizations on even SIMD intrinsics code, while MSVC tends to compile as-is. For example, in f3kdb, where there's a selection operation (I can't remember the details), clang directly optimize the whole operation into a completely different instruction sequence, which greatly improved the speed on SSE2, even making it almost as fast or faster than the AVX variant (due to lack of equivalent instruction in AVX). While MSVC simply compiled as-is, with some unroll maybe?

2) clang checks lots of extra warnings and errors. Having a clang compiled version means the code will likely compile on clang @ Linux or MacOS as well.

I personally also compile the code in GCC to make sure it satisfies all common compilers. However GCC uses POSIX ABI so it's not usable under MSVC C++ AVS+ so I didn't include it in the release.

[tormento]

There are so many options and sub-filters that it is impossible to test all cases and choose one "best" compiler.
I just tried a very simple filter case, that uses KNLMeansCL, MaskTools and MVTools only. The only available filter as both clang and VS2019 is MaskTools.

Average on 10x launch of same script:

MaskTools clang: 13.43 fps
MaskTools VS2019: 13.59 fps

The true bottleneck here is MVTools, that I always beg you to release on both compiler versions to see if any difference occurs. :p

[tormento]

A few reasons.
Thanks for the exaustive reply. In the mean time I asked my old friends in University what they use and confirmed me Intel compiler is one of the best to have fast code. On some peculiar cases, mostly scientific simulations, they can see 20x increase vs VS one.

[MeteorRain]

But this speed up again... What kind of sorcery is this? :devil:

I have a pretty smart :sly: LRU caching system and a multi-threading counting system, to make sure I use the least possible memory to work with give multi-threading model. So it should now runs at 6 threads from input.

Then for each plane I let them fly on their own threads, so 18 threads into the engine.

From there, some hot paths like copying window data into blocks operation gets parallel'd using C++ PSTL, which is basically a trouble free thread pool.

Core functions such as Apply and Sharpen families get full SSE/AVX/AVX512 optimization. Because I have a centralized wrapper and put variants into templates, it's pretty easy for me to transform loops into parallel computing. I've tried putting all blocks into their own threads, and it turns out it runs slower. So current design is to run 4 parallel computing batch, and each run a quarter of the data blocks.

I definitely don't want it to occupy too much CPU, because it's usually paired with other filters. So I tweak it to use about 3-4 full cores maximum to maintain a high running efficiency.

[MeteorRain]

Thanks for the exaustive reply. In the mean time I asked my old friends in University what they use and confirmed me Intel compiler is one of the best to have fast code. On some peculiar cases, mostly scientific simulations, they can see 20x increase vs VS one.

Yes and no. Lots of CPU intensive code nowadays are written in assembly / intrinsics anyway, so the compiler is having less and less things to optimize.

Like I said, you must be able to optimize assembly code to further improve the performance. Sometimes you also have to take into consideration what the target CPU is, because, there's a few instructions that runs faster and slower on different CPUs.

For example, if in the SIMD I write code A; B; C, but the compiler thinks my code is dumb because it can be done using X; Y, which is faster, it should delete my code and change it to the faster version right away.

Then there's times when ABC is faster on, for example, haswell, but XY is faster on skylake, now the compiler would ask you, which CPU would you prefer to target. If you say I love haswell then it should leave ABC there.

Optimization is a very interesting topic to study, and I only know a small portion of it. Here's my $0.02.

[ChaosKing]

I have a pretty smart :sly: LRU caching system and a multi-threading counting system, to make sure I use the least possible memory to work with give multi-threading model. So it should now runs at 6 threads from input.

Then for each plane I let them fly on their own threads, so 18 threads into the engine.

From there, some hot paths like copying window data into blocks operation gets parallel'd using C++ PSTL, which is basically a trouble free thread pool.

Core functions such as Apply and Sharpen families get full SSE/AVX/AVX512 optimization. Because I have a centralized wrapper and put variants into templates, it's pretty easy for me to transform loops into parallel computing. I've tried putting all blocks into their own threads, and it turns out it runs slower. So current design is to run 4 parallel computing batch, and each run a quarter of the data blocks.

I definitely don't want it to occupy too much CPU, because it's usually paired with other filters. So I tweak it to use about 3-4 full cores maximum to maintain a high running efficiency.

Now do the same for mvtools :D
Haha just kidding.

[MeteorRain]

Never looked at that code. You tell me how hard it could be for me to get hands on it. If it's not to hard I may actually give it a try.

[ChaosKing]

Never looked at that code. You tell me how hard it could be for me to get hands on it. If it's not to hard I may actually give it a try.

As far as I read on doom9, the code is a mess...

https://github.com/pinterf/mvtools
https://github.com/dubhater/vapoursynth-mvtools

But maybe it would be better and easier to improve the c++ reimplementation of mvtools by feisty2
https://forum.doom9.org/showthread.php?t=172525
https://github.com/IFeelBloated/vapoursynth-mvtools-sf <-- I had some problematic scenes where this version was ok where the other mvtools showed some artifacts. Maybe 32bit precision had something to do with it, idk.

[pinterf]

While fft3dfilter update took some hours for me, I spent months with mvtools.

[StainlessS]

I spent months with mvtools.

You must have found it very interesting :)

[MeteorRain]

How's f2's version working? Is it fully functional in terms of parameters and functions support?

Although he just said he might rewrite it....

[ChaosKing]

How's f2's version working? Is it fully functional in terms of parameters and functions support?

Although he just said he might rewrite it....

Yes everything works as far as I know. It is used for smdegrain (tr >4), TemporalDegrain2, mClean etc here https://github.com/Selur/VapoursynthScriptsInHybrid/blob/master/G41Fun.py#L1929

[MeteorRain]

How fast (slow) it runs? Do you think it is a good idea to forget the original version and just take this as the base?

[Sharc]

While fft3dfilter update took some hours for me, I spent months with mvtools.
FFT3DFilter has the option 'interlaced=true' for the direct filtering of interlaced video. Shouldn't the 2 scripts below produce identical outputs? Actually they don't. Which one is correct? Do I miss something? :confused:

#Script 1
AVISource("source.avi")
separatefields()
even=selecteven().fft3dfilter(plane=4,interlaced=false)
odd=selectodd().fft3dfilter(plane=4,interlaced=false)
v1=interleave(even,odd)

#Script 2
AVISource("source.avi")
fft3dfilter(plane=4,interlaced=true)
v2=separatefields()

return subtract(v1,v2).Levels(127,1,129,0,255) #should give grey picture if v1,v2 are identical

[ChaosKing]

How fast (slow) it runs? Do you think it is a good idea to forget the original version and just take this as the base?

SMDegrain(mvf.Depth(clip, 16), tr=3) # 16bit mvtools "fast version" -> 18 fps
SMDegrain(mvf.Depth(clip, 32), tr=3) # 32bit mvtools-sf -> 3 fps

The only thing I can say is, that in my tests the mvtools-sf version produced better results in some edge cases and the source code is probably a bit easier to read. Maybe dubhater can give a hint which version he would improve ;-)

[tormento]

The only thing I can say is, that in my tests the mvtools-sf version produced better results in some edge cases and the source code is probably a bit easier to read. Maybe dubhater can give a hint which version he would improve ;-)
I have tested SMDegrain under VS too and it's a clear example of added complexity and lower speed. Perhaps VS is much better for other things but not for this specific one.

[Stereodude]

r2 -- marked as pre-release for now -- has been uploaded to GitHub.

I spend a few hours to completely rewrite the dual interface wrappers and it should be easier to work with now. I'm planning to move some of my filters into the new platform if I have time, including f3kdb (before fixing some raised issue).

Let me know how it works -- and if it is faster than it was. I experimentally used C++ Parallel STL in a few hot code paths and should have improved speed a bit.
Why did you remove the plane argument from Neo_FFT3D? Both MCTD and QTGMC make use of it. Unless I'm missing it any speed improvements this Neo version has can't be use for the less aggressive presets because they're not expecting the chroma planes to be processed.

[MeteorRain]

Why did you remove the plane argument from Neo_FFT3D? Both MCTD and QTGMC make use of it. Unless I'm missing it any speed improvements this Neo version has can't be use for the less aggressive presets because they're not expecting the chroma planes to be processed.

Because with y=3, u=2, v=2 I don't see a point keeping plane option there, being redundant and less useful. Let me know what your needs are if this is insufficient.

[Stereodude]

Because with y=3, u=2, v=2 I don't see a point keeping plane option there, being redundant and less useful. Let me know what your needs are if this is insufficient.
Somehow I overlooked those arguments. Let me see if I can modify the scripts to use the new arguments. It looks pretty straightforward at least for MCTD.

[Stereodude]

So MCTD gets a ~13% speed increase using neo_fft3d r3 vs. fft3d 2.6 on HD resolution content on system without AVX2 and a ~10% speed increase on a system with AVX2. This was using a mild NR preset and MPP.

On SD (DVD) content the gains are a lot less.

[tormento]

so mctd gets a ~13% speed increase using neo_fft3d r3 vs. Fft3d 2.6
Post it NOW :D

[Stereodude]

Post it NOW :D
Done: https://forum.doom9.org/showthread.php?p=1907108#post1907108

(pending attachment approval)

[tormento]

Done
:thanks:
(pending attachment approval)
*cough*paste.bin*cough

[Stereodude]

:thanks:

*cough*paste.bin*cough
added...

[tormento]

added...

Thanks.

[pinterf]

What about starting a separate topic for the new plugin?

[DJATOM]

Yeah, it would be nice from mods to move Neo related posts into new topic :)

[StainlessS]

+1 on Neo having own thread.
(helps in avoiding confusion)

[tormento]

+1 on Neo having own thread.
(helps in avoiding confusion)



So should pinterf :)

[StainlessS]

P is still considering it [although one might think 6 months (or is it 12) would be enough time to analyse and make a decision, very careful guy is P, he don't like to jump the gun].

[MeteorRain]

Another option is me converting neo f3kdb to neo family post, and waiting for mod to move replies there. (Is it possible?)

[tebasuna51]

If pinterf (owner of this thread) want we can create a new thread FFT3DFilter-Neo and after move the related post (I need a list of post numbers # involved)

[pinterf]

I do not want but it seems practical.

[poisondeathray]

FFT3DFilter v2.8 pinterf fork plane=3 issue, u,v color shift

colorbars(width=400, height=300, pixel_type="yv12")
histogram("levels")

colorbars(width=400, height=300, pixel_type="yv12")
fft3dfilter(bt=1, sigma=0, plane=3)
histogram("levels")
subtitle("fft3dfilter(bt=1, sigma=0, plane=3), gamma2")

(apng should animate in most browsers)
https://i.postimg.cc/fyfWKYH8/apng1.png (https://postimages.org/)


eg on dark scene (brightened with levels gamma=2 for display purposes) , rgb histogram instead of uv levels
(apng should animate in most browsers)
https://i.postimg.cc/wMgg776L/apng2.png (https://postimages.org/)

sigma= higher value does not alter the shift
plane=4 (all Y,U,V) does not alter the U,V shift

[pinterf]

Interesting. Only negative U and V values are affected. Rounding issue? How does the newer neo version behave?

[poisondeathray]

How does the newer neo version behave?

neo_fft3d r10 works ok (no U,V shift) ; sigma > 0 ok too (or expected results)

neo_fft3d(sigma=0, bt=1, y=2, u=3, v=3)

[pinterf]

Yep, that was fixed in neo_fft3d. Though the original plugin is superseded in most aspects, I'm gonna update it.

[pinterf]

New "yesIknowthereisneo" release, because even old things must be kept clean.
https://github.com/pinterf/fft3dfilter/releases/tag/v2.9

[poisondeathray]

New "yesIknowthereisneo" release, because even old things must be kept clean.
https://github.com/pinterf/fft3dfilter/releases/tag/v2.9

Thanks

Many older scripts use fft3dfilter classic syntax, not updated neo, so this is still useful for some people

[StainlessS]

Yip, I'm still on the antique one, thanks very much.

[GMJCZP]

I was testing version 2.9 and after coding and closing Virtualdub2 or VirtualdubMod it throws me an error message associated with libfftw3f-3. I have already tried several versions of the library and the same error appears, this does not happen with neo_fft3d that works, somewhat slower yes, but correctly.

[pinterf]

I was testing version 2.9 and after coding and closing Virtualdub2 or VirtualdubMod it throws me an error message associated with libfftw3f-3. I have already tried several versions of the library and the same error appears, this does not happen with neo_fft3d that works, somewhat slower yes, but correctly.
Script and how-to steps needed, cannot reproduce.

[GMJCZP]

Script and how-to steps needed, cannot reproduce.

I already found out who is guilty, it's Stab, Stab calls DePan, DePanEstimate and RGTools (DePanEstimate calls libfftw3f-3).
These are the versions I am using:

DePan and DepanEstimate: mvtools-2.7.45
RGTools: 1.2

Stab is the script originally created by g-force (December 10, 2008)

pinterf, if you use a script like this:

SourceFilter(video)
Stab()
fft3dfilter()

It should reproduce the problem. What I find strange is what is the relationship between Stab and fft3dfilter.

Edit: just opening the script with virtualdub and closing the program produces the error.

[pinterf]

Yep, I've got it, debugged it, but do not understand :)

[GMJCZP]

Yep, I've got it, debugged it, but do not understand :)

There seems to be a love triangle between DePanEstimate (Stab) - libfftw3f-3 - fft3dfilter, and while neo_fft3d stays in the final with the girl who is the protagonist of the story. :confused:

[pinterf]

Check please v10 (https://github.com/pinterf/fft3dfilter/releases/tag/v2.10).

[GMJCZP]

All right, thank you pinterf.