DGDecomb

[admin]

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.

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.

[gonca]

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

[admin]

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. I have my old journal entries to remind me, thank heavens.

[gonca]

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]

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.

[admin]

Sounds good, gonca and Aleron. Thank you.

[Aleron Ives]

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!

[admin]

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

[admin]

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]

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