Internaly multi-threaded resampling functions

[jpsdr]

ResampleMT 1.5.3 x86 XP SSE4.2 doesn't work on Windows XP x86, although the normal XP executable works fine (the one without assembly optimizations)
All have the same optimisations, it's just that the SSE4.2 (and all others) are compiled with SSE4.2 (or others) settings in the Intel compiler. I have unfortunately no idea why it's not working, maybe the compiler generate "more" than SSE4.2...:confused:
Just switch to "standard", the only difference is that it's compiled with Visual Studio, without specific CPU.
Maybe test also the "all in one" plugin, with resample and nnedi in the same dll.

[FranceBB]

I see. I compiled it with Visual Studio with no problem in SSE and SSE2. The only problem is that Visual Studio doesn't have the option to optimize to something greater than SSE2, and compilation fails with GCC and OpenWatcom.
I'm downloading Intel Parallel Studio XE 2016 right now :)
Also, I modified afxres.h
//#include "afxres.h"
#include "WinResrc.h"
#define IDC_STATIC -1
in order to be able to compile it with Visual Studio Express :)

[jpsdr]

New version, see first post (minor update).

[FranceBB]

Tested in Windows XP SP3 x86. I'm still getting an error with XP_SSE4.2, but it's not a big deal,
'cause normal XP Release works flawlessly. Thanks! ^_^

[jpsdr]

New version, see first post (minor update).

[jpsdr]

New version, minor change, see first post.

[jpsdr]

New version, see first post.

[Atak_Snajpera]

Do we really need so many builds for specific extension. One for SSE4.2 another for AVX,AVX2,AVX-512.

On my SandyBridge (Xeon E5-2690) binary from Release_W7/XP folder is the fastest.

Script
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\RawSource\RawSource.dll")
video1=RawSource("E:\_Video_Samples\y4m\crowd_run_1080p50.y4m")
video2=RawSource("E:\_Video_Samples\y4m\park_joy_1080p50.y4m")
video3=RawSource("E:\_Video_Samples\y4m\ducks_take_off_1080p50.y4m")
video4=RawSource("E:\_Video_Samples\y4m\in_to_tree_1080p50.y4m")
video5=RawSource("E:\_Video_Samples\y4m\old_town_cross_1080p50.y4m")

return video1+video2+video3+video4+video5

Resizer used:
Spline36ResizeMT(1280,720)


SSE 4.2
AVSMeter 2.2.6 (x86)
AviSynth 2.60, build:Mar 31 2015 [16:38:54] (2.6.0.6)
Loading script...

Number of frames: 2500
Length (hh:mm:ss.ms): 00:00:50.000
Frame width: 1280
Frame height: 720
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 2500 (0 - 2499)
FPS (min | max | average): 127.8 | 172.1 | 153.0
Memory usage (phys | virt): 527 | 523 MiB
Thread count: 17
CPU usage (average): 14%

Time (elapsed): 00:00:16.341

AVX
AVSMeter 2.2.6 (x86)
AviSynth 2.60, build:Mar 31 2015 [16:38:54] (2.6.0.6)
Loading script...

Number of frames: 2500
Length (hh:mm:ss.ms): 00:00:50.000
Frame width: 1280
Frame height: 720
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 2500 (0 - 2499)
FPS (min | max | average): 130.4 | 173.3 | 154.0
Memory usage (phys | virt): 527 | 523 MiB
Thread count: 17
CPU usage (average): 14%

Time (elapsed): 00:00:16.232


Release_W7/XP
AVSMeter 2.2.6 (x86)
AviSynth 2.60, build:Mar 31 2015 [16:38:54] (2.6.0.6)
Loading script...

Number of frames: 2500
Length (hh:mm:ss.ms): 00:00:50.000
Frame width: 1280
Frame height: 720
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 2500 (0 - 2499)
FPS (min | max | average): 133.5 | 180.2 | 159.7
Memory usage (phys | virt): 527 | 522 MiB
Thread count: 17
CPU usage (average): 13%

Time (elapsed): 00:00:15.657

Is above compiled with default microsoft's compiler? What extensions did you use?

[TheFluff]

I'm getting removegrain flashbacks, here. Please don't trigger my PTSD.

Jokes aside, I'm pretty sure it's been repeatedly pointed out in several different places by several different people that compiling NNEDI with AVX2 (or SSE4.2 for that matter) does pretty much nothing to improve performance because there's nothing performance critical the compiler can potentially autovectorize, but that doesn't stop d9 posters from cargo cult optimizing by flipping all the compiler switches. Benchmarking is for nerds.

e: jpsdr was specifically told about this over a year ago (https://forum.doom9.org/showthread.php?p=1779552#post1779552) but, well. The internet is all FAKE NEWS anyway, can't trust anyone on here.

[jpsdr]

Do we really need so many builds for specific extension.
Maybe not, but i rather continue to make them, just in case. In the worst case, it's just my time i'm waisting making all of these builds.
For exemple, it may just be a tiny optimisation, but who knows if on functions like memcpy, the compiler it's not using different code according the instructions setting...?



...
Release_W7/XP
...
Is above compiled with default microsoft's compiler? What extensions did you use?
Yes, as said in the ReadMe, and it's archsee2.

[TheFluff]

For exemple, it may just be a tiny optimisation, but who knows if on functions like memcpy, the compiler it's not using different code according the instructions setting...?

Optimizing memcpy does effectively nothing for Avisynth. This has been shown empirically in the past. ultim had a bitblt (effectively memcpy for video frames) that was over 20% faster in benchmarks of only that routine, but it produced no measurable speedup in actual filter chains. Your imagination is not a functional optimization tool, so please stop trying to use it for that. You might as well try optimization by means of voodoo dolls.

All you're doing is confusing your users, who are expecting you (who is, after all, the authoritative expert on your own software) to know what you're doing.

[hello_hello]

I don't see the problem. If RemoveGrain peaked high on the confusion scale, the current needi3 releases would barley register. Each new release comes as a single 7z file containing an organised assortment of nnedi3.dlls. One for every occasion. Pick the one that takes your fancy based on CPU and OS and you're good to go.... links to the appropriate runtime files included..... and no pleading for an XP version required.....

[AzraelNewtype]

Did you miss the benchmarks above showing that if a user were to naively choose the version that actually matches their CPU, they would be lowering their performance compared to the generic one?

[jpsdr]

Personnaly, when i'm doing benchmark, i'm doing it from Colorbars video. At least, i'm sure i'm only benchmarking the filter, and not the codec, hdd access or anything else.
Doesn't mean it will necessary change the results, of course, but at least, you're sure of what you've benchmarked.

[hello_hello]

Did you miss the benchmarks above showing that if a user were to naively choose the version that actually matches their CPU, they would be lowering their performance compared to the generic one?

No, because I reasoned if there was no generic one, they'd be forced to choose the one that matches their CPU. ;)

[Atak_Snajpera]

To be honest generic XP version is all we need. I'm really surprised that Microsoft's compilers generates faster code than Intel's.

PS. Without resizing I get 200 fps. With single threaded Spline36Resize(1280,720) fps drops to 100 fps.

[Groucho2004]

I'm really surprised that Microsoft's compilers generates faster code than Intel's.
You can't generalize this. Intel's optimization algorithms are quite different from Microsoft's, it all depends on the code. Not to mention the huge number of optimization options that Intel's compiler has, it takes quite some time to find the right combination and it's not always the one you would expect, I have a couple of examples where "O1" produces faster code than "O2" or "O3".

[stax76]

@jpsdr

Please have a look with a freeze I get in staxrip, environment is avs+ x64, script is:

LoadPlugin("D:\Projekte\VS\VB\StaxRip\bin\Apps\Plugins\both\ffms2\ffms2.dll")
LoadPlugin("D:\Projekte\VS\VB\StaxRip\bin\Apps\Plugins\avs\JPSDR\Plugins_JPSDR.dll")
FFVideoSource("D:\Temp\StaxRip\atmos.mkv", colorspace = "YV12", \
cachefile = "D:\Temp\StaxRip\atmos_temp\atmos.ffindex")
BicubicResizeMT(1920, 1080)

It opens fine in VirtualDub x64, and if you close your editor or encoder you might not even notice, but if you close the file via VFW (which staxrip does) it freezes, you can reproduce it easily in VirtualDub, in the main menu go to: File > Close video file, you'll get a freeze.

[jpsdr]

Where can i get ffms2.dll ?

Edit :
Is it this one (https://github.com/FFMS/ffms2/releases) ?

[jpsdr]

I don't have an mkv for, so i tested with an avi file, with standard avisynth under W7 x86, can open and close the file without issue.
I can't for now, but i'll try soon later with avs+ under W7 x64 with avs+.
My test script :

FFVideoSource("SP_IVTC.avi", colorspace = "YV12", \
cachefile = "D:\Temp\SP_IVTC.ffindex")
BicubicResizeMT(1920, 1080)


Edit :
So i've tested this script under W7 x64 with avs+ and Virtualdub x64, opened it, browse a little with the slide, and close it with "File -> Close video file" without issue.
Maybe you should provide me your mkv file...? Is your ffms2 dll the same that i've used ? (i've used the one i get from the link in post above).

[stax76]

I've a win7 VM client for staxrip development and there it works! This could be win10 specific or worse specific to my system, can other win 10 users confirm it? I tried 3 different source filters and it don't seem to be related to the source or source filter.

[jpsdr]

I've just thought about it, out of curiosity, does it also happen if you add threads=1 in the filter parameters ?
Does it also happen with the 2 others filters of the plugin ? (nnedi3 and AutoYUY2).
This is to try to figure out if it's related to the MT or not, and if it's specific or global.

[stax76]

nnedi3, AutoYUY2 and threads = 1 work fine.

[jpsdr]

Euh... Do you mean that nnedi3 and AutoYUY2 works fine whatever threads is, and MTResize works fine with threads=1 ?
Or that nnedi3 and AutoYUY2 works fine also only with threads=1 ?

[stax76]

Sorry but I didn't think that nnedi3 has a threads parameter too, I've tried it now with threads = 4 and that's fine, problem is only with the re-sample functions.

[jpsdr]

Ah... Interesting...
Can you try a last thing : Disable/remove the plugin dll, and use the dll of the resample filter only. It should behave the same, but i want to be sure, just in case.

[stax76]

It freezes too.

[jpsdr]

Ok. I'll check if i see something when i have time. On the other hand, i'm also asking, if someone else with Windows 10 can make the same test.

[jpsdr]

@stax76
Sorry to bother you, if you can, i would like you made some few others tests.

Is just the following nnedi3_rpow2(rfactor=2,cshift="Spline36Resize") (with the source filter vfw of course) trig the issue or not ?

With resample, can you also give me the result of the following tests :
- Resample changing only horizontal size.
- Resample changing only vertical size.

[stax76]

In my experience there is no way around:

1. trying to reproducing a bug
2. test the other big OS regularly, with big OS I mean Win 7 and Win 10

I use wmware and it's the only reason we found out so quickly and easily that this bug is Win 10 specific. I have to test every GUI change to ensure the High DPI scaling is pixel perfect, I do it with wmware. For 2 years there were limitations for Windows 7 users due to bugs in Windows 7 not supporting Unicode in batch files, I said it's the fault of Windows 7 as excuse and it's true but I never gave up looking for a solution and finally found one and the solution was better then the previous solution anyway. Since then I made a promise to Win 7 users that I will work very hard to make them stay first class citizens for as long as possible.

I coded a lot on my new libmpv based C# player called mpv.net and need some rest, I'll make your test as soon as possible, if anybody can help out, that would be great.

[jpsdr]

As i don't have and will not have Windows 10, i'm first trying to figure out the "configuration" wich trig the issue, to after try to see if i can figure out it by analysing it.
Also, is this issue present since the begining, or is it after a specific release ?

[stax76]

At the end you might regret that you didn't try to reproduce it from the very start, been there, done that and learned it the hard way, trust me.

Is just the following nnedi3_rpow2(rfactor=2,cshift="Spline36Resize") (with the source filter vfw of course) trig the issue or not ?

I tried it in staxrip and it works, source filter as previous tests have shown don't seem to play a role.

With resample, can you also give me the result of the following tests :
- Resample changing only horizontal size.
- Resample changing only vertical size.

It freezes even if both width and height parameters are identical to the source:

BicubicResizeMT(1280, 720, prefetch = 4)

[jpsdr]

At the end you might regret that you didn't try to reproduce it from the very start
I agree that being able to reproduce would be the best, but as i said, i don't have and will not have Windows 10, so...

But the fact that even with identical sizes (so, doing "nothing") it freezes, it's odd... But interesting in a way. This may be a clue.

EDIT :
Interesting indeed, because this case (doing "nothing"), i can reproduce. But i have a rough idea for this case, will solve this case also solve the others, maybe, but not sure.

[jpsdr]

This will be a tough one, because i'm totaly...:confused:

I see what's happening, but i don't understand why it's happenig.
When i resume my thread, with Resumethread it should be restarted, the value returned is 1, meaning the thread was sleeping but was restarted, except that... It wasn't restarted (i know because i don't "stop" at the breakpoint i've put within it), creating a lock when just after i'm waiting for the thread to exit.
So, i must said that for now, i'm a little stuck... :(

[jpsdr]

For now, it seems that everything thread related i'm doing when i'm in the destructor (ResumeThread or WaitForSingleObject) is not working, or is doing nothing, which is very... annoying ! I've not been able to found informations on the net. :(

When i'm within a destructor, the ResetEvent/SetEvent works, but the WaitForSingleObject never exit, even when if the thread exited...

EDIT :
More specific, these destructors are destructors called when DLL is unloaded, this seems to be a special condition, different than a call on a destructor when the DLL is "used", in that case, it seems there is no issue... Hard...

[burfadel]

Is it just the MTResize parameters that are causing the issue? I'm on Windows 10 and use the varius MT resizers like sincresizeMT and bicubicresizeMT (included in a modded Resize8 script for my own use), so multiple calls of MTResize works fine for me. Or is it just when used in nnedi3_rpow2?

[jpsdr]

One issue for sure : calling resample when "doing nothing" create an issue on Windows 7 and Windows 10.
Maybe also multiple calls in a way mask the issue on Windows 10, issue maybe trigged only with a single call.
It's not specific/related to use in nnedi3_rpow2.

[Atak_Snajpera]

calling resample when "doing nothing" create an issue on Windows 7 and Windows 10.
Question: What is "doing nothing" ?

[jpsdr]

Calling the resampler with both width and height parameters are identical to the source => Asking him to do "nothing".

[burfadel]

Something interesting. For me at least, on an interlaced source if I run NNEDI3 before my mclean script, it freezes, if I run it after the script it is fine. If I use fielddeinterlace() or any other deinterlacer before mclean it is also works fine, so not sure what's going on there? I tried adjust all of nnedi3's parameters involving threads, set fapprox to 0, opt=1 etc, no luck. However, if in the script I follow nnedi3 directly with prefetch(4), followed by mclean it works fine as well. Very improper, but it works! I believe by doing that you are separating the running of nnedi3 from the rest of the script? In any case, it's weird behaviour. Nothing in mclean is related to nnedi3, so they shouldn't be clashing. Could it be an issue with the resource sharing of nnedi3's prefetch parameter or clashing threadpool?

So for me, resizeMT works fine, but nnedi3 doesn't :). Even if I just have the source filter, nnedi3, and mclean, nnedi3() simply does work before mclean unless prefetch is stated in between. Source filter doesn't change anything either.

Does not work:
source filter here
nnedi3()
mclean()
prefetch(4)

(doesn't work whether prefetch(4) is stated or not).

Does work:
source filter here
nnedi3()
prefetch(4)
mclean()

[jpsdr]

So, if i understand the whole, this only :

nnedi3()
mclean()

is not working, but just nnedi3() is working ?

Can you provide the whole scirpt with all the parameters, and the script of mclean ?

[burfadel]

That's right, nnedi3() by itself works, and it works after mClean, just not before.

mClean here:
https://forum.doom9.org/showthread.php?t=174804

It's a work in progress script, but as you can see there is nothing in there really that should be causing issues. I'll try and find the exact clash in the script.

Found it! It's mDegrain2 causing it to freeze.

Try this, with just the source filter in addition, interlaced source (MPEG2 DVD for example).
nnedi3()
super = MSuper (hpad=16, vpad=16)
bvec2 = MAnalyse (super, isb = true, delta = 2)
bvec1 = MAnalyse (super, isb = true, delta = 1)
fvec1 = MAnalyse (super, isb = false, delta = 1)
fvec2 = MAnalyse (super, isb = false, delta = 2)
MDegrain2 (super, bvec1, fvec1, bvec2, fvec2)

[jpsdr]

I'll try this in latter time, there is a lot of filters i need to get first...
But i must said it's odd. I don't see any reason at first glance. Another tricky issue... :(
And i'd rather continue this on nnedi3 thread.

[stax76]

@jpsdr

The built you mailed me fixes the issue but an avsmeter benchmark showed poor performance, with following I'm getting 50 fps:

LoadPlugin("D:\Temp\Plugins_JPSDR\Plugins_JPSDR.dll")
LoadPlugin("D:\Projekte\VS\VB\StaxRip\bin\Apps\Plugins\avs\L-SMASH-Works\LSMASHSource.dll")
LWLibavVideoSource("D:\Temp\StaxRip\Truck.ts", format = "YUV420P8")
Spline36ResizeMT(1920, 1080, prefetch = 4)
Prefetch(4)

This gives 550 fps:

LoadPlugin("D:\Temp\Plugins_JPSDR\Plugins_JPSDR.dll")
LoadPlugin("D:\Projekte\VS\VB\StaxRip\bin\Apps\Plugins\avs\L-SMASH-Works\LSMASHSource.dll")
LWLibavVideoSource("D:\Temp\StaxRip\Truck.ts", format = "YUV420P8")
Spline36Resize(1920, 1080, prefetch = 4)

CPU usage was similar, about 80%.

[jpsdr]

I'm not realy happy with what i've done, so i'll send you later another first dll, will probably fix the issue when "doing nothing", but not sure for the rest.
And then, after result of this first dll, a second where there should be no deadlock (intend to implement another thing in threadpool). But, before sending the second, i would like to know about the first.

About performance, my MT version are more for people like me who are not using external MT or are using standard 2.6 avisynth.
If you're using external MT, either your value prefecth is lower than your CPU number, in that case, in the MT version you can adjust the parameters to have (threads*prefecth = 1 to 1.5 * CPU), but if you already prefetch with your number of CPU, it would be best to have threads=1 in my versions. Meaning, in case of resampling, there is no realy interest to use it in that case.

[jpsdr]

New version, see first post.

[Atak_Snajpera]

Seems to be working fine now. So how did you fix that? Did you use some dirty workaround or applied better method.

[jpsdr]

The freeze for "doing nothing" has a proper fix, the freeze because of MDegrain2 messes things resulting of destructor not called anymore is more like a workaround trying to minimize damages, because honestly, i don't know what i can do in this case...

[jpsdr]

New version, big update, see first post.

[jpsdr]

New version, Desample update, see first post.