Port of NNEDI under new v2.6 AVS API

[jpsdr]

A little late, but here is a Christmass present with a big step features new version (see 1rst post).
(My CPU hasn't FMA4, so the FMA4 functions are not tested).

[real.finder]

A little late, but here is a Christmass present with a big step features new version (see 1rst post).
(My CPU hasn't FMA4, so the FMA4 functions are not tested).

thanks, and about 10-14 bit?

[jpsdr]

It seems that i should have been more specific that with 16bits i mean everything <=16 bits.
I'll change the post.

[jpsdr]

Add new version, check first post.

[edcrfv94]

If add mclip parameter like eedi3 can speed up anti-aliasing script with pscrn = 0 so much.

[FranceBB]

Thanks for the update, once again! :)

[jpsdr]

Ouupss !!!! The last version crash on x64 (except with opt=1), no issue with x86. I'll fix it soon.

[TheSkiller]

I noticed on white (255, 255, 255) surfaces nnedi3_rpow2 produces this "jailbar" pattern.


BlankClip(pixel_type="RGB24", width=200, height=100, color=$FFFFFF)

nnedi3_rpow2(rfactor=2, cshift="Spline16Resize")

Levels(254,1,255, 0,255, false) #to make the pattern visible


https://picload.org/image/rodgddlg/nnedi3_jailbars.png


Should be a plain white surface.
Happens with all kinds of versions, even with the old nnedi2. Happens in YUV as well as RGB24.


I noticed it while enlarging an image that uses an alpha channel. The resulting enlarged image had quite visible jailbars in those parts where the alpha channel is white (opaque), so it can be seen in real world scenarios.

[jpsdr]

I'll try to see if i can figure something out, but not sure at all.

Edit :
I've figure out... You may probably not have the issue if you set prscrn=0.
When prescreener is used, 255 is used as a "special" value by the code, to "mark" pixel which should be processed by the neural network. If a pixel is not to be processed by the neural network, it's value will be a simple interpolation, but clamped at 254, to keep the 255 only for marked pixels.
But, on your whole blank clip, no pixel is neural network, so, every pixel will be interpoled and clamped at 254. As nnedi is a deinterlacer, and only half the lines are processed (or double), anyway, the untouched lines stays at 255, producing output at 254 and 255.
I'll see if something can be made to solve this, but it may take a little time, it will have a not small impact on the code, but shouldn't be too hard.

The x64 fix will be delayed until i fix this. Thanks to pointing this, strange that this wasn't realized before. I also should have been to realize it, having understood a little more the code core to add the 16bits/float datas.

[real.finder]

I noticed on white (255, 255, 255) surfaces nnedi3_rpow2 produces this "jailbar" pattern.


BlankClip(pixel_type="RGB24", width=200, height=100, color=$FFFFFF)

nnedi3_rpow2(rfactor=2, cshift="Spline16Resize")

Levels(254,1,255, 0,255, false) #to make the pattern visible


https://picload.org/image/rodgddlg/nnedi3_jailbars.png


Should be a plain white surface.
Happens with all kinds of versions, even with the old nnedi2. Happens in YUV as well as RGB24.


I noticed it while enlarging an image that uses an alpha channel. The resulting enlarged image had quite visible jailbars in those parts where the alpha channel is white (opaque), so it can be seen in real world scenarios.

it's something in pscrn, if you set it to 0 or false you will not get this

edit: jpsdr was faster than me

[jpsdr]

The only way to fix this will be to create a "boolean" memory plan of the same size of the plane processed, to mark pixels to be processed on this plane, instead of using the value 255, this will keep the value 255 usable in the prescreener. It will increase a little the memory used, but shouldn't affect the speed noticeably.

[TheSkiller]

Thank you for your fast reply. pscrn=0 does indeed fix it for now.
The explanation makes sense. It's a bit of a "hacky" way reserving 255 for the prescreener. :)

[edcrfv94]

It will be useful if nnedi3 can show which pixels are processed by the neural network into a edge mask.
Also add mclip parameter to use neural network only on specified pixels can improve anti-aliasing script speed.

Thanks

[jpsdr]

This is not in my todo list for now, and i've never done this kind of thing (having extra intput/output clip parameters). This may probably needs a specific (or another) nnedi3 function, because i don't know if you can put "no value" and switching to "default" value on this kind of parameters if you don't need/use them. I'll think about it, but not in the near future, and no promises.

[jpsdr]

New version, both issues are fixed, check first post.

[jpsdr]

New version, see first post.

[kuchikirukia]

I'm getting "module not found" for the x86 W7 SSE4.1, AVX, and AVX2. Win10 with Haswell.

E: fixed it. Did it need the Intel 2016 too? I forget if I restarted MeGUI after installing 2017. I did after erroring out and trying 2016 too.

[jpsdr]

No, the 2017 is enough (at least, it's the case for me).

[jpsdr]

New version see first post.
Some quick speed tests showed these results (at least on my CPU) :
Speed improvement from opt=2 to opt=4 on nnedi3 8bits data, not nnedi3_rpow (this last having several others image manipulation which will alter the test speed) :
prscrn=1, fapprox=12 : around +25%
prscrn=1, fapprox=15 : around +10%
prscrn=2, fapprox=15 : around +40%

[pinterf]

Nice speedup. You mentioned AVX512 in the vdub thread, are you interested on a 64 byte aligned build from avs+?

[jpsdr]

Not for now, i haven't anything yet to use it. I was just saying that it could be interesting to just have a 64bits default alignment, this will ensure a long future, and don't have to worry about it for a looong time... ;)

[burfadel]

No desktop processors support hose instructions yet. When they do, Intel have dividied them up into different sets and desktop variants may not necessarily get those sets most beneficial for encoding etc.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post (nothing big this time).

[burfadel]

I just upgraded to a Ryzen 1700x. Everything is working brilliantly apart from NNEDI3 x64! The latest version makes an instant crash, and this is with the latest redists installed. I even tried the intel redists for the AVX builds etc, no luck, all compiled files causes an instant crash. I went back through the versions and found that Version v0.9.4.36 is the last one that worked correctly. With this version, the Intel AVX2 etc versions all work fine.

So somewhere in the code change between 0.9.4.36 (works) and 0.9.4.37 (doesn't work) there is an issue that causes it to crash.

[ryrynz]

I have no crash here. Ryzen 1700 using nnedi3_rpow2 through ffdshow with x64 .38 Core 2 AVX2 build.
I have the Intel 64 c++ redistributables 16.9.246 installed.

[jpsdr]

Oh yes !!! A LOT of things changed between .36 and .37, all the AVX2/YMM use code has been added. What command exactly are you using within your script ? Are the not Intel version also crash ?

[burfadel]

Oh yes !!! A LOT of things changed between .36 and .37, all the AVX2/YMM use code has been added. What command exactly are you using within your script ? Are the not Intel version also crash ?

Regardless of the command line, even just nnedi3(). However, opt=3 works fine, but would rather no disalbe those AVX2 speedups.

[ryrynz]

Well that's an issue with your system by the sounds as I'm using the same build, are you using the latest BIOS for your board? Could be a Ryzen bug.

[jpsdr]

What is your color input format ? I've made a lot of tests, but it's not impossible that i've missed something.
Are opt=5 or opt=6 also crash ?

Btw, Ryzen users, if you could benchmark nnedi3 (not rpow) between opt=4,5 and 6, i'm curious.

[ryrynz]

I did a quick test earlier tonight between auto (4?), 5 & 6 and there was sweet F all difference. Honestly I couldn't pick a winner by CPU frequency or CPU utilization.
Would need to do a proper AVS bench to know which is faster but the differences are so small I don't care to waste my time to know, this is in real time so perhaps a far more demanding script with this would highlight what's best for Ryzen.

[burfadel]

I don't know how FMA4 could work on Ryzen, but opt=5 works for me as well. So ryrynz, the nnedi3 being used is definitely 0.9.4.39? I tested a whole heap of other AVX2 stuff, no issues (including a whole day of parallel encodes of x265), only AVX2 in 0.9.4.37 onwards doesn't work for me.

[ryrynz]

Definitely, I just updated from .38. Double checked by moving the file too. Does it work for you through ffdshow raw by any chance?
I'm using Avisnth+ build 2455.

[jpsdr]

@burfadel : Do you mean that AVX2 crash in .37 but not in .39 ?
I don't know which CPU uses FMA4. As it seems it's not Intel, i thought it would be AMD, so maybe the Ryzen.

[ryrynz]

Ryzen apparently doesn't have FM4 implemented, which makes why that optimization works somewhat of a mystery.

[pinterf]

Perhaps this one? Ryzen FMA3 bug.
http://techreport.com/news/31621/amd-readies-a-fix-for-ryzen-fma3-bug

[Groucho2004]

I don't know which CPU uses FMA4. As it seems it's not Intel, i thought it would be AMD, so maybe the Ryzen.
Ryzen does not support FMA4. Bulldozer and Piledriver do.

[burfadel]

In which case manually specifying FMA4 it shouldn't work. I guess it automatically disabled it anyway? For the crashing, it's only AVX2 that causes it, and only versions .37 and above. This is for any of the builds provided, and any of the colourspaces, using Avisynth+ 2455 x64 version (and NNEDI x64 of course). It also crashes when placing the .avs file through MPC, but fine on .36. The AVS file just contains the source filter (using DSS2mod), and NNEDI3.

I just did a little test, I downloaded MPC-HC 32-bit, copied the relevant 32-bit avisynth files to the respective locations, and changed the script to point to the 32-bit source and NNEDI files, and it worked! The video played perfectly and could seek etc, unlike with any usage of the x64 version that crashes instanstly without displaying a picture using any method.
NNEDI3 0.9.4.39 x64 version doesn't work with AVX2
NNEDI3 0.9.4.39 x86 version works with AVX2

@ryrynz are you using 32-bit (that works for me) or 64-bit?

[ryrynz]

Full 64 bit chain, MPC, ffdshow, Avisynth and NNEDI3.

[Groucho2004]

I ran some performance tests with the various builds on Win7 with AVSMeter64 on my i5 2500K @ 4GHz (no AVX2 since the CPU doesn't support it):

Script:
colorbars(width = 3840, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0,499)
NNEDI3(dh = true, nsize = 0, nns = 4, qual = 2)

Release_XP (x64):
FPS (min | max | average): 13.57 | 18.11 | 17.32
Memory usage (phys | virt): 53 | 60 MiB
Thread count: 13
CPU usage (average): 55%

Release_W7 (x64):
FPS (min | max | average): 13.37 | 18.09 | 17.24
Memory usage (phys | virt): 53 | 61 MiB
Thread count: 13
CPU usage (average): 59%

Release_Intel_XP_Core2_SSE4.2 (x64):
FPS (min | max | average): 9.988 | 18.17 | 17.27
Memory usage (phys | virt): 54 | 64 MiB
Thread count: 17
CPU usage (average): 57%

Release_Intel_W7_Core2_SSE4.2 (x64):
FPS (min | max | average): 10.70 | 18.70 | 17.41
Memory usage (phys | virt): 54 | 64 MiB
Thread count: 17
CPU usage (average): 56%

Release_Intel_W7_Core2_AVX (x64):
FPS (min | max | average): 7.734 | 17.97 | 16.89
Memory usage (phys | virt): 54 | 64 MiB
Thread count: 17
CPU usage (average): 56%

And, just for fun, Original NNEDI3 0.94 (built with ICL11) (x86) (https://forum.doom9.org/showthread.php?t=173259) (which obviously doesn't have the additional colorspaces):
FPS (min | max | average): 17.28 | 19.97 | 19.85
Memory usage (phys | virt): 49 | 58 MiB
Thread count: 13
CPU usage (average): 85%

The efficiency (FPS/CPU usage) of jpsdr's builds is quite good but the multi-threading could be better.

[jpsdr]

@burfadel : Does the FMA3 (opt=5) work with x64 ? This may help me to locate were the issue could be. x86 working and x64 not, very very likely an issue in the asm files. If FMA3 works, it means the issue is somewhere in a function which have duplicate AVX/FMA. If FMA3 doesn't work, it means the issue is in a function both used in FMA/AVX. There is probably an issue in the asm code, i don't trig, neither ryrynz. It happened allready a while ago, someone had an issue, and it was trigged only in specific situation. The more likeky a pointer register i've missed to pass in 64bits version.

[Groucho2004]

One thing I find puzzling about the documentation:

opt -

Sets which cpu optimizations to use. Possible settings:

0 = auto detect
1 = use c
2 = use sse2
3 = use sse4.1
4 = use AVX2
5 = use FMA3 [Manual set only, not in auto-detect]
6 = use FMA4 [Manual set only, not in auto-detect]


The available builds are:
Release_Intel_W7_Core2_AVX
Release_Intel_W7_Core2_AVX2
Release_Intel_W7_Core2_AVX2_Broadwell
Release_Intel_W7_Core2_SSE4.2
Release_Intel_W7_Xeon_AVX512
Release_Intel_XP_Core2_SSE4.2
Release_W7
Release_XP

I can't figure out which build does what when using any of the "opt" parameters. For example, what build supports SSE4.1? Maybe I'm just missing something obvious...

[jpsdr]

All the builds do the same thing with "opt". It's just the compiler option which are differents. The Core2_AVX is build with "AVX instruction" on the compiler, Core2_AVX2_Broadwell is build with "AVX2 Instructions" + "Broadwell micro code" in the compiler, etc...

[Groucho2004]

All the builds do the same thing with "opt". It's just the compiler option which are differents. The Core2_AVX is build with "AVX instruction" on the compiler, Core2_AVX2_Broadwell is build with "AVX2 Instructions" + "Broadwell micro code" in the compiler, etc...OK, but what's the point of all these builds if they don't bring any speed benefit? Or, in case of the AVX test above, are even slower?

[jpsdr]

Theoricaly, i thought they should have an effect. Strange thing is the fact that there is 4 more threads on the Intel version. Well...

[burfadel]

@burfadel : Does the FMA3 (opt=5) work with x64 ? This may help me to locate were the issue could be. x86 working and x64 not, very very likely an issue in the asm files. If FMA3 works, it means the issue is somewhere in a function which have duplicate AVX/FMA. If FMA3 doesn't work, it means the issue is in a function both used in FMA/AVX. There is probably an issue in the asm code, i don't trig, neither ryrynz. It happened allready a while ago, someone had an issue, and it was trigged only in specific situation. The more likeky a pointer register i've missed to pass in 64bits version.

It happens with opt=5 as well.

[jpsdr]

Sorry, last question, to help me to locate the issue.
Can you tell me if it happens with :
8bits, 10bits, 14bits, 16bits and 32bits (float) ?
A script like this will do the trick (YV12 data will be good):

ConvertBits(x)
nnedi3()
ConvertBits(8) # If needed for your output.

with x=10,14,16,32 assuming your input is 8bits.

EDIT
Never mind, i've just made a search on "eax" (and similar) on the x64 asm file, and find something which may explain the crash issue. Can you pm me an email i can send you a build test ?

[jpsdr]

x86 working, x64 crashing => 99.999% chance it's in the asm code.
It's working for me and a lot of people, and suddenly someone has a crash => 99.999% chance i've missed an address register and kept it on its 32bits version instead of changing it to its 64bits version (keeping a mov xxx,[esi] instead of changing to mov xxx,[rsi] for exemple).
And of course, it's what i've found out, searching for occurance of 32bits registers in the x64 asm code.
I should have thought doing this kind of search before...
Note for myself : Always doing this on x64 asm code for now... ;)

[jackoneill]

x86 working, x64 crashing => 99.999% chance it's in the asm code.
It's working for me and a lot of people, and suddenly someone has a crash => 99.999% chance i've missed an address register and kept it on its 32bits version instead of changing it to its 64bits version (keeping a mov xxx,[esi] instead of changing to mov xxx,[rsi] for exemple).
And of course, it's what i've found out, searching for occurance of 32bits registers in the x64 asm code.
I should have thought doing this kind of search before...
Note for myself : Always doing this on x64 asm code for now... ;)

Or you could just use one of the solutions that allow you to write and maintain only one copy of this code...




(yasm + x86inc.asm from x264, or intrinsics)

[burfadel]

A test version sent to me works perfectly! The issue jpsdr found in the code is what was causing the issue, it's interesting how it affects some people and not others with seemingly similarish systems.