AviSynth+ thread Vol.2

[TomArrow]

Hello. I'm trying to develop a plugin and running into super strange stuff. My plugin is an import plugin that produces an RGB64 image. When I try to use ConvertToRGB48() on the output I get the error

"Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame".

I can assure you that my code does absolutely nothing CUDA-related. The same happens if I output RGB48 and try to convert to RGB64. This does not happen if I try to do this with a BlankClip.

However if I just leave it at outputting RGB64 and open the script without any conversions in VirtualDub, it shows me the image just fine with no issues.

Is this some new stuff? How do I fix this? I reckon the error might lie somewhere else and this might just be a symptom but I find this mystifying.

Edit: With ffmpeg I get access violation. Must be some other issue I guess that's bleeding over.

Edit 2: This actually happens even with an older version of the plugin: http://avisynth.nl/index.php/ImageSequence . If you take the 64 bit plugin and use it with the wildcard input filter for 2 jpeg files and then run ConvertToRGB48() after it, the same error happens, including the access violation in ffmpeg (but not in VirtualDub). I'm at a loss.

Edit 3: On a sidenote, my PC doesn't even have CUDA. It's an AMD APU without a discrete GPU.

Edit 4: Searching around on Google, I ignorantly (without knowing what it even does) tried adding onCPU(1) after the input plugin. Made no difference. Then I tried onCUDA(1) and it said "This AviSynth does not support memory type 2(CUDA)". This is, uh, really strange?

Edit 5: Ok it might have been an access violation that somehow went under the radar for years and nobody noticed. I fixed that, however I downgraded to a lower AVISynth version, so not sure if I'll get to test if it also solved the CUDA thing error.

Edit 6: Ok this problem was completely unrelated to the Access Violation problem. Bottom line is, every version above 3.7.0 (I tested from newest backwards) has this problem with the CUDA stuff.

[gispos]

Originally Posted by gispos

This repo contains Clang builds of AviSynthPlus.

Unfortunately I get error messages every now and then with these builds.
AvsPThumb (a delphi program) cannot create a clip every now and then. I have never had this problem with the official versions, but I have never tested a 'Clang' version before.
I don't know if it's the clang compiler or not.

Unfortunately I can't provide any exact information about the error, but I just wanted to post it here, even if it doesn't make much sense.

New test build (r3820)
https://gitlab.com/uvz/AviSynthPlus-Builds

Since r3820 there are no more problems so far.
Nice!

[Stereodude]

Is prefetch supposed to slow down sources?

A script consisting of only a source

DGSource("HZLIP.dgi")

I get 550fps per AVSmeter without a prefetch or with a prefetch of 1. With a prefetch of 2 or more it drops to ~60fps. I'm sure you're wondering why I'm using prefetch with just a source. I'm not normally, but I'm trying to figure out if my script was source limited and saw this behavior.

[FranceBB]

Some plugins have their own multithreading that works internally and I'm pretty sure DGSource() is one of them.
For those who have their own multithreading and/or threadpool, Prefetch() will do nothing but harm.
To be absolutely fair, I'm not a big fan of Prefetch as I believe plugins should be multithreading and create their own thread-pool in the best and most efficient way, without relying on Avisynth trying to be smart.
Things used to be much worse back in the days (I'm talking about AVS 2.5 MT) and that came back to bite me in one of my first jobs as encoder for a streaming company when I was hardsubbing stuff as some filters didn't really like the temporal discontinuity introduced by some of the MT Modes.

Anyway, long story short, it's normal to get faster speeds without prefetch for some filters/plugins as it means that they create their own threadpool with their own multithreading (and rightly so).

[Stereodude]

Originally Posted by FranceBB

Some plugins have their own multithreading that works internally and I'm pretty sure DGSource() is one of them.
For those who have their own multithreading and/or threadpool, Prefetch() will do nothing but harm.
To be absolutely fair, I'm not a big fan of Prefetch as I believe plugins should be multithreading and create their own thread-pool in the best and most efficient way, without relying on Avisynth trying to be smart.
Things used to be much worse back in the days (I'm talking about AVS 2.5 MT) and that came back to bite me in one of my first jobs as encoder for a streaming company when I was hardsubbing stuff as some filters didn't really like the temporal discontinuity introduced by some of the MT Modes.

Anyway, long story short, it's normal to get faster speeds without prefetch for some filters/plugins as it means that they create their own threadpool with their own multithreading (and rightly so).

FWIW, I did find that after adding another filter to the script that the prefetch at the end didn't slow down DGSource anymore.

[FranceBB]

Originally Posted by Stereodude

FWIW, I did find that after adding another filter to the script that the prefetch at the end didn't slow down DGSource anymore.

Perhaps the filter you added is single thread and therefore nullified the advantage of DGSource()?

Try with:

DGSource()

Spline64ResizeMT()


###Use whatever parameters you like###

from plugins_JPSDR.dll
I know for sure that his plugins have their own multithreading and create their own threadpool, so you should see better results without Prefetch() compared to with Prefetch, thus confirming my hypothesis.


p.s if you don't get better results without Prefetch, then I'll join you in the

[Boulder]

My guess is that using Prefetch clogs up the lane between the CPU and the GPU in a single line DGSource's case. Have you checked what the GPU usage shows in Task Manager for the AVSMeter process? I've noticed that when launching an encode, it jumps very high at the beginning and then gradually slows down as the encoder does not request frames so fast (because my script has denoising, resizing etc. in it). In my case it's like 3-4% at maximum during the encode phase.

[Stereodude]

r3820 doesn't really do this anymore. I was using r3661 before. No prefetch is 550, prefetch(2) is 535, prefetch(12) is 500.

[DTL]

It may be a bug or issue with internal MT:

I sometime have lost of MT (single thread running) with adding

myclip=some_filter()
return myclip

Prefetch(N)

If simply left internal last clip as output

some_filter()

Prefetch(N)

- the MT of N threads is working. It can not be easy simulated with BlankClip but happens with last filter of MDegrainN (or Weave after MDegrainN) from mvtools for me. May be it depends on MT_MODE somehow too.

It is typically not a great issue because I use return as debug/tuning preview and production script is running without return at the end. But some finding.

[Gavino]

'return' ends the script execution so the Prefetch() is never invoked.

Do this:

return myclip.Prefetch(N)

or

return myclip. \
Prefetch(N)

[LigH]

Another variation: If you don't explicitly use any return statement, then the last statement of a script is the implicit "return last" statement. All you have to do is assigning your active clip variable to the implicit "last" clip variable. You can do that with an explicit assignment using the equal sign, or implicitly by just mentioning the clip variable in a single line.

myclip = some_filter()

myclip
# means the same as:
# last = myclip

Prefetch(N)
# means the same as:
# last = last.Prefetch(N)

# implicit last statement:
# return last

Keep in mind: Wherever you don't explicitly assign a specific clip variable (using "=" or "."), the result of a filter is assigned to the implicit clip variable "last".

[DTL]

"the last statement of a script is the implicit "return last" statement."

If add

return last
Prefetch(N)

The MT also not working.

Prefetch(N) before return -

Prefetch(N)
return last

the MT is working. Putting Prefetch to the beginning of script returns error 'bad arguments for Prefetch'. So it looks Prefetch(N) need to be applied to the last (output) clip ?

Found in the documentation: http://avisynth.nl/index.php/SetFilterMTMode
Enabling MT
You enable MT by placing a single call to Prefetch(X) at the end of your script, where X is the number of threads to use. If there is a return statement in your script it must be placed after Prefetch().

So to return something from middle of script with MT:

myclip = some_filter()

myclip=Prefetch(myclip, N)

return myclip

?

[LigH]

You really misunderstood.

"Implicit" statements are those you do not write in the script but they are in fact executed because you did not write them.

Originally Posted by DTL

"the last statement of a script is the implicit "return last" statement."

But only

Originally Posted by LigH

If you don't explicitly use any return statement

Only if.

[Gavino]

Originally Posted by LigH

If you don't explicitly use any return statement, then the last statement of a script is the implicit "return last" statement.

Being pedantic, it is not strictly true that "return last" is the default action when 'return' is omitted.
In practice, that is usually what happens, but there are some cases when 'last' is not returned, such as when the final expression is not a clip. See here.)

[TDS]

Originally Posted by gispos

Deleted. Wrong thought.

Try this :-

Go into "edit", and the delete option is in the bottom right corner of the message window.

[gispos]

Originally Posted by TDS

Try this :-

Go into "edit", and the delete option is in the bottom right corner of the message window.

Thanks

[TomArrow]

Any clues on the "Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame" problem?

Way to reproduce:

1. Get newest AVISynth+ release.

2. Grab CoronaSequence plugin from http://avisynth.nl/index.php/ImageSequence

3. Load image sequence with CoronaSequence command.

4. Add ConvertToRGB64() at the end.

[Emulgator]

If I only had enough time I would skim AviSynth source code for that error
"Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame"

[VoodooFX]

Originally Posted by TomArrow

Any clues on the "Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame" problem?

No error on my side.

[Reel.Deel]

Originally Posted by Emulgator

If I only had enough time I would skim AviSynth source code for that error
"Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame"

https://github.com/AviSynth/AviSynth...anager.cpp#L81