Wow, parallel ATA connectors. What's the CPU, a 386?
The first processor I coded for was an 8080. The OS was CP/M. It had a 100K floppy drive that raised and lowered the head on each sector access (the infamous head-loading solenoid), causing a pleasing bang-bang-bang that the neighbors loved. I clearly remember tossing that system (Heathkit H8) in the dumpster when I upgraded to a 386-based system.
8080 and 386
Those were the days, never to be seen again, thank whichever supreme deity for that small favor
Gee-sh, now I am getting politically correct
CUDASynth-enabling of DGDenoise is complete. It was an involved thing because I had to code and test all combinations of: fulldepth=true/false [times] chroma=true/false [times] fsrc=cpu/gpu0/gpu1 [times] fdst= cpu/gpu0/gpu1. That is a total of 2x2x3x3 = 36 combinations, each with its unique mix of CUDA kernel launches and pitched 2D memcpy's. It all seems to be working, thankfully. Don't ever accuse me of not being persistent.
There are four things to do now:
1) Ensure all filters still work fine when the source filter does not declare GPU buffers and a lock, i.e., when the source filter is not CUDASynth-enabled. This is context creation/management stuff. I also want to add an integer pipeline ID that can be specified in the script, thereby allowing for multiple pipelines to run simultaneously.
2) Thorough code review and any needed refactoring.
3) Vapoursynth native support.
4) Documentation and code sample (open source).
I'm going to hold off on 3) for now, do the others and then give y'all the new toy to play around with.
Have to open source the CUDA filter framework to recruit others to develop compatible filters. The core filters should be CUDASynth-enabled as well.
Item 1) above is finished, but without the pipeline ID. That is going to need some deeper thinking, as it must allow any filter to create ping-pong buffers, etc. Let's hold off on that for now. So tomorrow, I want to make the documentation and source code example and get it into your hands. Code review can be done in parallel with your testing.
The source is 3840x2160 59.94 HDR10. The resulting frame rate is 95 fps, 1.6 x real-time. If the pipeline is not used (all fsrc and fdst set to "cpu", then the frame rate is 30 fps, half of real-time. So for this real-world example CUDASynth is increasing performance by over 300%. Gotta love it, am I wrong?
The source code example filter is done. I used DGSharpen (debundled from DGDecodeNV) and removed the licensing and CUDA code encryption. Now I just have to write some documentation.
No visible issues that I could see on the encoded file
CPU usage down, and surprisingly so is GPU and VPU load.
Speed is right up there though
Looks good
Thanks for the test results, gonca. Now to get some critical mass we need to make more CUDASynth-enabled filters. Feel free to suggest possibilities. If there are any good open source ones it would not be hard to port them.
testing, sorry, per the CUDASynth.txt "* Vapoursynth is not yet supported" unfortunately I no longer have avisynth.
Filters possibilities ? You have current functionality for
- decode / deinterlace / crop / resize
- denoise
- sharpen
- HDR10 to SDR
That's about all I use, other than maybe an occasional
- deblock for low quality TV broadcasts (Aus telly can be bitrate starved)
- video stabilisation, rarely, more for the home videos that one must share including vhs type captures
- croprel, addborders, rarely, more for the home videos that one must share including vhs type captures
- HDRAGC or equivalent, rarely, more for the home videos that one must share including vhs type captures
- despot, very rarely for some vhs type captures
- mdegrain, very rarely for some vhs captures etc
- anti-alias ?sangnom, almost never nowadays
- QTGMC deinterlacing, almost never nowadays
I'd like to have nnedi3/eedi3 CUDA versions. They are cpu consuming, and offloading to gpu will help a lot. Currently we have nnedi3 openCL (full rewrite to use gpu only) and eedi3 openCL (partial rewrite to use gpu for calculating connection costs), so the second one still consuming cpu for main processing.
If you want to look at them, eedi3 | nnedi3.
Thank you, gentlemen, for the thoughts and links. eedi3 and nnedi3 look like they might be fun to try. First, though, I need to get serious about DGIndex MKV support.
@hydra3333
For Vapoursynth, can't you use the avscompat layer? I can add native support later, although I have to confess that the required code duplication is a royal pain in the you-know-what.
avscompat layer seems to be working, but speed is near the same as in "cpu" mode.
But still relatively fast - near 65 fps (default settings, DGSource -> DGDenoise -> DGSharpen) and 105 fps (default settings, DGSource -> DGDenoise).
Hardware: GTX 750, i5-4670k
I'll measure avscompat (without and with fsrc/fdst) soon, need to close browser to have more GPU RAM for testing.
And as there are no native Vapoursynth versions for DGDenoise/DGSharpen, should I check them in avscompat and DGSource in the native modes?