Quote:
Originally Posted by VS_Fan
I remember some years ago having problems with frame decimation in a Multi-Threaded environment (old AVS-MT) and trying innumerable different configurations for ‘RequestLinear’ to no avail.
What I successfully ended doing was: - Separating only the source, decimation with any other ‘MT_SERIALIZED’ filters in one Single-Threaded AVS script, No need of of using 'requestlinear';
- Then I either: ‘mounted’ that first script with AVFS; or simply read it directly with “AVIFileSource” into a second MultiThreaded AVS script where I put every other processing filters, susceptible of speed gains because of multi-threading
I don’t think this is genius idea, but I sincerely hope it helps  |
It's might be simpler than that. As far as I can tell FDecimate isn't in mtmodes.avsi, but since it's a m-in-n decimation filter it's almost certainly very stateful and not at all threadsafe. Setting it to MT_SERIALIZED might very well fix the crashing.
That said, the filter chain in that script is so full of ancient serialized junk so far down into the chain that the only thing of note that runs parallelized at all is FineSharp (I don't
think vdub filters are MT_NICE? who knows though), so it's no wonder it's not any faster. As a reminder, inserting a MT_SERIALIZED filter into a filter chain will effectively cause
every filter upstream of it all the way up to the source filter to run serialized too, at least as far as performance goes.
Quote:
Originally Posted by an3k
I have a Plugin (DGHDRtoSDR) that is not yet listed in the mtmodes.avsi and I would like to test (and add) it. I've searched but not found the info thus I asked here.
1) What is the "single-thread" mtmode in which every plugin perfectly runs at (since it's "non-MT-behavior")? Is it NICE_FILTER or SERIALIZED?
2) What is the most performant mtmode we would love to have all plugins running at? MULTI_INSTANCE?
Thanks |
1) MT_SERIALIZED.
2) MT_NICE_FILTER.
See
here for more details. As mentioned above, using a MT_SERIALIZED filter late in a chain effectively disables MT (you'll be so bottlenecked that MT doesn't help you much).
If you're using Vapoursynth though you can get some degree of parallelism even with serialized Avisynth filters, which you can't do in Avs+ itself. In Avs+, calling GetFrame on a serialized filter will essentially run every filter upstream of that point single threaded too, so requesting a frame will make the entire thing block until the entire chain is finished processing that frame, one filter at a time in a single thread. In VS, you still get a single instance of the serialized filter (in its own pretend environment) and it will only ever be asked to process one frame at a time, but upstream of it can run in parallel.