AviSynthShader + SuperRes

[Groucho2004]

Any idea what this means and what I can do about it?There are several possibilities. This could be resolved in minutes if you would do what I suggested.

[jrodefeld]

There are several possibilities. This could be resolved in minutes if you would do what I suggested.

Okay, I've been running AVSMeter and it crashes before it is done. The error is:

"AVSMeter - Avisynth Script Testing has stopped working"

Before it did crash, it did say that d3dx9_43.dll was missing. I installed it and I don't get the same error anymore, I'm getting a different error.

Now it says "Avisynth open failed: Shader: Failed to open pixel shader YuvToLinear.hlsl"

Not sure what that means. Maybe I can get AVSMeter to run all the way through without crashing. Or maybe you or someone else knows what the above error means.

[Groucho2004]

Now it says "Avisynth open failed: Shader: Failed to open pixel shader YuvToLinear.hlsl".
I'm sure the author will help you with that, I'm not familiar with this shader thingy.

Maybe I can get AVSMeter to run all the way through without crashing. Or maybe you or someone else knows what the above error means.
Once you have all required files in the right places it will surely run.

[MysteryX]

d3dx9_43.dll was missing? Was OS are you using for not having DirectX9?

It looks for HLSL files in the same folder as the DLL. Make sure they are at the right place. To make sure the right DLL is being loaded, you can place those in a separate folder and use LoadPlugin on the DLL.

[jrodefeld]

I got it to work! I don't know why, but when I used an older version of the AviSynthShader package, it worked fine. The new version didn't work for me for some reason.

Anyway, I haven't had a chance to fully test it out yet, but this probably will be my default method of upscaling from now on.

[MysteryX]

Version 1.5.2 is ready (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.5.2)

What's new:
- All standard shader files are now included within the DLL.
- If a shader file of the same name is also found in the DLL's folder, that one will be taken first.
- Recompiled with AviSynth+ r2022's headers. It won't won't work with older AviSynth+ (AviSynth 2.6 is OK)

[citroenfan]

Thank you very much MysteryX for your time and effort to write this script and to make it better and better.
I'm using it for upscaling material in SD resplution (720×576 pixels, living in PAL country) to HD.
Together with QTGMC and VideoFred/Johnmeyer scripts (for some other restoration work)
it gives really good results.

Working with various avisynth scripts almost ten years now, so I think I'm relative skilled with this.

I'm using your script from version 1.3.1 (when I found it).
Last version which I'm using without problems is 1.4.6.
But with versions from 1.5.0 I'm having a problem, I could not make them to work, tried everything I know.

My computer is running Windows7 64 bit, but as most avisynth plugins I'm using are 32bit (there is no 64bit versions for some of them or if exist they are buggy or not working with particular avisynth or...)
all my work is in 32bit chain.

Shader.dll is in Avisynth/plugin folder, as superres.avsi (for working 1.31) or shader.avsi (when working with 1.46).

When working with shader.dll from version 1.3.1., script version 1.3.1 (SuperRes.avsi) and up-scaling material in 960×720pixels to 1440×1080pixels with MT version of Avisynth 2.60 I'm geting speed about 6,90fps.

When working with shader.dll from version 1.5.2., script version 1.3.1 (SuperRes.avsi) and up-scaling material in 960×720pixels to 1440×1080pixels with MT version of Avisynth 2.60 I'm getting speed about 30,50fps.

When tried to get the script 1.52 to work, I only get the message "Failed to open pixel shader YuvToLinear.hlsl"

In attachments I send you avsmeter logs so maybe you can see what went wrong and help me to correct the problem.

Thank you once more and best regards.

[MysteryX]

Strange. The latest version includes all the HLSL and CSO files within the DLL.

Try copying all these files into the same folder as the DLL to see if that helps.
https://github.com/mysteryx93/AviSynthShader/tree/master/Src/Shaders

I can't yet read the log files until they are approved.

Try running the files manually with something like this

input = ConvertToShader()
Shader("YuvToGamma.hlsl")
Shader("GammaToYuv.hlsl")
last.ExecuteShader(input)
ConvertFromShader()


Let me know what you find out. Is there the possibility of regional settings with the "." causing interference somewhere? I don't know.

[luigizaninoni]

I have exactly the same issue as citroenfan.

Putting the files that you linked in the same folder as the dll does not help

Running the files manually with
input = ConvertToShader()
Shader("YuvToGamma.hlsl")
Shader("GammaToYuv.hlsl")
last.ExecuteShader(input)
ConvertFromShader()

works perfectly

If I use shader.dll from 1.5.2 but shader.avsi from 1.4.6 it works.

So I suppose that the problem lies in shader.avsi (in the changes after 1.4.6)

[luigizaninoni]

Also, how would I check if regional settings are a problem ? My regional settings are Italian, so . for 1.000 (one thousand) and , for 1,32 (one point thirty-two)

[MysteryX]

When using 601 color matrix, it passes floating-point values to configure the conversion shaders before compilation. Perhaps that's where it's failing. If you stick to 709 color matrix, does it work? You can also play with the AVSI file and trim it down until you get to the issue.

[luigizaninoni]

When using 601 color matrix, it passes floating-point values to configure the conversion shaders before compilation. Perhaps that's where it's failing. If you stick to 709 color matrix, does it work? You can also play with the AVSI file and trim it down until you get to the issue.

With 709 it does not work either

[MysteryX]

Are you able to do a simple ResizeShader with Bicubic? Which functions fail and which ones work? By playing around with the AVSI file, you can narrow down the part that isn't working.

If even the Bicubic ResizeShader doesn't work, you can copy its script code into your main script and simplify it until you get it to execute.

[luigizaninoni]

DGSourceIM("F:\work\prova_temp\prova.dgim")
SuperXBR()

works

SuperRes doesn't work

[luigizaninoni]

DGSourceIM("F:\work\prova_temp\prova.dgim")
SuperRes(2,0.65,0.0,"""nnedi3_rpow2(2, cshift="Spline36Resize",fwidth=1920,fheight=1080)""")

not working

[luigizaninoni]

Trying to simplify,
DGSourceIM("F:\work\prova_temp\prova.dgim")
SuperRes(2,0.65,0.0,"""nnedi3_rpow2(rfactor=2)""")

does not work

[luigizaninoni]

I am unable to reproduce it now, but avsmeter gave an error message concerning line 121 of shader.avsi - which is eval(upscale)

[MysteryX]

Are you using MT with a version of NNEDI3 that has an issue with MT mode? A new version of NNEDI3 was released to fix that.

[luigizaninoni]

it looks unbelievable, but avsmeter every four or five attempts is able to run:
DGSourceIM("F:\work\prova_temp\prova.dgim")
SuperRes(2,0.45,0.01,"""nnedi3_rpow2(2, cshift="Spline16Resize")""")

without errors. The other attempts end with system access violation, or no message at all

Every other application (avspmod, staxrip, mpchc, virtualdub) are unable to open the script, and exit without error message

[luigizaninoni]

my nnedi3 version is 9.4.22, it is the latest as far as I know. released on 30 may 2016

[luigizaninoni]

and I am running the script single-threaded, anyway. With AVS+ 64-bit

[MysteryX]

And this happens *only* with SuperRes? All other functions are working fine?

Do you have the latest version of AVS+?

[luigizaninoni]

SuperXBR, SuperResXBR, ResizeShader all work

Only superres doesn't

That's all there is to try, isn't that ?

My avs+ is the latest (r2022)

[MysteryX]

Does NNEDI3 on its own work? oh... maybe it hasn't been recompiled with the latest AVS headers.

[luigizaninoni]

Yes it works. I use it all' the time. Actually I Can use shader.dll from 1.5.2 and shader.avsi from 1.4.6 and everything works fine. (i don't know if it is totally correct though). I simply have to put all' the cso and hlsl in the same folder. Shaders.dll 1.5.2 seems much faster than 1.4.6

[MysteryX]

I'm getting an Access Violation on
nnedi3_rpow2(2,nns=4,cshift="spline16")

I don't even know if an updated version has been published; haven't seen it.

Try with AviSynth 2.6, that might work as it won't be affected by the AVS+ header change issue.

[luigizaninoni]

Thanks, I'll try again if a new version of nnedi3 comes out

[loneboyz]

When tried to get the script 1.52 to work, I only get the message "Failed to open pixel shader YuvToLinear.hlsl"


I also get a similar error above, the current I'm running Avisynth 2.6 32bit on system Window 7 x64 Ultimate. I can't running begin from ver 1.51 onward

[MysteryX]

I can't get NNEDI3 to work, either with AviSynth 2.6 or AVS+; that will need to be fixed first.

If I remove sub-pixel shift from NNEDI3, however, it works.
This runs fine for me with AviSynth 2.6

SuperRes(Upscale="""nnedi3_rpow2(2)""", MatrixIn="Pc601", MatrixOut="709")


I cannot reproduce the problem with YuvToLinear.hlsl

[MysteryX]

OK I'm seeing something wrong with the latest version. Although it is supposedly MT_NICE_FILTER, I just saw I was mistakenly still registering it as MT_MULTI_INSTANCE. Which means that when running 8 threads, it might actually be creating 16 engines!? With MT_NICE_FILTER it is freezing and giving access violation. Need to investigate more.

It's surprising that memory usage and performance were still good! We might have another performance boost surprise then :)

[MysteryX]

- Fixed: Filter was accidentally being registered as MT_MULTI_INSTANCE on AviSynth+
- Fixed: Filter did not work with MT_NICE_FILTER
- Fixed: Filter wasn't creating the second core (back to square one with MT_MULTI_INSTANCE)
- ExecuteShader: Added Engines parameter to specify the number of cores to run when using MT_NICE_FILTER

Engines is 2 by default, and in heavy scripts where you are calling at least 2 Shader functions, you can get a small performance boost by setting Engines to 1.

However, I'm not able to reproduce the issue you guys are having. I don't think you're affected by the bug I just fixed; yours was behaving exactly as if it was a simple MT_MULTI_INSTANCE filter. I'd want this solved before releasing a new version.


To Groucho who said that reducing the scope of the lock wouldn't make a difference because memory transfers don't take any time, results show otherwise.

ColorBarsHD(width = 352, height = 288, pixel_type = "YV24").killaudio().assumefps(25, 1)
SuperResXBR(Engines=2)
SuperResXBR(Engines=2)
Prefetch(8)

With thread lock excluding transfers in/out:

FPS (min | max | average): 3.021 | 1000000 | 24.53
Memory usage (phys | virt): 245 | 255 MiB
Thread count: 43
CPU usage (average): 5%

With a unique_lock at the beginning of GetFrame (which behaves similarly to MT_SERIALIZED)

FPS (min | max | average): 1.247 | 1000000 | 20.46
Memory usage (phys | virt): 223 | 233 MiB
Thread count: 45
CPU usage (average): 2%

It's easy to verbally assault people. Just make sure what you say makes sense. Otherwise it's called trolling, and it goes against the forum rules. You should already know that.

[TurboPascal7]

With a unique_lock at the beginning of GetFrame (which behaves similarly to MT_SERIALIZED)
It doesn't behave similarly to MT_SERIALIZED. It blocks every bloody thread in the core.

Imagine you've got a filter chain with 100500 filters and only one of those filters is MT_SERIALIZED. When the core has to execute that MT_SERIALIZED filter, it can use exactly one thread for it. Other threads are free to do other stuff, like executing some filter calls required for the next frame.

Now imagine that filter is registered as MT_NICE_FILTER and has an unique_lock inside its GetFrame. The core happily tries to run that filter in multiple threads at the same time, blocking every single thread but one. Now those threads can do exactly nothing but simply idle there waiting for their turn. So in essence you just ruined every possible optimization the core might have for filter chains with MT_SERIALIZED filters. Good job.

[MysteryX]

Calls to MT_SERIALIZED come from various threads. As for the implementation/optimizations details, I don't know much more, except that MT_SERIALIZED really is a crutch on performance.

[TurboPascal7]

Calls to MT_SERIALIZED come from various threads.
Not at the same time.

[MysteryX]

No, not at the same time. In complex scripts where the CPU is the bottleneck, AVS probably has an opportunity for small optimization by routing threads elsewhere. In this demo script, however, that makes no difference as there's nothing else to run.

Bottom line is: don't use MT_SERIALIZED unless for source filter or for compatibility, and reduce the scope of locks.

[TurboPascal7]

In complex scripts where the CPU is the bottleneck, AVS probably has an opportunity for small optimization by routing threads elsewhere. In this demo script, however, that makes no difference as there's nothing else to run.
My point exactly. You're actively making your filter worse for anything but trivial benchmarks. Moreover, you give other people wrong advice to mark filters as nice and then using locks internally to prevent crashes. Please stop doing that.

[Groucho2004]

To Groucho who said that reducing the scope of the lock wouldn't make a difference because memory transfers don't take any time, results show otherwise.
What? I merely pointed out your tendency to blame the poor performance results of your outlandish experiments on memory performance - in a different thread and context, by the way. I think you're losing your grip on reality.

[MysteryX]

TurboPascal, you have a good point that MT_SERIALIZED does give AVS an opportunity for optimization in complex scripts. Let's see how it shows up in real-life.

Plain script

ColorBarsHD(width=800, height=600, pixel_type="YV24").killaudio().assumefps(25, 1)
SuperResXBR(Engines=1)
Prefetch(8)

MT_SERIALIZED
FPS (min | max | average): 1.571 | 1000000 | 22.75
Memory usage (phys | virt): 213 | 215 MiB
Thread count: 28
CPU usage (average): 2%

MT_NICE_FILTER
FPS (min | max | average): 2.498 | 1000000 | 23.51
Memory usage (phys | virt): 237 | 238 MiB
Thread count: 28
CPU usage (average): 3%

2 Engines
FPS (min | max | average): 3.160 | 1000000 | 26.81
Memory usage (phys | virt): 276 | 279 MiB
Thread count: 33
CPU usage (average): 4%


Let's try on my full script to upscale 288p to 768p. Script includes KNLMeans, 2x SuperResXbr, InterFrame and various 16-bit tools.

MT_SERIALIZED
FPS (min | max | average): 1.080 | 19.69 | 7.930
Memory usage (phys | virt): 643 | 698 MiB
Thread count: 49
CPU usage (average): 9%

MT_NICE_FILTER
FPS (min | max | average): 3.436 | 1000000 | 13.27
Memory usage (phys | virt): 680 | 736 MiB
Thread count: 52
CPU usage (average): 27%

No point in setting 2 engines because there are already 2 shader functions


or let's try heavier GPU processing with complex CPU work

ColorBarsHD(width=1940, height=1080).killaudio().assumefps(25, 1).ConvertToYV12()
SMDegrain(thsad=200, prefilter=2, lsb=true)
SuperResXBR(5, 1, .15, fWidth=2600, fHeight=1500, fKernel="SSim", Engines=1)
Prefetch(8)

MT_SERIALIZED
FPS (cur | min | max | avg): 1.809 | 0.218 | 1.903 | 1.729
Memory usage (phys | virt): 1036 | 1044 MiB
Thread count: 34
CPU usage (current | average): 16% | 17%

MT_NICE_FILTER
FPS (cur | min | max | avg): 3.531 | 0.311 | 1000000 | 3.059
Memory usage (phys | virt): 1109 | 1125 MiB
Thread count: 34
CPU usage (current | average): 34% | 32%

2 Engines
FPS (min | max | average): 0.260 | 1000000 | 2.713
Memory usage (phys | virt): 1184 | 1203 MiB
Thread count: 39
CPU usage (average): 33%


Flawless Victory

Edit: I just fixed something that fixes an occasional image corruption and further improves performance. My full script went from 13.27fps to 16fps.

I think this closes the topic of MT_SERIALIZED vs MT_NICE_FILTER with lock (MT_SERIALIZED going back to its grave).

The last test is curious; performance is lower with 2 engines, but then there's an unknown bottleneck within SMDegrain.

What? I merely pointed out your tendency to blame the poor performance results of your outlandish experiments on memory performance - in a different thread and context, by the way. I think you're losing your grip on reality.
I don't try to speculate on the cause. I simply show benchmarks.

The situation with KNLMeans really isn't very different than here. In fact the issues are exactly the same.

[MysteryX]

For the crash, currently NNEDI3 and AviSynthShader are not compiled with the same headers, and thus won't work together in AviSynth+ until NNEDI3 is recompiled.

So for now use AviSynth 2.6 for testing.

Oh, I think I know what's happening. If you're not using the latest build of NNEDI3, it works fine with AVS+ as it doesn't try to self-register its MT mode; but crashes if trying to run as MT_NICE_FILTER. Perhaps it starts crashing from the versions of AviSynthShader that self-register as MT_NICE_FILTER which also cause NNEDI3 to run as MT_NICE_FILTER.

Using edi_rpow2.avsi works, otherwise you'll have to use AviSynth 2.6 for now.

[MysteryX]

Version 1.5.3 is ready! (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.5.3)
- Fixed: Filter was accidentally being registered as MT_MULTI_INSTANCE on AviSynth+
- Fixed: Filter did not work with MT_NICE_FILTER
- Fixed: Filter wasn't creating the second core (back to square one with MT_MULTI_INSTANCE)
- ExecuteShader: Added Engines parameter to specify the number of cores to run when using MT_NICE_FILTER
- MT_NICE_FILTER now working as expected
- Performance boost and lower memory usage

This time the AVX build isn't included as the script isn't currently using any conversion to float.

Next will be to support converting to/from the new Avisynth+ INT16/FLOAT types.

[loneboyz]

Upgrade the script 1.53, I still get an new error message "Failed to open pixel shader YuvToGamma.hlsl"

[MysteryX]

Upgrade the script 1.53, I still get an new error message "Failed to open pixel shader YuvToGamma.hlsl"
Which function gives you that error? Do the other functions work? This can also depend on the video format you're working with.

As the old saying goes, post your script.

[loneboyz]

As the old saying goes, post your script.

I'm try this script

ColorBars(pixel_type="YV12")
KNLMeansCL()

SR_Path = "F:\Setup\Encode\Tools\Avisynth.Plugin\AviSynthShader-1.5.3\"
LoadPlugin(SR_Path + "Shader.dll")
Import(SR_Path + "Shader.avsi")

SuperResXBR(3, Str=1, Soft=.15, XbrStr=2.5, XbrSharp=1, fWidth=720, fHeight=576)

[MysteryX]

This script works here.

Can you try with ConvertToRGB() ? That way it will skip YUV-RGB conversion.

[loneboyz]

I tried with ConvertToRGB() before call SuperResXBR, but not success

It's appear another message "Failed to open pixel shader SuperXBR.hlsl"

[MysteryX]

Then D3DXCompileShader fails on your system for some reason.

What OS are you using? Do you have DirectX 9c installed? (https://www.microsoft.com/en-us/download/details.aspx?id=34429)

[loneboyz]

Now, my system Windows 7 Ultimate 64bit (6.1 Build 7601), DirectX version 11. Tks!

[MysteryX]

Transferring the question to gamedev.net (http://www.gamedev.net/topic/680313-d3dxcompileshader-failing-on-user-computer/)... ah... might have something to do with the D3DXCompileShader function I'm using being deprecated. Edit: Searching online, using the newer D3DCompile gives error on Windows 7 with missing D3dcompiler_47.dll

Now I'm thinking. You take 16-bit output, dither to 8-bit YV24, then convert to YV12. The chroma dithering is kind of lost in the resize.

Wouldn't the quality be better if I'd resize the chroma in 16-bit, and then apply dithering to each plane and output YV12 data directly? We'd also get a serious performance gain by having YV12 output instead of YV24. This would however require considerable changes to the code structure. We'd get gains both on quality and performance.

[loneboyz]

The problem still can not be solved although I copied to SysWOW64 with missing D3dcompiler_47.dll, and I'm continuing to search

MysteryX, thank a lot for your help

[MysteryX]

Can you try installing DirectX 9c and see if that helps?

If not, can you try installing DirectX SDK (June 2010) and see if that helps?

That would help identify the issue.

Edit: Apparently it does indeed have dependencies on DX redistributables that must be installed separately. Since running the script with pre-compiled files does work, then it's only that function that has a bunch of dependencies. I'll try to instead use D3DCompile and to ship D3dcompiler_47.dll with it.