fft3dGPU 0.8.2

[grennis]

Originally Posted by Dreassica

That looks liek you are using it in QMF, may very well be this filter not liking to be used within QMF.

I have no idea what QMF is, so I don't think I'm doing that

I have also noticed that I get D3D errors when using FFT3DGPU over remote desktop and disconnect/reconnect. There probably isn't much you can do about it?

Is the sigma value exactly the same as in the fft3dfilter? It seems like I need to use a higher sigma in fft3dgpu to get the same result.

[rkalwaitis]

TSP or someone else in the know.

I really like what I can do with this filter, Im very impressed by the quality I can achieve and results when compressing.

Just a few questions? I like to use x264. Are the cqm/cqf (Sharktooth's) matrixes necessary since the filter is so efficient?

I also seem to notice that the colors, (at least for me) tend to be a bit different? Is this a setting I'm dorking up? Perhaps a correction I can make? The colors seem to lend themselves to a slight blueish-green and the picture seems to brighten up a bit resulting in a slightly bleached look. I can tweak filter it and get back some of it. Is this another setting Im messing up!

Well anyways I like it. I wonder if using this filter with say 'snow' or 'msu' it would work faster?

[Adub]

Matrices are not specifically designed for the removal of noise, that's what denoisers are for. Sure a matrix can be tuned to help in the removal of noise, but not like a denoiser can. So, yes, as long as the quality is better than not using one, keep using a matrix.

If you get better results without a matrix then don't use it. These instances have nothing to do with fft3dgpu however, as it is a denoiser. Denoise your source until it looks as good as you want it to, and then encode it (with or without a matrix, your choice).

As to the colors, it maybe that you need to add ColorMatrix() to your script. It depends on what your source is and what you are doing with it.

For instance, if you are converting a DVD to mp4 or mkv, then chances are you will need to edit your script to look something like this:

DGDECODE_Mpeg2Source("video.d2v", info=3)
Colormatrix(hints=true)
...other filters...

It's correct use depends on the source, as I said above.

[rkalwaitis]

Thanks for the info. Adding the color matrix as you suggested worked. It was a dv2 source. Lots to learn. I can't tell a difference with the matrix I was trying to use, so Ill just not use it. They are confusing to me, ulr, vlr, .....and so on. I thought they could help me crunch a bit more, but in the end it is not that important. I like the best possible picture, then worry about size.

Thanks again.

[XBoy]

I'm trying to compile the latest source for x64 but it seems to be missing a few files, mainly

filtersps.h, filtersps.cpp, dxinput.h, dxinput.cpp

Where do these come from??

[Leak]

Originally Posted by XBoy

filtersps.h, filtersps.cpp, dxinput.h, dxinput.cpp

Where do these come from??

The latter 2 definitely come from the DirectX SDK, and I wouldn't be surprised if the same goes for the former...

[tsp]

sorry I have updated the file to include all 4 files although dxinput might cause problem the the latest version of directx SDK as support for dxinput has been removed.

http://www.avisynth.org/tsp/fft3dgpu0.8.2a.exe

[Mosfetov]

Oh, nice filter. It's very fast and gives high quality filtered image with minimum artifacts (even at high sigma). At 720p this filter works with my X800XT in realtime (framerate more than 24fps). There is only one restriction - size of GPURAM. It must be at least 256MB to work at 720p. Otherwise, speed will downgrade, because speed between GPU and aperture memory (System RAM) more-more slower than between GPU - GPURAM. But even in this case, FFT3DGPU works faster than FFT3DFilter. By default, i use bw=32, bh=32, ow=16, oh=16, or in some cases bw=64, bh=64, ow=32, oh=32. This takes approx up to 200+MB of GPURAM at 720p. If GPURAM only 128 MB, it's possible to use bw=64, bh=64, ow=16, oh=16. It reduces GPURAM utilization to 100-120MB at 720p and speed will boost. But quality will a little bit less.

Fizick, tsp, thank you for this useful filter!

PS: My box - X800XT 256MB, Athlon XP 2300MHz (FSB 192MHz, sync to RAM), nF2U400, RAM 2048MB

[murrsturr]

Thanks to both TSP and Fizick!

This stuff is very much appreciated by myself and thousands of others.. and at this point in time... I speak for them all!

[Blue_MiSfit]

Yeah seriously. I use this filter on practically every single stupid thing I encode - to kill chroma noise.

Amazingly effective, and basically free, since it runs on the GPU!

I like free!!!! Thanks guys!

~MiSfit

[Quark.Fusion]

I know you can assume that GPU-based filter isn't benefit from multithreading, but think about next filter in chain — while thread one doing it's part on GPU thread two still can do CPU part, and when it is thread two time for GPU, thread one can continue on next CPU part.

So is it possible to make thread-safe GPU filter? What about using CAL/CUDA?

Example:

MTsource(input)
MT("""
    FFT3DGPU()
    DeBlock_QED()
""")

in this example script can do deblock on first part while second is processing on GPU by using extra thread.

Why not just use mutex for synchrotisation?

[Terka]

2>tsp
on page 1 of this thread:

Have you plan to implement in GPU all my other plugins?
Only the FPU heavy filter

Could you please implement mvtools in GPU too?

[Zep]

Originally Posted by Terka

2>tsp
on page 1 of this thread:

Could you please implement mvtools in GPU too?

yeah MVtools is the main filter I wish was GPU also

[Terka]

everybody wishes

[Underground78]

Hello,

Is there a way to take advantage of a CrossFire system with fft3dGPU ? I've made some searches in this thread but I can't find anything new about that ...

[Underground78]

Hello,

There is something that puzzled me a bit, when using a script without fft3dGPU, x264 first pass runs at ~100 fps with a CPU usage near 100%, the same script with fft3dGPU (default settings) runs at ~45 fps but with a CPU usage of about 35% and a GPU usage of about 50% so I assume it could be faster ... What could explain this ?

Thanks in advance

[talen9]

Do you have a dual-GPU video adapter? If so, then I think FFT3DGPU is using only one of the two GPU cores, and the processing speed of that one core is lower than the one you can obtain using your (dual/quad core) CPU ... your best using that, I'm afraid, if my analysis is correct.

[Underground78]

Originally Posted by talen9

Do you have a dual-GPU video adapter? If so, then I think FFT3DGPU is using only one of the two GPU cores, and the processing speed of that one core is lower than the one you can obtain using your (dual/quad core) CPU ... your best using that, I'm afraid, if my analysis is correct.

The GPU occupation I've given is normally for one GPU only.

[Quark.Fusion]

I think that because GPU have many different blocks (ROPS, Shaders, etc) and fft3dGPU uses only vertex shaders. Look at shaders usage in GPU profiler.

[Underground78]

Originally Posted by Quark.Fusion

I think that because GPU have many different blocks (ROPS, Shaders, etc) and fft3dGPU uses only vertex shaders. Look at shaders usage in GPU profiler.

I will test this, thanks ! But where can I find this ? It seems to be a quite uncommon tool ...