Support forum for DG Tools

FYI
Running a full encode of a very grainy source
Using DGDenoise(strength=0.075)
GPU is running in the high 90s percent ( 97 to 99)

admin wrote:Thanks for your testing, gonca. Good to hear you like my NLM implementation (based on nVidia sample of course).

Since you have a later iGPU, could you test DGBobIM for me? If so, please use the colored_fields.avs script with double-rate deinterlacing and let me know if random access returns the correct fields. I was worried that things might have changed for later iGPUs. If you get a chance, please report in the DGBobIM thread.

Also, any suggestions for additional GPU features would be welcome. I am looking at making a deblocker next, unless y'all have a better idea.

If I am understanding correctly the iGPU would be an integrated GPU within the i7
I am running an X edition i7, it has no graphics capabilities

Oy, you're right, 6900K has no iGPU!

No iGPU on a i7-6900k

OK, then, never mind about testing DGBobIM.

Sorry I couldn't be of help

I'm blaming Intel. You rock.

Had a thought
I might be able to test the IM functions in a couple of weeks
I ordered one of these https://www.newegg.ca/Product/Product.a ... -_-Product to be my HTPC which has a Kaby Lake i7, and if I can access the iGPU I will try to test the IM functions, with your help (I will probably need it)

That would be great. When you get it we'll work together on it. I might have a deblocker by then too.

Looks like a great system. I've been window shopping, but haven't pulled the trigger yet. I may do my own build this time.

My main system is a personal build, but with the form factor and custom parts (GPU) I decided t just order the system
The eyes aren't what they used to be

Solved the no opencl issue
Just had to copy the 32 bit opencl.dll into the gpucapsviewer folder
It is version 1.2

@gonca
Off the records: If compressability matters you may also want to try the x264 integrated denoiser. It is very fast (you will hardly notice a reduction in encoding speed) and efficient at improving compressability and preserving details in my experience with noisy videotape sources, using --nr 800. I didn't test it with high quality sources though.
Just add --nr xxx to the x264 commandline, xxx ranging from 0 to 1000. A good starting value is 200. It can also be used in combination with external filters of course.
On the downside you can't test it standalone outside of x264, means you have to run an encode (sample).
I just thought I mention this option.

Sharc wrote:@gonca
Off the records: If compressability matters you may also want to try the x264 integrated denoiser. It is very fast (you will hardly notice a reduction in encoding speed) and efficient at improving compressability and preserving details in my experience with noisy videotape sources, using --nr 800. I didn't test it with high quality sources though.
Just add --nr xxx to the x264 commandline, xxx ranging from 0 to 1000. A good starting value is 200. It can also be used in combination with external filters of course.
On the downside you can't test it standalone outside of x264, means you have to run an encode (sample).
I just thought I mention this option.

I don't like compressing that much, I like retaining as much detail as possible.
Just thought I'd post the compressed size for those that do filtering with the intent of gaining more compression
I just like to clean very lightly excessive noise or grain

gonca wrote:Solved the no opencl issue
Just had to copy the 32 bit opencl.dll into the gpucapsviewer folder
It is version 1.2

That doesn't seem right. GPUCapsViewer should find it in your system directory. If it can't, then how can KNLM?

Were you able to get KNLM working?

@Sharc

Thanks for the idea. I'm going to see how it performs for my encodes.

The older KNLMeansCL DLL does not work for me. It shows only gray frames and gives this exception:

KNLMeansCL: Avisynth GetFrame() error!

I run on Win10 64 with a GT 620, which has OpenCL 1.1 and driver version 378.49.

I will try reverting my driver, but DGDenoise works fine here.

I reverted to 376.53 and got things working with the older KNLMeansCL.

OK, Sharc is vindicated, as I obtained similar timings with my GT 620 to those he reported.

So things look like this right now: On Pascal GPUs (10xx), both gonca and myself find that DGDenoise is much faster than KNLMeansCL, while on pre-Pascal GPUs, Sharc and I both find KNLMeansCL winning. I have a Pascal, so I am happy. But seriously, this is pretty shocking and I will do some investigation to see what could be the cause of this big discrepancy between pre-Pascal and Pascal. Even if I find nothing I can do anything about, I'll release DGDenoise because it does perform marvellously on Pascal, and it does work in use cases where KNLMeansCL does not.

Tin-foil-hat guys might suggest that nVidia crippled OpenCL on Pascal, but that seems over the top. More likely to me is that CUDA was improved substantially. Volta is expected to double the performance of Pascal, so I am licking my lips.

I'll be buying another 1050Ti to put in my Win10 i7-980X machine. Still haven't pulled the trigger on i7 Kaby Lake.

never got it working
copying the dll was from the website for gpucapsviewer, I believe

Try copying it to System32 for Win10 64, or SysWOW64 for Win10 32. That is not reversed by mistake!

Then use nVidia driver 376.53 with a clean install.

opencl.dll already exists in system32
opencl.dll and opencl64.dll are in syswow64
That was one of the first things I checked

Uninstalled the Nvidia drivers
Searched and removed any stray opencl.dll files that were straggling
Re-installed drivers
Now Gpu Caps Viewer can see my opencl capabilities
Do you want me to try and retest with KNML

gonca wrote:Do you want me to try and retest with KNML

Only if you have the time and inclination. It would be interesting, for sure. Theoretically, the latest version should work.

Already started to recreate the sample

couple runs done on KNLM
Source is 1080p and very noisy, same as before

0,3,4,4.0 --- 2 fps
1,3,4,4.0 --- less than 1 fps

Didn't do the full 5 minute clip this time
I've seen molasses flow faster in February
Any other settings
Compared to this DGDenoise is an absolute speed demon

Thanks, gonca, default settings would provide the best comparison, so if you could do that it would be helpful.

BTW, I have a way to make it even faster, if you invoke it through DGSource(). Instead of invoking the denoising by means of Invoke() of the stand-alone DGDenoise() filter, I can run the kernel directly after getting the decoded frame back. This will save two full frame copies and Avisynth overhead per frame.

admin wrote:Thanks, gonca, default settings would provide the best comparison, so if you could do that it would be helpful.

Keep in mind that for KNLMeansCL the default for d is 1 which penalizes its speed in comparison.