DGDecomb

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

DGDecomb

Post by admin » Sun Mar 12, 2017 10:00 am

Just starting a thread for tracking a CUDA accelerated Decomb, which I name DGDecomb. The first thing to do, however, is to make a 64-bit version of Decomb. I can't believe I never made one. :facepalm:

Adding the existing Telecide() and Decimate() drops the frame rate from 395 fps to 85 fps for 1080p, so there is a lot of room for speed-up here.

User avatar
gonca
Distinguished Member
Distinguished Member
Posts: 663
Joined: Sun Apr 08, 2012 6:12 pm

Re: About DGDecomb

Post by gonca » Sun Mar 12, 2017 11:10 am

Would you consider a sub forum just for the DG (GPU) cudasynth filters.
DGCudasynth might be a good name?

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

Re: About DGDecomb

Post by admin » Sun Mar 12, 2017 11:15 am

I was thinking about that this morning. If I have a forum called (say) CUDA/CUVID Tools, then I would have to put DGDecNV in there also. So now I am thinking of just renaming the DGDecNV forum to CUDA/CUVID Tools. Or just do nothing. What would make sense for you?

Meanwhile, I'm trying to recall how Decomb works. :scratch: I have my old journal entries to remind me, thank heavens.

User avatar
gonca
Distinguished Member
Distinguished Member
Posts: 663
Joined: Sun Apr 08, 2012 6:12 pm

Re: About DGDecomb

Post by gonca » Sun Mar 12, 2017 11:32 am

Leave DGDecode where it is, after all, it is used with many third party tools outside of your control >>> DGDecode and DGIndex are universal tools
Cudasynth are reliant upon DGDecode and under your control
I just thought that the separate sub-forum would keep things neater and easier to track / manage

Aleron Ives
Distinguished Member
Distinguished Member
Posts: 113
Joined: Fri May 31, 2013 8:36 pm

Re: About DGDecomb

Post by Aleron Ives » Sun Mar 12, 2017 3:23 pm

I would suggest leaving the DGDecNV forum the way it is, but create a sub-forum named "DGDecNV Plugins" or something like that where you can put threads to discuss all of these secondary filters that rely on DGDecNV. You can then have all of these "master" threads gathered in one place while regular DGDecNV discussion continues as usual in the parent forum. At this point I don't think it's necessary to have separate sub-forums for DGDenoise/DGSharpen/DGDecomb, etc., but I think you have enough plugins/extensions now to warrant a general sub-forum for them as a group.

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

Re: About DGDecomb

Post by admin » Sun Mar 12, 2017 5:41 pm

Sounds good, gonca and Aleron. Thank you.

Aleron Ives
Distinguished Member
Distinguished Member
Posts: 113
Joined: Fri May 31, 2013 8:36 pm

Re: DGDecomb

Post by Aleron Ives » Sun Mar 12, 2017 5:51 pm

Oh, it looks like we got not a sub-forum, but a top-level forum. CUDA Filters are too proud to be subordinates of the DGDecNV forum! 8-)

:lol:

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

Re: DGDecomb

Post by admin » Sun Mar 12, 2017 7:29 pm

Oh yeah, I just noticed you suggested a subforum. :facepalm: Oh well, this works good too.

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

Re: DGDecomb

Post by admin » Mon Mar 13, 2017 10:56 am

Here's my current thinking on a design for fast matching. I will have two GPU textures set up, one for the current frame and one for the previous frame. I will have two GPU global memory arrays, one for the current-current per-pixel calculation results, and one for the current-previous calculations. The kernel will make the two difference calculations for a single pixel and store the results in the global memory arrays (of course, all the pixels run in parallel to the extent supported by the GPU). Then a second kernel will perform parallel reductions to get the sum of differences for current-current and current-previous.

When we step to the next frame, we don't want to have to update two textures, because on the GPU the current texture can become the previous texture. But swapping the references requires texture objects, which are supported only on Kepler+. So to keep the older cards, I will have two kernels which differ only in that they treat texture A as current and B as previous, and vice versa. Then the caller just calls the appropriate kernel, knowing which texture was just updated (the caller toggles between them, of course). On a random access, both textures are updated and then linear stepping is performed from there as described.

We'll actually need 4 differencing kernels in total, two as described above for TFF processing, and two for BFF. That will be more efficient than passing a kernel parameter and having conditionals in the kernel code.

This should be super fast. We'll see.

Postprocessing and decimation come later.

Aleron Ives
Distinguished Member
Distinguished Member
Posts: 113
Joined: Fri May 31, 2013 8:36 pm

Re: DGDecomb

Post by Aleron Ives » Mon Mar 13, 2017 3:10 pm

:wow:

Image

:lol:

Seriously though, thank you for preserving support for older cards.

Post Reply