CUDASynth

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
User avatar
admin
Site Admin
Posts: 4002
Joined: Thu Sep 09, 2010 3:08 pm

Re: CUDASynth

Post by admin » Mon Oct 08, 2018 5:46 pm

Thanks, guys, awesome!

DGDenoise and DGSharpen are both CUDASynth-enabled.

Meanwhile, there is another limitation I discovered. Some 3rd party players and encode apps open the script multiple times. That will not work with CUDASynth as currently designed because there can be only one pipeline. I think I can fix that up fairly easily by having only the first source filter set up the framework.

Also, I have CUDASynth-enabled DGPQtoHLG. I'll make a release tomorrow after some testing.

User avatar
hydra3333
Distinguished Aussie Member
Distinguished Aussie Member
Posts: 132
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: CUDASynth

Post by hydra3333 » Tue Oct 09, 2018 12:33 am

Extremely nice work, DG. Thank you.

edit:To allay my lack of clarity, in the context of the new pipeline enabled DGDecodeNV.dll and the aforementioned test scripts with like
(a)

Code: Select all

core.std.LoadPlugin("C:/Program Files (Portable)/dgdecnv/x64 Binaries/DGDecodeNV.dll")
clip = core.dgdecodenv.DGSource(r'I:\test.dgi', fieldop=0, fulldepth=True)
and
(b)

Code: Select all

core.avs.LoadPlugin(r'C:\322\x64\DGDecodeNV.dll')
clip = core.avs.DGSource(r'J:\Darling6\STREAM\EP16.dgi', fdst="gpu0")
clip = core.avs.DGDenoise(clip, fsrc="gpu0", fdst="gpu0")
edit: added LoadPlugin to snippet (b) for clarity

and per the CUDASynth.txt "* Vapoursynth is not yet supported", would be correct to say the original non-cudasynth DGDecodeNV.dll is used in snippet (a) with ".dgdecodenv." and cudasynth DGDecodeNV.dll in snippet (b) with ".avs." ?

Hmm, I must not have caught up with the latest as my (long not updated) scripts have continued to use "core.avs.LoadPlugin" and "core.avs.DGSource" rather than "core.std.LoadPlugin" and "core.dgdecodenv.DGSource" ... damn, get I must get in from the scrub outa the midday sun. https://www.youtube.com/embed/z2YvYiWto ... &version=3
Last edited by hydra3333 on Tue Oct 09, 2018 6:16 pm, edited 1 time in total.

gonca
Distinguished Member
Distinguished Member
Posts: 607
Joined: Sun Apr 08, 2012 6:12 pm

Re: CUDASynth

Post by gonca » Tue Oct 09, 2018 5:30 am

and per the CUDASynth.txt "* Vapoursynth is not yet supported", would be correct to say the original non-cudasynth DGDecodeNV.dll is used in snippet (a) with ".dgdecodenv." and cudasynth DGDecodeNV.dll in snippet (b) with ".avs." ?
Yes

User avatar
admin
Site Admin
Posts: 4002
Joined: Thu Sep 09, 2010 3:08 pm

Re: CUDASynth

Post by admin » Tue Oct 09, 2018 9:28 am

and per the CUDASynth.txt "* Vapoursynth is not yet supported", would be correct to say the original non-cudasynth DGDecodeNV.dll is used in snippet (a) with ".dgdecodenv." and cudasynth DGDecodeNV.dll in snippet (b) with ".avs." ?
No. The dgdecodenv versus avs decides whether the referenced DLL is invoked natively or via the avscompat layer. Either way, you would still load the same DLL. However, the CUDASynth DLL can only be loaded with avscompat at this time. If you omit the load plugin call then you could pick up something from autoloading. I recommend always using explicit loading.

gonca
Distinguished Member
Distinguished Member
Posts: 607
Joined: Sun Apr 08, 2012 6:12 pm

Re: CUDASynth

Post by gonca » Tue Oct 09, 2018 10:05 am

Snippet (a) is the one I used in the benchmarking you asked for, and it uses to original non-cudasynth dll
Snippet (b) is the one from DJATOM's testing of the cudasynth dll

User avatar
admin
Site Admin
Posts: 4002
Joined: Thu Sep 09, 2010 3:08 pm

Re: CUDASynth

Post by admin » Tue Oct 09, 2018 10:19 am

I don't see a loadplugin call in snippet b so it's ambiguous. Also, snippet b leaves the output on the GPU. The last filter should output it to the CPU.

To get precise answers, one needs to ask precise questions. ;)

User avatar
admin
Site Admin
Posts: 4002
Joined: Thu Sep 09, 2010 3:08 pm

Re: CUDASynth

Post by admin » Tue Oct 09, 2018 11:08 am

CUDASynth 0.2:

* Added CUDASynth-enabled DGPQtoHLG.

* Revised the user manual: explain meaning of gpu0/1 (not different cards!),
added note that Vapoursynth can be used in avscompat mode, and mention
limitation of some players and third-party apps.

http://rationalqm.us/misc/CUDASynth_0.2.rar

User avatar
admin
Site Admin
Posts: 4002
Joined: Thu Sep 09, 2010 3:08 pm

Re: CUDASynth

Post by admin » Tue Oct 09, 2018 4:38 pm

Regarding the test results you guys gave, I'm having a little trouble digesting it as you have included CUDASynth results when I specifically asked you to exclude it. Also, there seems to be some confusion about native versus avscompat, etc. Finally, we want the prefetch() call for Avisynth+, otherwise we throw away some performance. Tell you what, I'll do some testing and post full results with full scripts and we can go from there.

One of my motivations here is to know whether using the asvcompat layer for Vapoursynth loses performance versus native. To be honest, I'd like to know why I should bother with the PITA of duplicating code to have native Vapoursynth if avscompat performs the same. Even if I have to release an avscompat.dll that's way easier than writing Vapoursynth native code for everything. Any thoughts?

User avatar
DJATOM
Posts: 32
Joined: Fri Oct 16, 2015 6:14 pm

Re: CUDASynth

Post by DJATOM » Tue Oct 09, 2018 5:56 pm

Yeah, it's possible to make autoloading with hand-written python module (as I did before native DGSource version came out), but it's, say, wasting a time to type another line in the script. So I'd like to have native versions if possible. I almost don't use avs+ nowadays, moved to VS about 1 year ago :lol:

User avatar
hydra3333
Distinguished Aussie Member
Distinguished Aussie Member
Posts: 132
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: CUDASynth

Post by hydra3333 » Tue Oct 09, 2018 6:25 pm

admin wrote:
Tue Oct 09, 2018 4:38 pm
Tell you what, I'll do some testing and post full results with full scripts and we can go from there.
Beaut ! :hat:
admin wrote:
Tue Oct 09, 2018 4:38 pm
One of my motivations here is to know whether using the asvcompat layer for Vapoursynth loses performance versus native. To be honest, I'd like to know why I should bother with the PITA of duplicating code to have native Vapoursynth if avscompat performs the same. Even if I have to release an avscompat.dll that's way easier than writing Vapoursynth native code for everything. Any thoughts?
An eminently reasonable line of reasoning :) Maybe also a question over at the other site as to what may or may not be be foregone if using the asvcompat layer for Vapoursynth versus native ? With any luck the VS author may provide some insight.

Post Reply