CUDASynth
Re: CUDASynth
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.
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.
Re: CUDASynth
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)
and
(b)
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
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)
(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")
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
I really do like it here.
Re: CUDASynth
Yesand 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." ?
Re: CUDASynth
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.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." ?
Re: CUDASynth
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
Snippet (b) is the one from DJATOM's testing of the cudasynth dll
Re: CUDASynth
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.
To get precise answers, one needs to ask precise questions.
Re: CUDASynth
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
* 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
Re: CUDASynth
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?
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?
Re: CUDASynth
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
PC: RTX 2070 | Ryzen R9 5950X (no OC) | 64 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Re: CUDASynth
Beaut !
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.admin wrote: ↑Tue Oct 09, 2018 4:38 pmOne 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?
I really do like it here.
Re: CUDASynth
Being a control freak from way back (too many systems went belly up if decent control was omitted during development) I always manually load everything and don't begrudge a line or 20 of code Personal preference.DJATOM wrote: ↑Tue Oct 09, 2018 5:56 pmYeah, 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
rar ? google tells me
3rd seems about right given the vsrepo experience with 7zWhat does RAR stand for in finance?
Abbr. Meaning
RAR Revenue Agent Report (US IRS)
RAR Refund-Anticipated Return
RAR Run At Risk
RAR Regulatory Asset Ratio (finance)
I really do like it here.
Re: CUDASynth
If you go this route all I really need to do is change my templates to be avs compatible.
So, all is good
Now that I think about it, the only reason I moved to vs was the lack of high bit depth support in the avisynth chain (NVEncC)
That has been corrected though
So, all is good
Now that I think about it, the only reason I moved to vs was the lack of high bit depth support in the avisynth chain (NVEncC)
That has been corrected though
Re: CUDASynth
Good points, guys, thanks.
I have found a simple script that runs perfect in Avisynth+ but runs at half speed and then stops completely in Vapoursynth native (no CUDASynth for both). I want to check a few things first and then I'll give you the script to see if you can replicate it. Then we'll have to try to figure out what is going wrong.
I have found a simple script that runs perfect in Avisynth+ but runs at half speed and then stops completely in Vapoursynth native (no CUDASynth for both). I want to check a few things first and then I'll give you the script to see if you can replicate it. Then we'll have to try to figure out what is going wrong.
Re: CUDASynth
I found the cause of the Vapoursynth slowdown and stoppage. DGHDRtoSDR was missing a freeFrame(src) call (affecting only the Vapoursynth code) and so memory was being exhausted. I'll release a fix later today and then get back to proper benchmarking.
Re: CUDASynth
Good to hear you are making headway
Re: CUDASynth
Yup. I also got things going with my test script in avscompat mode. I had an earlier version of Vapoursynth and when I upgraded to R44 everything started working.
Re: CUDASynth
Following are performance results with a simple script with just DGSource() followed by DGHDRtoSDR() for 3840x2160. I won't give the exact scripts right now as I need to give you a revised DGHDRtoSDR.dll and a revised AvsCompat.dll to enable you to duplicate my results. I'll give you those things in a while. Benchmarked with AVSMeter and VSEdit.
The change made to AvsCompat.dll for the results below was to add PREFETCHR1(DGHDRtoSDR). DGHDRtoSDR() is not temporal but the prefetching helps Vapoursynth to parallelize things.
Native Avisynth+: 80.4 fps / 14% CPU
Native Avisynth+ with pipeline: 181.7 / 8% CPU
Native Vapoursynth: 79.8 fps
AvsCompat Vapoursynth: 80.2 fps
AvsCompat Vapoursynth with pipeline: 181.7 fps
These results support my proposed plan to not make Vapoursynth native versions but rather to ship an optimized AvsCompat.dll instead. I'm also thinking of revising AvsCompat.dll to be able to read from a file of prefetch values, so users can tweak things. Or, maybe better, add a prefetch parameter to the filter itself for use by AvsCompat.dll. Always thinking outside the box.
The change made to AvsCompat.dll for the results below was to add PREFETCHR1(DGHDRtoSDR). DGHDRtoSDR() is not temporal but the prefetching helps Vapoursynth to parallelize things.
Native Avisynth+: 80.4 fps / 14% CPU
Native Avisynth+ with pipeline: 181.7 / 8% CPU
Native Vapoursynth: 79.8 fps
AvsCompat Vapoursynth: 80.2 fps
AvsCompat Vapoursynth with pipeline: 181.7 fps
These results support my proposed plan to not make Vapoursynth native versions but rather to ship an optimized AvsCompat.dll instead. I'm also thinking of revising AvsCompat.dll to be able to read from a file of prefetch values, so users can tweak things. Or, maybe better, add a prefetch parameter to the filter itself for use by AvsCompat.dll. Always thinking outside the box.
Re: CUDASynth
This sounds like a great idea.Or, maybe better, add a prefetch parameter to the filter itself for use by AvsCompat.dll.
Allows to tweak the performance by filter instead of entire script
Re: CUDASynth
Very nice, yes.
I wonder, the vs author may accept a patch https://github.com/vapoursynth/vapoursynth
I wonder, the vs author may accept a patch https://github.com/vapoursynth/vapoursynth
I really do like it here.
Re: CUDASynth
Just thought to let you guys know I managed to place an order for a 2080 Ti Founders Edition with the nVidia store. It's estimated to ship between 10/19/2018 and 10/26/2018. It's financed from donations so thank you to my users! You know I will use it to make DG tools greater than ever before for all of us.
https://www.nowinstock.net/computers/vi ... rtx2080ti/
Meanwhile, on the CUDASynth front, I have discovered some very interesting things focused around what Prefetch() does in Avisynth+, and what the PREFETCH macro does in Vapoursynth, and how they interact with CUDASynth. It opens a possible avenue for further performance gains. I'll write a post about it when I get an energy burst. Right now I am working on DGIndex MKV support. I have decoded and displayed a frame from an MKV but have loads of things to do to complete MKV support. Fortunately, most of it can be pulled from DGDecNV.
@hydra3333
A patch would likely not be accepted as similar ideas have been rejected. No problem; it's easy to replace AvisynthCompat.dll.
https://www.nowinstock.net/computers/vi ... rtx2080ti/
Meanwhile, on the CUDASynth front, I have discovered some very interesting things focused around what Prefetch() does in Avisynth+, and what the PREFETCH macro does in Vapoursynth, and how they interact with CUDASynth. It opens a possible avenue for further performance gains. I'll write a post about it when I get an energy burst. Right now I am working on DGIndex MKV support. I have decoded and displayed a frame from an MKV but have loads of things to do to complete MKV support. Fortunately, most of it can be pulled from DGDecNV.
@hydra3333
A patch would likely not be accepted as similar ideas have been rejected. No problem; it's easy to replace AvisynthCompat.dll.
Re: CUDASynth
My 2080 Ti shipped today and will arrive Saturday.
Re: CUDASynth
Financed by my users. Thank you!
Re: CUDASynth
I stepped out for an unavoidable coaching session, and 7 minutes after I drove away the FedEx guy arrived. Murphy's Law. They retry tomorrow and I'll be home all day. I am excited about the tensor cores.