Dogway's Filters Packs

[madey83]

Yes, that's a given, the problem was actually limit=255 while keeping the UHDHalf setting. I will run a few tests today and see how it behaves.


EDIT: Ok, this is what's going on. Specially when using UHDHalf=true, and also specially when paired with mode!=MDegrain (although it also shows with mode="MDegrain"), there's some detail warping.
I guess that to minimize this effect I chose to limit changes to no bigger than 2. It still warps details but it's not as exaggerated.
SMDegrain(tr=2, thSAD=400, mode="IQMT", limit=255, UHDHalf=true, prefilter=1, refinemotion=true) # prefilter=2 for UHDHalf=false

Source (3x zoom)
https://i.imgur.com/gec0fjqm.png (https://i.imgur.com/gec0fjq.png)

UHDHalf=false
https://i.imgur.com/F1FW4F6m.png (https://i.imgur.com/F1FW4F6.png)

UHDHalf=true
https://i.imgur.com/mv2qCGAm.png (https://i.imgur.com/mv2qCGA.png)

UHDHalf=true, Limit=2
https://i.imgur.com/l1rNqhRm.png (https://i.imgur.com/l1rNqhR.png)

when i look up on those screens i do not see "warping". To be honest i bearly see difference between them.
Could some one point me where i should look to see difference between pictures?

[anton_foy]

when i look up on those screens i do not see "warping". To be honest i bearly see difference between them.
Could some one point me where i should look to see difference between pictures?

Actually I agree I see just small differences on these examples. I used mode=temporalsoften though not mdegrain. The difference between uhdhalf=true/false on my footage was alot more visible. Can share if you want.

[madey83]

Actually I agree I see just small differences on these examples. I used mode=temporalsoften though not mdegrain. The difference between uhdhalf=true/false on my footage was alot more visible. Can share if you want.

@anton_foy yes please.

Can i use uhdhalf option when i encode 1080p or it is only designed to UHD source.

[madey83]

@Dogway,

is it posible you SMDegrain to remove grain from picture and if you could you please give an example how - how to point SMDegrain to take all pictures from folder and after degrain compress it to jpg again.
for movies i use StaxRip and defined insite it SMDegrain call, but for picture is for me something new.

Thank you in advance :)

[madey83]

To my eye's, it's hard to tell them apart...maybe the bottom one...

With the above call, where would be the best line to add them to, in my call, below ?

pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=2000)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)


:thanks:

I'm sorry for stupid question but why for HDR/DV source before degrain i need to use this call: "DGHDRtoSDR(mode="pq",white=2000)"?

i've done several denoising dolby vision source without it and for me looks identical in matter of colors after encode was done...

[Guest]

I'm sorry for stupid question but why for HDR/DV source before degrain i need to use this call: "DGHDRtoSDR(mode="pq",white=2000)"?

i done several denoising dolby vision source without it and for me looks identical in matter of colors after encode was done...

It was something suggested to me several weeks ago, so I just went with it.

And I asked a question here, and the reply I got from LeXXuz :-

https://forum.doom9.org/showthread.php?p=1987078#post1987078

[madey83]

It was something suggested to me several weeks ago, so I just went with it.

And I asked a question here, and the reply I got from LeXXuz :-

https://forum.doom9.org/showthread.php?p=1987078#post1987078

Does it mean the tone mapping is mandatory for SMDegrain to work on the source properly...?

[Guest]

Does it mean the tone mapping is mandatory for SMDegrain to work on the source properly...?

I can't really answer that, but I think it was only on HDR10 content, just to assist a particular filter/script.

It doesn't change HDR to SDR, tho.

[Dogway]

@FTLOY: You have to flip through the images, you won't see much differences as it is, just open them in tabs and flip through them, you will see the warping.

@LeXXuz: Probably a mistake on my part. I'm trying to guess my think process at the time.

I'm sorry for stupid question but why for HDR/DV source before degrain i need to use this call: "DGHDRtoSDR(mode="pq",white=2000)"?

i've done several denoising dolby vision source without it and for me looks identical in matter of colors after encode was done...
Computing motion vectors from a PQ log encoded clip is not a good idea because data is compressed and lacks contrast. That's why converting to SDR is recommended.

I did some extra tests and this is now my recommended call:
DGHDRtoSDR(mode="pq",white=XXX,gamma=1/2.4,tm=1.0)

is it posible you SMDegrain to remove grain from picture and if you could you please give an example how - how to point SMDegrain to take all pictures from folder and after degrain compress it to jpg again.
for movies i use StaxRip and defined insite it SMDegrain call, but for picture is for me something new.

SMDegrain is temporal, if you need to degrain single images use a spatial denoiser like KNLmeansCL, ex_bilateral, ex_minblur, or any kind of spatial median.

[LeXXuz]

@FTLOY: You have to flip through the images, you won't see much differences as it is, just open them in tabs and flip through them, you will see the warping.

That's actually what I did. :D


@LeXXuz: Probably a mistake on my part. I'm trying to guess my think process at the time.

No worries. ;)

[DTL]

"DGHDRtoSDR(mode="pq",white=XXX,gamma=1/2.4,tm=1.0)"

If follow the idea 'linear is better' it may be better to use 16bit linear (or for Die-Hard perfectionists - float32 linear). Or the gamma for 8bit (or 10bit) SDR may be adjusted based on some optimizing runs (like zopti ?) or individual users runs. So may be gamma closer to 1 (full linear) may run somehow better.

Also complete processing in SDR/linear for MDegrainX is not required - only MAnalyse can possibly benefit from running closer to linear. So it can process HDR in its natural transter domain (though it also may be not really good for linear blending). The best math results expected from linear processing (both MAnalyse and MDegrain) but linear HDR can not fit even in 16bit so only float32 (slowest) possible. Linear SDR of 8bit is only about 10bit so can be freely run in 16bit processing.

[Guest]

You don't have to change anything in your script regarding UHDHalf unless you want more quality at the cost of a hefty speed penalty. Then you'll have to add UHDHalf=false, limit=255 to your SMDegrain call.

Btw. I would do the tone mapping first with DGHDRtoSDR before filtering the prefilter clip with ex_Median.
pre=DGHDRtoSDR(mode="pq",white=2000).ex_Median(mode="IQMST",thres=255)

I tried this, and I get a error :(

This works:-

pre=ex_Median(video,mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=2000)
video=STTWM(video,sw=50,tw=50,aw=100,sthres=5,tthres=5)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)


This doesn't, has a DGHDRtoSDR error:- (fixed by adding the "red" video)

pre=DGHDRtoSDR(video,mode="pq",white=2000).ex_Median(mode="IQMST",thres=255)
video=STTWM(video,sw=50,tw=50,aw=100,sthres=5,tthres=5)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)

[kedautinh12]

Are you got DGHDRtoSDR plugins or your GPU support it??

[kedautinh12]

Can help if you don't give an error alert

[LeXXuz]

I tried this, and I get a error :(


What is the error you're getting?

[Guest]

What is the error you're getting?

Well the first script that works was something I think you suggested a couple of weeks or so ago...

But the other day you suggested to swap the DGHDR end
for end, and that's the one that just throws a simple DGHDRtoSDR error, something about it can't find it or the syntax is wrong or something.

I can't provide the exact error right now.

[LeXXuz]

"DGHDRtoSDR(mode="pq",white=XXX,gamma=1/2.4,tm=1.0)"

If follow the idea 'linear is better' it may be better to use 16bit linear (or for Die-Hard perfectionists - float32 linear). Or the gamma for 8bit (or 10bit) SDR may be adjusted based on some optimizing runs (like zopti ?) or individual users runs. So may be gamma closer to 1 (full linear) may run somehow better.

Also complete processing in SDR/linear for MDegrainX is not required - only MAnalyse can possibly benefit from running closer to linear. So it can process HDR in its natural transter domain (though it also may be not really good for linear blending). The best math results expected from linear processing (both MAnalyse and MDegrain) but linear HDR can not fit even in 16bit so only float32 (slowest) possible. Linear SDR of 8bit is only about 10bit so can be freely run in 16bit processing.

You're right. And on many movies I deliberately deepen the luma ramp to get better results. Quite a lot of movies have strong noise especially in the whites, which means the SAD is particular high in these areas.

With a linear ramp I have to raise thSAD way too much to get these areas denoised while the blacks and even midtone areas (skins f.e. !), already lose way too much detail.

So either you have to live with only partial denoising, which looks even more ugly than the original imho, or risk destroying detail, especially in areas where it's important to keep.

So I use Levels() in the prefilter clip to flatten the luma curve from the upper whites.

I even had a very old movie which looked way better in the end with heavily compressed luma (Levels(0,1.2,255*256,0,128*256)) (!) than with the default curve. And m.e. was still fine, even with that very low contrast.

BUT I also had the opposite where I really needed HDR-SDR conversion to get more contrast in the picture. A very foggy scene f.e. where peoples faces are barely visible, yet you have I nice amount of film grain in there + the compressed range. Have fun denoising that without losing those faces.
Unless you want to go with more fancy stuff like masking and such. Which is where I decided to draw the line of how much effort I'm willing to put into every single film.

So, as we know, there is no holy grail that works best for all contents.

[LeXXuz]

But the other day you suggested to swap the DGHDR end
for end, and that's the one that just throws a simple DGHDRtoSDR error, something about it can't find it or the syntax is wrong or something.

I can't provide the exact error right now.

Provide some when you have the time.
Like kedautinh12 already said, without a proper error message it's hard to tell what's going on. ;)

[kedautinh12]

FTLOY make me remember about old man, comment bug without error message :D

[DTL]

" get these areas denoised while the blacks and even midtone areas (skins f.e. !), already lose way too much detail."

It may be possible to make some level-depending mixer (using Layer/Overlay) and creating simple mask from (blurred) luma channel. So it will mix denoised and original noised clips based on (average/blurred) luma mask and it should allow to separately put to output high/mid/low luma parts of frame with weight from 0 to 100% from either denoised or original noised clip.

If it is frequently useful it may be added to 'limit' post-processing in the MDegrainN. May be auto-masking with some control values (gamma, high/low clipping) or external 0..255 single channel mask clip input.

[anton_foy]

" get these areas denoised while the blacks and even midtone areas (skins f.e. !), already lose way too much detail."

It may be possible to make some level-depending mixer (using Layer/Overlay) and creating simple mask from (blurred) luma channel. So it will mix denoised and original noised clips based on (average/blurred) luma mask and it should allow to separately put to output high/mid/low luma parts of frame with weight from 0 to 100% from either denoised or original noised clip.

If it is frequently useful it may be added to 'limit' post-processing in the MDegrainN. May be auto-masking with some control values (gamma, high/low clipping) or external 0..255 single channel mask clip input.

Very good I think we have the same approach since I use to merge filtered and original to send to prefiltering. Usually it works better than fully procesed.

[Guest]

Provide some when you have the time.


Well, I figured it out, it turned out to be very simple, and I'm almost embarrassed to say, so I won't. :rolleyes:

Fixed (https://forum.doom9.org/showthread.php?p=1987108#post1987108)

:thanks:

[LeXXuz]

Very good I think we have the same approach since I use to merge filtered and original to send to prefiltering. Usually it works better than fully procesed.

That is an interesting idea. Would you mind sharing your script for this before I have to start experimenting with this from scratch? :o

[LeXXuz]

I need some help with NNEDI3/CL.

Even with gpuid=-1 set in SMDegrain, NNEDI3CL is still used instead of NNEDI3.

TransformsPack, ResizersPack and SMDegrain are latest versions.

Oddly enough: if I remove NNEDI3CL from my plugins and select pel=4 but subpixel=3, I still get an error that there is no function NNEDI3CL in Transforms and Resizerspack :confused:

https://abload.de/thumb/2023-05-1517nvfvh.png (https://abload.de/image.php?img=2023-05-1517nvfvh.png)

Plus, I still have a VRAM memory leak with RTX 30 cards. NNEDI3CL uses up all VRAM. This does not happen with GTX 10 models, AMD RX or Intel ARC. Anyone made similar experience with NNEDI3CL?

[Dogway]

Ok I'm going to have a look now.

Meanwhile I wanted to ask for suggestions. Should I default UHDHalf to false? is it not too slow?
And second given my previous post about detail warping with UHDHalf, would you unregardless recommend defaulting 'limit' to 255 (and just add a warning about the artifact on the documentation and the workaround)?

Also I'm working on another Gamut Compression alternative for TransformsPack, looks great.

[LeXXuz]

Ok I'm going to have a look now.

Meanwhile I wanted to ask for suggestions. Should I default UHDHalf to false? is it not too slow?

I'd go with quality over quantity any day. But it may be too much of a speed penalty on an average desktop system.

Maybe leave it as it is but with a more obvious hint to a "Quality" mode for 4k content in the docs or the script header?

Personally I completely overlooked the UHDHalf setting. And without anton_foy's comment I still wouldn't know there is a reduction in pecision for 4k by default.


And second given my previous post about detail warping with UHDHalf, would you unregardless recommend defaulting 'limit' to 255 (and just add a warning about the artifact on the documentation and the workaround)?

I haven't done much testing with the limit yet. Isn't there anything in between 2 - 255 to make that effect a little less obvious/strong?

[Dogway]

I'd go with quality over quantity any day. But it may be too much of a speed penalty on an average desktop system.
What speed are we talking about? for example at a reference CPU on a UHD 16:9 aspect 24fps title. My reference is between 3fps and 5fps using x264 to encode a 2h title in about 8h (overnight) given only SMDegrain is used which is an optimistic take.

I haven't done much testing with the limit yet. Isn't there anything in between 2 - 255 to make that effect a little less obvious/strong?
So it is indeed obvious? Well, maybe I should pass the responsibility to MVTools' vector scaling and not assume strange defaults in SMDegrain.

[LeXXuz]

What speed are we talking about? for example at a reference CPU on a UHD 16:9 aspect 24fps title. My reference is between 3fps and 5fps using x264 to encode a 2h title in about 8h (overnight) given only SMDegrain is used which is an optimistic take.

Well, define reference CPU first. :D

Like I said, quality over quantity for me.
I encode everything with custom 10-bit presets for x265 which are somewhere between the build-in "Slower" and "Very Slow" preset. So those alone demand much more processing power than any x264 preset. Plus, I probably use much more demanding settings in SMDegrain than the average user. The biggest challenge here was to create workflows that nearly saturate my CPUs.

So around 5fps is an accustomed speed area for me, while others probably rather hang themselves than dealing with those speeds :D


So it is indeed obvious? Well, maybe I should pass the responsibility to MVTools' vector scaling and not assume strange defaults in SMDegrain.

It is to me. But others barely noticed the difference looking at the comments regarding your screenshots. Depends if you know what to look for and probably on what screens you watch your content.

[Dogway]

Thanks, so what's your CPU that you get 5fps with UHD denoising with UHDHalf=false and encoding in x265 (provide also 'tr')? That would make a reference ground to compare. For me a CPU from the 8th Gen or so onwards would be reference.
I just tested NNEDI3CL and got no issues with SMDegrain(2,pel=4,subpixel=4,gpuid=-1) with and without NNEDI3CL on the plugins path, what's your call and source?

I made some changes to defaults and documentation fixes, once this NNEDI3CL issue is solved I upload the new update.

[LeXXuz]

Note to myself: Never fiddle with your posts in the middle of the night on a tiny tablet. Somehow I managed to kill my last post. :confused::rolleyes:

So once again in short form:

Thanks, so what's your CPU that you get 5fps with UHD denoising with UHDHalf=false and encoding in x265 (provide also 'tr')? That would make a reference ground to compare. For me a CPU from the 8th Gen or so onwards would be reference.

That is with a Ryzen 7950x and more demanding settings in SMDegrain including custom filter chains for mfilter and prefilter. Plus debanding and FilmGrainPlus afterwards. All in 16 bit. Temporal radius I always use multiples of 6 which I found to be most effective. So most of the time tr=6 in some rare cases 12.
I also have two Ryzen 5950x and a 3950x machine. Which are about 25%, respective 40% slower than the 7950x.

If you like I can run some tests with parameters you usually use for a better comparison.




I just tested NNEDI3CL and got no issues with SMDegrain(2,pel=4,subpixel=4,gpuid=-1) with and without NNEDI3CL on the plugins path, what's your call and source?

I made some changes to defaults and documentation fixes, once this NNEDI3CL issue is solved I upload the new update.

I solved this. It was a fault on my end. I had more than one instance of NNEDI3 and NNEDI3CL in my plugin-folder after running some updates due to slightly different naming. So the new versions did not overwrite the old ones but got copied into the plugin-folder leaving the old ones. That must have caused some confusion in Avisynth. Sorry for the trouble. :o

But the VRAM leak is still present with RTX30. But I guess that is a problem between NNEDI3CL and Nvidia drivers.

[Dogway]

Yes, the 3950x is comparable to i7-8700 (about 10% faster though). The 7950x is about 90% faster than the 8700. So a simple test is ok without all the bells and whistles. This should target 4fps minimum.


# SDR 3840x2160 YUV420 limited source (P16 or P8)
ConvertBits(16)
SMDegrain(tr=3, UHDHalf=false, limit=255, refinemotion=true)
ConvertBits(8,dither=1)

# And encode with x264 or x265, with slow or medium preset.

EDIT: Finally updated SMDegrain to v4.4.0

[anton_foy]

That is an interesting idea. Would you mind sharing your script for this before I have to start experimenting with this from scratch? :o

Sorry for late reply, here is one you can try (with or without ex_unsharp):

w=last.width()
hq=convertbits(8,dither=-1).ConvertToYv12()
hq=hq.hqdn3d(0,0,12,12,13,mt=true).merge(hq,0.37).removegrain(11).ColorYUV(levels="tv->pc",gamma_y = 200).ex_unsharp(300/1800., Fc=w/8., th=0.0, UV=1)

Edit: this is the prefilter only, for smdegrain, mdegrain or mocomped temporal denoiser. Converted to yv12 for speed.

[StainlessS]

Note to myself: Never fiddle with your posts in the middle of the night on a tiny tablet. Somehow I managed to kill my last post. :confused::rolleyes:

TextAreaCache, originally suggested by HolyWu. [FireFox AddOn, also for Chrome]

https://forum.doom9.org/showthread.php?t=177066

[LeXXuz]

Yes, the 3950x is comparable to i7-8700 (about 10% faster though). The 7950x is about 90% faster than the 8700. So a simple test is ok without all the bells and whistles. This should target 4fps minimum.


You mean single core performance, right? In overall performance a i7-8700 is nowhere near a 3950x.

I'll do a speed test with your code on my machines. And post the results soon. :)

TextAreaCache, originally suggested by HolyWu. [FireFox AddOn, also for Chrome]

https://forum.doom9.org/showthread.php?t=177066


Thanks StainlessS! :) That could be a lifesaver next time I'm too dumb to use my fingers right. :D

[Dogway]

No, multi-threaded. Play with Prefetch to optimize performance. In any case I uploaded v4.4.0 because I have many pending projects and want to move on.
Probably today I upload v1.9 of TransformsPack with new Gamut Compression function.

[LeXXuz]

No, multi-threaded.

How can a 6C/12T i-8700 be any close to a 16C/32T 3950x :confused:

https://ark.intel.com/content/www/us/en/ark/products/126686/intel-core-i78700-processor-12m-cache-up-to-4-60-ghz.html

Unless we're talking about a different CPU, there is no way on earth this CPU would be as fast as a 3950x in multi-threading ;)

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-8700+%40+3.20GHz&id=3099
https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+9+3950X&id=3598

[Dogway]

They seem to be on par (https://cpu.userbenchmark.com/Compare/Intel-Core-i7-8700-vs-AMD-Ryzen-9-3950X/3940vs4057) for 4-cores. For 8-cores is about 40% faster but I don't know if AviSynth can really leverage 8-cores.

[LeXXuz]

They seem to be on par (https://cpu.userbenchmark.com/Compare/Intel-Core-i7-8700-vs-AMD-Ryzen-9-3950X/3940vs4057) for 4-cores. For 8-cores is about 40% faster but I don't know if AviSynth can really leverage 8-cores.

Avisynth can perfectly handle high core counts as long as the filters play along.

Here are the results with your SMDegrain settings for 3840x2160 source:
https://abload.de/thumb/speedtest_5950xkzdgg.png (https://abload.de/image.php?img=speedtest_5950xkzdgg.png)

From top left to bottem right:
tl: x264 Medium @ CRF20, tr: x264 Slow @ CRF20
bl: x265 Medium @ CRF20, br: x265 Slow @ CRF20

Taken on a system with 5950x CPU as can be seen in the screenshot.
Should be easy enough to interpolate that onto a 7950x or 3950x or your i7-8700.

As you can see the CPU is fully saturated with Prefetch(32).
The jobs were run in sequence of course and not parallel. I just paused them and left the windows open for better comparison.

Unless you have a rather old CPU I think UHDHalf=false is perfectly feasible considering the quality improvement.

[Dogway]

Thanks for the tests!
I read that for some people, maybe more complex scripts anything higher than Prefetch(4) or 6 didn't bring more performance. Anyway I don't use anything else than my signature rig so I set the 8700 as the cut off since it was a considerable performance step up compared to previous gens.

The 5950x is quite a monster so I expected a bit better numbers than those specially for such a simple script. I will keep the setting as 'false' for a while I think.

Will update TransformsPack as soon as I can, today if I have some time. Really excited for the new feature.

[Guest]

Thanks for the tests!
I read that for some people, maybe more complex scripts anything higher than Prefetch(4) or 6 didn't bring more performance. Anyway I don't use anything else than my signature rig so I set the 8700 as the cut off since it was a considerable performance step up compared to previous gens.

The 5950x is quite a monster so I expected a bit better numbers than those specially for such a simple script. I will keep the setting as 'false' for a while I think.

Will update TransformsPack as soon as I can, today if I have some time. Really excited for the new feature.

It's a shame that you only have access to a fairly old CPU (might have been a powerhouse in its day, but not so much, now).

I think it would make a significant difference to your settings, if you were able to upgrade.

And if you think a 5950X is a "monster", a 7950X shame's it !!!

[Dogway]

Well lately I've been only developing not really encoding/rendering. Even then I switched to Redshift render engine which is GPU based. And for the next 2 years I'll be doing some APPs in Dart.

I will wait until the market relaxes a bit, today prices are inflated and then I'll move to the next Xeon, even if it's the bottom tier. Not really digging this performance/efficiency core system and no AVX512 on top of that, also looking forward to AVX-1024, AMX2, TSX, DDR6 and PCI Gen6, and RTX5000 with path tracing for the GPU with some meaningful RAM+CUDA count.

[DTL]

"DDR6"

After Xeon Max with at least 64 GB of HBM integrated starts shipping in 2023 it looks DDR-SDRAM died in the past for high-performance computing. I hope for poor and dying end-users PCs for homes market intel (or may be AMD) can provide HBM-based CPU compute platform in close years. Still some hope exist.

Also the total compute platform architecture finally redesigned again - from poor host RAM with fast CPU and non-x86/64-compatible compute accelerator(s) mounted via PCIe bus intel finally moves to high-performance CPU+RAM factory assembled module with 20x faster RAM speed and it compatible with all x86/64 software and can use standart periferal and also graphics/DCA PCIe adapters if needed.

It can be designed to poor-people low-LGA CPU socket motherboards with 2ch DDR-SDRAM if expansion required.

[Guest]

Well lately I've been only developing not really encoding/rendering. Even then I switched to Redshift render engine which is GPU based. And for the next 2 years I'll be doing some APPs in Dart.

I will wait until the market relaxes a bit, today prices are inflated and then I'll move to the next Xeon, even if it's the bottom tier. Not really digging this performance/efficiency core system and no AVX512 on top of that, also looking forward to AVX-1024, AMX2, TSX, DDR6 and PCI Gen6, and RTX5000 with path tracing for the GPU with some meaningful RAM+CUDA count.

It's a shame that the 13th Gen Intel's dropped AVX512 support, and the P-cores & E-cores complicate the situation, a little.

However, the 7950X does have AVX512 support, and ALL cores do the job equally (kind of).

In my experience, the 7950X is just a little better than a 13900 (except maybe the 13900KS), when encoding.

But things just keep getting too expensive :(

[DTL]

How can a 6C/12T i-8700 be any close to a 16C/32T 3950x :confused:



The computing may be simply RAM-speed limited because AVS make most of data storage in main host RAM.

The simple 6ch DDR4 6 cores Xeon may run at 1800+ fps and any cores 2ch DDR4/5 based CPU may be limited to about 1000 fps - https://forum.doom9.org/showthread.php?p=1987162#post1987162

[Guest]

"DDR6"

After Xeon Max with at least 64 GB of HBM integrated starts shipping in 2023 it looks DDR-SDRAM died in the past for high-performance computing. I hope for poor and dying end-users PCs for homes market intel (or may be AMD) can provide HBM-based CPU compute platform in close years. Still some hope exist.

Also the total compute platform architecture finally redesigned again - from poor host RAM with fast CPU and non-x86/64-compatible compute accelerator(s) mounted via PCIe bus intel finally moves to high-performance CPU+RAM factory assembled module with 20x faster RAM speed and it compatible with all x86/64 software and can use standart periferal and also graphics/DCA PCIe adapters if needed.

It can be designed to poor-people low-LGA CPU socket motherboards with 2ch DDR-SDRAM if expansion required.

I don't think saying "poor people" is very polite....

[DTL]

"It's a shame that the 13th Gen Intel's dropped AVX512 support"

Intel optimize general-public (really shrinking and dying) market of home PCs to the standard performance tests to be comparable with AMD goods of the same season. So as general public market software close to no benefit from AVX512 and fast RAM - the marketing goods will continue to fight for best fps in Microsoft Word. So no AVX512 and no HBM RAM may reach general public CPUs any more.

For intel it is better to add E-cores with simple AVX2 (and 2 cores of AVX2 can overload simple 2ch DDR4/DDR5 RAM config - no need to put 1 core of AVX512 with about 4x more performance). So it will be comparable in MS Word and 7zip and all other standard marketing tests to make money in each season.

If you will look in the every-year home PCs tests - the intel and AMD is about +-10..30% of performance only. It is simple making money every year - not making high-performance compute platforms for users of smartphones.

Real HPC is Datacenters/Enterprise in 2023 and it is Xeon Max now.

For 8-cores is about 40% faster but I don't know if AviSynth can really leverage 8-cores.

AVS can start whatever required by user threads with Prefetch() and it will be displayed in Task Manager as busy CPU cores. But each thread is also a chain of filters and each filter is surrounded with large software cache located in host RAM. So Busy CPU cores typically spin idle loops and waiting for RAM. It is not thread-logical idle state so Task Manager of OS do not show core idle. It can be found in the hardware performance counters in VTune for example.

[kedautinh12]

It's a shame that you only have access to a fairly old CPU (might have been a powerhouse in its day, but not so much, now).

I think it would make a significant difference to your settings, if you were able to upgrade.

And if you think a 5950X is a "monster", a 7950X shame's it !!!

Old man was said: "7950x don't different with 5950x" :D

[Boulder]

Thanks for the tests!
I read that for some people, maybe more complex scripts anything higher than Prefetch(4) or 6 didn't bring more performance. Anyway I don't use anything else than my signature rig so I set the 8700 as the cut off since it was a considerable performance step up compared to previous gens.

The 5950x is quite a monster so I expected a bit better numbers than those specially for such a simple script. I will keep the setting as 'false' for a while I think.

Will update TransformsPack as soon as I can, today if I have some time. Really excited for the new feature.
The thing with Prefetch is that you have to control the number of frames or the performance will suffer (because the default is threads x 2 I think). Threads can always be set to the maximum number available IMO. For example, I use Prefetch(threads=32, frames=12) on my 5950X. Lowering the amount of prefetched frames will also have a positive effect on memory usage which is often an issue with 4K stuff and Avisynth cache being what it is..

[Guest]

Old man was said: "7950x don't different with 5950x" :D

Who is this "old man" you keep referring to ?

A 7950X with the right settings is WAY better than a 5950X !!!

[kedautinh12]

Who is this "old man" you keep referring to ?

A 7950X with the right settings is WAY better than a 5950X !!!

He is
https://forum.doom9.org/member.php?u=244197