newer FFTW DLL's Windows?

[Sparktank]

Edit 3: Currently active links
It's Clang.


For people who want to try binaries built by different compilers, here are the new builds.

fftw3-20200415-3a103f4 (Clang 10.0) (http://www.mediafire.com/file/cb0dmixb7uytlkt/fftw3-20200415-3a103f4_%2528Clang_10.0%2529.7z/file)
fftw3-20200415-3a103f4 (GCC 9.3) (http://www.mediafire.com/file/tuj2f5pieqpgo92/fftw3-20200415-3a103f4_%2528GCC_9.3%2529.7z/file)
fftw3-20200415-3a103f4 (ICL 19.1) (http://www.mediafire.com/file/vcsxdqechs2z2e6/fftw3-20200415-3a103f4_%2528ICL_19.1%2529.7z/file)
fftw3-20200415-3a103f4 (MSVC 2019) (http://www.mediafire.com/file/k8abg481f4z0xia/fftw3-20200415-3a103f4_%2528MSVC_2019%2529.7z/file)

You may need to install Microsoft Visual C++ 2015-2019 Redistributable Package (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads) and/or Intel C++ Redistributable Package (https://software.intel.com/en-us/articles/redistributable-libraries-for-intel-c-and-fortran-2020-compilers-for-windows) first.


v3.3.7 is here:

https://forum.videohelp.com/threads/388908-fftw-3-3-7-DLLs

and v3.3.8 is here:

http://www.mediafire.com/file/ag82s51rtip052y/fftw-338.7z/file






EDIT2:
(removed dead link; see above)



EDIT:
libfftw3f-3.dll 3.3.7 (rename it if you wish to FFTW) inside DFTTest Vapoursynth version:

Here (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-DFTTest/releases)

From official mirror: ftp://ftp.fftw.org/pub/fftw/


Old:
I notice on the FFTW site that the current Windows builds are for 3.3.5.
http://fftw.org/install/windows.html

Since then, there are have been a few updates for the 'stable' 3.3.6 verison:
http://fftw.org/release-notes.html
FFTW 3.3.6-pl2
Mar 25th, 2017

Bugfix: MPI Fortran-03 headers were missing in FFTW 3.3.6-pl1.

FFTW 3.3.6-pl1 (withdrawn)
Jan 16th, 2017

Bugfix: FFTW 3.3.6 had the wrong libtool version number, and generated shared libraries of the form libfftw3.so.2.6.6 instead of libfftw3.so.3.*.

FFTW 3.3.6 (withdrawn)
Jan 15th, 2017

The fftw_make_planner_thread_safe() API introduced in 3.3.5 didn't work, and this 3.3.6 fixes it. Sorry about that.
Compilation fixes for IBM XLC.
Compilation fixes for threads on Windows.
fix SIMD autodetection on amd64 when (_MSC_VER > 1500)

media-autobuild_suite doesn't include fftw building.
and the last time I tried to compile something myself, I ended up spending 2 days trying to get everythint together and I don't even remember if I finished or not. :o

EDIT: Can someone please compile and upload? :)
The official site might update once they reach 3.3.7.
I'm pretty sure the version I have currently on my system is one of the deprecated versions.

[GMJCZP]

libfftw3f-3.dll 3.3.7 (rename it if you wish to FFTW) inside DFTTest Vapoursynth version:

Here (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-DFTTest/releases)

[LoRd_MuldeR]

FWIW, here is FFTW 3.3.7 for Win32 (SSE2 build):

fftw-3.3.7-win32.zip (http://www.mediafire.com/file/4oh6rdffa6x2x53/fftw-3.3.7-win32.zip)

[Overdrive80]

From official mirror: ftp://ftp.fftw.org/pub/fftw/

[GMJCZP]

Direct link (32 and 64 bit versions):

Here (http://www.filedropper.com/libfftw3f-3dll337)

[Groucho2004]

I built libfftw3f-3.dll with gcc 4.9.3 (https://www.dropbox.com/s/0waxhi8m47ar09k/libfftw3f-3_gcc493_x86.7z?dl=1) (SSE2, x86) and was surprised to see it perform better than the ICC version that comes with dfttest.

Tested on i5 2500K @4GHz.
Script for testing:
colorbars(width = 1280, height = 720, pixel_type = "yv12").killaudio().assumefps(50, 1).trim(0, 49)
RemoveNoise()

function RemoveNoise(clip video, int "threshold")
{
last = video
sc = MSuper(hpad = 16, vpad = 16)
backward_vector = MAnalyse(sc, isb = true, delta = 1, blksize = 16, overlap = 4, truemotion = false, sadx264 = 4, dct = 1)
forward_vector = MAnalyse(sc, isb = false, delta = 1, blksize = 16, overlap = 4, truemotion = false, sadx264 = 4, dct = 1)
MDegrain1(sc, backward_vector, forward_vector, thSAD = 300)
return last
}


ICC build taken from DFTTest:
Frames processed: 50 (0 - 49)
FPS (min | max | average): 0.742 | 1.529 | 0.760
Memory usage (phys | virt): 51 | 47 MiB
Thread count: 9
CPU usage (average): 25%

gcc 4.9.3 build:
Frames processed: 50 (0 - 49)
FPS (min | max | average): 0.899 | 1.806 | 0.921 (+21%)
Memory usage (phys | virt): 49 | 45 MiB
Thread count: 9
CPU usage (average): 25%

[GMJCZP]

Thank you, brother Marx! Better in speed and memory usage, superb!

Edit: if I missed something, in which part of the script is called dfttest or fft3dfilter?

[Groucho2004]

Thank you, brother Marx! Better in speed and memory usage, superb!

Edit: if I missed something, in which part of the script is called dfttest or fft3dfilter?
The test was with MDegrain where MAnalyse uses FFTW when dct = 1.

However, with dfttest the gcc build is quite a bit slower. So, not recommended for dfttest. With fft3dfilter it's about the same speed.

[Groucho2004]

Interesting. I had compiled FFTW with GCC 7.2.0 as well but only done tests with FFTW's benchmark program (benchf.exe) and DFTTest since I didn't use DCT mode in MVTools. After investigation I find out that MVTools dislike ICC's O3 optimization for unknown reason, change to O2 optimization gives better performance. I also discover that FFTW by default only generate efficient codelets of size 8 in DCT/IDCT transforms. I especially generate codelets of typical sizes 4, 16, 32 and 64 so now it's at least 50% faster than before when blksize is one of them. DFTTest and FFT3DFilter are unaffected since they use real DFT transforms. The 7z file on GitHub is updated.
Nice, the new fftw DLL is almost twice as fast with the script I posted above. :)

[tormento]

Direct link (32 and 64 bit versions)]
The link has expired. Could someone please post a link with a windows working x64 build of 3.3.7?

[Midzuki]

The link has expired. Could someone please post a link with a windows working x64 build of 3.3.7?

https://forum.videohelp.com/threads/388908-fftw-3-3-7-DLLs-for-Windows

[FranceBB]

@Wolfberry... Nice, but if you don't mind, could you build the SSE2 with v141_XP and AVX/AVX2 with the normal v141?

Thank you in advance.

[ChaosKing]

THX for the builds.
o2 is always faster on my Ryzen 1700 (like 0.5 fps faster :D). And for some reason the avx build is the slowest. Tested with dfttest.

[FranceBB]

I tested it, it works fine on WinXP, but I had to include LIBGCC_S_DW2-1.DLL myself in system32 as it was missing.

Thanks. ^_^

[ErazorTT]

@Wolfberry:
I tested the performance of your x64 compilations with dfttest on a mobile i5 Haswell. The one named „simd128+256“ was around 10% faster than the official 3.3.5 Build, all others were 5% slower.
However using fft3dfilter with „simd128+256“ produces an access violation. As far as I know, the instruction set of haswells should be complete up to AVX-256. Did someone manage to get fft3dfilter working with this build, if yes on what system?

[Wolfberry]

@ErazorTT
Confirmed.
It seems that fft3dfilter dislike generic (gcc) 256-bit SIMD optimizations.
Updated original post.

[ErazorTT]

Great, I will test the performance with your new builds when I’m back home.


It seems that fft3dfilter dislike generic (gcc) 256-bit SIMD optimizations.


For me this sounds like some kind of an alignment error.
Can you show the differences of the flags you use for your compilations and the old 128+256?

[ErazorTT]

Ok so all builds apart of simd256 work with fft3dfilter. However the old build simd128+256 appears to have been a wee bit faster than all new builds with dfttest.

Out of curiosity: what do you actually mean by simd 128 or 256 in contrast to sse2/avx/avx2? After all sse2 is a 128 simd and avx/avx2 have additional 256 simd instructions on top of sse2. :confused:

[Wolfberry]

--enable-sse2 enable SSE/SSE2 optimizations
--enable-avx enable AVX optimizations
--enable-avx2 enable AVX2 optimizations
--enable-avx512 enable AVX512 optimizations
--enable-avx-128-fma enable AVX128/FMA optimizations
--enable-kcvi enable Knights Corner vector instructions optimizations
--enable-altivec enable Altivec optimizations
--enable-vsx enable IBM VSX optimizations
--enable-neon enable ARM NEON optimizations
--enable-generic-simd128 enable generic (gcc) 128-bit SIMD optimizations
--enable-generic-simd256 enable generic (gcc) 256-bit SIMD optimizations

Above is some flags that you can use during configuration.
The SIMD builds also enabled SSE2/AVX/AVX2, but I am not sure if it is worth it.
AFAIK, the generic-simd128/256 is some kind of generic AVX(2), not sure how generic they are.

The fftw release note says: enabling them all at the same time is a bad idea, because it increases the planning time for minimal gain
And the more path you enabled, the more fat the dlls will be.
I especially generate codelets of typical sizes 4, 16, 32 and 64 so now it's at least 50% faster than before when blksize is one of them. DFTTest and FFT3DFilter are unaffected since they use real DFT transforms.
The future builds will have these codelets generated as well.

[ErazorTT]

So the generic options are based on the compiler vectorization and optimization.

Have you tried to increase the alignment using --with-incoming-stack-boundary? Like suggested here: https://forum.doom9.org/showthread.php?p=1857180#post1857180

[Wolfberry]

There are a number of guidelines here (http://www.fftw.org/install/windows.html) about building fftw.

The official guideline for building fftw on windows is outdated, I consider BUILD-MINGW32 (https://github.com/FFTW/fftw3/blob/master/support/BUILD-MINGW32.sh) and BUILD-MINGW64 (https://github.com/FFTW/fftw3/blob/master/support/BUILD-MINGW64.sh) and PKGBUILD (https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-fftw/PKGBUILD) as a better reference.

On win32, some versions of gcc assume that the stack is 16-byte aligned, but code compiled with other compilers may only guarantee a 4-byte alignment, resulting in mysterious segfaults.

As quoted, --with-incoming-stack-boundary=2 is only applicable to win32(x86), not x64.
configure:15780: checking whether C compiler accepts -mincoming-stack-boundary=2
configure:15795: gcc -c -mincoming-stack-boundary=2 conftest.c >&5
cc1.exe: error: -mincoming-stack-boundary=2 is not between 3 and 12

[FranceBB]

Thanks for the new build! :D

[almosely]

Hi,

currently I am using AviSynth 2.6.0 MT (SEt) (x86) and almost everytime FFT3DGPU 0.8.2 (with my GeForce GTX 660 Ti); my CPU is an Intel Core i5-3470S (Features: MMX, SSE, SSE-2, SSE-3, SSSE-3, SSE4.1, AVX, DEP, VMX, SMX, SMEP, EM64T, EIST, TM1, TM2, Turbo, AES-NI, RDRAND).

I want to save Energy, therefore I am going to switch to AviSynth+ r1576 (x64) and to FFT3DFilter 2.5 (x64); the latter needs FFT3W. At the moment I have fft3w.dll 3.3.4 (x86) (original FFT3W-build). I testet that one against the original 3.3.5-build, but 3.3.4 is faster (testet with my old environment, AviSynth 2.6.0 x86 MT). The 3.3.7-build (x86, SSE) from Lord_Mulder is not working in my environment, sadly. Another linked 3.3.7-build here (from GMJCZP), is apparently an AVX2-build. The next link (from GMJCZP) to File Dropper is offline. Another one (from Groucho2004) is offline too. The link to another 3.3.7-version (from Midzuki) - there I don't know, which build it is. And the last link (from Wolfberry) to an 3.3.8-build, I cannot find (and it is AVX2, which my CPU does not have, and I don't know what "codelets" means too).

So ... I would be very happy, if someone could compile a 3.3.8-version (with SSE2 and AVX; that's all, my CPU is able to do, I think - respectively that's all, that FFT3W is utilizing, regarding my CPU?) in x86 and x64 version! That would be great :-) I tried to install MinGW, but could not figure out, how to build it on my own (so I uninstalled it).

[Groucho2004]

Hi,

currently I am using AviSynth 2.6.0 MT (SEt) (x86) and almost everytime FFT3DGPU 0.8.2 (with my GeForce GTX 660 Ti); my CPU is an Intel Core i5-3470S (Features: MMX, SSE, SSE-2, SSE-3, SSSE-3, SSE4.1, AVX, DEP, VMX, SMX, SMEP, EM64T, EIST, TM1, TM2, Turbo, AES-NI, RDRAND).

I want to save Energy, therefore I am going to switch to AviSynth+ r1576 (x64) and to FFT3DFilter 2.5 (x64)
A couple of questions/remarks:

What makes you think that you'll save energy switching to the CPU variant of that filter? Did you measure power consumption and, more importantly, task energy (power consumption * time)?

Why do you want to use the very old AVS+ r1576? It does not even support multi-threading. The recent builds of AVS+ can be found here (https://github.com/pinterf/AviSynthPlus/releases).

[StainlessS]

Why do you want to use the very old AVS+ r1576?
Probably because Utlim is still in charge of Avs+ thread, and that is the posted latest on first page.
Pinterf is apparently considering opening his own avs+ thread, where this prob should no longer exist.

[Groucho2004]

Pinterf is apparently considering opening his own avs+ thread, where this prob should no longer exist.Sounds good.

[almosely]

Oh, thanks for the fast replies and the hint for the newer versions of AVS+! Of course I am going with the newer ones then :-)

I did not measure the consumption with a device, but I know the TDPs of my CPU and GPU and watch the consumptions within HWInfo. The GTX uses 15% of 150W in IDLE mode, another 15% when just playing a video through its engine and another 10% for using FFT3DGPU. These are 60 W in total for the GTX 660 Ti, plus 31 W from the CPU (6,5 W IDLE plus 24,5 W while encoding). I switched to QuickSync as Video Engine and used FFT3dFilter (same parameters as fft3dgpu, 32 blocksize and bt=3), let a short clip encode, got 24 fps and a power consumption auf 56 W for both, cpu (encoding) and gpu (idle). The same clip using the GTX video engine and FFT3DGPU (utilizing the gtx) got 29 fps and consumed 91 Watts. So the pure cpu-encoding takes 20% longer, which results in 67 Watts for the same clip against 91 W when I use my gpu in addition. Sadly enough, that the gtx is using 24 W in IDLE, grrr.

[StainlessS]

Quality wise, the CPU version is probably better bet, methinks that GPU FFT3DFilter is now quite old and works in (I think) less precise fixed point calculations,
CPU version updated many times since GPU version. (leastwise, thats what I seem to remember, maybe I'm wrong on that).

[almosely]

I observed a big difference when comparing fft3dfilter against fft3dgpu within AvsPmod at first sight (histogram "luma" activated). But until now I did not go into depth comparing - I just checked if everything is working so I could test the consumptions. Is AvsPmod still working with AVS+? Or is there a better tool like AvsPmod meanwhile? I use it everytime before I start an encoding.

-edit-

Btw, my computer is running aprox. 12 hours a day, almost non-stop, used as a NAS and workstation. So, the IDLE-consumption is there anyway. The pure consumption for the encodings are therefore 31 W (31 W CPU + 0 W GPU) against 61 W (25 W CPU + 36 W GPU) (task energy) - 50% less/more, thats a huge difference.

[Groucho2004]

I did not measure the consumption with a device, but I know the TDPs of my CPU and GPU and watch the consumptions within HWInfo. The GTX uses 15% of 150W in IDLE mode, another 15% when just playing a video through its engine and another 10% for using FFT3DGPU. These are 60 W in total for the GTX 660 Ti, plus 31 W from the CPU (6,5 W IDLE plus 24,5 W while encoding). I switched to QuickSync as Video Engine and used FFT3dFilter (same parameters as fft3dgpu, 32 blocksize and bt=3), let a short clip encode, got 24 fps and a power consumption auf 56 W for both, cpu (encoding) and gpu (idle). The same clip using the GTX video engine and FFT3DGPU (utilizing the gtx) got 29 fps and consumed 90 Watts. So the pure cpu-encoding takes 20% longer, which results in 67 Watts for the same clip against 90 W when I use my gpu in addition. Sadly enough, that the gtx is using 24 W in IDLE, grrr.
OK, so you did (kind of) compare. Fair enough. Stainless is correct that the GPU version is a bit old and that the CPU version is probably better in terms of quality. As for the FFTW DLLs I suggest to use these (https://forum.videohelp.com/threads/388908-fftw-3-3-7-DLLs) (for now).

[almosely]

Thanks for the hint; I already downloaded them (these are the ones from Midzuki), but did not test (an hour ago). If this 3.3.7-version is working, I don't know if it's optimised for SSE2 and AVX - probably not. For now, it would be okay. But I think with SSE2 and AVX my encodings would be finished earlier, so more energy saving - especially the times, when the computer is running for encoding only (sometimes at night), finishing with a shutdown. And of course, sometimes faster would just be nice. And, maybe I could use the sigma2,3,4 parameters of fft3dfilter, which the fft3dGPU-version not provides - sometimes the noise/grain is very different, that could help a lot, while obtaining the same encoding-speed as with a non-SSE2-AVX-build. Maybe someone is compiling a new one, I hope so.

[Wolfberry]

I can compile 3.3.8 with ICC 19.0 in a few days, once it is done, you may do some tests to see if it is any faster.

[almosely]

3.3.8 with SSE2 and AVX (not AVX2) in x86 and x64, please - that would be great! :-) (x86 for safety and test against AVS 2.6.0). In a few days is fine - I also need some time to setup AVS+ and read into it (and have some other urgent jobs to do). Thank you in advance! :-) I will do some different tests, of course.

-edit, because I forgot to mention within my first post -

I did not measure the consumption with a device, but I know the TDPs of my CPU and GPU and watch the consumptions within HWInfo. The GTX uses 15% of 150W in IDLE mode, another 15% when just playing a video through its engine and another 10% for using FFT3DGPU. These are 60 W in total for the GTX 660 Ti, plus 31 W from the CPU (6,5 W IDLE plus 24,5 W while encoding). I switched to QuickSync as Video Engine and used FFT3dFilter (same parameters as fft3dgpu, 32 blocksize and bt=3), let a short clip encode, got 24 fps and a power consumption auf 56 W for both, cpu (encoding) and gpu (idle). The same clip using the GTX video engine and FFT3DGPU (utilizing the gtx) got 29 fps and consumed 91 Watts. So the pure cpu-encoding takes 20% longer, which results in 67 Watts for the same clip against 91 W when I use my gpu in addition. Sadly enough, that the gtx is using 24 W in IDLE, grrr.

Using QuickSync + FFT3DGPU still consumes 90 W, although the CUVID-Engine is not used; so it's not only 10% of the TDP for FFT3DGPU and that way isn't an alternative to prior usage.

HWInfo is showing Watts for the "CPU Package" and Percent only for the "Total GPU Power" auf the GTX.

The default values for the blk-sizes of FFT3DGPU are 32x32, for FFT3dFilter they are 48x48. When I tested FFT3DGPU vs FFT3dFilter, 48x48 was significantly slower than 32x32 and same goes with bt=3 vs bt=5; so I compared these two filter-versions with blk-size 32x32 and bt=3 (even it would probably result in a better quality, if FFT3dFilter would use its bt=5, which the FFT3DGPU is not able to do; even bt=4 is buggy there).

Oh, and to get QuickSync working while having the GTX 660 Ti still in use, was very tricky - so stupid and annoying from microsoft, grrr! After many setbacks and different unveilings (e.g. that the HD Graphics is absolutely not capable of OpenCL even Intel is telling so), the final solution is now, to use the GTX as the first initialized GPU (within BIOS), let the IGPU (HD Graphics 2500) work in "Multi-Monitor" (within BIOS) and let Windows 7 "think", that there is another display device, working in "extended screen"-mode, connected as "VGA" to the HD Graphics (even that there is actually no device connected to), and put that "display" on the top left edge of my real display, so that I am still able to use window-edge-snapping and don't slide out of the screen with the mouse and windows at any display-border. But that way, I can use QuickSync and CUVID (and OpenCL and any other feature of the GTX) parallel, the same time. Till now, that setup is working good - I hope, installing and playing games won't be a problem. But it would be such a waste of potential and energy, to not use QuickSync when it's provided (1 Watt with QS vs 25 Watt with CUVID for pure and "simple" video-decoding is a joke/effrontery!).

[Wolfberry]

FFTW 3.3.8 built with ICC 19.0 now in my signature.

Have fun :)

[almosely]

Coooooool :-) Thank you very much!!!

Just downloaded every generated version. I will test later, today or in 1-2 days, and report my results.

Question: While building FFTW, there's the only option to choose one single SIMD or could it be a combination of more, e.g. SSE2+AVX? ;-)

[ChaosKing]

thx, I get 2-4 fps more now on a Ryzen xD
Will add it to my vs portable fatpack.

[almosely]

FFTW 3.3.5
Jul 31, 2016

- New SIMD support:
-- Power8 VSX instructions in single and double precision. To use, add --enable-vsx to configure.
-- Support for AVX2 (256-bit FMA instructions). To use, add --enable-avx2 to configure.
-- Experimental support for AVX512 and KCVI. (--enable-avx512, --enable-kcvi) This code is expected to work but the FFTW maintainers do not have hardware to test it.
-- Support for AVX128/FMA (for some AMD machines) (--enable-avx128-fma)
-- Double precision Neon SIMD for aarch64. This code is expected to work but the FFTW maintainers do not have hardware to test it.
-- generic SIMD support using gcc vector intrinsics.
- Add fftw_make_planner_thread_safe() API.
- fix #18 (disable float128 for CUDACC).
- fix #19: missing Fortran interface for fftwq_alloc_real.
- fix #21 (don't use float128 on Portland compilers, which pretend to be gcc).
- fix: Avoid segfaults due to double free in MPI transpose.
- Special note for distribution maintainers: Although FFTW supports a zillion SIMD instruction sets, enabling them all at the same time is a bad idea, because it increases the planning time for minimal gain. We recommend that general-purpose x86 distributions only enable SSE2 and perhaps AVX. Users who care about the last ounce of performance should recompile FFTW themselves.

It would be possible ;-)

[almosely]

AVX implies support for all extensions up to SSE4.1)

https://software.intel.com/en-us/forums/intel-isa-extensions/topic/591956

Yeah! :-) So, no another build with SSE2 + AVX is needed.

I am going to test a little bit with AviSynth 2.6.0 so far.

[almosely]

So, I did some tests with AviSynth 2.6.0 (x86), this time with another clip (the fastest results gave: multithreading=off, ncpu=1 (fft3dfilter) and no RequestLinear(); everything else was more slowly; blk-size 32, bt=3).

FFTW 3.3.8 AVX is 4% faster than FFTW 3.3.4 (I guess, it's an AVX-build too, given the filesize 2259 KB), at least with this setup :-) Thank you! And I am very curious about comparing that with AVS+ (x64)!

26.88 fps CUVID
26.54 fps CUVID + FFT3DGPU 0.8.2 (sigma 1.0)
26.41 fps CUVID + FFT3DGPU 0.8.2 (sigma 1.0, sharpen 0.16) (GPU Power 59 W)
26.14 fps CUVID + FFT3DGPU 0.8.4 (sigma 1.0, sharpen 0.16) (GPU Power 59 W)

26.90 fps QuickSync

FFTW 3.3.4 (AVX)
------------------
22.10 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0)
21.81 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0, sharpen 0.16)

FFTW 3.3.8 SSE2
-----------------
22.84 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0)
22.31 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0, sharpen 0.16)

FFTW 3.3.8 AVX
----------------
22.99 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0)
22.39 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0, sharpen 0.16)

Speed Comparison
------------------
100.00 % 120.09 % 115.44 % 26.54 fps CUVID + FFT3DGPU 0.8.2 (sigma 1.0)
083.27 % 100.00 % 096.13 % 22.10 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0) FFTW 3.3.4 (AVX)
086.06 % 103.35 % 099.35 % 22.84 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0) FFTW 3.3.8 SSE2
086.62 % 104.03 % 100.00 % 22.99 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0) FFTW 3.3.8 AVX

Consumption Comparison: CPU+GPU total (workload only)
------------------------------------------------------
100 % 90 Watt (100 % 60 Watt) 60 min 26.54 fps CUVID + FFT3DGPU 0.8.2 (sigma 1.0)
-26 % 67 Watt (-48 % 31 Watt) 72 min 22.10 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0) FFTW 3.3.4 (AVX)
-29 % 64 Watt (-50 % 30 Watt) 69 min 22.99 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0) FFTW 3.3.8 AVX

- edit -

I did some tests with AviSynth+ 0.1.0 r2772 MT (x64) with the same clip and script, and this time with the x64-filter-plugins, of course - compared with formerly QuickSync results of AVS 2.6.0 ...

098,96 % 26.62 fps QuickSync

FFTW 3.3.8 AVX
----------------
099.91 % 22.97 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0)
101,25 % 22.67 fps QuickSync + FFT3dFilter 2.5 (sigma 1.0, sharpen 0.16)

... so, a little bit slower, sadly, except the last one. Maybe with activated MT it will be better.

BUT: I can't use FFT3dFilter - it destroys the luma :-( Regarding this, I posted within the corresponding thread:

https://forum.doom9.org/showpost.php?p=1864190&postcount=53

- edit -

Tested QuickSync + FFT3dFilter 2.5 (sigma 1.0, sharpen 0.16) in MT-mode: Every trial was more slowly (2,4,6 threads, with and without requestlinear;19-21 fps)

[Groucho2004]

Tested QuickSync + FFT3dFilter 2.5 (sigma 1.0, sharpen 0.16) in MT-mode: Every trial was more slowly (2,4,6 threads, with and without requestlinear;19-21 fps)
Multi-threading should speed this up. Post your complete script.

[almosely]

Single-Threaded-Script:
-----------------------

DGSourceIM("clip.dgi", engine=1)

Trim(515, 4291)

Crop(0, 0, -0, -8)

FFT3DFilter(sigma=1.0, beta=1.0, bw=32, bh=32, sharpen=0.16, scutoff=0.27, plane=0, bt=3)

return last


Multi-Threaded-Script:
----------------------

DGSourceIM("clip.dgi", engine=1)

RequestLinear(rlim=50, clim=50) # tested with and without; with has been faster

Trim(515, 4291)

Crop(0, 0, -0, -8)

FFT3DFilter(sigma=1.0, beta=1.0, bw=32, bh=32, sharpen=0.16, scutoff=0.27, plane=0, bt=3)

Prefetch(2) # tested with 1,2,3,4,6

return last


And I am using the "mtmodes.avsi" from here: http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest


Results: AVSMeter 2.8.9 (x64):
------------------------------

1) ST: 44.18 fps (CPU usage: 25%)

2) MT(2): 58.98 fps (CPU usage: 50%) # with RequestLinear(50,50)

3) MT(2): 57.73 fps (CPU usage: 50%) # with RequestLinear(100,100)

4) MT(3): 55.90 fps (CPU usage: 74%) # with RequestLinear(50,50)

5) MT(3): 60.83 fps (CPU usage: 74%) # with RequestLinear(100,100)

6) MT(4): 57.42 fps (CPU usage: 95%) # with RequestLinear(100,100)


Results: Simple x264/x265 Launcher (64-Bit) 2.89.1138:
------------------------------------------------------

1) 22.49 fps

2) 21.51 fps

5) 20.53 fps


The corresponding x264.exe line:
--------------------------------
--output-depth 8 --crf 18.0 --preset medium --tune film --trellis 2 --direct auto --me umh --partitions all --vbv-maxrate 24000 --vbv-bufsize 30000 --b-adapt 2 --bframes 3 --merange 16 --ref 3 --keyint 240 --subme 10 --aq-mode 1 --sar 1:1 --rc-lookahead 40 --output "clip.mkv" --frames 3777 --demuxer y4m --stdin y4m -


And sometimes, the MT-Job crashes within Simple Launcher. To be up-to-date, I updated the Simple Launcher a few hours ago, and with this new version, the fps got less too (from 22.67 fps to 22.49 fps).

I let AVS+ autoload all plugins and sripts; I put everything I need into the corresponding "plugins64"-folder:

addgrain.avs
AddGrainC.dll
avstp.dll
CheckTopFirst.avsi
colormatrix.dll
CompTest.avsi
DGDecodeIM.dll
DGDecodeNV.dll
dither.avsi
dither.dll
fft3dfilter.dll
FFT3dGPU.dll
fft3dgpu.hlsl
libmfxsw64.dll
masktools2.dll
mt_xxpand_multi.avsi
mtmodes-rev.850.avsi
RgTools.dll
TIVTC.dll

These are the installed filter and script-versions:

AddGrainC 1.7.1 (25-11-2013)
ColorMatrix 2.5 (20-03-2010)
DGDecNV 2052 (30-07-2016)
DGDecodeIM beta50 (10-10-2015)
Dither tools 1.27.2 (30-12-2015)
FFT3DFilter 2.5 (02-07-2018)
FFT3dGPU 0.8.4 (21-11-2018)
FFTW 3.3.8 (28-05-2018)
MaskTools2 2.2.18 (05-09-2018)
RgTools 0.97 (02-07-2018)
TIVTC 1.0.11 (23-03-2018)

[Groucho2004]

I ran a few tests with your script, it seems that fft3dfilter doesn't scale well in mt setups. I vaguely remember that it has adaptive mt mode registration depending on parameter values. The bottleneck could also be the FFTW library.

[almosely]

Version 2.3 - February 21, 2017
- apply current avs+ headers
- 10-16 bits and 32 bit float colorspace support in AVS+
- Planar RGB support
- look for libfftw3f-3.dll first, then fftw3.dll
- inline asm ignored on x64 builds
- pre-check: if plane to process for greyscale is U and/or V then returns original clip
- auto register MT mode for avs+: MT_SERIALIZED
- autoscale sigma and smin/smax parameter from 8 bit scale if colorspace is different
Version 2.4 - June 08, 2017
- some inline asm (not all) ported to simd intrisics, helps speedup x64 mode, but some of them faster also on x86.
- intrinsics bt=0
- intrinsics bt=2, degrid=0, pfactor=0
- intrinsics bt=3 sharpen=0/1 dehalo=0/1
- intrinsics bt=3
- Adaptive MT settings for Avisynth+: MT_SERIALIZED for bt==0 (temporal), MT_MULTI_INSTANCE for others
- Copy Alpha plane if exists
- reentrancy checks against bad multithreading usage
Note: for properly operating in MT_SERIALIZED mode in Avisynth MT, please use Avs+ r2504 or better.
Version 2.5 - July 02, 2018
- Change 32 bit float formar: U/V chroma center to zero instead of 0.5 to match Avisynth+ r2728

Yes, it has. I use bt=3, so mt-mode 2 will be used.

But I think I have to use AVS+ in 32-bit-mode or migrate back to AVS 2.6.0 MT (SEt), because the FFT3dFilter 2.5 (and 2.4 and 2.3) is messing with the luma, even when the filter is only in the filter-chain without adjustments. It looks like FFT3dFilter dithers and brightens and darkens the image, just when in the filter-chain included - it seems to be an issue with colorspace- or bit-depth-conversion to me. Maybe the old 2.1.1 version (2007) from Fizick is working right and I can use that one (but I did not find any 64-bit version of it and don't know if it's working with AVS+). FFT3DGPU does work fine, regarding that. And AVS 2.6.0 did not crash with this script, wether in ST- nor in MT-Mode.

[Groucho2004]

Maybe the old 2.1.1 version (2007) from Fizick is working right and I can use that one (but I did not find any 64-bit version of it and don't know if it's working with AVS+).I made a 64 bit build of 2.1.1 (https://www.dropbox.com/s/gy7pzo8pmmnky39/fft3dfilter211_32_64.7z?dl=1) some time ago. You're welcome to try it. It does work just fine with AVS+.

[almosely]

Cool, thank you! :-) ... but, I just tried: Still not working right. Must be a problem of AVS+ (x64) :-(

-edit-

I observed a big difference when comparing fft3dfilter against fft3dgpu within AvsPmod at first sight (histogram "luma" activated).

Grml ... Obviously it's a difference in general between FFT3dFilter and FFT3DGPU :-( At that point I had'nt installed AVS+ and still tested with AVS 2.6.0. But how could it be, that nobody realised that problem before? Perhaps I should check every parameter - maybe a default-value is set wrong?

[almosely]

So, after a long term of testing AVS 2.6.0 MT (SEt) (x86) vs. AviSynth+ 0.1.0 r2772 MT (x64) I came to the conclusion, that AVS+ is faster in general - and, at least with my filter-collection - same/more stable.

With the newest available versions of my filters, VC Redist 2017 and AVS+, the encoding frame-rate went up from 16.76 fps to 16.99 fps and the one from AVSMeter 2.8.9 from 40.37 to 43.49 fps (with one common test-clip).

But I discovered something more and that I will post within the corresponding AVS+ thread in a few minutes:

https://forum.doom9.org/showthread.php?t=168856&page=225

[ciko5]

hello,

i need fftw3.dll for x64 bit and x32 bit fftw-3.3.8 or fftw-3.3.7 etc. or what do you have. My OS is Windows 10 64 bit

Sincerely.

[filler56789]

hello,

i need fftw3.dll for x64 bit and x32 bit fftw-3.3.8 or fftw-3.3.7 etc. or what do you have.

v3.3.7 is here:

https://forum.videohelp.com/threads/388908-fftw-3-3-7-DLLs

and v3.3.8 is here:

http://www.mediafire.com/file/ag82s51rtip052y/fftw-338.7z/file

My OS is Windows 10 64 bit.

Good luck with that :D

[ciko5]

v3.3.7 is here:

https://forum.videohelp.com/threads/388908-fftw-3-3-7-DLLs

and v3.3.8 is here:

http://www.mediafire.com/file/ag82s51rtip052y/fftw-338.7z/file



Good luck with that :D

thank you so much:) i have a question. If i rename libfftw3f-3.dll to fftw3.dll can i use it? because fft3dfilter.dll needs fftw3.dll.

[filler56789]

thank you so much:) i have a question. If i rename libfftw3f-3.dll to fftw3.dll can i use it? because fft3dfilter.dll needs fftw3.dll.

Yes, just rename it.