Internaly multi-threaded resampling functions

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[edcrfv94]

7920x 2.0.3 work fine, 2.0.2 & 1.5.8 no response, But my 3770k 2.0.3, 2.0.2, 1.5.8 all working well it.
2.0.3 "Fix a bug in the MTData" solve freeze?

[jpsdr]

No, solved a crash "all or nothing" case. But your results are odd... Having no response on a CPU, and working fine on another with the exact same script on the exact same video, it's odd indeed.

[edcrfv94]

No, solved a crash "all or nothing" case. But your results are odd... Having no response on a CPU, and working fine on another with the exact same script on the exact same video, it's odd indeed.

I find out which part cause the problem.


kf_Padding(2, 2, 2, 2) #freeze
kf_Padding(4, 4, 4, 4) #working well

function kf_Padding_test(clip c, int "left", int "top", int "right", int "bottom", bool "pspuv")
{
w = c.width()
h = c.height()
return c.pointresizeMT(w+left+right, h+top+bottom, -left, -top, w+left+right, h+top+bottom)
}

[jpsdr]

I've just tested with the actual version, both work for me.
I must said that i will not spend time searching why a previous version wasn't working if the actual works...;)

[jpsdr]

New version, see first post, and i've also added on it a part about the multi-threading.

[jpsdr]

There is issue with the Intel versions.

I'll update the release files on github, removing the Intel versions, and keeping only VS version, and adding an VS AVX2 version. Wait at least 24h to check/re-download the files.

[jpsdr]

Trashed Intel version, file updated, redownload it.

[jpsdr]

New version, see first post, updated also the Multi-treading text part.

[jpsdr]

New version, see first post (minor update).

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.
About the fix to perfectly match the avs+ output. It didn't produce bad or incorrect output before, just different.
The resize works by resizing horizontal and vertical. You can choose one of your own, but there is no specific rules that says if you should do H before V or the opposite. If you resize H before V, it will produce a different result than resizing V before H (except in float mode). Difference will be very small, and both results are proper results. Sometimes my filter wasn't doing the resize in the same order, so the result was different, but still proper. Now the results perfectly match.

[jpsdr]

I've messed-up my files management between my VS versions, commited but not pushed, result the build was made with only some parts of the fixes (but still the output was not bad or incorrect).
If you see this post and have already downloaded the 2.2.2 version, re-download it, and sorry for the inconvenience.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

Even if i can just "quickly" merge (without building) DTL's PR, there still the small pinterf's fix i want also include before making a new build. But as the organisation of internal resample and my filter is slighty different, i have to spend a little time to see how to put it in mine, and for now, i'm focussing all of my few spare time on something else, so there will be no new build for a while.

[DTL]

As suggested made temporal build of pre-2.3.2 version if anyone interested in using/testing - see later post. Still only x64 binary (with minimum SSE2 CPU I think) because win32 produces some linker error about SAFESEH with my VS2015.

[jpsdr]

Ok, i try to guess english from my VS french version :
Project -> Property -> Linker -> Advanced -> "Image with exception...something"/the last setting -> SAFESEH:NO

And, as history shows, a new kernel function with the small pinterf fix will just be a 2.3.2... ;)

[DTL]

Ok, i try to guess english from my VS french version :
Project -> Property -> Linker -> Advanced -> "Image with exception...something"/the last setting -> SAFESEH:NO


Yes - this helps.

Renamed to 2.3.2 and upload new release to fork: https://github.com/DTL2020/ResampleMT/releases/tag/2.3.2

[jpsdr]

New version, see first post.

[real.finder]

can UserDefined2ResampleMT simulate Dither_resize16 additional kernels?

also it will be nice if there are something like "MT_resize" that has all Dither_resize16 parameters so we can say goodbye to dither tools and it's lsb hacks :)

[jpsdr]

I don't know, DTL may answer, but the UserDefined is using bicubic if remember as core root, so it's not a totaly open function.

[DTL]

the UserDefined is using bicubic if remember as core root,

No - it is pure sinc-based. Its kernel is just a sum of weighted sincs:

return c*sinc(x+2) + b*sinc(x+1) + a*sinc(x) + b*sinc(x-1) + c*sinc(x-2);

Where a=1 and b and c are user-defined weights. It can be expanded to any more number of members for better precision but for typical users it is hard to work even with 2 control params.

For experienced perfectionists or some scientific work may be added expanded version for example with 4 control members (UserDefined4ResizeMT(b,c,d,e) like

return e*sinc(x+4) + d*sinc(x+3) + c*sinc(x+2) + b*sinc(x+1) + a*sinc(x) + b*sinc(x-1) + c*sinc(x-2) + d*sinc(x-3) + e*sinc(x-4);

With expand filter support and other adjustments. It may look as Bicubic just because way of passing params from script to kernel-generation function was taken from BicubicResize and names b and c looks like not very bad, though names may be changed to other simple numbering like param1, param2 etc.

As I see from wiki-description: Dither_resize16 can also accept user-defined samples for kernel generation:

"impulse" Offers the possibility to create your own kernel (useful for convolutions). Add your coefficents in the string after “impulse”, separated with spaces (ex: "impulse 1 2 1"). The number of coefficients must be odd. The curve is linearly interpolated between the provided points. You can oversample the impulse by setting kovrspl to a value > 1.

But it uses linear interpolation between provided samples. So it may be separate request to jpsdr to add this as new resampler's kernel with some new function name.

As I think Dither-tools uses separate non-Avisynth resampler with many other params of kernel adjustments/tweaking. So if you use user-provided kernel in Dither-tools with other options it may be not very easy to port its resizer to ResampleMT.

"also it will be nice if there are something like "MT_resize" that has all Dither_resize16 parameters"

I think it mostly probably will require to port full Dither-tools resampling engine to use all these tweaking and adjustments params. Though may be possible to make some class to prepare kernel (from all that params) usable with ResampleMT/Avisynth resampling engine. Anyway it may require long work.

[real.finder]

"also it will be nice if there are something like "MT_resize" that has all Dither_resize16 parameters"

I think it mostly probably will require to port full Dither-tools resampling engine to use all these tweaking and adjustments params. Though may be possible to make some class to prepare kernel (from all that params) usable with ResampleMT/Avisynth resampling engine. Anyway it may require long work.

yes it seems

there are vs port https://github.com/EleonoreMizo/fmtconv maybe it can help

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[DTL]

When trying to make a table of b,c coefficients of impulse kernel for UserDefined2ResizeMT I found something interesting:

Later I think there are many possible b and c combinations available for each power of LPF filtering and over/under shoot amplitude. Keeping 'far' ringing as small as possible. But for real practic it is good to have a table to start with. So I start to make table of b param in rows and 3 different columns for c - for no_overshoot, low, medium, and high.
But at the process of filling the table it shows no many valid combinations available for 'far' ringing as low as possible for each fixed 'b' or 'c' member.
Current table for b,c (and also a bit more precise b,c,d,e for possible UserDefined4Resize())
https://i2.imageban.ru/out/2021/09/03/2942e09c366b65e4c5e123385e62e340.png
It can be used currently with UserDefined2ResizeMT(). I send e-mail to jpsdr with suggestion to add b,c version of this table to plugin documentation but not sure it e-mail received.

As table for b,c,d,e shows the practical not-far ringing self-windowing kernel fades quick enough so even e-member typically small differs from zero. Close to +-1LSB. Ofcourse it is for 8bit presicion integer. With very high precision float required number of members may be >10. But for many practical already distorted moving pictures it may be invisible.

So is the main idea of this findings:
The practically useful combinations of b,c (b,c,d,e) is not function of many arguments but looks like function of 1 argument (like b for example). So it is possible to hard-code the b,c,d,e = f(b) table with step like 5 and linear interpolation inbetween values and make separate named resize function of only 1 user-defined argument. As well as SinPowResize(), but that kernel uses attempt of analytic definition of required 'self-windowed low ringing' kernel. And now we have partially table-defined function with sinc internal interpolation as required for resampler.
Will try to make it.

Additional note: The finding above looks like only (mostly) valid for high downsampling ratios like 10:1 and more and (may be) for sources with good conditioning against ringing. For small downsampling ratios the lowest-ringing b,c (d,e) combinations be differs from the current designed table. But it require more investigations. For example if a source with already having some ringing is feed to the resampler. So to compensate the source ringing the different weights for sincs are required. So it not mean the current UserDefined2ResampleMT() will be complete obsolete after new named resizer is designed with only 1 argument and build-in table inside.

It may be also treated as 'self-weighted' kernel. Because it is quickly fades to zero and the real resampler's windowing with 'support' natural 'box window' do not cause additional kernel cutting and no additional Gibbs-effects may be of higher order. So may be possible name for new named resize function is SelfWeightedResize or SWResize to type less in scripting. Also because it very quickly fades to zero it should be fast enough in processing because it do not require large 'support' size for resampler engine. Speed will be close to current UserDefined2ResizeMT with fixed support=2. So new resizer may have speed/quality switch like using bc or bcde table and support =2 or 4.

[hello_hello]

I've been trying to debug a resizing function for so long I'm pretty sure my mind has gone, so I'm not certain this is real. Could somebody please tell me if this is real?

ResampleMT 2.3.4 (and 2.3.3) XP version.

Version.GaussResize(420, 520, src_left=0.0, src_top=0.0, src_width=-300.0, src_height=0.0)

https://i.postimg.cc/DmyXq4RL/GR-300.jpg (https://postimg.cc/DmyXq4RL)

Version.GaussResizeMT(420, 520, src_left=0.0, src_top=0.0, src_width=-300.0, src_height=0.0)

https://i.postimg.cc/qhQ6Pp6N/GRMT-300.jpg (https://postimg.cc/qhQ6Pp6N)

Version.GaussResize(420, 520, src_left=0.0, src_top=0.0, src_width=300.0, src_height=0.0)

https://i.postimg.cc/dZ1ZvgG4/GR-300.jpg (https://postimg.cc/dZ1ZvgG4)

Version.GaussResizeMT(420, 520, src_left=0.0, src_top=0.0, src_width=300.0, src_height=0.0)

https://i.postimg.cc/MXPjtK84/GRMT-300.jpg (https://postimg.cc/MXPjtK84)

Edit: Trying to discover why the ResampleMT resizers appear to be behaving themselves when used with one function but not another.
Version.ExtractR().GaussResizeMT(420, 520, src_left=1.0, src_top=1.0, src_width=-300.0, src_height=0.0)

https://i.postimg.cc/5HHZkWnb/R-Plane.jpg (https://postimg.cc/5HHZkWnb)

This is also satisfactory, so maybe it's just an RGB thing?
Version.ConvertToYV12().GaussResizeMT(420, 520, src_left=1.0, src_top=1.0, src_width=-300.0, src_height=0.0)

[jpsdr]

I'll try to take a look during my hollydays in november, i should have time.
You said XP version, it's specific to the XP version ?

[hello_hello]

I'm mainly using an XP machine, but I checked the vanilla Win7 version (ResampleMT 2.3.4) on a laptop and it's doing the same thing.
The laptop had ResampleMT 2.2.2 on it (I don't use it for video conversion much) and it was also the same, so I guess it's an old problem that's managed to go unnoticed.

Thanks!

[poisondeathray]

This is also satisfactory, so maybe it's just an RGB thing?
Version.ConvertToYV12().GaussResizeMT(420, 520, src_left=1.0, src_top=1.0, src_width=-300.0, src_height=0.0)


ConvertToPlanarRGB() also works. There was a recent thread about similar weirdness for packed vs planar RGB, I'll try to find it

[hello_hello]

poisondeathray,
Yeah, it's a different thread so you probably haven't seen my post, but I mentioned in the JPSDR Avisynth's plugins pack thread (https://forum.doom9.org/showthread.php?p=1955476#post1955476) that the problem seems to be confined to RGB24/32.

[VoodooFX]

I gave it a go, but its use case eludes me...

Script example:
LWLibavVideoSource("D:\test.mkv")
ExtractY
SincResizeMT(2360, 244, taps=2, threads=4) # Upsize *2

Benchmarks:
AVSMeter 3.0.7.0 (x86), (c) Groucho2004, 2012-2020
AviSynth+ 3.6.2 (r3341, master, i386) (3.6.2.0)
Frames processed: 4006


SincResize(2360, 244, taps=2)
FPS: 483.0
CPU: 77.0%

SincResizeMT(2360, 244, taps=2)
FPS: 369.3
CPU: 55.1%

SincResizeMT(2360, 244, taps=2, threads=4)
FPS: 330.0
CPU: 50.3%

SincResizeMT(2360, 244, taps=2).Prefetch(4)
FPS: 41.24
CPU: 78.7%

[hello_hello]

Odd. I gave it a spin (on an old quadcore).

AviSynth+ 3.7.0
ResampleMT via the JPSDR Avisynth's plugins pack
Source 704x528

SincResize(1408,1056, taps=2)
FPS 238
CPU 38%

SincResizeMT(1408,1056, taps=2)
FPS 384
CPU 72%

ExtractY
SincResize(1408,1056, taps=2)
FPS 345
CPU 43%

ExtractY
SincResizeMT(1408,1056, taps=2)
FPS 522
CPU 77%

SincResize(1408,264, taps=2)
FPS 301
CPU 43%

SincResizeMT(1408,264, taps=2)
FPS 443
CPU 74%

ExtractY
SincResize(1408,264, taps=2)
FPS 415
CPU 50%

ExtractY
SincResizeMT(1408,264, taps=2)
FPS 584
CPU 81%

Edit: The help file suggests that if you're using Prefetch in a script, the ResampleMT Prefetch argument should have the same value. I didn't test with Prefetch in the script.

[jpsdr]

@VoodooFx read the MultiThreading.txt file provided with the plugins for using prefecth. After, sometimes things which work better for someone aren't for someone else... :(

[jpsdr]

I wonder if issue is not here...

result=env->Invoke(turnLeftFunction,clip).AsClip();
result=CreateResizeV(result, subrange_left, subrange_width, target_width,threads_number,_sleep,(step2)?1:range_mode,desample,accuracy,0,0,avsp, f, env);
result=env->Invoke(turnRightFunction,result).AsClip();

After turnLeftFunction, are some parameters not good...

[VoodooFX]

Odd. I gave it a spin (on an old quadcore).
Odd... Btw, I tried x86 "Release_W7_AVX" version.

@VoodooFx read the MultiThreading.txt file provided with the plugins for using prefecth.

I've found something :) :


ExtractY.SincResizeMT(2360, 244, taps=2, threads=2).Prefetch(2)
FPS: 401.0
CPU: 83.5%

ExtractY.SincResize(2360, 244, taps=2).Prefetch(2)
FPS: 72.56
CPU: 81.6%

[jpsdr]

@VoodooFx
How core do you have ?

[VoodooFX]

@VoodooFx
How core do you have ?

Tested on 2 real cores (4 virtual),

[jpsdr]

Out of curiosity, try :ExtractY.SincResizeMT(2360, 244, taps=2, threads=2, prefetch=2).Prefetch(2) and ExtractY.SincResizeMT(2360, 244, taps=2, SetAffinity=true)

[VoodooFX]

Out of curiosity, try :ExtractY.SincResizeMT(2360, 244, taps=2, threads=2, prefetch=2).Prefetch(2)
SincResizeMT hangs at start, no error.

ExtractY.SincResizeMT(2360, 244, taps=2, SetAffinity=true)
FPS: 397.5
CPU: 63.6%

[jpsdr]

Ah... hangs... That's unexpected... Another things to investigate... one day...

[MysteryX]

L1-L2 cache limitations, interesting.

I was having issues in VapourSynth with 5K video clips. Performance starts at 0.55fps and then drops to 0.35fps after 10 frames. Bicubic resize being at the top of the list of performance-heavy filters??

Could it be the exact CPU cache issue you're talking about here?

To test the theory, I just ran the full script with 5K vs 720p videos, and here's the output of vspipe --filter-time (top of the list of performance-heavy filters)


720p
KNLMeansCL parreq 98.82 10.09
BM3D parallel 34.93 3.56
Analyse parallel 9.82 1.00
Analyse parallel 9.39 0.96
Analyse parallel 8.87 0.91
Analyse parallel 8.87 0.91
Analyse parallel 8.86 0.90
Bicubic parallel 8.69 0.89
Bicubic parallel 5.02 0.51
Analyse parallel 4.75 0.48
Bicubic parallel 4.33 0.44
Expr parallel 3.67 0.37
Expr parallel 3.57 0.36
Expr parallel 3.52 0.36
Degrain3 parallel 3.48 0.35
Expr parallel 3.45 0.35
Bicubic parallel 3.36 0.34
bitdepth parallel 3.13 0.32
Spline36 parallel 3.02 0.31


5K
Bicubic parallel 71.76 50.94
BM3D parallel 60.19 42.73
Bicubic parallel 56.42 40.05
KNLMeansCL parreq 55.52 39.42
bitdepth parallel 46.31 32.88
Degrain3 parallel 42.70 30.32
Analyse parallel 38.09 27.04
Analyse parallel 37.40 26.55
Analyse parallel 37.18 26.39
Analyse parallel 35.70 25.34
Analyse parallel 35.10 24.92
Analyse parallel 34.07 24.18
Bicubic parallel 30.62 21.74
Super parallel 21.67 15.38
Spline36 parallel 13.47 9.56
Bicubic parallel 12.79 9.08
Recalculate parallel 11.23 7.97
Recalculate parallel 11.04 7.83
Recalculate parallel 10.37 7.36
Recalculate parallel 10.28 7.30
Recalculate parallel 10.18 7.22
Spline36 parallel 10.00 7.10
Recalculate parallel 9.69 6.88
Convolution parallel 9.41 6.68


Currently I'm in the process of porting the script to Avisynth. Is there any VapourSynth version of your solution to test it out?

[DTL]

I sometime get hanging at start of avsmeter tool. But it is not repeatable usually. So it is good to try start >1 attempt.

[jpsdr]

Hang is not because of avsmeter (unfortunately for me).
Sorry for disapointment, but investigate of issues will not be done before unknow date. I'm not in the mood for now to spend time on this, i have others stuff i want to spend my time on.

[jpsdr]

Hangs using prefetch fixed, will be on the next build. In fact it was a generic issue with MT_NICE filters and my threadpool when using prefetch. Also affect aWarpsharp and HDRTools and... that's all. The other filters are not MT_NICE. Fix will be included when i'll do a next build, probably not before stable release of llvm 13.0.1.

[jpsdr]

Packed RGB issue fixed, everything is pushed on git, expect a build maybe this WE.

[FranceBB]

expect a build maybe this WE.

Thank you, as always. ;)
Looking forward to it. :)