AviSynth+ thread Vol.2

[DTL]

Looks like edges of some blocks are damaged (zero YUVs and green spots ?) and blurred to internals of the block. Though sometime black spots blurred from edge of the block.

[real.finder]

Looks like edges of some blocks are damaged (zero YUVs and green spots ?) and blurred to internals of the block. Though sometime black spots blurred from edge of the block.

it seems, anyway here what I find about it https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest/issues/6#issuecomment-3536772841

[ENunn]

thanks for the solutions!! unfortunately performance tanks when i add the things you posted on the github. my script was 10fps before, now it's 4. not 100% sure why.

[DTL]

Someone need to make test build from latest sources with that commit about threads lock. May helps. But I do not see build instructions with Visual Studio. No project files. No cmake.

[pinterf]

seems its old problem https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest/issues/6

The fftw library planner function is not thread safe. A simple instance of plugin can make it thread safe on its own. But when there are multiple instances and/or different plugins that use fftw DLLs, they can still mess into each others planner.

Avisynth's new v12 interface can help with this topic, if they use the same "global lock", different instances and plugins can safely work together.

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/Cplusplus_api.html#cplusplus-acquiregloballock

The original issue:
https://github.com/AviSynth/AviSynthPlus/issues/444

My old fft3dfilter repo got this update as well.
https://github.com/pinterf/fft3dfilter/commit/599632e3878caaf7aab93d822cc3a426b4003fbc

[pinterf]

Overlay add/remove got 32-bit float and direct RGB support.

So here is a long-time-no-see test build from me, Avisynth r4335.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4335

For the change list, check readme inside, or the usual https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

Built with Visual Studio 2026, I wonder if people with ancient (or not so ancient) systems can use them without problem. The XP build are with MSVC, the non-XP ones were built with clang-cl (LLVM) option.

Theoretically the Microsoft Visual C++ redistributable - which is not part of this pack (called now "Visual C++ Redistributable v14") - is still general for v14 compiler families (2017-2026):
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-c-redistributable-v14
(remember: the redist XP support stopped at an old specific version)

Give feedback, please, whether it works on pre-Win10 systems.

[tebasuna51]

...
So here is a long-time-no-see test build from me, Avisynth r4335.
...
Give feedback, please, whether it works on pre-Win10 systems.

Problems with old W10 versions mine is (Build 14393)
AvsInfo checks:

[LigH]

No surprise that a recompilation with a newer Visual Studio may require newer MSVC runtimes. Installing e.g. the recent AIO repack should help.

[StainlessS]

Posted by seagate yesterday:- Repack – Visual C++ redistributable runtimes v.0.103.0 – by abbodi1406 (https://gitlab.com/stdout12/vcredist/-/releases/v0.103.0//)

[jpsdr]

The new v14 redistributable (14.50) doesn't install on Windows 7, but i don't know if it's mandatory for VS2026 builds, or if the last 2022 (14.44.35211) is still enough.
I'm still making my AVS build with VS2019 and LLVM.

[v0lt]

pinterf
What version of InnoSetup will you be using in the next release?
I'd like to try fixing the display of the license text in the Russian localization.

[qyot27]

x86 releases are still on Inno Setup 5. ARM releases are on Inno Setup 6, because there's no point in maintaining installer compatibility with ancient, long past EOLed OSes for legacy reasons on an architecture they were never available for.

[pinterf]

New test build. 32/64 bit,

A Clang-cl (LLVM) build and an XP (MSVC) build as well.

Avisynth+ v3.7.6pre-r4356 test build
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4356

Changes since last week:

- add AVX512 VNNI flag (avisynth.h, avisynth_c.h)
- make Info() more compact when displaying AVX512 flags.
- optimize horizontal 32-bit float small (<=4) kernel size
- optimize 32-bit float vertical avx2
- Add mechanism (cache hint) to inform a filter about the effective number of threads when Prefetch is called.

Check full change list and additional info links here:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

[jpsdr]

Just to be sure, it's still not possible to know the Prefetch value during the "Create" stage ?

[DTL]

It is expected to be possible. It is designed to inform filter about threads number so filter can configure itself for best performance before processing start. Though how to be sure this already was set by environment may be not clear.

May be the only good time (but a bit later) is to check
num_threads at the beginning of GetFrame() method and select required processing way.

From example:

class ConvertToRGB : public GenericVideoFilter {
private:
int num_threads; // initialize it, since CACHE_INFORM_NUM_THREADS is not called if no Prefetch is used
...
int __stdcall SetCacheHints(int cachehints, int frame_range) override {
if (cachehints == CACHE_GET_MTMODE) return MT_NICE_FILTER;
if (cachehints == CACHE_INFORM_NUM_THREADS) {
num_threads = frame_range;
}
return 0;
}

- the class member num_threads expected to be initialized by environment (if Prefetch is set to >1 for this script area) before first call to GetFrame() of this class (?). So default init value at class constructor may be = 1 (or any other required default in the fiter). And if Prefetch > 1 is set - its value will be increased (set) by calling of SetCacheHints(CACHE_INFORM_NUM_THREADS, Prefetch_num).

[jpsdr]

Unfortunately it's too late, i create my threadpools in the "Create" stage. Anyway, it was just for being able to have an "automatic" value in my prefetch parameter. There was not until now, it will just stay the same.

[pinterf]

Just to be sure, it's still not possible to know the Prefetch value during the "Create" stage ?

Yep, I thought that it will be too late. I thought, you could still create the thread pool, but when Prefetch signals to your filter the actual "mt go live" thread count, then you can somehow rearrange this-or-that and set back the process to work with 0..height-1 limits again, instead of feeding your own threads with the partial stripes.

Anyway, the feature is there...

[DTL]

May be simply add one more function to IScriptEnvironment like GetThreadsNum() ? And user can call it from class constructor if required.

[pinterf]

May be simply add one more function to IScriptEnvironment like GetThreadsNum() ? And user can call it from class constructor if required.
When a class is created, the future thread count is not known. It only turns out when Prefetch is reached, and at this point all filters before the Prefetch will be informed about the actual count.

[Emulgator]

Win10P64 i9-11900K Avs r4356 x86_64 runs ok.
Win10P64 i9-11900K Avs r4356 x86 STATUS_ACCESS_VIOLATION in C:\Windows\SysWOW64\MSVCP140.dll immediately within Groucho's AviSynth Installer.
Did only copy the AviSynth.dll, not the 6 base plugins.
The previous Win10P64 i9-11900K AviSynth.dll (4289.375) x86 runs ok.

Win7U64, WinXP32 testing soonish.

P.S. My C:\Windows\SysWOW64\MSVCP140.dll: 14.29.30156.0

[pinterf]

Win10P64 i9-11900K Avs r4356 x86_64 runs ok.
Win10P64 i9-11900K Avs r4356 x86 STATUS_ACCESS_VIOLATION in C:\Windows\SysWOW64\MSVCP140.dll immediately within Groucho's AviSynth Installer.
Did only copy the AviSynth.dll, not the 6 base plugins.
The previous Win10P64 i9-11900K AviSynth.dll (4289.375) x86 runs ok.

Win7U64, WinXP32 testing soonish.
Thank you for the feedback.

My version (I'm on Win11) is 14.50.35719.0

Theoretically, the "Latest supported v14 (for Visual Studio 2017–2026)" redist pack is still OK for Windows 10, maybe an update needed. If it works, for the record, it would be interesting to know which version did not work for you.

Also (quotation):
Support for Visual C++ 2015 Redistributable (version 14.0.24212) ended October 15, 2025.

Link:
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#latest-supported-redistributable-version

[aarv]

Found an funny issue, the example script Authors.avs no longer output the text on r4356

[pinterf]

Found an funny issue, the example script Authors.avs no longer output the text on r4356
Thanks, investigating, something went astray around the changed MessageClip.

[pinterf]

New build, Merry Christmas!

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4392

EDIT:
May need a 14.50.xxx Visual C++ redistributable. Latest V14 redist is from here (permalink to the .exe):
https://aka.ms/vc14/vc_redist.x64.exe
__________________

This is what had happened in the last weeks:

1.) A tremendous amount of time was spent with experimenting with DTL on basic 32 bit float
resampler ideas. The effort involved was measured in man-weeks on my side, and I believe even
more on his. I can say it was good entertainment.

2.) Now that AVX512 is practically killed by Intel on consumer PCs and AVX10 is not yet available,
CPU flags were both simplified and extended. :) I'm happy, I have i7-11700, so this was like a toy for me.

3.) Compiling ARM64 on Windows with Visual Studio now is as easy as doing an Intel compilation. Since I
tried experimenting with Raspberry Pi 5, I wanted to add ARM64 CPU feature flags - done. This was done
as blind development.

4.) For other changes, see the change log.

For online documentation check https://avisynthplus.readthedocs.io/en/latest/

Actual changelog since last official release:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist376.html

20251220 3.7.5.r4392 (pre 3.7.6)
--------------------------------
- "Info": Optimize AVX512 features display, group features, make a bit more compact
- "Info": add L2 cache size display
- "SetMaxCPU": add "avx512base" and "avx512fast" options to enable/disable AVX512 grouped features. see SetMaxCPU .
- ARM64 (aarch64) area:
- "Info": add ARMV8-A features display (NEON, DOTPROD, SVE2)
- Add ArmV8-A cpu feature detection (NEON, DOTPROD, SVE2) on ARM64 Windows/Linux/macOS builds. On Windows,
only up-to DOTPROD can be detected due to OS limitations.
- New CPU flags in cpuid.h and avisynth_c.h: CPUF_ARM_NEON, CPUF_ARM_DOTPROD, CPUF_ARM_SVE2
- "SetMaxCPU": add "neon", "dotprod", "sve2" options to enable/disable ARM64 (aarch64) features.
- New CPU flags: cpuid.h and ``avisynth_c.h - added AVX512 group feature flags CPUF_AVX512_BASE and
CPUF_AVX512_FAST (Ice Lake, usable AVX-512 since that point). - added many new AVX512 individual feature
flags - added ARM64 feature flags CPUF_ARM_NEON, CPUF_ARM_DOTPROD, CPUF_ARM_SVE2 - CPUF_xxxxx
flags are now 64 bit, replace enum with constexpr.
- CMakeLists.txt: avx512 compile flag support for gcc/clang ("fast" Ice Lake-like feature set).
- V12 interface: GetCPUFlagsEx returning 64 bit flags (too many AVX512 subfeatures to fit in 32 bit). C interface:
avs_get_cpu_flags_ex. see GetCPUFlagsEx and GetCPUFlags
- V12 interface: L2 cache size query support. New entry in AvsEnvProperty: AEP_CACHESIZE_L2 (C++), AVS_AEP_CACHESIZE_L2 (C)
to query L2 cache size in bytes with IScriptEnvironment->GetEnvProperty(). x86/x64 architecture only for now.
See AvsEnvProperty .
- Refactor CMakeLists.txt:
- Correct default of ENABLE_INTEL_SIMD for cross-compiling scenarios (e.g. ARM64 target on x86_64 host) Old logic relied
on the host processor: ${CMAKE_SYSTEM_PROCESSOR}
- Add back option to compile ARM64 builds with Visual Studio on Windows. On VS2026 even clangcl (LLVM) is supported
out-of-box for ARM64 platform, easily cross-compilable way from an x64 machine.
- VDubFilter: allow building on Windows only x86/x64 targets (and not for ARM64).
- Fix LLVM/clangcl/Intel ICX compile warning: 'WIN32' macro redefined as "#define WIN32 /D_WINDOWS /W3 /GR /EHsc 1 ",
when CMake injects a command-line macro wrongly and thus redefines WIN32 . The fix: converts global add_definitions("/D ...")
and other option string magics into per-target target_compile_definitions() and target_compile_options(). Thus removing
the accidental injection of ${CMAKE_CXX_FLAGS} into add_compile_options(), and prevents the WIN32 macro redefinition.
- Change video-framebuffer over-allocation from 16 to 64 bytes. Allocate 64 bytes more than needed for video frame buffer
in order to be able to read 64 bytes safely with AVX512 without risking access violation on the last pixels of the frame.
- rst docs
- Update GetCPUFlags, add GetCPUFlagsEx
- Update CPU Feature Flags with AVX512 and ARM64 features
- Update SetMaxCPU with AVX512 and ARM64 features
- Update AvsEnvProperty with L2 cache size entry
- Update Russian GPL notice in UTF-8 format

[tormento]

New build, Merry Christmas!
Likewise!
experimenting with DTL on basic 32 bit float resampler ideas
Any plan about having internals descale routines too? I miss border_handling option from Descale (https://github.com/Irrational-Encoding-Wizardry/descale).
AVX10 is not yet available
Luckily Nova Lake is not so far and AVX10.2 support has been confirmed. Eagerly waiting for it to upgrade my ancient i7-2600k ;)

[StainlessS]

And a Merry XMas to you P, and all D9'ers.

[StainlessS]

Hi P, would latest update make it necessary to have a new AvisynthWrapper for MeGUI,
all my MeGUI instances (across machines that I've updated with new AVS+) just disappear in a puff of smoke.
Well actually, no smoke, but MeGUI instance crashes and leaves all of the expanded runtimes in-situ.
(they are usually expanded on running MeGUI, then deleted on close)

[pinterf]

Hi P, would latest update make it necessary to have a new AvisynthWrapper for MeGUI,
all my MeGUI instances (across machines that I've updated with new AVS+) just disappear in a puff of smoke.
Well actually, no smoke, but MeGUI instance crashes and leaves all of the expanded runtimes in-situ.
(they are usually expanded on running MeGUI, then deleted on close)
Only this one, or the previous build as well?

The XP version was built with VS2026 + MSVC.
Non-XP is VS2026 + clang-cl (LLVM 20.1.8 in present state).

However this had not changed since the previous test.

[StainlessS]

I did not install previous built,
I dont remember why but something made me think that I should not. [EDIT: I think that I had not updated for several versions]

MeGUI log,


Preliminary log file only. During closing of MeGUI the well formed log file will be written.

-[Information] Versions
--[Information] MeGUI: 6.6.6.6 20251116 x64
--[Information] MeGUI Debug Data: available
--[Information] Update Check: Disabled
-[Information] Operating System: Windows 10 Home 22H2 x64 (10.0.19045.6456)
-[Information] .NET Framework: 4.8.1
-[Information] Microsoft Visual C++ 2008 x86: 9.0.21022
-[Information] Microsoft Visual C++ 2010 x64: 10.0.40219
-[Information] Microsoft Visual C++ 2010 x86: 10.0.40219
-[Information] Microsoft Visual C++ 2015-2022 x86: 14.42.34438
-[Information] Redistributables
-[Information] DPI: 100% (96/96)
-[Information] Resolution: 1920x1080
-[Information] Primary Screen: True
-[Information] Monitor 1
-[Information] Resolution: 1920x1080
-[Information] Primary Screen: False
-[Information] Monitor 2
--[Information] System Information
-[Information] Update detection
--[Information] [20/12/2025 19:07:04] Automatic update is disabled
-[Information] Haali Media Splitter: 1.13.138.14 (14-04-2013)
-[Information] Haali DSS2: (14-04-2013)
-[Information] ICSharpCode.SharpZipLib: 0.85.5.452 (24-03-2024)
-[Information] MediaInfo: 25.10.0.0 (05-11-2025)
-[Information] SevenZipSharp: 0.64.3890.29348 (24-03-2024)
--[Information] [20/12/2025 19:07:04] Using cached update config and server: http://megui.org/auto/fork/
-[Information] 7z: 9.20 (24-03-2024)
--[Information] Component Information
-[Information] Version: 1.0.3000.1
-[Information] Date: 25-11-2024
-[Information] Interface: 6
-[Information] AviSynth Wrapper
--[Information] [20/12/2025 19:07:04] No package requires an update
--[Information] [20/12/2025 19:07:04] redist files copied: 2019_x64

[StainlessS]

I re-installed older version that I had been using,
64 Bit Avisynth+ 3.7.5 (r4289, 3.7, x86_64) (3.7.5.0)
as shown by Groucho "setavs.cmd".

Now working OK again.

EDIT: I installed only (the broken instance) the normal one, no clang, no XP.

EDIT: And my i5-11400T shows the same AVX512 flags as my i7-11700. (I was curious if different, but not)

[pinterf]

This one seems a bit outdated: Microsoft Visual C++ 2015-2022 x86: 14.42.34438.
but it's for x86, your MEGUI is x64.
The x64 redist file - if the '2019_x64' line is valid, then it is also very-very old.
Its name is no longer 2015- but 2017-. I'd try to download the latest one.

[pinterf]

The "normal" one is the clang version. But it's just the compiler, the redistributable is the same as of the MSVC version.
Maybe it needs a newer one. Maybe.
EDIT: Yes, it is probably hungry for a newer one. You have 14.25.28508, which seems to be not good for the new dll.

It's crashing in MEGUI's copy of that almost 6 year old redistributable: msvcp140_1.dll

'MeGUI.exe' (Win32): Loaded 'C:\MeGUI\AviSynth.dll'. Symbols loaded.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\winmm.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\msvfw32.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\Windows\System32\avifil32.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\MeGUI\vcruntime140.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\MeGUI\msvcp140.dll'. Symbol loading disabled by Include/Exclude setting.
'MeGUI.exe' (Win32): Loaded 'C:\MeGUI\vcruntime140_1.dll'. Symbol loading disabled by Include/Exclude setting.
Exception thrown at 0x00007FFEA5EB2EB0 (msvcp140.dll) in MeGUI.exe: 0xC0000005: Access violation reading location 0x0000000000000000.



msvcp140_1.dll 31 728 2020.01.08 01:09 -a--

EDIT2:
Latest V14 redist is from here (permalink to the .exe)
https://aka.ms/vc14/vc_redist.x64.exe

EDIT3:
By copying the newer msvc*.dll files from my System32 folder to the local MeGUI folder, MEGUI stopped crashing.

[StainlessS]

Well sussed out P, I'll point Kurt over here.

[qyot27]

3.) Compiling ARM64 on Windows with Visual Studio now is as easy as doing an Intel compilation. Since I
tried experimenting with Raspberry Pi 5, I wanted to add ARM64 CPU feature flags - done. This was done
as blind development.

- Refactor CMakeLists.txt:
- Add back option to compile ARM64 builds with Visual Studio on Windows. On VS2026 even clangcl (LLVM) is supported
out-of-box for ARM64 platform, easily cross-compilable way from an x64 machine.
It was always easy to build for ARM64 from Visual Studio. That wasn't the point.

The restriction was there to stop the core/plugin C++ ABI madness and only support MinGW and the Itanium C++ ABI on non-x86 platforms. ClangCL uses MSVC's ABI, which means it only perpetuates the problem we had on x86.

[pinterf]

It was always easy to build for ARM64 from Visual Studio. That wasn't the point.

The restriction was there to stop the core/plugin C++ ABI madness and only support MinGW and the Itanium C++ ABI on non-x86 platforms. ClangCL uses MSVC's ABI, which means it only perpetuates the problem we had on x86.
Yes, I wanted you to ask about Windows case, and if the initial reasons still apply.


Using MinGW is a pain from plugin developers' point of view, I guess that 98% of the lazy developers (including me) will always have troubles and extra efforts compiling and providing their plugins on the ARM64 platform.

This is the practical reality of c++ development on Windows. The MSVC ABI is de-facto standard. So the path of least resistance for an unknown (I mentioned 98% but I'm sure it's something like that) percent of plugin developers on Windows is Visual Studio and the MSVC toolchain.

I rarely use MinGW, so rarely that I always have to restart the learning curve. Not counting the cross compiling madness (which is a little be less madness once you dig into it, but still is). Most developers use Visual Studio from which it is the same effort to build an ARM64 version as having a Win32 bit output.

2.) Forget what I wrote so far. You may be right. Right now I recalled my Raspberry Pi 5 project - I realized that there are many other platforms which is not Windows but still ARM64. So if I compile and publish an aarch64 plugin, it would work i non-Windows env.

You've made a huge step on creating the rst's.
I'm going to re-read it and update with real-lazy-developers mind-stopping steps. This should workd with practically zero pre-knowledge of MinGW (see my ever-restarting learning curve) - i can make it more detailed ("for dummies") step by step intructions if I find troubles. The most ideal case is a single batch file on my Windows machine which refreshes everything, creates the dll which I can put that into the release pack. Avisynth or plugins or whatever.

[StainlessS]

("for dummies")
Yep, lots of us stupid people out here, the dummier the better.

[DTL]

"I miss border_handling option from Descale."

AVS resizers also do not support different user-defined border handling processing. Only one fixed way.

I found very promising comment about great future of AVS+ filtergraphs performance - https://github.com/pinterf/AviSynthPlus/blob/362477cb9c67c3f54dd40d56efb990fc77dad9e9/avs_core/filters/intel/resample_avx2.cpp#L1806 . May be already some implementations in 2026.

[tormento]

AVS resizers also do not support different user-defined border handling processing.
That's why I "miss" them ;)

[qyot27]

Yes, I wanted you to ask about Windows case, and if the initial reasons still apply.


Using MinGW is a pain from plugin developers' point of view, I guess that 98% of the lazy developers (including me) will always have troubles and extra efforts compiling and providing their plugins on the ARM64 platform.

This is the practical reality of c++ development on Windows. The MSVC ABI is de-facto standard. So the path of least resistance for an unknown (I mentioned 98% but I'm sure it's something like that) percent of plugin developers on Windows is Visual Studio and the MSVC toolchain.

I rarely use MinGW, so rarely that I always have to restart the learning curve. Not counting the cross compiling madness (which is a little be less madness once you dig into it, but still is). Most developers use Visual Studio from which it is the same effort to build an ARM64 version as having a Win32 bit output.

2.) Forget what I wrote so far. You may be right. Right now I recalled my Raspberry Pi 5 project - I realized that there are many other platforms which is not Windows but still ARM64. So if I compile and publish an aarch64 plugin, it would work i non-Windows env.

You've made a huge step on creating the rst's.
I'm going to re-read it and update with real-lazy-developers mind-stopping steps. This should workd with practically zero pre-knowledge of MinGW (see my ever-restarting learning curve) - i can make it more detailed ("for dummies") step by step intructions if I find troubles. The most ideal case is a single batch file on my Windows machine which refreshes everything, creates the dll which I can put that into the release pack. Avisynth or plugins or whatever.
I never try to do any compiling all from memory. I know the basic shape of it due to familiarity, but the Windows/MSVC build commands for AviSynth+ or anything else...nope. I just copy and paste from a text file I first wrote up over ten years ago, modifying it as necessary. I do the exact same thing when building stuff on Linux. Only with the absolute simplest things (like the AviSynth+ core without plugins or letting it autodetect) do I not bother just copy/pasting. It's why the tedious FFmpeg/mpv crosscompile build guide (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt) exists in the first place.

I can't say because I don't use an IDE, but VSCode/VSCodium can work with MinGW-w64 GCC (or Clang, if this thread is as straightforward as it seems (https://stackoverflow.com/questions/67456720/vscode-c-c-intellisense-with-clang-mingw)). I would assume that using it that way wouldn't be *too* different from using Visual Studio, just that it's using standard Clang instead of ClangCL.

As that thread notes, integrating it properly still can be done by pulling in Clang and its tools using MSys2. The last time I looked at it, MSys2 still doesn't have a native ARM version (https://www.msys2.org/docs/arm64/), but Windows 11 resolves that by using an emulator (same as Rosetta on macOS, or FEX (https://fex-emu.com/) - or qemu-user or box86 - on Linux). I eventually just relented and installed the normal x86-64 version on W11 to get access to the MSys2 environment instead of waiting around for a fully ARM-native version, even though the builds were still done in WSL2 using llvm-mingw as detailed below.

MSys2's clang packages for winarm64 would be pulled from llvm-mingw anyway, and WSL2 users can actually just git clone the llvm-mingw repository (https://github.com/mstorsjo/llvm-mingw) and run the build script to set up the compiler (which is exactly what I did when creating the ARM64 releases for 3.7.4 and 3.7.5). It also means that cross-compilation from OtherOS->Windows works, so long as you can build llvm-mingw on it (ClangCL can't be used outside of Windows unless you go through possibly convoluted steps to install Visual Studio under Wine or extract the SDK out of it and then rebuild everything).

The Windows on ARM guide in the AviSynth+ docs (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/docs/english/source/avisynthdoc/contributing/avsplus_external_deps_guide_manual_arm.rst) covers the entire environment setup and build process. I actually just copied the instructions directly out of the aforementioned tedious crosscompile guide, which is why some of the directory names are a little strange (read: this is why all the source code downloads/git clones go into a directory named mpv-build-deps or why it refers to NASM even though NASM is irrelevant for ARM).

Soundtouch (https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-soundtouch/PKGBUILD) and DevIL (https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-devil/PKGBUILD) both exist as MSys2 packages, and are enabled for the clangarm64 target.

[pinterf]

I'm just talking to diffent Mr. AIs. Gemini at the moment.

It started like this: "Navigate to a well-known resource for pre-built GNU toolchains. For AArch64 Linux." This is my problem. Well known. Yes, surely :) for those who are doing this on a daily base. Then I asked and it helped a little more detailed. So this way of development is simply not that intuitive.

An average plugin developer - I'm not sure that there are many left - will better go running on a 100k trail running event than copy-paste and issue miriads of command lines. Right-click, choose ARM - build, this is what I'd like to achieve.

Some days ago when I wanted to check my commits (which accidentally failed because of committing an orphan "(" ), I made gcc build tests on my old 20.04 WSL. I spent five minutes on a Url not found message, until I figured out the right command line magic: sudo apt-get update :)

Back to the ARM64 and DLLs world. It turned out that Windows is still different, I though I can make dlls (or .so) for non-Microsoft ABI almost universally. But not (of course, how could I think differently). For Targeting Linux (like my Raspberry Pi 5) I have to install one kind of cross compiler (runs on my x64 Windows, targets RPi5).

And for Windows I need another type of cross compiler. If building build a Windows ARM64 dll, which must be treated and compiled specially, then what is the point of not using Visual Studio and Microsoft tools for that?

Anyway, Gemini (AI) says, that Visual Studio integration is somehow possible though CMake Toolchain files. After installing the toolchain (MinGW-whatever). Something like this, even remote debugging is possible.
# --- aarch64-pi5-toolchain.cmake ---

# Specify the target operating system and architecture
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)

# --- Toolchain Path Configuration ---
# !!! REPLACE THIS WITH YOUR ACTUAL PATH !!!
set(TOOLCHAIN_ROOT "C:/Toolchains/aarch64-linux-gnu")

# The prefix used by the compiler executables (e.g., aarch64-linux-gnu-)
set(TOOLCHAIN_PREFIX aarch64-linux-gnu)

# Specify the C and C++ cross-compilers
set(CMAKE_C_COMPILER ${TOOLCHAIN_ROOT}/bin/${TOOLCHAIN_PREFIX}-gcc.exe)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_ROOT}/bin/${TOOLCHAIN_PREFIX}-g++.exe)

# Search for programs (like target tools) in the host path
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# Search for libraries and headers only in the target path
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

# Optional: Set Raspberry Pi 5 specific flags for optimization
set(CORTEX_FLAGS "-mcpu=cortex-a76 -mtune=cortex-a76")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${CORTEX_FLAGS}" CACHE STRING "")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CORTEX_FLAGS}" CACHE STRING "")

"Your next step will be to open Visual Studio 2026 and configure a CMake project to use this file. Would you like to proceed with setting up the CMake project in Visual Studio?"

I'm just reading now a lot and try to summarize to myself these steps, then I will compare with yours. But it will take weeks, the holidays are always busy for me.

Or this is its recommendation for ARM64 on Windows:
# --- aarch64-windows-toolchain.cmake ---

# Specify the target operating system and architecture
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR AARCH64)

# Set the C and C++ cross-compilers
set(TOOLCHAIN_ROOT "C:/Toolchains/aarch64-windows-gnu") # Must be different folder!
set(TOOLCHAIN_PREFIX aarch64-w64-mingw32) # Common prefix for Windows target

set(CMAKE_C_COMPILER ${TOOLCHAIN_ROOT}/bin/${TOOLCHAIN_PREFIX}-gcc.exe)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_ROOT}/bin/${TOOLCHAIN_PREFIX}-g++.exe)

# Search rules are often simpler for MinGW-w64 on Windows hosts
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

[Emulgator]

Win10P64 i9-11900K Avs r4392 x86_64 runs ok.
Win10P64 i9-11900K Avs r4392 x86 STATUS_ACCESS_VIOLATION in C:\Windows\SysWOW64\MSVCP140.dll immediately within Groucho's AviSynth Installer.
Did only copy the AviSynth.dll, not the 6 base plugins.

The "official" AviSynth.dll (4289.375) x86 runs ok.

My C:\Windows\SysWOW64\MSVCP140.dll: 14.29.30156.0 (was the same with AccessViolation of r4356)

---------------------------------------------------------
2004 DELL XPS M1710 (Core2Duo T7600G, 4GB) Dual-boot, first into WinXPPro32SP3:
AvsPmod32 2.7.9.4, one-liner source script
FFMS2("path\file.mp4",-1,-1)
Avs+ r4289 x86 runs ok.
Avs+ r4335 x86 runs ok.
Avs+ r4356 x86 runs ok.
Avs+ r4392 x86 runs ok.
Many thanks, pinterf !
--------------------------------------------------
Same 2004 DELL XPS M1710 (Core2Duo T7600G, 4GB) Dual-boot, other boot into Win7P64SP1:
AvsPmod32/64 2.7.9.4, same one-liner source script
FFMS2("path\file.mp4",-1,-1)

Avs+ r3961 x86 runs ok.

---------- "Official" 3.7.5, many thanks, qyot27 and pinterf !------

Avs+ r4289 x86 XP32 runs ok, plus the non-xp run ok !
Avs+ r4289 x64 XP64 runs ok, plus the non-xp run ok !

3.7.5 seems to be the gold standard of compatibility for me.

---------- pinterf test versions, many thanks, pinterf ! -------

Avs+ r4335 x86 XP32 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"
Avs+ r4335 x64 XP64 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"

Avs+ r4356 x86 XP32 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"
Avs+ r4356 x64 XP64 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"

Avs+ r4392 x86 XP32 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"
Avs+ r4392 x64 XP64 runs ok (yippie, good work !), the non-xp throw "procedure entry 'CreateFile2' missing in Kernel32.dll"

Together with those x86 build crashes it looks to me as if the concerning compilation environment is generating builds departing from that universal compatibility.
---------------------------

Further tests on a "proper one-trick pony" 2009 i940XM 8GB Win7U64 to follow...
Seems to confirm these findings: 3.7.5 is the gold standard of compatibility.
Avs+ r4392: the non-xp versions x86 and x64 suffer from "procedure entry 'CreateFile2' missing in Kernel32.dll", even on Win7 and a newer CPU.

[pinterf]

Thank you
In 2024 there was a binary change how mutexes are working. Old redistributables are not compatible with MS toolsets from end of 2024. This is the mutex crash, which is not win7 and vs2026 specific, you just need to refresh the too old redistributables. I will figure out which is the first working version. Search for: c++ mutex lock crash.
Second part: missing CreateFile2 means that Win7/8.1 support is dropped in both VS2026 and the 14.50.xx redistributable. I suppose the v145 toolset requires that. Win7 compatible builds should use v143 toolset, I guess not the last one but have to find the specific version number and only use that.
Btw the xp toolset is way too old, it does not allow using new (c++20) elements, fully incompatible. It takes 65 minutes to build one dll. For the incompatibility reason I'd like to drop it, if not in the next release, but in the next-next for sure. It will be enough to keep Win7 compatibility.

[jpsdr]

The last working Windows 7 redistributable is 14.44.35211, if it's what you want to know.

[pinterf]

The last working Windows 7 redistributable is 14.44.35211, if it's what you want to know.
Thanks, we'll register it, just like the latest XP compatible one.

Regarding the "mutex lock crash", it's there, since June, 2024, which belonged to VS 2022, toolset 17.10.
https://github.com/microsoft/STL/issues/4730

The toolset's baseline version is 14.39.32551.0, so with old redistributables prior to this version our program will crash in mutex related code.

Then the Win7 compatibility.

The last Windows 7 compatible Visual Studio 2022 version was 17.7: toolset version v143 (14.37.xxxx)

Since toolset v143 (14.38.xxxx) the programs will not work on Windows 7.

Not to mention VS2026 which started with toolset v145 (14.50.xxxxx-).

(VS2026 can use older toolsets as well, if they are selected)

[pinterf]

Avisynth new build.
20251223 3.7.5.r4400 (pre 3.7.6)
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4400

20251223 3.7.5.r4400 (pre 3.7.6)

- Resamplers, horiz. float, add back DTL2020's new quick algorithms for kernel size <= 4. Since MT is not their forte, use the generic resamplers if Prefetch > 1.
- AVX512 float resampler additions, optimize horizontal (kernel size <= 8), add code for vertical (DTL2020)
- Fix an ApplyMessage regression not recognizing '\n' line ends of Authors.avs (since 20250831)

XP build still exist.
Non-XP version is built with clangcl (LLVM).
Windows 7 not supported.
Needs fresh VC14 redistributables. Get latest V14 redistributable from here (permalink to the .exe):
https://aka.ms/vc14/vc_redist.x64.exe

[flossy_cake]

I've been using AVSMeter (benchmarking tool) to try and understand when the frame cache comes into play to boost performance.

Suppose we do:


SelectEvery(1,0,0) # double the fps with duplication
BicubicResize(3840,2160)


Would the frame cache see that BicubicResize has already generated an upscaled frame for the duplicate and just re-use the same output frame? Is that how it works? Because in AVSMeter tests I am getting conflicting results - in some cases I see a gain, in others I don't.

:thanks:

[StainlessS]

See CacheTest,


CacheTest(), by StainlessS @ Doom9. https://forum.doom9.org/showthread.php?t=184920

CacheTest(clip c, String "text"="", String DvChar="", Bool "Always"=False, Bool "Silent"=False)

CacheTest() Sends text message to DebugView when requested frame is "Out Of Sync", ie not previous frame + 1.
Insert between filters to see if there are any repeat requests for frame, or out of sync frame requests.

Requires DebugView, [ DebugView v4.90, @ Micro$oft:- https://learn.microsoft.com/en-us/sysinternals/downloads/debugview ]
DebugView captures debug messages on your local machine (or network) and shows them in a window, can also save to file.
These messages may be output by the system, or eg graphics card driver, or some other program on a machine.
[really annoying when nVidia floods debug logs in some supposedly non beta drivers].
You can add a DebugView Filter via DebugView Edit menu, to only capture debug message lines containing some substring eg ":",
so that you only see the lines containing that substring, but you would then need to ensure that your debug messages also contain ":".
NOTE, RT_Stats plugin has RT_Debug() and RT_DebugF() functions for outputting script debug Info in real time during Filter Graph creation
stage, or during frameserving from within the Runtime environment (eg ScriptClip).
All RT_Debug/RT_DebugF messages contain a COLON character.

Args:

Text, Default "".
Allows add some kind of text label to the Title string that is output to DebugView.
Where CacheTest filter Instance is 3, and Text="PorridgeOats", and DvChar="", then
the Title output would be "CacheTest_0003_PorridgeOats:". (Ends with SINGLE COLON, ':')

DvChar, Default "".
Where CacheTest filter Instance is 3, and Text="PorridgeOats", and DvChar=":", then
the Title output would be "CacheTest_0003_PorridgeOats::". (Ends with DOUBLE COLON, ':')
The DvChar is inserted after the always present 1st ":" character, it allows to set
a more specific DebugView filter string, so as to only see CacheTest debug messages in DebugView.
Some messages sent to DebugView may not involve a COLON, some do use a COLON, you can eg set
DvChar to ":" so that only DebugView messages containing "::" will be captured, or can set some other character following ':'.
(You could even set DebugView filter to eg "CacheTest" if required, or even "PorridgeOats").

Always, Default False.
True = Output all frame requests debugview.

Silent, Default False.
True = switch off ALL messages (overrides ALWAYS).
Leaves an additional Cache between filters, without writing messages to DebugView.

Shows messages as in
"CacheTest_0005_Node_A1: 1001] *** REPEAT REQUEST {RepeatCnt=7, OSyncCnt=21}"
where there is a repeat request for CacheTest instance 0005 where Text="Node_A1",
@ frame 1001, and total Repeat Count = 7, and Out Of Sync Count = 21.
OR,
"CacheTest_0003_Marmalade: 873] *** OUT OF SYNC REQUEST, Previous=884 {RepeatCnt=7, OSyncCnt=21}"
where there is an Out Of Sync request for CacheTest instance 0003 where Text="Marmalade",
@ frame 873, where previous request was for frame 884, and total Repeat Count = 7, and Out Of Sync Count = 21.

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

Example:
Return Colorbars(Pixel_type="YV12").KillAudio.CacheTest()


Untested

Last="..."

ALWAYS=True

CacheTest(Text="Cache_SOURCE_A",Always=ALWAYS) # I expect Source filter caching to occur here !!! (due to double request in below SelectEvery)
SelectEvery(1,0,0) # double the fps with duplication
CacheTest(Text="Cache_SELECTEVERY_B",Always=ALWAYS)
BicubicResize(3840,2160)
#CacheTest(Text="Cache_BICUBIC_B",Always=ALWAYS)
Return Last

[flossy_cake]

@StainlessS - before I install Microsoft Debugview and pursue that avenue, first could I confirm if am I correct in understanding that if cachetest() reports the request is NOT previous_frame+1 , then this means it WAS gotten from the cache?

Revisiting AVSMeter using the upscaling example, it looks to me like Avisynth isn't getting it from the cache when doing a synthetic test with no other filters in the pipeline. But with other more "real world" tests where multiple other filters are in the pipeline, I see almost no performance difference whether I do the framedoubling before/after the upscaling. But I think that is just because of bottlenecks to do with other filters still waiting to finish. If I get rid of all other filters then it seems performance drops by roughly half when moving the upscaling to after the framedoubling which is consistent with upscaling twice as many frames which means no caching.

[DTL]

It looks old full-blood Xeon Golds like 613x are not detected as 'fast' and AVX512 processing not enabled. Can we force CPUF_AVX512_FAST from script ?

[pinterf]

It looks old full-blood Xeon Golds like 613x are not detected as 'fast' and AVX512 processing not enabled. Can we force CPUF_AVX512_FAST from script ?

Yes, see the online docs for setting max CPU level.