Support forum for DG Tools

https://www.newegg.com/Product/Product. ... 6819113541
https://www.amazon.com/AMD-Threadripper ... per+2990wx
review
https://wccftech.com/amd-ryzen-threadri ... benchmark/

Unless you want to go dual cpu server, then Epyc CPUs would be it

Looks good. Any suggestions for a compatible mobo?

https://www.newegg.com/Product/Product. ... 6813144079
https://www.newegg.com/Product/Product. ... 6813145044
https://www.newegg.com/Product/Product. ... 6813157785
https://www.newegg.com/Product/Product. ... 6813157784

Just read the reviews

Thank you!

The other option you might want to consider, seeing as you have this thing about GPUs (NVidia), is to drop the CPU to the 16 core/ 32 thread version and maybe go with 2 GPUs
or
(note: here goes the budget)
Get the 32 core CPU and 2 GPUs

gonca wrote: ↑

Wed Sep 19, 2018 3:37 pm

(note: here goes the budget)
Get the 32 core CPU and 2 GPUs

That sounds good. I don't have a budget. I'm getting older so I'm going to blow it all on hardware and travel adventures.

BestBuy went to preorder on the 2080 Ti but by the time I saw the alert it was all taken. Nobody wants these things.

Thanks for making this thread go into flames (the icon on the forum list).

Thanks for making this thread go into flames

That is how I learned about the hardware side of things.
Making things go up in flames

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

If using the word "God" is politically incorrect, then we are done. Praise the Lord!

Status report...

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.

Thank you very much.

You're welcome, hydra3333!

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.

Consider this script:

dgsource("LG Chess 4K Demo.dgi",fulldepth=true,fdst="gpu0")
dghdrtosdr(light=250,fsrc="gpu0",fdst="gpu1",fulldepth=true)
dgdenoise(fsrc="gpu1",fdst="gpu0",chroma=true)
dgsharpen(fsrc="gpu0")
prefetch(2)

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?

Gotta love it, am I wrong?

You are right

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.

I am happy to announce CUDASynth 0.1:

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

Testing and feedback will be appreciated.

Got a couple of things to finish off and then the testing will begin

Speed looks good Can't see the results of the cudasynth file in VDub or MPC-HC so I will run quick encode and check

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

DGTelecide
DGDecimate
DGPQtoHLG

I tend to use the DG filters more than any other

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.

Masktools 2 seems to be popular
https://github.com/pinterf/masktools/releases