AviSynth+ thread Vol.2

[TR-9970X]

And to confirm gispos and DTL, we have a second hit:
AviSynth+64 r4198 ICX Base under that similar Win10P64, i9-11900K
Universal AviSynthInstaller reports: Immediate AccessViolation in C:\Windows\system32\MSVCP140.dll
Runtime versions are 14.36.32532 from 10.05.2023

I am very thankful for the XP-compatible builds and will be backing off from ultra-modern-but-incompatible compiler builds for now
(had only dived in for that educational reason anyway).
To me at least those marginal gains seem not worth the hassle of broken bridges, but I am still thankful to those who try.

I know you didn't like my suggestion of that AIO installer I posted a link to, you know you can unpack it, and probably copy any single .dll from the version you want, instead of just letting it install EVERYTHING.

Might be worth a try...

[Emulgator]

It was a wonderful experience back then, a nice readup here for all willing to try, see here:
https://forum.doom9.org/showthread.php?p=1981377&highlight=Abbodi#post1981377
Yes, single tries could help.

[real.finder]

I know you didn't like my suggestion of that AIO installer I posted a link to, you know you can unpack it, and probably copy any single .dll from the version you want, instead of just letting it install EVERYTHING.

Might be worth a try...

there are also this https://baltagy1.blogspot.com/2018/04/microsoft-visual-c-redistributable-repack.html

and this https://www.techpowerup.com/download/visual-c-redistributable-runtime-package-all-in-one/

[VoodooFX]

AviSynth+ r4198

Enjoy the life.

https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4198

No problems with it so far.

I just had an unpleasant surprise when a function I wrote using v3.7.3_r4198 produced garbage encodings on another PC running v3.7.3 (stable). :D
Why not bump the version to 4.0.0, or at least 3.8.0?

[Emulgator]

Second that. Enjoying the life with AviSynth+ r4198 and its broad choice of compilations here too.
Once qyot27 / pinterf / majority of power users agree that a milestone is reached
(and on github it looks like qyot27 is cleaning up the docs)
I would call it a day and welcome the suggested means of version distinction.

[qyot27]

Why not bump the version to 4.0.0, or at least 3.8.0?
All previous minor version bumps happened with the introduction/merge of milestone features*, and there's no reason to jump to 4.x given that massive API/ABI incompatibilities (we're not talking about regular churn of the INTERFACE_VERSION here; I mean stuff as major as a wholesale rewrite in a different programming language) have not arisen to warrant it.

*0.1 - first release of the initial fork; this would include 64-bit, asm->intrinsics rewrite, build system overhaul, etc.
[0.2] - would have been multithreading, but the bump never happened
[0.3] - would have been high bit depth and MinGW/GCC support, again, the bump never happened
3.4 - consolidation back to Github and a catch-up release before 3.5
3.5 - cross-platform (Linux/Mac/BSD) support
3.6 - merge of Neo features, ARM support/ability to build with the Intel intrinsics deactivated
3.7 - technically, PowerPC, and Haiku, with RISC-V, SPARC, MIPS, and Loongson added in subsequent bugfix versions (RISC-V and SPARC tested only in VM, MIPS and Loongson basically just tacked into config.h so it won't fail on those platforms but not personally tested because I don't have any of the relevant hardware); also generally allowing for frame properties to stabilize more

There are things I consider to be important enough to warrant future bumps to 3.8, 3.9, etc., but when work on those things might happen is anyone's guess.

[VoodooFX]

...there's no reason to jump to 4.x given that massive API/ABI incompatibilities have not arisen..

That's very, very conservative... take a look at Firefox or Chrome versioning.
"a function I wrote using v3.7.3_r4198 produced garbage with v3.7.3" <- That alone would be a good reason for me. Actually, 3.7.3 could be '4.0' since it reached the 4000-commit milestone. :D

[Emulgator]

Many thanks for that insight, qyot27, very impressive.

[FranceBB]

I'm actually ok with 3.7.4 for that matter.
Speaking of which, we're now in March 2025, there are 79 days from here (March 1st) to May 19th, so if it gets released on May 19th 2025 it would be on the day of Avisynth's 25th birthday.
That on its own would be quite a milestone. I mean, there aren't many projects on the web that can say to be 25 years old and if we think that it's been totally community driven, free and open source, this is even more impressive!


(it would be a Monday, so I might even bring a theme cake to the office to my colleagues for real this time).

[Boulder]

I have to say that about 20 years ago, I wouldn't have expected to still be using Avisynth this day. I guess I can start calling video processing my hobby now, thanks to pinterf for keeping it going for so long :)

[tormento]

I think next time it's better to do the Intel stuff using static linked libraries.
I don't think it's a good idea.

Two reasons: bug fixes and security issues can arise in time and people would be stucked with a bugged/insecure version.

Me myself had problems with the .0 version (random crashes on long encodes) that were solved in .4.

MSVC works well with shared libraries, I think ICC should stay with shared libraries too.

[LigH]

Such a unique signature:

https://www.rationalqm.us/www.math.berkeley.edu/benrg/signature.gif

Ben Rudiak-Gould, original developer of Avisynth

[pinterf]

New day, new build.

AviSynth+ r4210.
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4210

Today's feature: wildcard and regex support in propShow, propDelete and propCopy functions.
More info at
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_internal_functions_frame_properties.html
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/propShow.html
Like this:
PropCopy(a) # make all properties the same with of clip a
PropCopy(a, merge=true) # Adds new properties from clip a, overwrites if already exists

# Add properties from clip "a" which end with "1" or "2"
PropCopy(a, merge=true, props=["*2","*1"])

# Add properties from clip "a" where not started with "_"
PropCopy(a, merge=true, props="_*", exclude = True)

# same with regex
PropCopy(a, merge=true, props="^[^_].*$")

# erase all, then copy all, except listed ones
propCopy(org,props=["_Matrix", "_ColorRange"], exclude = true)

[FranceBB]

Ah, more tools to tame my everlasting enemy, frame properties!
Thank you Ferenc. :)

[pinterf]

I've seen your complaints, and that was the final straw. I was already considering a feature extension since Avisynth and frame properties are such hot topics. Recently, I received an ultimatum from the Secret Association of Pink Unicorns. They demand the immediate removal of all frame property adding functionality from Avisynth, while they welcome the extension of property deleters.

Then, the King of United Frames decreed that Avisynth must be the official language of the Solar System. This left poor Vapoursynth speakers on the Moon without legal protection, allowing them to add as many frame properties as they want. "This cannot be!" I said to myself. To ease FranceBB's pain and deep sorrow, I decided to implement regex. And that's exactly how it happened.

[tormento]

And that's exactly how it happened.
Please attach some of the drugs you are taking.

I want pink unicorns too. :p

P.S: I don't think having static Intel builds is a good idea, for the reasons I explained in my previous post.

[FranceBB]

To ease FranceBB's pain and deep sorrow, I decided to implement regex. And that's exactly how it happened.

And I really appreciate that! :D


I want pink unicorns too. :p


The Pink Pony Club is very unique.


https://youtu.be/8lmK_dMWY8o?si=Gej1t2lGi0SLiC5_

[LigH]

I want pink unicorns too. :p

PFUDOR (https://www.youtube.com/watch?v=qRC4Vk6kisY)

https://frupic.frubar.net/shots/44152.gif

[tormento]

AviSynth+ r4210
I've tested your 4210 ICX version and it's not working:

Script Error

Failed to load AviSynth+

Your previous one 4193 or the "unofficial" gitlab (https://gitlab.com/uvz/AviSynthPlus-Builds)4198 IntelLLVM work perfectly fine.

[tormento]

The Pink Pony Club is very unique.

PFUDOR

Actually even your drugs are very good too. :p

[Z2697]

Isn't ICC just based on LLVM now? Why not just use clang?
How did this ICC craziness even started? tormento asking for ICC builds everywhere?

[tormento]

Isn't ICC just based on LLVM now? Why not just use clang?
How did this ICC craziness even started? tormento asking for ICC builds everywhere?


🥱

tl;dr ICC compiler is simply the best one around. It produces clean, fast and stable code. Please stick with msvc or even better gcc and close your eyes whenever you see the words “intel” and/or ICC/ICX. Thank you.

[pinterf]

I wouldn't say it's stable :) Using a good static library ensures that Intel cannot mess it up later with a bad driver or library update (like they did with version 2025.0.0 and their OpenCL driver).
(And we are not talking about the need of the huge bloatware we must download and install just because of two small DLLs).

And in my next post, I'll show you how a theoretically good idea (supporting multiple optimized architectures through dynamic dispatching - just an additonal compiler switch) can result in significant performance loss.

[pinterf]

Since we'll soon have more support for Arm64, thanks to qyot27, I experimented a bit and updated Expr where we cannot have the convenient JIT.

So I rewrote the C (non-Intel-JIT) path to support vectorization, if the compiler is capable.

Even if the compiler is not very advanced (MSVC khhhhmm..) this approach is faster because it has less overhead when interpreting the instruction flow. It processes 16, 8, 4, and 1 floats when handling the horizontal line, taking the largest chunks it can then finishing the rest with the smaller ones.

Benchmarks (x64 bit). For comparison, I also provide the JIT results.

Script (optSSE2 = false disables JIT):

# Mandelbrot
ColorBarsHD()
a="X dup * Y dup * - A + T^ X Y 2 * * B + 2 min Y^ T 2 min X^ "
b=a+a
c=b+b
blankclip(width=960,height=640,length=1600,pixel_type="YUV420P8")
Expr("sxr 3 * 2 - -1.2947627 - 1.01 frameno ^ / -1.2947627 + A@ X^ syr 2 * 1 - 0.4399695 "
\ + "- 1.01 frameno ^ / 0.4399695 + B@ Y^ "+c+c+c+c+c+b+a+"X dup * Y dup * + 4 < 0 255 ?",
\ "128", "128",optSSE2 = false, optAVX2=false) # optVectorC=true default


MSVC: Microsoft VC, actual VS2022 version.
Intel: Intel C++ Compiler 2025 - LLVM based, aka ICX.

"Base" means the instruction set is not specified: SSE2 is the minimum for x64.

Compiler/Settings VectSize FPS
-------------------------------------- ---------- -----
MSVC debug 1 0.27
Intel (base + optional AVX2 paths) 1 1.01 (! Mixed instruction set support, slow)
MSVC Base 1 1.71 VectorSize=1, not optimal :)
MSVC old single variable C: - 2.82
Intel old single variable C: - 2.90
MSVC Base 16 4.47 (initial Proof of Concept version)
MSVC AVX2 16 4.59 (initial PoC version)
MSVC Base 16 5.94
MSVC AVX2 16 6.04
Intel Base 16 6.29 (initial PoC version)
Intel AVX2 optional AVX512 -Qax:AVX512 16 12.60 (! Mixed instruction set support, slow)
Intel Base 16 14.70
Intel AVX2 16 19.20
Intel AVX512 16 20.10
MSVC JIT SSE2 2x4 59.00 (dual lanes, XMM regs)
MSVC JIT AVX2 2x8 128.00 (dual lanes,YMM regs)


In this test, where dual processor optimization was enabled, Intel performed poorly (though it still achieved twice the speed of MSVC). It seems that dynamically dispatching code fragments to different instruction sets incurs significant overhead.

Conclusion:

We should better avoid builds mixed-code sets.

Since AVX2 has been generally supported for at least ten years, creating a non-mixed AVX2-only compilation is a reasonable enhancement.

Looking at the numbers, achieving one-third the speed of the old SSE2 JIT, which we considered fast, is quite impressive.

Even x86/x64 users can benefit from this speedup: if the Expr contains specific trigonometric functions (tan, asin, acos, atan) that have no JIT implementation, then Avisynth cannot use JIT and falls back to the C implementation.

[pinterf]

Such a unique signature:

https://www.rationalqm.us/www.math.berkeley.edu/benrg/signature.gif

Ben Rudiak-Gould, original developer of Avisynth
Nice signature indeed!

See also: Clive Barker's Abarat

[tormento]

I wouldn't say it's stable :)
You read where I wrote that the last build is not working for me, didn’t you? [emoji6]

[pinterf]

You read where I wrote that the last build is not working for me, didn’t you? [emoji6]
Opps, not yet. Don't know, why. It was compiled with base (SSE2) + optional AVX2.

[tormento]

Opps, not yet. Don't know, why. It was compiled with base (SSE2) + optional AVX2.

Try to compile a dynamic one. :D

[pinterf]

Try to compile a dynamic one. :D
Then I receive not one but ten complaints about the necessary hundred megabytes overhead and systems which Intel screwed up. If you read back, you'll note that uvz builds are created exactly like this.
Try to do it yourself, I don't know what do you expect from this.

[tormento]

Try to do it yourself, I don't know what do you expect from this.
It was a joke… [emoji6]

[pinterf]

Anyway, a more detailed error report is needed than just "Script Error, Failed to load AviSynth+". The following information would always help a lot:

Are your experiences limited to r4610 ICX build, or do they also occur with the r4610 MSVC versions?
From which system did you receive the error message?
If possible (everything is possible :) ), please check with avsmeter64 to ensure avisynth loads correctly and maybe displays a reason, why it would fail. e.g. plugin's compatibility, etc.

[gispos]

Hello Ferenc,
please check the return version of the r4210 icx version
I see: 3.7.2 r3661
And various scripts therefore spit out an error message.

The new Avisynth icx versions are fast, I feel that everything is a bit faster and also the caching works better than with the previous versions.

Edit:
Everything back to square one!
That was a mistake. The r4210 cannot be loaded in AvsPmod and AvsPmod then loads another available Avisynth version if an alternative path is specified under Options.

So I have to agree with Tormento, the r4210 does not work.
It is also a lot smaller than the r4198, forgot what to link?

[StvG]

...
Intel (base + optional AVX2 paths) 1 1.01 (! Mixed instruction set support, slow)
...
Intel AVX2 optional AVX512 -Qax:AVX512 16 12.60 (! Mixed instruction set support, slow)
...


What are these? Separate source file only with the relevant instructions?

[Z2697]

MSVC is not Clang.
Visual Studio can use Clang.

ICC is based on LLVM. Clang is based on LLVM, even better, it's the official frontend for LLVM.
ICC will not beat Clang.

Blindly trusting an Intel fanboy is not a good choice.

��

tl;dr ICC compiler is simply the best one around. It produces clean, fast and stable code. Please stick with msvc or even better gcc and close your eyes whenever you see the words “intel” and/or ICC/ICX. Thank you.

Which just sound ridiculous.
I didn't even brought up the "brand fanaticism" topic. I mean, Intel surely had better days.

[StvG]

MSVC is not Clang.
Visual Studio can use Clang.

ICC is based on LLVM. Clang is based on LLVM, even better, it's the official frontend for LLVM.
ICC will not beat Clang.

Blindly trusting an Intel fanboy is not a good choice.



Which just sound ridiculous.
I didn't even brought up the "brand fanaticism" topic. I mean, Intel surely had better days.

ICC is the old/legacy Intel C/C++ Compiler.
ICX is the new one based on LLVM.

In some cases (libs/apps) clang produces faster binaries, in other cases icx produces faster binaries, in third cases msvc produces faster binaries, in fourth cases gcc produces faster binaries...
There is no such thing "ICX is the best", there is no "ICC will not beat Clang" (implying Clang is always better than ICC). Not to mention that same compiler from one version to another can produce binaries with different speed.

[DTL]

New day, new build.

AviSynth+ r4210.
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4210



ICX not working in Win10 even after installing lastst C++ runtimes.

Debugger output is very poor - simple some C++ exception at some address


'VirtualDub64.exe' (Win32): Loaded 'C:\Distr\VirtualDub2_44282\VirtualDub64.exe'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\user32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\win32u.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32full.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp_win.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\comdlg32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\combase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\SHCore.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\shlwapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\shell32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\bcrypt.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ole32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\oleaut32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\winmm.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvfw32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\avifil32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.4355_none_60b8b9eb71f62e16\comctl32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\winmmbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\bcryptprimitives.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\uxtheme.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Distr\VirtualDub2_44282\plugins64\avlib-1.vdplugin'. Module was built without symbols.
'VirtualDub64.exe' (Win32): Loaded 'C:\Distr\VirtualDub2_44282\plugins64\scripted.vdplugin'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msimg32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msctf.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\TextShaping.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\TextInputFramework.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\CoreMessaging.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\CoreUIComponents.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ws2_32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ntmarta.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\WinTypes.dll'.
The thread 0x4fc has exited with code 0 (0x0).
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\clbcatq.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\windows.storage.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\wldp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cfgmgr32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\propsys.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\profapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dwmapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Program Files\Common Files\microsoft shared\ink\tiptsf.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\edputil.dll'.
Exception thrown at 0x00007FF94B94B699 in VirtualDub64.exe: Microsoft C++ exception: MyWin32Error at memory location 0x0000000000CFA7D8.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\WindowsCodecs.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\thumbcache.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ntshrui.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\sspicli.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\srvcli.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cscapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\StructuredQuery.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\policymanager.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp110_win.dll'.
The thread 0x1fb0 has exited with code 0 (0x0).
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\DataExchange.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\d3d11.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dcomp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\dxgi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\twinapi.appcore.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\Windows.StateRepositoryPS.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\urlmon.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\netutils.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\iertutil.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\Windows.Storage.Search.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\apphelp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Users\USER\AppData\Local\Microsoft\OneDrive\25.025.0209.0001\FileSyncShell64.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\crypt32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\secur32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\wininet.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\wtsapi32.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\userenv.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\version.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\EhStorShell.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\setupapi.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\cscui.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\Windows.FileExplorer.Common.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\AviSynth.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\imagehlp.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\msvcp140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140_1d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\AviSynth.dll'
Exception thrown at 0x00007FF94B94B699 in VirtualDub64.exe: Microsoft C++ exception: MyAVIError at memory location 0x0000000000CFEF68.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\AviSynth.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\imagehlp.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\msvcp140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140_1d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\AviSynth.dll'
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\AviSynth.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1d.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'VirtualDub64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'.
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\imagehlp.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\msvcp140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\ucrtbased.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140d.dll'
'VirtualDub64.exe' (Win32): Unloaded 'C:\Windows\System32\vcruntime140_1d.dll'
'VirtualDub64.exe' (Win32): Unloaded
<- start opening 'version' script

'C:\Windows\System32\AviSynth.dll'
Exception thrown at 0x00007FF94B94B699 in VirtualDub64.exe: Microsoft C++ exception: MyError at memory location 0x0000000000CFF428.

[pinterf]

What are these? Separate source file only with the relevant instructions?
No, it's for code generation. It optimizes for more than one (i.e., two) instruction sets. In the IDE, they appear under Code Generation (Intel).

The /Qax flag generates a secondary code path, allowing the program to dispatch between the base and optional versions at runtime. While I generally think this is beneficial (similar to what we do manually within Avisynth and plugins), and even MSVC does this (running SSE4.1 code instead of the base SSE2 path after checking an internal flag), in Expr, it has such a significant overhead that it kills performance. I tried "Not Set + Optional AVX2" and "AVX2 + Optional AVX512," but both failed to do what I expected. As you can see it in the benchmarks.

The rest of this VS2022/Intel specific page (two more) are optimizer options that fine-tune for a specific architecture, I guess, considering factors like cache, ports, and typical uOps.

So, while it's a good feature, I better avoid using it in the future.

[pinterf]

Hello Ferenc,
please check the return version of the r4210 icx version
I see: 3.7.2 r3661
And various scripts therefore spit out an error message.

The new Avisynth icx versions are fast, I feel that everything is a bit faster and also the caching works better than with the previous versions.

Edit:
Everything back to square one!
That was a mistake. The r4210 cannot be loaded in AvsPmod and AvsPmod then loads another available Avisynth version if an alternative path is specified under Options.

So I have to agree with Tormento, the r4210 does not work.
It is also a lot smaller than the r4198, forgot what to link?
@gispos, DTL, do no more test, don't waste your time. I'm creating a new build set (Expr changes) and will try to set only _one_ instruction set optimization at a time.

[pinterf]

This new build follows the latest Expr commits.

Since the modification affected the C (slowish) part of Expr, you won't see any new features here. With the Intel build, I stayed on the safe side. May the pink ponies be with you.

Avisynth 3.7.3 r4212.
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4212

By now, I'm more or less ready with implementing my ideas. Some other ideas are waiting in the Issues section, but they are not easy ones.

[real.finder]

I wouldn't say it's stable :) Using a good static library ensures that Intel cannot mess it up later with a bad driver or library update (like they did with version 2025.0.0 and their OpenCL driver).

so it was driver problem after all? https://forum.doom9.org/showpost.php?p=2013760&postcount=1584 did they fix it?

[Z2697]

ICC is the old/legacy Intel C/C++ Compiler.
ICX is the new one based on LLVM.

In some cases (libs/apps) clang produces faster binaries, in other cases icx produces faster binaries, in third cases msvc produces faster binaries, in fourth cases gcc produces faster binaries...
There is no such thing "ICX is the best", there is no "ICC will not beat Clang" (implying Clang is always better than ICC). Not to mention that same compiler from one version to another can produce binaries with different speed.

OK, ICX then. I do understand that sometimes one thing is better and some other times another thing is better, I mean it's possible that ICX can be better than Clang sometimes, but it will not beat Clang, does this makes sense? If you understand that as "implying ICX is not always better than Clang" not the other way around?

[DTL]

By now, I'm more or less ready with implementing my ideas. Some other ideas are waiting in the Issues section, but they are not easy ones.

Waiting for 2D resampler engine inside AVS+ core in 202x years. It also work in avs-libplacebo plugin - but it is GPU-only as I understand.

[tormento]

Avisynth 3.7.3 r4612
Thanks, now working here.

[FranceBB]

By now, I'm more or less ready with implementing my ideas. Some other ideas are waiting in the Issues section, but they are not easy ones.

XYZ support so that we don't have to spoof it as a fake RGB64 (i.e RGB 16bit)?

[DTL]

" 16bit"

16bit may be also float half-precision. It may be good for HDR linear. Because current civilization fail to do fast enough RAM for computing systems - usage of float16 allow to double performance with enough (acceptable) precision for visual systems.

But old CPU cores do not support float16 processing (conversion from float32 to float16 and back) ?

Also float16 will half RAM usage for float samples formats and it may be good for current AVS+ multithreading and caching model.

[pinterf]

Waiting for 2D resampler engine inside AVS+ core in 202x years. It also work in avs-libplacebo plugin - but it is GPU-only as I understand.
I've just documented your "new" resizers. Developers like documenting; this has always been the case. :) Please check and let me know if there are any major mistakes in it. Thank you in advance.
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html

[DTL]

I tried to register at the AVS wiki to add about new resizers but I have not received an activation email for months at my @gmail.com email address.

"SincLin2Resize (v3.7.3-) A high-quality resizer that supplements SincResize, designed to maintain performance with increased sinc taps for minimal artifacts."

It is a version of SincResize with a workaround for the 'kernel edge computing issue' of the original SincResize kernel. It is a bit more sharp in comparison with other weighted sinc kernels with the same number of taps used (like Lanczos or Blackman). To suppress that computing errors below 1 LSB of 8 bit recommended number of taps > 3..4. With too low taps used it still may expose that issue. For higher precision computing (> 8bit per sample) the minimum number of taps to shift residual computing error below 1 LSB may be higher.

Both SinPow and UserDefined2 resizers allow to control the 'acutance' effect of the output while saving from too much ringing (in some range of control params). Link to wiki for 'acutance' https://en.wikipedia.org/wiki/Acutance . Acutance of Gauss kernel may be treated as 'zero level' and for SinPow and UserDefined2 may be > zero (depending on control params).

For UserDefined2Resize:

"b: Controls the blurring. Optimal range: -50 to 250.
c: Controls the ringing. Optimal range: -50 to 250.
s (support): Controls the support size. Default is 2.2. Valid range: 2.0 to 4.0."

-50 to 250 are Valid range (values outside this range are typically of no sense and are clipped to -50 to 250). Though recommended c-values may be as low as -40 so the low range clipping may be expanded to -60 or lower.
s-value expected to have a valid range of about 1.8 to 4.0 (or more). 2.0 is too high clipping for low values. Sometimes s-values as low as 1.8 are still usable in some cases.

Typical usable range for b is 70..130 and for c is -30 to 23.

The b and c values are generally interconnected via table or recommended values. Where b typically looks like control for 'sharpness look/makeup' and c looks like a supplement to balance kernel to produce as low ringing as possible. Tables of recommended b and c values may be used as image form or transformed to HTML formatted table form for text-like documentation.
https://i.postimg.cc/sDRhLP1t/image-2025-03-08-015558168.png
where columns were planned as 'overshoot/acutance' view of the output but only single combination of b and c may produce the minimal ringing for each b and c pair (but may also depend on source sharpness (Fourier spectrum)). Table of the recommended b and c values may be mostly valid for high enough downsampling ratios like 10:1 or more but typically usable also to about 2:1 and less. So b > 130 typically close to GaussResize with 'zero acutance' ('film' look/makeup) and b < 95 produces high levels of sharpness/acutance ('video' look/makeup). For initial setup c value must follow b value from table and may be adjusted for each source to minimize ringing.
Internally it is based on a sum of weighted sinc functions by b and c params. With b=c=16 it is equal to SincResize with given support size by s-param.

"The default values of b and c (121/19) create a very soft result. It may be better to use sharper values like 90/-12."

Better version: The default values of b and c (121/19) create a soft film-like look/makeup. It may be better to use sharper values like 80/-20 with higher 'sharpness/acutance'.

s-param description: It controls the used part of the computed kernel in the resampler. Also affect the resampler' performance (more support - less performance). Most sinc-based resizers have support=taps.
For UserDefine2Resize it is possible to manually control support value: Low values like 1.8..2.2 may give some additional 'crispening' effect (while can cause more ringing). High values like 3..4 and more required for more linear processing (highest level of ringing suppression). Also the 'wide-long' soft kernels like b=210 c=98 may require larger support to save from too early kernel truncation in a resampler. If the kernel decays very fast - too much support param may be useless wasting of the computing resources. Higher values of support param may be required for highest precision computing using float samples formats.

SincLin2Resize taps count:
"It is designed to be "not-worse" in full-strike sinc taps count. Recommended to set SincLin2(taps) to two times larger than SincResize(taps)."

Better version: It provides at least taps/2 full-strike sinc taps (lobes ?) count before beginning of linear weighting to zero at the end of the kernel. Recommended to set SincLin2(taps) to two times larger in comparison with previously used SincResize(taps) in old projects. While performance of the resampler will degrade proportionally to taps value used". Taps param controls the balance between performance and quality and ringing length (if present).

"Range:
1-20 for SincResize"

As I remember taps param upper limit for SincResize was relaxed to 150 or more to show how that computing issue may go below 1 LSB for 8 bit with taps > about 80. Need to check current sources for current limit value.

For p-param of SinPow :
"Useful for creating content conditioned to the Nyquist frequency, reducing aliasing and ringing."

Better version: Useful for creating content conditioned to the band-limited channel, reducing aliasing and Gibbs-ringing.

Useful note about resizers usage:
The set of SinPower/UserDefined2 and Sinc/SincLin2/Lanczos/Blackman resizers form a complementary set of resizers for sinc-based workflow for digital imaging with controlled sharpness and ringing. Where SinPowerResize or UserDefined2Resize used for content-creation as downscaling (compressing) and any sinc-based resizer used for upscaling for displaying or intermediate processing (interpolation, decompressing).

Addition 2 to the Notes:
Most (except Point ?) resizers can be used for convolution processing with its kernel without resampling. To enable (force) processing, users must set non-zero values for src_left and/or src_top params (depending on the required dimensions for processing). To save from visible shifting the values must be very low floats (like 0.000001 - need to check the lowest acceptable as non-zero float value ?).

[wonkey_monkey]

I think I've found another version of this old issue (https://forum.doom9.net/showthread.php?p=1849921) (has it really been six years?!):

version.crop(8,32,16,16)
animate(0,100,"bicubicresize",\
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0)

There's a discontinuity at frame 50 because resizing is skipped. With b=1.0/3.0, c=1.0/3.0 (which is the default), or indeed anything other than b=0,c=0.5 (which I still maintain should be the default :sly: ), BicubicResize always blurs or sharpens its output, regardless of resizing, and that blur is missing from frame 50.

[ryrynz]

I've just documented your "new" resizers. Developers like documenting; this has always been the case.


https://i.imgur.com/Yh1tPCKm.jpeg

[pinterf]

I think I've found another version of this old issue (https://forum.doom9.net/showthread.php?p=1849921) (has it really been six years?!):

version.crop(8,32,16,16)
animate(0,100,"bicubicresize",\
16,16,1.0/3.0,1.0/3.0,-1.0,-1.0,\
16,16,1.0/3.0,1.0/3.0, 1.0, 1.0)

There's a discontinuity at frame 50 because resizing is skipped. With b=1.0/3.0, c=1.0/3.0 (which is the default), or indeed anything other than b=0,c=0.5 (which I still maintain should be the default :sly: ), BicubicResize always blurs or sharpens its output, regardless of resizing, and that blur is missing from frame 50.
Strange, I've just came across it in the change log when I was looking for documentation hints. I remember it having been fixed.
"Resizers: don't use crop at special edge cases to avoid inconsistent results across different parameters/color spaces"

EDIT:
One condition is left there:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/resample.cpp#L941
and
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/resample.cpp#L972