View Single Post
Old 23rd May 2020, 17:43   #197  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by Boulder View Post
I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.
A minor note: vector scaling is no longer necessary with newer mvtools, MDegraining a 16 bit clip will accept vectors made from arbitrary bit depth source. This is why you can MDegrain even a 32 bit float clip.

I suppose, you get those numbers with older avisynth versions as well?
Last year (or before that) I investigated a similar source which behaved sub-optimally, to say at least. I could reach e.g. 60% CPU max. Could not solve it.

Vapoursynth has a rather different strategy on requesting frames. An Avisynth filter which requires e.g. 6 input clips (2-2 vector clips, super and the source clip itself) is requesting them in a serial ways inside a GetFrame. Caching helps a lot but not always. Contrary to this, Vapoursynth start requesting all 6 inputs _parallel_ and waits until they are all ready.

Maybe your case is a different one, which is only showing that the source filter (which is usually automatically set as MT_SERIALIZED mode) is getting more out of order (random) requests than it can cope with or cache.

Does your source filter have a debug or more verbose logging mode?
pinterf is offline   Reply With Quote