newer FFTW DLL's Windows?

[kedautinh12]

FFTW 3.3.8 built with ICC 19.0 now in my signature.

Have fun :)

I don't see in your signature

[FranceBB]

I don't see in your signature

Just use this FFTW 3.3.8 (http://www.mediafire.com/file/ag82s51rtip052y/fftw-338.7z/file)

[Forteen88]

Just as a reminder:
In Windows10 64-bit, for AviSynthPlus, when I put libfftw3f-3.dll (64-bit version) in the directory,
C:\Program Files\AviSynthPlus\plugins64
it didn't work.
But when I put it in the directory,
C:\Program Files\AviSynthPlus\plugins64+
it worked!

[Selur]

getting:
'fftw: alloc.c:29: assertion failed: p'
when using:
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\LoadDll.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\AddGrainC.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\dfttest.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\EEDI2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\eedi3.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\FFT3DFilter.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\mvtools2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\TDeint.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\RgTools.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\PlanarTools.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MedianBlur2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\nnedi3.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\hqdn3d.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\FFT3dGPU.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\dither.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\KNLMeansCL.dll")
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\yadif.dll")
LoadDLL("I:\Hybrid\32bit\AVISYN~1\libfftw3f-3.dll")
LoadDLL("I:\Hybrid\32bit\AVISYN~1\d3dx9_30.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\QTGMC.avsi")
Import("I:\Hybrid\32bit\avisynthPlugins\SMDegrain.avsi")
Import("I:\Hybrid\32bit\avisynthPlugins\AnimeIVTC.avsi")
Import("I:\Hybrid\32bit\avisynthPlugins\dither.avsi")
Import("I:\Hybrid\32bit\avisynthPlugins\TemporalDegrain-v2.avsi")
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: F:\TestClips&Co\files\interlaceAndTelecineSamples\interlaced\proRes_interlaced_1080_pcm.mov
# input color sampling YUY2
# input luminance scale tv
FFVideoSource("F:\TESTCL~1\files\INTERL~1\INTERL~1\PRORES~1.MOV",cachefile="E:\Temp\mov_8679e2db13be0eb3ee9aa34b1fc35571_853323747_1_0.ffindex",colorspace="YUY2")
# current resolution: 1920x1080
# deinterlacing
ConvertToYUY2(interlaced=true)
AssumeTFF()
QTGMC(Preset="Fast", ediThreads=2)
SelectEven()
# cropping
Crop(22,0,-14,-8)# 1884x1072
# filtering
# grain handling
# callConvertTo with:
ConvertToYV12(interlaced=false)
TemporalDegrain2() # <- usees fftw3
# letterboxing
AddBorders(18,4,18,4)# resolution: 1884x1072 -> 1920x1080
ConvertToRGB32(matrix="Rec709")
PreFetch(8)
return last
only thing regarding this I found was https://github.com/FFTW/fftw3/issues/17
I tried the 3.3.8 build from filler56789, the 3.3.5 build from http://fftw.org/install/windows.html and the 3.3.7 build from https://forum.videohelp.com/threads/388908-fftw-3-3-7-DLLs (using Avisynth+ 32bit on Windows 10pro)
-> is there another build I could try?

Cu Selur

[StainlessS]

getting:
'fftw: alloc.c:29: assertion failed: p'


Any body make any sense out of this, from 3.3.8 source

///////////////////////
// # fftw-3.3.8 //
///////////////////////


// # alloc.c

#include "kernel/ifftw.h"

void *X(malloc_plain)(size_t n)
{
void *p;
if (n == 0)
n = 1;
p = X(kernel_malloc)(n);
CK(p); // # alloc.c line 29

#ifdef MIN_ALIGNMENT
A((((uintptr_t)p) % MIN_ALIGNMENT) == 0);
#endif

return p;
}

void X(ifree)(void *p)
{
X(kernel_free)(p);
}

void X(ifree0)(void *p)
{
/* common pattern */
if (p) X(ifree)(p);
}


########################################################################

// # assert.c

#include "kernel/ifftw.h"
#include <stdio.h>
#include <stdlib.h>

void X(assertion_failed)(const char *s, int line, const char *file)
{
fflush(stdout);
fprintf(stderr, "fftw: %s:%d: assertion failed: %s\n", file, line, s);
#ifdef HAVE_ABORT
abort();
#else
exit(EXIT_FAILURE);
#endif
}

########################################################################

// # kernel\ifftw.h

/* determine precision and name-mangling scheme */
#define CONCAT(prefix, name) prefix ## name
#if defined(FFTW_SINGLE)
typedef float R;
# define X(name) CONCAT(fftwf_, name)
#elif defined(FFTW_LDOUBLE)
typedef long double R;
# define X(name) CONCAT(fftwl_, name)
# define TRIGREAL_IS_LONG_DOUBLE
#elif defined(FFTW_QUAD)
typedef __float128 R;
# define X(name) CONCAT(fftwq_, name)
# define TRIGREAL_IS_QUAD
#else
typedef double R;
# define X(name) CONCAT(fftw_, name)
#endif

// #

...

// #


/* define HAVE_SIMD if any simd extensions are supported */
#if defined(HAVE_SSE) || defined(HAVE_SSE2) || \
defined(HAVE_AVX) || defined(HAVE_AVX_128_FMA) || \
defined(HAVE_AVX2) || defined(HAVE_AVX512) || \
defined(HAVE_KCVI) || \
defined(HAVE_ALTIVEC) || defined(HAVE_VSX) || \
defined(HAVE_MIPS_PS) || \
defined(HAVE_GENERIC_SIMD128) || defined(HAVE_GENERIC_SIMD256)
#define HAVE_SIMD 1
#else
#define HAVE_SIMD 0
#endif

extern int X(have_simd_sse2)(void);
extern int X(have_simd_avx)(void);
extern int X(have_simd_avx_128_fma)(void);
extern int X(have_simd_avx2)(void);
extern int X(have_simd_avx2_128)(void);
extern int X(have_simd_avx512)(void);
extern int X(have_simd_altivec)(void);
extern int X(have_simd_vsx)(void);
extern int X(have_simd_neon)(void);

// #

...

// #

/*-----------------------------------------------------------------------*/
/* alloca: */
#if HAVE_SIMD
# if defined(HAVE_KCVI) || defined(HAVE_AVX512)
# define MIN_ALIGNMENT 64
# elif defined(HAVE_AVX) || defined(HAVE_AVX2) || defined(HAVE_GENERIC_SIMD256)
# define MIN_ALIGNMENT 32 /* best alignment for AVX, conservative for
* everything else */
# else
/* Note that we cannot use 32-byte alignment for all SIMD. For
example, MacOS X malloc is 16-byte aligned, but there was no
posix_memalign in MacOS X until version 10.6. */
# define MIN_ALIGNMENT 16
# endif
#endif


// #

...

// #

/* assert.c: */
IFFTW_EXTERN void X(assertion_failed)(const char *s,
int line, const char *file);

/* always check */
#define CK(ex) \
(void)((ex) || (X(assertion_failed)(#ex, __LINE__, __FILE__), 0))

#ifdef FFTW_DEBUG
/* check only if debug enabled */
#define A(ex) \
(void)((ex) || (X(assertion_failed)(#ex, __LINE__, __FILE__), 0))
#else
#define A(ex) /* nothing */
#endif

extern void X(debug)(const char *format, ...);
#define D X(debug)

[LoRd_MuldeR]

Well, there is an assertion checking that pointer 'p' is not NULL. That is what the 'CK' macro does. And this assertion obviously failed, which means that 'p' was NULL.

Since 'p' was assigned to the result of kernel_malloc(), it looks like the memory allocation failed, i.e. it returned NULL.

We don't see the details of kernel_malloc() here, but a typical cause for malloc operations to return NULL is "out of memory" situation. This certainly applies to a standard malloc().

[StainlessS]

Thankyou my lord,

thats what I thought, but all them there void X(...) whotsits left me a little perturbed.

details of the kernel_malloc() below in kalloc.c


#include "kernel/ifftw.h"

#if defined(HAVE_MALLOC_H)
# include <malloc.h>
#endif

/* ``kernel'' malloc(), with proper memory alignment */

#if defined(HAVE_DECL_MEMALIGN) && !HAVE_DECL_MEMALIGN
extern void *memalign(size_t, size_t);
#endif

#if defined(HAVE_DECL_POSIX_MEMALIGN) && !HAVE_DECL_POSIX_MEMALIGN
extern int posix_memalign(void **, size_t, size_t);
#endif

#if defined(macintosh) /* MacOS 9 */
# include <Multiprocessing.h>
#endif

#define real_free free /* memalign and malloc use ordinary free */

#define IS_POWER_OF_TWO(n) (((n) > 0) && (((n) & ((n) - 1)) == 0))
#if defined(WITH_OUR_MALLOC) && (MIN_ALIGNMENT >= 8) && IS_POWER_OF_TWO(MIN_ALIGNMENT)
/* Our own MIN_ALIGNMENT-aligned malloc/free. Assumes sizeof(void*) is a
power of two <= 8 and that malloc is at least sizeof(void*)-aligned.

The main reason for this routine is that, as of this writing,
Windows does not include any aligned allocation routines in its
system libraries, and instead provides an implementation with a
Visual C++ "Processor Pack" that you have to statically link into
your program. We do not want to require users to have VC++
(e.g. gcc/MinGW should be fine). Our code should be at least as good
as the MS _aligned_malloc, in any case, according to second-hand
reports of the algorithm it employs (also based on plain malloc). */
static void *our_malloc(size_t n)
{
void *p0, *p;
if (!(p0 = malloc(n + MIN_ALIGNMENT))) return (void *) 0;
p = (void *) (((uintptr_t) p0 + MIN_ALIGNMENT) & (~((uintptr_t) (MIN_ALIGNMENT - 1))));
*((void **) p - 1) = p0;
return p;
}
static void our_free(void *p)
{
if (p) free(*((void **) p - 1));
}
#endif

void *X(kernel_malloc)(size_t n)
{
void *p;

#if defined(MIN_ALIGNMENT)

# if defined(WITH_OUR_MALLOC)
p = our_malloc(n);
# undef real_free
# define real_free our_free

# elif defined(__FreeBSD__) && (MIN_ALIGNMENT <= 16)
/* FreeBSD does not have memalign, but its malloc is 16-byte aligned. */
p = malloc(n);

# elif (defined(__MACOSX__) || defined(__APPLE__)) && (MIN_ALIGNMENT <= 16)
/* MacOS X malloc is already 16-byte aligned */
p = malloc(n);

# elif defined(HAVE_MEMALIGN)
p = memalign(MIN_ALIGNMENT, n);

# elif defined(HAVE_POSIX_MEMALIGN)
/* note: posix_memalign is broken in glibc 2.2.5: it constrains
the size, not the alignment, to be (power of two) * sizeof(void*).
The bug seems to have been fixed as of glibc 2.3.1. */
if (posix_memalign(&p, MIN_ALIGNMENT, n))
p = (void*) 0;

# elif defined(__ICC) || defined(__INTEL_COMPILER) || defined(HAVE__MM_MALLOC)
/* Intel's C compiler defines _mm_malloc and _mm_free intrinsics */
p = (void *) _mm_malloc(n, MIN_ALIGNMENT);
# undef real_free
# define real_free _mm_free

# elif defined(_MSC_VER)
/* MS Visual C++ 6.0 with a "Processor Pack" supports SIMD
and _aligned_malloc/free (uses malloc.h) */
p = (void *) _aligned_malloc(n, MIN_ALIGNMENT);
# undef real_free
# define real_free _aligned_free

# elif defined(macintosh) /* MacOS 9 */
p = (void *) MPAllocateAligned(n,
# if MIN_ALIGNMENT == 8
kMPAllocate8ByteAligned,
# elif MIN_ALIGNMENT == 16
kMPAllocate16ByteAligned,
# elif MIN_ALIGNMENT == 32
kMPAllocate32ByteAligned,
# else
# error "Unknown alignment for MPAllocateAligned"
# endif
0);
# undef real_free
# define real_free MPFree

# else
/* Add your machine here and send a patch to fftw@fftw.org
or (e.g. for Windows) configure --with-our-malloc */
# error "Don't know how to malloc() aligned memory ... try configuring --with-our-malloc"
# endif

#else /* !defined(MIN_ALIGNMENT) */
p = malloc(n);
#endif

return p;
}

void X(kernel_free)(void *p)
{
real_free(p);
}


Selur, you take any note of mem usage in eg Task Manager when your script is called, or use G2K4 tools (avsMeter) ?

[Selur]

Hmm,.. now I just get an access violation (when using Prefetch > 3), but that is probably due to the memory usage which hits the 32bit limit. (with Prefetch 3 script already uses ~2378MB according to avsmeter)
Thanks for that build. :)

Cu Selur

[tormento]

URL=https://www.mediafire.com/file/ueof4d9d6y3y589/fftw3-20200404-ef15637.7z/file]fftw3-20200404-ef15637[/URL]
Thanks! What compiler did you use?

[real.finder]

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.

thanks, will try them, since https://forum.doom9.org/showthread.php?p=1907464#post1907464 seems not as fast as v3.3.8 from https://forum.doom9.org/showthread.php?p=1883313#post1883313

[real.finder]

now all them (Except ICL 19.1) seems as fast as v3.3.8 from https://forum.doom9.org/showthread.php?p=1883313#post1883313

but ICL 19.1 one is the fastest for now!

[tormento]

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

Great job!

:thanks:

[Zetti]

Link for the new build is invalid.

[foxyshadis]

Other than build fixes and the very rare bugfix, the last meaningful change to FFTW was in 2015, so other than hunting down and fixing a bug yourself, a newer build isn't likely to mean anything anyway.

[almosely]

Thanks, HolyWu!

I tested all your versions against each other and against my old compile from Wolfberry (3.3.8 AVX ICC 19.0) (https://forum.doom9.org/showthread.php?p=1864138#post1864138).

- edit -

I just uploaded Wolfberry's build here (http://www.mediafire.com/file/hwu5acm7s60tlt5/FFTW_3.3.8_%25282019-01-29%2529_ICC_19.0.7z/file), if someone needs it. There are multiple files for different SIMD versions (SSE2, AVX, AVX2) for x64 and x86.

- edit -

What is your version exactly, HolyWu? 3.3.8 with SSE2 and AVX enabled?

Originally Posted by http://www.fftw.org/release-notes.html
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.

I am running Windows 10 Pro (x64). I have an Intel Core i7-3770 CPU with 16 GB DDR3 1333 RAM (Dual-Channel).

My test-script was:

DGSource("test.dgi", crop_l=0, crop_r=0, crop_t=0, crop_b=0, deinterlace=0, use_top_field=true, use_pf=true)

Trim(0, 1000)

RequestLinear(rlim=100, clim=100)

neo_fft3d(sigma=1.0, beta=1.0, bw=32, bh=32, sharpen=0.040, scutoff=0.01, y=3, u=2, v=2, bt=5)

Prefetch(2) # 3,4 and without prefetch

return last

My test-clip was:

1280 x 720 (tennis training at roland garros)

Additionally to the following Intel C++ redists (I updated from 15 to 19 for this test) are all the (latest) versions of MS Visual C++ redists from 2005 to 2019 installed.
Sadly, the newest Intel C++ version (2020 19.1) is not downloadable (Intel-Link is broken).

https://i.imgur.com/0Jkf1rw.png

... so, for me, GCC 9.3 was the fastest and least cpu consuming version of all.

Oh, and I used AviSynth+ 3.5.1 r3106 (x64) and AVSMeter 2.9.9.1 (x64).

- edit -

Meanwhile I got the newest Intel C++ 2020 version from here (https://forum.doom9.org/showthread.php?p=1911130#post1911130) and made two further tests (as seen in the newer table above). GCC 9.3 is still the fastest and most efficient build.

[almosely]

Could it be possible that the GCC compile is bypassing the injected Spectre and Meltdown protection microcode somehow, while the ICC and MSVC versions don't?

https://i.imgur.com/yYkblkH.png

[stax76]

I would like to suggest that plugin authors using this library support loading the DLLs from the path environment variable (LoadLibrary searches in path by default), otherwise GUIs are forced to put all plugins and DDLs in the same folder if they want to support avisynth and vapoursynth portable mode. This is extremely messy, there is a workaround using soft links that generally works, it's just not the best possible solution, needs extra code and requires to identify all plugins which use the library, in case of staxrip not easy as it includes 152 plugins:

AddGrainC, adjust, AnimeIVTC, AutoAdjust, Average, AviSynthShader AVSI, AviSynthShader DLL, AvsResize, AVSTP, AWarpSharp2, BM3D, Bwdif, checkmate, CNR2, CNR2, CropResize, CTMF, d2vsource, DAA3Mod, DCTFilter, DCTFilter, DCTFilter-f, Deblock, Deblock, Deblock_QED, DeblockPP7, Decomb, DegrainMedian, DeGrainMedian, DehaloAlpha, DeNoise Histogram, DeNoiseMD, DeNoiseMF, DePan, DePanEstimate, DFTTest, DFTTest, DGDecodeNV, Dither, Dither AVSI, Dither DLL, DSS2mod, edi_rpow2 AVSI, EEDI2, EEDI2, EEDI3, eedi3_resize, EEDI3m, ffms2, FFT3DFilter, FFT3DFilter, FFT3DGPU, FineDehalo, finesharp, FineSharp, FixTelecinedFades, flash3kyuu_deband, FluxSmooth, FluxSmooth, fmtconv, FrameRateConverter AVSI, FrameRateConverter DLL, fvsfunc, G41Fun, GradFun2DB, GradFun2DBmod, havsfunc, HQDeringmod, HQDN3D, HQDN3D, InterFrame, IT, JincResize, JPSDR, KNLMeansCL, Lazy Utilities, LSFmod, L-SMASH-Works, MAA2Mod, masktools2, mcdegrainsharp, mClean, MCTemporalDenoise, MedianBlur2, MiniDeen, MipSmooth, modPlus, MPEG2DecPlus, MSharpen, msmoosh, MT Expand Multi, MultiSharpen, muvsfunc, mvmulti, mvsfunc, mvtools, mvtools2, mvtools-sf, NicAudio, nnedi3, nnedi3 AVSI, nnedi3_rpow2, nnedi3cl, nnedi3x AVSI, Oyster, Plum, psharpen, pSharpen, QTGMC, resamplehq, ResizeX, RgTools, Sangnom, SangNom2, scenechange, SMDegrain, SmoothAdjust, SmoothD2, SmoothD2c, SVPFlow 1, SVPFlow 1, SVPFlow 2, SVPFlow 2, taa, TCanny, TDeint, TDeintMod, TEMmod, TemporalMedian, temporalsoften, TimeCube, TIVTC, TMM2, TNLMeans, TTempSmooth, UnDot, VagueDenoiser, VagueDenoiser, VapourSource, vcfreq, vcmod, vcmove, Vine, vinverse, vsCube, VSFilterMod, W3FDIF, xNLMeans, Yadifmod, yadifmod2, YFRC, znedi3

[ChaosKing]

Why can't you keep all plugins in one folder? I mean avisynth is doing the same...

In staxrip you could use the loaddll plugin to load FFTW from anywhere I think.

[stax76]

If every plugin would only be exactly one file then it would be OK, if there are more files like support DLLs and help files then you need a folder otherwise it's messy.

Every good extension system supports folders:

https://mpv.io/manual/master/#script-location

https://github.com/stax76/mpv.net/blob/master/Manual.md#extensions

Every tool including plugins has its own folder in staxrip.

In staxrip you could use the loaddll plugin to load FFTW from anywhere I think.

This might be an alternative to symbolic links, didn't really know it.

[tormento]

If every plugin would only be exactly one file then it would be OK, if there are more files like support DLLs and help files then you need a folder otherwise it's messy.
Just rename them to follow plugin naming.

[tormento]

Could it be possible that the GCC compile is bypassing the injected Spectre and Meltdown protection microcode somehow, while the ICC and MSVC versions don't?
I have disabled all of them... useless here.

[nevcairiel]

I would like to suggest that plugin authors using this library support loading the DLLs from the path environment variable (LoadLibrary searches in path by default)

Thats a bad idea for security purposes, which opens you up to DLL injection attacks of all sorts.

Its much better to determine where a plugin lives and load it specifically, instead of hoping the right one gets loaded from $somewhere. And not only for FFTW but in general all DLL loading.

[Groucho2004]

I would like to suggest that plugin authors using this library support loading the DLLs from the path environment variable (LoadLibrary searches in path by default)Every (Avisynth) plugin I know that uses FFTW loads the DLL by using LoadLibrary() or LoadLibraryEx().
Am I missing something?

[stax76]

Thats a bad idea for security purposes, which opens you up to DLL injection attacks of all sorts.

Its much better to determine where a plugin lives and load it specifically, instead of hoping the right one gets loaded from $somewhere. And not only for FFTW but in general all DLL loading.

Isn't then the whole path thing flawed altogether? Many tools just call LoadLibrary("avisynth.dll") and portable mode works because LoadLibrary searches path and it's a simple rule many devs agree and appreciate. If it's so bad then why is that the default behavior of LoadLibrary and dotnet? How are you going to make avisynth and vapoursynth portable work without putting all DLLs and executables in one folder creating a giant mess? What if executables require different versions of DLLs like ffmpeg libraries, please note that a GUI like staxrip or hybrid includes up to twenty tools that read avs and vpy and conflicts are almost certain. In staxrip I modify the path env par putting the locations on top, that makes DLL injection attacks impossible, right?

Every (Avisynth) plugin I know that uses FFTW loads the DLL by using LoadLibrary() or LoadLibraryEx().
Am I missing something?

There are some, I use soft links to workaround it, probably I miss some, got to check that using the CLI of Dependency Walker, look here:

https://github.com/staxrip/staxrip/blob/master/General/GlobalClass.vb#L1395

[Groucho2004]

There are some, I use soft links to workaround it, probably I miss some, got to check that using the CLI of Dependency WalkerYou won't find them with DepWalker, they are delay-loaded.

[Groucho2004]

If you want portable, have a look at this (https://forum.doom9.org/showthread.php?p=1867417#post1867417).

[stax76]

LoadDLL maybe is cleaner than soft links, I think I will try this, need to look how to do it with python.

I didn't even know delay load is possible, runtime linking has still advantages in regard of versioning?

I use it here:

https://github.com/staxrip/staxrip/blob/master/FrameServer/VapourSynthServer.cpp#L56

nvenc code is similar.

I can wait for bug reports, some tips which else plugin might be affected would be a great help, so far I'm aware of three vapoursynth filters:

DFTTest
BM3D
DCTFilter

[Groucho2004]

I didn't even know delay load is possible, runtime linking has still advantages in regard of versioning?If you use LoadLibrary() in a plugin it's considered delay-load. Loading the DLL won't happen until the function in which you attempt to load the external DLL (fftw) is called.

[stax76]

In case you are not aware of, LoadPlugin in VapourSynth has an altsearchpath parameter which does what you want when set to True.

It would find DFTTest in path but also FFTW being in different path folder than DFTTest?

[nevcairiel]

If it's so bad then why is that the default behavior of LoadLibrary and dotnet?

Legacy. Many things were designed a long time ago, and one needs to take care today to make them secure.
Microsoft doesn't typically break existing code, instead they expect you do use it differently.


How are you going to make avisynth and vapoursynth portable work without putting all DLLs and executables in one folder creating a giant mess?

Security tops your concerns. Just because something is hard is not a reason to throw security out of the window.

If you know where your AviSynth (etc) folder is, which you should, even in portable, then you can just dynamically build pathes, or even use SetDllDirectory/AddDllDirectory (with care, it has its own problems).

[stax76]

If you use LoadLibrary() in a plugin it's considered delay-load. Loading the DLL won't happen until the function in which you attempt to load the external DLL (fftw) is called.

There is some automatic delay load using a linker flag allowing working with lib file? That would be more convenient than working with GetProcAddress if it doesn't have a versioning disadvantage.

Security tops your concerns. Just because something is hard is not a reason to throw security out of the window.

If you know where your AviSynth (etc) folder is, which you should, even in portable, then you can just dynamically build pathes, or even use SetDllDirectory (with care, it has its own problems).

But I don't have control of all the tools that read avs and vpy, most support path.

then you can just dynamically build pathes

You mean move large exe and dll files around?

[stax76]

@HolyWu

It's working and didn't require rewriting code, thanks!

[almosely]

I built from git commit 3a103f4, commited on 2020/4/15. I enabled SSE2, AVX, AVX2, and AVX512.

Thanks! :-)

[Groucho2004]

If you use LoadLibrary() in a plugin it's considered delay-load. Loading the DLL won't happen until the function in which you attempt to load the external DLL (fftw) is called.

There is some automatic delay load using a linker flag allowing working with lib file? That would be more convenient than working with GetProcAddress if it doesn't have a versioning disadvantage.I actually got it backwards. Delay-load is using the MS linker flag /delayload which means that you don't have to use LoadLibrary and GetProcAddress.
I have however never seen this used in any plugin that uses the FFTW DLL, they all use LoadLibrary and GetProcAddress.

[LoRd_MuldeR]

Delay loading (https://docs.microsoft.com/en-us/cpp/build/reference/specifying-dlls-to-delay-load?view=vs-2019) is a feature of the Microsoft compiler/linker.

It will generate a "stub" function for each imported function, which – when it is called for the first time – loads the required DLL (if not loaded yet) and then resolves the actual address of the function. If anything goes wrong (e.g. the required DLL can not be loaded, or required entry point is missing), then the "stub" code will throw a structured exception – which may be caught and handled by the application code, e.g to implement optional dependencies.

Note that, under the hood, the "stub" code generated by delay loading still uses the standard LoadLibrary() and GetProcAddress() functions. The "advantage" of delay loading is that you don't have to write the DLL loading code manually.

But: You have to keep in mind that delay loading does not "magically" resolve the path to the DLL for you! It simply will invoke LoadLibrary() with the basename of the required DLL, so that the Standard Search Order for Desktop Applications (https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications) applies. Consequently, if the DLL does not happen to be located in one of the directories that Windows searches by default, then delay-loading the DLL is going to fail! Consequently, even when delay loading is used, it often still is necessary to explicitly pre-load the DLL, by manually invoking LoadLibrary() with the absolute path to the DLL – before any function from that DLL is invoked for the first time. Or by setting up the DLL search path via the SetDllDirectory() function.

[stax76]

Thanks for the explanation.

[almosely]

I made some new benchmarks.

https://i.imgur.com/LlsMHqZ.png

- edit -

Hm, I thought I had written everything important in my previous bench-post (https://forum.doom9.org/showthread.php?p=1911115#post1911115).

I am using an Intel Core i7-3770 (https://ark.intel.com/content/www/us/en/ark/products/65719/intel-core-i7-3770-processor-8m-cache-up-to-3-90-ghz.html) and Windows 10 Pro (x64) up-to-date.

Script

DGSource("test.dgi", crop_l=0, crop_r=0, crop_t=0, crop_b=0, deinterlace=0, use_top_field=true, use_pf=true)

Trim(0, 1000)

RequestLinear(rlim=100, clim=100)

neo_fft3d(sigma=1.0, beta=1.0, bw=32, bh=32, sharpen=0.040, scutoff=0.01, y=3, u=2, v=2, bt=5)

# FFT3DFilter(sigma=1.0, beta=1.0, bw=32, bh=32, sharpen=0.040, scutoff=0.01, plane=0, bt=5)

Prefetch(2) # 3, 4 and without prefetch

return last

Clip

1280 x 720 - 29.97 fps - Tennis-Training at Roland Garros

https://i.imgur.com/wuJTcFx.jpg

Programs and plug-ins in use (x64)

- AviSynth+ 3.5.1
- Simple x264/x265 Launcher 2.96.1198
- x264 core:160 r3000 33f9e14 (provided by Simple Launcher)
- AVSMeter 2.9.9.1
- DGDecNV 2052
- TIVTC 1.0.14 (for RequestLinear)
- neo_FFT3D r7
- FFT3DFilter 2.6

Simple Launcher (x264) parameter

"...\Simple x264 Launcher\toolset\x64\x264_x64.exe" --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 5 --merange 24 --ref 5 --keyint 300 --subme 10 --aq-mode 1 --sar 1:1 --rc-lookahead 40 --output "...\test.mkv" --frames 1001 --demuxer y4m --stdin y4m -

[ChaosKing]

@almosely Can you add the cpu model + x264 parameter to your list?

[almosely]

@ ChaosKing

Done

[foxyshadis]

I actually got it backwards. Delay-load is using the MS linker flag /delayload which means that you don't have to use LoadLibrary and GetProcAddress.
I have however never seen this used in any plugin that uses the FFTW DLL, they all use LoadLibrary and GetProcAddress.

Only a minor mistake in terminology; dynamic and delay loading aren't far apart anyway. Delay-loading just translates static-loading in the build into dynamic-loading in the executable. I'm sure pretty much anyone understands your meaning, since true delay isn't often used.

[kedautinh12]

Any update for 3.3.9??

[kedautinh12]

I seen new ver 3.3.10
https://github.com/FFTW/fftw3/blob/master/NEWS

[GMJCZP]

I don't know what version this will be but it seems to work fine, it is 32 bit:

Here (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins+/libfftw3f-3.dll)

64 bit:

Here (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins64+/libfftw3f-3.dll)

[kedautinh12]

this commit 1 year ago, i think it's old ver

[kedautinh12]

3.3.10 x64 ver
https://anaconda.org/conda-forge/fftw/3.3.10/download/win-64/fftw-3.3.10-nompi_hb424310_101.tar.bz2

[guest]

3.3.10 x64 ver
https://anaconda.org/conda-forge/fftw/3.3.10/download/win-64/fftw-3.3.10-nompi_hb424310_101.tar.bz2

Excuse my noobyness, but is this the same as "libfftw3f-3.dll"

[StainlessS]

same as "libfftw3f-3.dll"
Yes, same file, alternate name [some plugins require one or other name, some plugins can use either name].

[GMJCZP]

3.3.10 x64 ver
https://anaconda.org/conda-forge/fftw/3.3.10/download/win-64/fftw-3.3.10-nompi_hb424310_101.tar.bz2

Won't there be a 32-bit version?

[GMJCZP]

Won't there be a 32-bit version?

Please, does anyone know if there is a 32-bit version of this latest version of FFTW?

[StainlessS]

+1 on what GMJZP said, I will not use unless both available [downloaded and deleted x64 only].