fft3dGPU 0.8.2

[tsp]

Test this new GPU version of fft3dfilter.
Get the newest
version 0.8.2 (http://www.avisynth.org/tsp/fft3dgpu0.8.2a.exe). manual installation (dll and hlsl only) (http://www.avisynth.org/tsp/fft3dgpu0.8.2.7z)
version 0.8.1 (http://www.avisynth.org/tsp/fft3dgpu0.8.1.exe). manual installation (dll and hlsl only) (http://www.avisynth.org/tsp/fft3dgpu0.8.1.7z)
version 0.8 (http://www.avisynth.org/tsp/fft3dgpu0.8.exe). manual installation (dll and hlsl only) (http://www.avisynth.org/tsp/fft3dgpu0.8.7z)
version 0.7 (http://www.avisynth.org/tsp/fft3dgpu0.7.exe). manual installation (dll and hlsl only) (http://www.avisynth.org/tsp/FFT3dGPU0.7.7z)
version 0.6.4 (http://www.avisynth.org/tsp/fft3dgpu0.6.4.exe). manual installation (dll and hlsl only) (http://www.avisynth.org/tsp/FFT3dGPU0.6.4.7z)
version 0.6.3 (http://www.avisynth.org/tsp/fft3dgpu0.6.3.exe).
version 0.6.2 (http://www.avisynth.org/tsp/fft3dgpu0.6.2.exe).
version 0.6.1 (http://www.avisynth.org/tsp/fft3dgpu0.6.1.exe).
version 0.6 (http://www.avisynth.org/tsp/fft3dgpu0.6.exe).
version 0.51 (http://www.avisynth.org/tsp/fft3dgpu0.51.exe). (Manual installation available here (http://www.avisynth.org/tsp/fft3dgpu_051.zip))
version 0.5a (http://www.avisynth.org/tsp/fft3dgpu_05a.zip).
version 0.47 (http://www.avisynth.org/tsp/fft3dgpu_47.zip).
version 0.46.1 (http://www.avisynth.org/tsp/fft3dgpu_0461.zip).

From the readme:

Introduction

FFT3dGPU is a GPU version of Fizick's FFT3DFilter. The algorithm (Fast Fourier Transform, denoising) is the same for the most part. Currently the following is not implemented: support for noise pattern.

In this version the next frame is processed while waiting for the GPU to end it's work. Meaning the filters before fft3dGPU are working concurrently with it.
Install:

To use this filter you need directx 9.0c or better and a graphics card supporting directx 9 in hardware. That is at least an ATI Radeon 95xx or Nvidia Geforce fx 5xxx. Geforce 6xxx or better is recommended. If you have downloaded the installer just run it and you're done, else copy fft3dgpu.hlsl and copy FFT3dGPU.dll into the same directory from the 7-zip archive, also install the latest version of directx (april 2006 or later). You can get it here or extract the file d3dx9_30.dll (not included in the archive) to the c:\windows\system32 directory. The installer will copy d3dx9_30.dll to the right location meaning that it shouldn't be neccesary to run the directx installer if you have Directx 9c installed.
Syntax

FFT3DGPU(clip, float "sigma", float "beta", int "bw", int "bh", int "bt", float "sharpen", int "plane", int "mode", int "bordersize", int "precision", bool "NVPerf", float "degrid", float "scutoff", float "svr", float "smin", float "smax", float "kratio", int "ow", int "oh", int "wintype" , int "interlaced", float "sigma2", float "sigma3", float "sigma4", bool "oldfft" )
Function parameters:

clip: the clip to filter. The clip must be YV12 or YUY2.

sigma and beta has the same meaning as in fft3dfilter. Default=2.

sigma2, sigma3, sigma4 If specified controls the sigma value for highest(sigma) to lowest frequency(sigma4). Default=sigma

bw,bh: blockwide and block height. It should be a power of 2 ie valid values is 4,8,16,32,64,128,256,512 (note that bw should be greater than 4 for best result). Default=32

bt: mode. bt=-1 sharpen only, bt=0 kalman filtering, bt=1 is 2d filtering, bt=2 uses the current and previous frame, bt=3 uses the previous current and next frame, bt=4 uses the two previous frames, the current and next frame. default 3

sharpen: positive values sharpens the image, negative values blurs the image. 0 disables sharpening. Default 0.

plane: 0 filters luma, 1,2 and 3 filters Chroma (both U and V). 4 filters both luma and chroma. Default 0.

mode: 0 only overlaps 1:1. This is faster but produces artifacts with high sigma values.
mode=1 block overlaps 2:1. This is slower but produces fewer artifacts.
mode=2 again 1:1 overlap but with a additional border. This reduces border artifacts seen with mode=0. The speed is between mode 0 and 1.
Kalman(bt=0) works well with mode=0. Default 1

bordersize: only used with mode 2. Defines the size of the border. Default is 1.

precision: 0: to use 16 bit floats(half precision),
1: to use 32 bit float(single precision) for the fft and 16 bit float for the wienner/kalman and sharpening.
2: allways use 32 bit floats.
Using 16 bit float increases the performance but reduces precision. With a Geforce 7800GT precision=0 is ~1.5 times faster than than mode 2. Default=0.

NVPerf: Enables support for NVPerfHUD (http://developer.nvidia.com/object/nvperfhud_home.html). Default false.

degrid: Enables degriding. Only works well with mode=1. Doesn't degrid the Kalman filter (but it does degrid the sharpening (if enabled) after kalman filter). default 1.0 for mode=1, 0.0 for mode=0 or 2

scutoff, svr, smin, smax:Same meaning as fft3dfilter. Controls the sharpening. default scutoff=0.3, svr=1.0, smin=4.0, smax=20.0

kratio: same as fft3dfilter. Control the threshold for reseting the Kalman filter. Default 2.0

ow,oh: this only works with mode=1. This specifies how big the overlap between the blocks are. Overlap size must be less than or equal to half the blocksize. Ow must be even. Default: ow=bw/2 ,oh=bh/2

wintype: Change the analysis and syntesis window function. Same as fft3dfilter

interlaced: Set to true for separate filtering for each field. Default=false.

oldfft: Set to true to use the old fftcode (used in version 0.6.2 and lower) false to use new fft code. If not defined fft3dgpu will use the fastest code.
FAQ:
Q: What does it mean when I get a popup box Unexpected error encountered with Error Code: D3DERR_OUTOFVIDEOMEMORY.

A: It means that fft3dgpu needs more memory than there are availebol on the graphics card. So either you will have to upgrade or try lowering the resolution, precision, bt,bh,bw,ow,oh or use usefloat16=true or mode 0 or 2
Q: I can't get this filter to work

A: Try upgrading to the latest drivers(ati radeon or nvidia geforce). Check if your card is supported (see below). If that doesn't solve the problem write me an bug report (see support) where you include the script used, program used and what GPU, driver version, windows version and directx version version you use.
Q: What setting gives the same result as fft3dfilter?

A:fft3dGPU(mode=1,precision=2) is similair to fft3dfilter() but please note the different default values for bw,ow,bh,ow
Q: Is there any differences between fft3dfilter and fft3dgpu?

A: Some of the features from fft3dfilter is still missing.
Q: Why is fft3dGPU so slow compaired to fft3dfilter?

A: either you have a slow graphics card like a Geforce FX 5200 or you are not using it while doing cpu heavy encoding (like XviD/DivX)
Q: How do I use NVPerfHUD?

A: set NVperf=true and used this commandline or make a shortcut to run it: "PATH TO NVPerfHUD\NVPerfHUD.exe" "PATH TO VIRTUALDUB\virtualdub.exe" "PATH TO AVS\test.avs" and enabled "force NON PURE device"
Q: I get this errormessage: "Only pixelshader 2.0 or greater supported"

A: It is because you need a graphics card that has hardware support for Directx 9.
The following cards will not work:

Nvidia:
TNT
TNT2
Geforce 256
GeForce2 Ultra, Ti, Pro,MX,Go and GTS
Geforce3 Ti 200, Ti 500
GeForce4 Ti, MX, Go

Ati:
Radeon 7xxx
Radeon 8xxx
Radeon 90xx
Radeon 92xx

Matrox:
G2xx
G4xx
G5xx
maybe Parhelia

The following should work:

Nvidia:
Geforce FX 5xxx
Geforce 6xxx
Geforce 7xxx

Ati:
Radeon 9500
Radeon 9550
Radeon 9600
Radeon 9700
Radeon 9800
Radeon Xxxx
Radeon X1xxx

where x means any digit.

Support:

This thread on the doom9 forum or my email address (tsp (at) person.dk).
TODO:

(maybe) noise pattern support. Fix all the stupid bugs. Add the directx 9.0b version back.
Changelog:

* 0.1 first release. Buggy and used Brook
* 0.2 sigma should now work like fft3dfilter
* 0.3 Rewrote the code to use Directx 9.0 directly and support for 16 bit float increasing performance and stability.
* 0.31 Fixed bug causing aliased edges.
* 0.4 Added sharpen, mode 1,2, reduceCPU and multithreading
* 0.41 Fixed bug when calculating PSD.
* 0.42 Fixed memory leak when reloading
* 0.43 Fixed bug that caused coruptions on the Geforce FX cards and some more memory leaks. Added more comments to the sourcecode and small performance improvement in the shaders. Also added support for directx 9.0b
* 0.44 fft3dgpu can now reset a lost device and continue work. The direcx 9.0b version should work now.
* 0.45 fixed bug when filtering the chromaplane and mode=0 or 2 crashed the filter.
* 0.46 fixed lockups on hyperthread enabled machines(hopefull). Also fixed infinite loop when closing WMP 6.4.
* 0.46.1 fixed issue with nvperf=true causing fft3dgpu to lock up. Added a FAQ section to this file.
* 0.47 fixed bug with corrupted frames after reseting a lost device. Renamed the readme.txt to fft3dgpu.txt. Uses a newer version of DirectX 9.0c so please _read the install instructions_!!!
* 0.5 Added Kalman, sharpening, bt=4, degrid from fft3dfilter. Renamed ps.hlsl to fft3dgpu.hlsl. Rewrote some of the code. Added new bugs.
* 0.5a fixed bug with bt=2. Only file changed is fft3dgpu.hlsl
* 0.51 Fixed bugwithparametersafterNVPerfwasshifted.iedegrid=scutoff,scutoff=svr. Improved download speed from GPU. Geforce fx 5xxx now works with Kalman filter.
* 0.6 Added wintypes, plane=4 and variable overlap size (ow,oh). Change useFloat16 to precision. Changed default value for mode to 1
* 0.6.1 variable overlap now works on the geforce fx 5xxx. Default value for mode is 1 now.
* 0.6.2 bugfix: Degrid works better and vertical banding is gone when using mode 1. Right edge artifacts gone when using non mod 8 width and plane>0.
* 0.6.3 New fft code. Should improve performance when using larger blocksize and precision= 2(by up to 70%). Fixed bug with HC 0.17 crashing. New html doc(thanks Fizicks for creating this).
* 0.6.4 new fft code should now work with ati cards.
* 0.7 Added sigma2,sigma3 and sigma4 and support for interlaced filtering. Uses the fastest fft code now.
* 0.8 Added support for YUY2 colorspace. If not enough GPU memory is available the least used texture will be swapped to system memory.
* 0.8.1 Fixed crash when recovering lost device with plane=4 (thanks Fizick). Changed default for bt to 3 as ff3dfilter
* 0.8.2 Fixed crash when recovering lost device with interlaced=true (thanks Fizick) and recovering lost device with bt=0 and sigma2,3,4 =sigma.



Sourcecode released under GPL see copying.txt

[708145]

Very nice indeed :D

Could somebody with a recent GPU please provide info about results, problems, speedup, ...?

It'll definitely help to convince me to get out and buy a new GPU ASAP ;)

bis besser,
Tobias

[Soulhunter]

Hrm, bt mode 3 gives me this... (http://img107.exs.cx/img107/1258/118ve.png) :\

But mode 1/2 works nice (720x576 @ ~10fps) !!!

My box: Athlon XP2800+ / 1024MB RAM / GeForce 6600GT


Bye

[Fizick]

Tsp,
talanted works!
But not for my GF2MX400 :(
So, I will stay with fft3dfilter :)
BTW, what is "hole frame" ? Whole?

Once more question:
Have you plan to implement in GPU all my other plugins?
:D

[tsp]

BTW, what is "hole frame" ? Whole?


umm yes typo. It should be whole frame. So the border are also filtered.


Have you plan to implement in GPU all my other plugins?

Only the FPU heavy filter ;)

Also how does the Kalmar filter works if I should implement it?

Soulhunter: I get a similar result with bt=3. If you use usecache=false the chroma shift disappear (and also the speed)
I'm trying to find out where the error is.

708145: On my computer an athlon xp 2400 MHz with an ASUS Geforce 6800 GT (V9999GT) I get about 10-11 fps @ 720x576
I'm a little curious how the radeons would perform.

[bill_baroud]

gah, i forgot my usb dongle, i don't have my screenshots...

well i tested, and got some weird results, quickly :

- it does not any filter (??) but insert some weird black square on the image, of size bh/bw.

- it add some black borders horizontally too.

- speed is about 5-6fps on my FX5900 (looks like it likes those fps :)

[tsp]

I fixed the chroma bug with bt=3. Also added a new option reducecpu. If enabled the cpuload is reduced (but so is the framerate but hopefull it will be fixed someday).
Same link as before.

bill_baroud: What driver are you using? What size is the image? How does the script look like? This filter only process YV12.

[bill_baroud]

uh yeah, i forgot ... Source is MJPEG (avi) or MPEG4v2, 768x576 (PAL cap) or 832x480. My script just convert to YV12 and use fft3dgpu() with default settings (well i tried to change the others settings, but with no luck, it only change the size of black squares).

Drivers ??? huh ... i don't think they are the latest, something like 66.77.

I also tried other colorspace as input, but the results were really funky as expected, and not like my bug.

[tsp]

bill_baroud: I have tested the filter with version 66.93 and 71.80 both didn't show any artifacts. You could try to update the driver.

[Fizick]

tsp,
But sigma=1 in fft3dfilter ~ sigma=25 in fft3dGPU.

How about compatibility? I use:

norm = 1.0f/(bw*bh); // do not forget set FFT normalization factor
sigma2NoiseNormed = bt*sigma*sigma/norm; // normalize noise value

[Backwoods]

GeForce 6800 OC

720x272

FFT3dFilter = 10-12fps

FFT3dGPU = 12-16fps

(sigma=3.0, bt=3, bh=32 ,bw=32) for both filters.

[tsp]

Fizick I have added the normalization code to sigma. The only thing I can't seem to figure out is how to apply the 2d window function. At the moment I'm using af 1d window but this produces artifact with sigma values above 10.
When just multiplying the cosx and cosy values I get a checkboard pattern(when the picture is shifted bw/2 and bh/2 and summed the factor doesn't add up to 1.

edit

nevermind I cheated and used this as the window function:

void ImgStream::CreateFactorMap(float* Map,int x,unsigned int xnum,int y,unsigned int ynum,bool shift)
{
double cosy,cosx;
unsigned int offset=0;
double x1=x;
double y1=y;
//xnum=xnum/2;
//ynum=ynum/2;
for(unsigned int repy=0;repy<(ynum+shift);repy++){
for(double n1=(shift&&(repy==0||repy==ynum)?0:-y1/2.0)+0.5;n1<y1/2.0;n1++){
cosy=cos(n1*pi/(y1));
for(unsigned int repx=0;repx<(xnum+shift);repx++){
for(double n2=(shift&&(repx==0||repx==xnum)?0:-x1/2.0)+0.5;n2<x1/2.0;n2++){
cosx=cos(n2*pi/(x1));
Map[offset++]=sqrt(0.5*(cosx*cosx+cosy*cosy));
}
}
}
}
}


I have upload version 0.2 where the sigma values should work like fizick's fft3dfilter.

[Antitorgo]

Hmm... seems really slow.

The previous version I tested got something like 6-7fps now I get 2-3fps... This is with reduce CPU set to false (I tried true and got the same framerate with lower CPU utilization)... This could be because of something on my laptop or something tho.

From the stuff on the AviShader thread...

On the sleep() calls, I do them before copying the texture back, in D3D, as soon as the DrawPrimitive() call happens, the GPU begins it's thing, so any work you do between there and copying the texture back is the place to do things. For example, you can start copying the next frame up to the GPU or any sort of preprocessing on the CPU.

As far as my channel idea... if you are uploading a 1 channel 8-bit image (typically Luma) to the GPU, I'm guessing that brook is doing packing/unpacking into a 32-bit texture (which is native on the GPU) at 1/4 the width. This leads to an ineffeciency because of the packing/unpacking that has to happen on the GPU and just adds overhead. My idea was to upload 4 frames into each channel on a 32-bit texture, then you can run the shader across 4 frames at a time. In your case, it is a little complicated because you have your shifted/multiplied frame thing going on... so I'm not sure if it is applicable in your case (In avishader, I expect it to give me a huge performance boost when I get around to implementing it)...

[tsp]

Antitorgo I don't get lower framerates with the new version. Strange.
Also in this version the sleep is placed just before EndScene. And the texture is uploaded as D3DFMT_L8 then converted to D3DFMT_A32B32G32R32F where all the calculation is done (FFT requeres float) before converted back to D3DFMT_A8R8G8B8 for download. But I'm convienced that I will have to rewrite the filter without brook if I shall optimize this filter more. So now I just have to learn how to set up DirectX to do the rendering :p

[Antitorgo]

Yeah, copying back using the A8R8G8B8 is what has always killed me too, because it is the slowest operation and has to transfer 4x as much data as necessary. That is why I was thinking that the 4 frame at a time deal would work well...

If you want the source for AviShader which has all the D3D stuff, PM me and I'll see what I can do. D3D is pretty straightforward once you grok it.

[tsp]

when using A8R8G8B8 (or fixed4 in brook) I pack 4 pixels to avoid waisting bandwidth (see FFT3dshader.br for the brook shaders).

[tsp]

released version 0.3. It's a major rewrite now using Directx directly instead of brook. The shaders are also optimized and the filter can now use float16(2 byte float) instead of float32(4 byte float or single precision) for storing the calculations causing an up to 150% speed increase compaired to version 0.2:
This is the framerates for version 0.2 ,0.3 and fft3dfilter using this syntax:
fft3dGPU(bt=1,sigma=2)
fft3dfilter(bt=1,sigma=2)
on a 720x576 clip:

fft3dfilter 7.0 FPS
fft3dGPU 0.2 11.0 FPS
fft3dGPU 0.3 24.3 FPS

this is on an athlon XP 2400 MHZ (nforce-2 chipset 200 MHz DDR ram)
and a Geforce 6800 GT 128 MB RAM (411 MHz core/742 MHz mem).

So a 350 % speed increase compaired to fft3dfilter. Nice...

Please report if the filter work with your graphics card. What card it is and how fast.

I have only tested this version with my geforce 6800 GT so I don't know how well it works with geforce FX 5xxx and Radeon Xxxx and 9xxx so please try and report back.

[Backwoods]

AVISource("otto.avi")
ConvertToYV12()
(sigma=3,bt=3)

FFT3DFilter 4-6 fps
FFT3dGPU 8-12 fps

720x480

GeForce 6800OC
2.8HT
1gig RAM

And I noticed the AA problem too.

[tsp]

Fixed the bug causing the aliased edges. Get the fixed version from the first post.

Also it would be nice if you could post the driver version you are using.

Backwoods: I'm a little curious why you only get 8-12 fps when I get about 18-21 fps on a 720x576 clip using bt=3. Maybe it's the 4 extra pipelines in the geforce 6800 GT.

[Blue_MiSfit]

AWESOME!

On my 9800 pro I get about 7-15 fps (encoding into cq2 qpel vhq4(&bvop) xvid) depending on the scene with a crop, lanczosresize(), removegrain(mode=2) and unfilter(-5,-5) before it.

powerful denoising without smudging the image too much, I really like it so far for the new Star Wars DVDs which have an absurd ammount of noise (gives 6of9 nightmares when barely filtered!!).

More later

~misfit

[Didée]

Originally posted by Blue_MiSfit
(gives 6of9 nightmares when barely filtered!!)
No, it doesn't give nighmares to 6of9.

It gives you nightmares because of the achieved high bitrates ... ;)

For pressing very noisy sources into tiny files, 6of9 is not suited, by intention.

[Backwoods]

Originally posted by tsp
Backwoods: I'm a little curious why you only get 8-12 fps when I get about 18-21 fps on a 720x576 clip using bt=3. Maybe it's the 4 extra pipelines in the geforce 6800 GT.

Just installed 71.84 and fft3dgpu 0.31 and now:

12~22 fps maintained 16-18

720x480

Xvid Q2

[vinetu]

I did some tests and here is the results.
The CPU is P4 1.8GHz overclocked to 2.9GHz,The VGA card is Radeon 9600 Non Pro.
The source avi is an uncompressed, progressive 720x576 YV12.avi ,273 frames,almost static natural video .
The avs script is :
-------------
LoadPlugin("fft3dGPU.dll")
Avisource("X:\YV12.avi")
fft3dGPU(bla,bla)
-------------
The "X:" drive is a 500 Mb RAMDiSK drive.
Processed in VirtualDubMod in direct stream mode and the filtered avi is saved on the same RAM drive -no HDDs involved...

It's really impossible to me to see the differences between original and filtered images,
so I decide to compress the filtered avi files at later point to XviD (single pass,quant 2,no B-frames) to "visualize" the filtering.

The chain is "uncompressed->fft_filter->uncompressed".

|__ settings __________________ | fft3dfilter (fps) / XviD avi Size _____ | fft3dGPU (fps) / XviD avi Size

|__ no filtering ________________ | _______________________________________________ 9,861,120 bytes

| (sigma=2.0, bt=1) ____________ | _ 10.11 fps / 8,026,112 bytes _____ | 18.20 fps / 9,439,232 bytes

| (sigma=3.0, bt=3) ____________ | __ 7.58 fps / 6,307,840 bytes _____ | 16.05 fps / 7,495,680 bytes ___ |

| (sigma=3.0, bt=3, bh=16 ,bw=16) | __ 5.46 fps / 6,408,192 bytes _____ | 19.50 fps / 8,501,248 bytes ___ |

| (sigma=3.0, bt=3, bh=48 ,bw=48) | __ 7.00 fps / 6,305,792 bytes _____ | 13.00 fps / 6,516,736 bytes ___ |
| (sigma=3.0, bt=3, bh=48 ,bw=48) | ___ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | 14.37 fps (R9600 overclocked from 325/202 to 425/225 core/memory)



This test is my fisrt try with fft based filtering -I'm VERY impressed by the compressibility results without distorting original.

Bow to the ground to both of you Fizick and Tsp!!!

Edit: text formating :(

[tsp]

thanks for the feedback. Wonder if someone with a Geforce 6800 Ultra SLI could test this filter ;)

vinetu: Please note that if bw or bh is not a power of two (4,8,16,32,64,128,256,512) it's rounded up to the next power of two 48 -> 64. This is not the case when using fft3dfilter because it uses fftw. Also it should be faster to compress directly to XviD when using fft3dGPU because the waisted CPU cycles when waiting on the graphics card are used the encode the last processed frame (if the program is multithreaded (virtualdubmod is)).

[vinetu]

Thank You tsp!!!

In addition to speed tests - there is no difference in speed between AGPx8 and AGPx4 modes here,
so I guess PCI-E cards should have equal performance to AGP ones (if core chip/memory is the same)

Best Regards

[Soulhunter]

Uhm, the latest version throws a error... :\

http://img100.exs.cx/img100/866/9869sy.png (http://www.imageshack.us)

[tsp]

Soulhunter: You should copy the file ps.hlsl from the zip file into the same directory as fft3dgpu.dll (in this case c:\programme\Avisynth 2.5\plugins\)

[Soulhunter]

Ouch, I feel very stupid now... :D

Guess it was one of this "drag&drop" errors !?!


Bye

[Leo 69]

With this filter I get resized picture (i.e reduced one) with bunch of big black artifacts all over the place. I use GeForce FX 5900 NU @ 71.84 official drivers. :(

[tsp]

Leo 69: Damn I hoped the new version would work on a Geforce Fx. Would you try this (http://www.tsp.person.dk/test.zip) version and see if it works with bt=1 or bt=2 or both. In this test version the filtering is disabled so it is just to see where the error is.

[Blue_MiSfit]

@ Didee

No, it doesn't give nighmares to 6of9.

It gives you nightmares because of the achieved high bitrates ...

For pressing very noisy sources into tiny files, 6of9 is not suited, by intention.


I was actually doing a cq2 compressibilty test for 6of9

[Leo 69]

Originally posted by tsp
Leo 69: Damn I hoped the new version would work on a Geforce Fx. Would you try this (http://www.tsp.person.dk/test.zip) version and see if it works with bt=1 or bt=2 or both. In this test version the filtering is disabled so it is just to see where the error is.

Yes, the test version works fine :)

[tsp]

Leo 69: Also with fft3dGPU(bt=1)?? If that is the case it shouldn't be to hard fixing the error.

[Leo 69]

Originally posted by tsp
Leo 69: Also with fft3dGPU(bt=1)?? If that is the case it shouldn't be to hard fixing the error.

Yes, everything's OK with bt=1 too, tsp

[tsp]

Leo 69: Good then try version 0.31 again but change the following passage in the end of ps.hlsl(should be in the same directory as fft3dgpu.dll. It's an ordinary text file so use notepad to open it)


//****************************************************************
#ifdef BETA
float4 WFilter( PS_INPUT In) : COLOR
{
float4 src=tex2D(Src,In.texCoord);
float2 PSD=float2(length(src.xz),length(src.yw));
float4 MulFac=float4(BETA.x,BETA.x,BETA.x,BETA.x);
if(SIGMA.x<PSD.x)
MulFac.xz=((PSD.x-SIGMA.y)/PSD.x);
if(SIGMA.x<PSD.y)
MulFac.yw=((PSD.y-SIGMA.y)/PSD.y);
return MulFac*src;
}
#endif
//*******************************************************************


to this:

//*******************************************************************
#ifdef BETA
float4 WFilter( PS_INPUT In) : COLOR
{
float4 src=tex2D(Src,In.texCoord);
float2 PSD=float2(length(src.xz),length(src.yw));
float4 MulFac;
float4 dst;
MulFac.xz=((PSD.x-SIGMA.y)/PSD.x)*(SIGMA.x<PSD.x)+(SIGMA.x>=PSD.x)*float2(BETA.x,BETA.x);
MulFac.yw=((PSD.y-SIGMA.y)/PSD.y)*(SIGMA.x<PSD.y)+(SIGMA.x>=PSD.y)*float2(BETA.x,BETA.x);
dst=MulFac*src;
return dst;
}
#endif
//*******************************************************************

if that doesn't work try this version

//*******************************************************************
#ifdef BETA
float4 WFilter( PS_INPUT In) : COLOR
{
float4 src=tex2D(Src,In.texCoord);
float2 PSD=float2(length(src.xz),length(src.yw));
float4 dst;
if(SIGMA.x<PSD.x)
dst.xz=src.xz*((PSD.x-SIGMA.y)/PSD.x);
else
dst.xz=src.xz*float2(BETA.x,BETA.x);
if(SIGMA.x<PSD.y)
dst.yw=src.yw*((PSD.y-SIGMA.y)/PSD.y);
else
dst.xz=src.xz*float2(BETA.x,BETA.x);
return dst;
}
#endif
//*******************************************************************

[Leo 69]

None of the script versions work (properly), tsp. Overall Bt=2 mode gives largest amount of artifacts and by the way my mouse constantly stops responding for very short periods of time during playback (~0.2 sec or so).With test version too.

[tsp]

hmm could you post a sceneshoot of the artifacts? Also does this version produce artifacts(This disables the filtering but it's mainly to confirm that the bug lies in the if statements).

//*******************************************************************
#ifdef BETA
float4 WFilter( PS_INPUT In) : COLOR
{
float4 src=tex2D(Src,In.texCoord);
float4 dst;
dst=src;
return dst;
}
#endif
//*******************************************************************

Also I haven't heared about the mouse problem before. But I will see what I can do about it later when I get this filter working in a geforce FX (even if I have to buy a geforce FX 5200 to test on. Anyone has a spare one?)

[LordIntruder]

Hi,


I tested you work TSP and here is what I get:

I encoded a 10000 video frames (720 x 528) with this parameter for FFT:
'FFT3DFilter(sigma=3, bt=3, measure=true)'

For FFT3dGPU I used:
'fft3dGPU(sigma=3, bt=3)'

On a 2400+, 1Gb Ram, AGP Radeon 9600 Pro with latest drivers, Windows XP SP2, DirectX 9.0c. Neither my CPU nor my GPU are overcloked.

Without FFT:

1st Pass = 13 min
2nd Pass = 37 min

FFT Measure True:

1st Pass = 53 min
2nd Pass = 80 min

FFT Measure OFF:

1st Pass = 59 min
2nd Pass = 82 min

FFT3dGPU

1st Pass = 17 min
2nd Pass = 40 min

In my example I selected the heaviest solution with latest XviD beta: Qpel, GMC, VHQ4, VHQ for bframes, Chroma motion, etc... So this is why the encode is so slow. You untick Qpel, you put VHQ1, no chroma motion and the speed rise up to the roof :D

The GPU version is amazingly fast !!!! I can't believe it!!! :eek: :eek:

As far as my eyes can see, the quality seems the same between your filter and the original by Fizick. Can you confirm the only thing is about the 16 bits float (useFloat16)? Except that option (which we still can enable to 32 bits), we are suppose to get the same quality that the original filter right?

A last thing I don't understand, I quote you

--
"usecache: if enabled the frames are saved in the GPU after the 2d FFT to avoid calculating them again the next frame if bt=2 or 3.
It can be necessary to disable this internal cache if using motion compensation. Default = true"
--

What do you mean by motion compensation? GMC option in DivX or XviD? What drawbacks are we suppose to get? Artifacts I suppose? And this option Off slow down the encode a lot?

A great thanks for your work, Fizick's filter is very good but so slow. A good idea you've got here. :) I wouldn't imagine that my video card helps me to encode faster. Another reason to buy a fast new card :D

[tsp]

Originally posted by LordIntruder

As far as my eyes can see, the quality seems the same between your filter and the original by Fizick. Can you confirm the only thing is about the 16 bits float (useFloat16)? Except that option (which we still can enable to 32 bits), we are suppose to get the same quality that the original filter right?

Ahemm I just discovered that my filter cheats a little more than just using 16 bit float. I'm only using a 1:1 overlap instead of a 2:1 this means that the filter only does half as many calculations as fft3dfilter (explaining in part why it's 4 times as fast). This results in border artifacts when using high sigmavalues (about 2.5-10 depending on bw/h that is higher bw lower sigma before artifacts appears ). That is a 1-2 pixel width dark border. Like this image:
http://www.tsp.person.dk/bug.png

I will do two things about that:
1) Implement the 2:1 overlap(This will cut the speed in half :mad: ).
2) and as an option for the speed hungry people. Just use a slightly larger blocksize and then crop the borders.

Until that is implementet be a little extra carefull with high sigma values.


A last thing I don't understand, I quote you

--
"usecache: if enabled the frames are saved in the GPU after the 2d FFT to avoid calculating them again the next frame if bt=2 or 3.
It can be necessary to disable this internal cache if using motion compensation. Default = true"
--

What do you mean by motion compensation? GMC option in DivX or XviD? What drawbacks are we suppose to get? Artifacts I suppose? And this option Off slow down the encode a lot?

No it was mainly aimed at MVTools but I don't think it will cause artifact anyway so I will disable this option in the next version.

[tsp]

released version 0.40. Now includes sharpening, 2:1 overlap and 1:1 overlap with border. Also better optimized for multitasking (the filters before fft3dgpu are processed at the same time as fft3dgpu)

[vinetu]

Hi!
Some digits again-I did the "compressibility test" at same source (273 frames,PAL)

intel P4, Radeon 9600
non filtered Xvid.avi size 9,861,120 bytes

fft3dGPU v.0.31 (sigma=2.0,bt=1) ->9,439,232 bytes
fft3dGPU v.0.40 (sigma=2.0,bt=1) ->9,441,280 bytes

fft3dGPU v.0.31 (sigma=3.0,bt=3) ->7,495,680 bytes
fft3dGPU v.0.40 (sigma=3.0,bt=3) ->7,489,536 bytes

fft3dGPU v.0.31 (sigma=3.0,bt=3,bh=16,bw=16) ->8,501,248 bytes
fft3dGPU v.0.40 (sigma=3.0,bt=3,bh=16,bw=16) ->8,497,152 bytes

fft3dGPU v.0.31 (sigma=3.0,bt=3,bh=64,bw=64) ->6,516,736 bytes
fft3dGPU v.0.40 (sigma=3.0,bt=3,bh=64,bw=64) ->6,500,352 bytes
fft3dGPU v.0.40 (sigma=3.0,bt=3,bh=64,bw=64,mode=1) ->6,019,072 bytes

Still any artifacts are invisible here :)

Thank You!

P.S. Just curious why "FFT3DFilter(sigma=3.0,bt=3,bh=16,bw=16)"
is produceing much smaller file - 6,408,192 bytes vs 8,497,152 bytes(by fft3dGPU)

[Fizick]

tsp,
The speed results of your filter is great!

But what is your "1:1 overlap" and "2:1 overlap" mean?
Kokaram (and me) used say 16 pixels blocks width, every next block is shifted by 8 pixels (right, bottom), so one-side overlap size is 8 pixels for every block, and whole blocks width is overlapped, so summary overlap size (left and right) for block is equel to its width= 16 pixels.
I think it is full (maximum possible) overlapping (for simple algo).

Is it your "1:1" or "2:1" ?

Now i create (not release yet) new version of FFT3DFilter with partial overlapping (with arbitrary overlapped size), and confused with therms. I want use new parameter "overlap width" as one-side overlap size, with maximum value equal to half of block width.

[tsp]

Fizick : What you descripe is my 2:1 overlap=mode 1. In the 1:1 overlap (mode=0) the blocks are only shifted half bh down and bw to the right so 1/4 of a block is only overlapped by 1 block(compaired to 3 blocks when using mode=1). when using mode 2 only bw minus the border is used for overlapping (mainly because the artifacts are most severe at the borders). So this is nearly the same as partial overlap. mode 0 and mode 2 uses another window function than the one used in mode 1.
This image shows the diffent mode:
http://www.tsp.person.dk/overlap.png

So if you wants to compaire fft3dgpu with fft3dfilter use:
fft3dgpu(mode=1,usefloat16=false)

[Fizick]

tsp,
thanks for response and nice pic. But i am not not quite understand it.
I draw my overlap pic in fft3dfilter thread.
:)

[tsp]

Fizick: From your drawing it looks like the center of a block isn't overlapped at all. Is that true?
Also mode 1 in fft3dgpu and your default mode is the same. So look carefull at the (ugly) drawing of mode 1 and you can see four different colored blocks (dotted blue , dotted dark green, solid red and solid light green). To filter a 720x576 image we need to fft ~720/bw*576/bh*4 blocks. When using mode 0 there are only to overlapped block (red and green) meaning only ~720/bw*576/bh*2 blocks. And finaly mode 2 needs ~720/(bw-borderwidth*2)*576/(bh-borderheight*2)*2 blocks.

[tsp]

Found a bug. I forgot to square the modulus of the transformed image when calculating the PowerSpectralDensity. I will release a new version shortly until then the quick fix is to change line 518 in ps.hlsl from

float2 PSD=float2(length(src.xz),length(src.yw));

to

float2 PSD=float2(src.x*src.x+src.z*src.z,src.y*src.y+src.w*src.w);

[Fizick]

tsp,
Yes, center is not overlapped in my partial overlap mode.

So I conclude, that full overlap mode of my FFT3dfilter(bw=32,bh=32, ow=16, oh=16) is the same as your FFT3DGPU(mode=1, bw=32,bh=32).
But my partial overlap FFT3dfilter(bw=32,bh=32, ow=8, oh=8) is NOT the same as your partial overlap
FFT3DGPU(mode=0, bw=32,bh=32).
So, users may compare results (quality) of different approaches.
(after you fix recent bug, and i fix my quite possible bugs - i rewrote many lines of code in v.0.9)

[tsp]

released version 0.41. Only new thing is the above bugfix plus a minor bug when calculating sigma (when mapping from 0-255 to 0-1 divide with 255 not 256 doh ).

[LordIntruder]

Hi,


Some speed measurements again. I put old results back here for better readability:

Athlon 2400+, Radeon 9600 Pro, 1 Gb Ram.

I encoded a 10000 video frames (720 x 528) with these parameters for FFT:

'FFT3DFilter(sigma=3, bt=3)'

For FFT3dGPU I used:
'fft3dGPU(sigma=3, bt=3)'

Without FFT
1st Pass = 13 min
2nd Pass = 37 min

FFT Measure True (v0.8.3)
1st Pass = 53 min
2nd Pass = 80 min

FFT Measure OFF (v0.8.3)
1st Pass = 59 min
2nd Pass = 82 min

FFT3dGPU (v0.3)
1st Pass = 17 min
2nd Pass = 40 min
--------

Today I encoded the exact same clip with the updated versions:

'FFT3DFilter(sigma=3, bt=3)'
'fft3dGPU(sigma=3, bt=3, mode=1, reduceCPU=false)'

FFT Measure OFF (v0.9.1)
1st Pass = 28 min
2nd Pass = 55 min

FFT3dGPU (v0.4)
1st Pass = 25 min
2nd Pass = 49 min

FFT3dGPU (v0.41 reduceCPU=false)
1st Pass = 29 min
2nd Pass = 57 min

FFT3dGPU (v0.41 reduceCPU=true (default))
1st Pass = 21 min
2nd Pass = 38 min

I thought 'reduceCPU=false' increased encoding speed when I first read your explanations about this option. In fact it decrease the speed and by default (true) it is already the fatest.

In short 0.41 is faster than 0.4 (I was afraid that the more complex math to fix the bug would increase time encoding and it is the opposite, good). However as you can notice I used mode=1 (so 2:1 overlap) for the GPU version. Tsp you told me the encoding speed should be cut by half but it is not the case despite twice more calculations. Normal or a bug?

We also can see that the 3DNow optimizations help a lot for the normal version of FFT. That is really great. :D

Is the GPU version 3Dnow or SSE optimized? If not I hope you intend to do it, we would get some speed. :D

Finally is the GPU version work as something multi-threaded, I mean as if there were 2 CPU cores like the forthcoming Intel and AMD processors? Maybe it is the way it works (differently of course but the idea), just curiosity. I was thinking about some general code that could be used by others filters.

I mean you use a special DLL or something like that, some parameters in the AVS and thanks to this the calculation would be done half by the CPU, half by the GPU. Maybe it's impossible, just idea but like that not only the FFT filter would take benefit of the GPU but also others filters and/or general calculations. Instead to optimize each filter you write a general parameters and any filter can take benefit. A crazy idea ;)

Oh before I forget: with both FFT and FFTGPU (and only them) when I start the job using Virtualdubmod latest version, most of the time it closes itself. I launch again VDM, I start the job and the 1st pass start. Then at the end of the 1st pass again sometimes VDM close and I need to manually launch it again and start the 2nd pass by myself or this one is launched after the 1st finishes. It appears ramdomly. I'm using the Avisynth 2.56 build 31 Jan and have just see another Beta from february 21 is out. Will give a try.

Anyway cheers to both of you on the work done on these filters :)

[tsp]

Originally posted by LordIntruder


I thought 'reduceCPU=false' increased encoding speed when I first read your explanations about this option. In fact it decrease the speed and by default (true) it is already the fatest.

There is a good explanation to this. It's because avisynth(fft3dgpu) uses less cputime when reduceCPU=true. This means that XviD gets more time to do the encoding and the encodetime decrease even if avisynth uses a little more time to process a frame. If reduceCPU=false then the extra cpu-time would be waisted instead of used to encode. You could try to repeat the test with Huffyuv or another fast codec (MJPEG)instead of XviD and you would get some very different results(at least that's what I think would happend)


In short 0.41 is faster than 0.4 (I was afraid that the more complex math to fix the bug would increase time encoding and it is the opposite, good). However as you can notice I used mode=1 (so 2:1 overlap) for the GPU version. Tsp you told me the encoding speed should be cut by half but it is not the case despite twice more calculations. Normal or a bug?

First the bugfix made the math simpler. Instead of calculating the modulus/length of the complex number/vector (squareroot(a^2+b^2)) the modules/length squarred is used (just a^2+b^2) so the squareroot isn't need (and that's an expensive operation).
I must admit that i'm a little surprised that the speed decrease wasn't bigger but again I think it's because the GPU uses more time meaning that XVid get's more time to encode so that it somewhat offset the extra time used (multiprocessing is very nice). Again if you use huffyuv or MJPEG you would get a greater speed decrease.



We also can see that the 3DNow optimizations help a lot for the normal version of FFT. That is really great. :D

Is the GPU version 3Dnow or SSE optimized? If not I hope you intend to do it, we would get some speed. :D

fft3dgpu doesn't need 3dnow or sse because all the math heavy calculations are done on the GPU and it uses a very different operation set (basicly all the commands used are like sse on steroides). Maybe some speed could be gained by using assembly instead of HLSL(the c-like language used by directx.)



Finally is the GPU version work as something multi-threaded, I mean as if there were 2 CPU cores like the forthcoming Intel and AMD processors? Maybe it is the way it works (differently of course but the idea), just curiosity. I was thinking about some general code that could be used by others filters.

I mean you use a special DLL or something like that, some parameters in the AVS and thanks to this the calculation would be done half by the CPU, half by the GPU. Maybe it's impossible, just idea but like that not only the FFT filter would take benefit of the GPU but also others filters and/or general calculations. Instead to optimize each filter you write a general parameters and any filter can take benefit. A crazy idea ;)

The filter is multithreaded. Basicly just before the GPU begins the calculations a thread is created that fetchers the next frame. Meanwhile the first thread asks the GPU(driver) if it's done with the calculations if that is not the case it sleeps 5 msec before asking again. When the GPU is done the data is downloaded to the main memory and then the first threads waits for the second thread to exit. When the next frame is requested the results from all the filters before fft3dgpu are already cached (because they where run at the same time the GPU was working). So with a dualcore processor you could have the filter do it's calculations and calculate thenext frame at the same time (although the cache usage could be quite high)

Try to guess which of these two scripts who would run fastest or would they be equally fast?

#SCRIPT A
fft3dfilter(plane=1)
fft3dfilter(plane=2)
fft3dGPU()

#SCRIPT B
fft3dGPU()
fft3dfilter(plane=1)
fft3dfilter(plane=2)

script A would be fastest if used with a fast encoder because the two filters before fft3dGPU would be run at the same time as fft3dGPU while in script B the extra cpu time would just be waisted because there are no filters before fft3dgpu. If used with Xvid or another slow encoder the speed difference would be less because the waisted cputime would be used by Xvid


Oh before I forget: with both FFT and FFTGPU (and only them) when I start the job using Virtualdubmod latest version, most of the time it closes itself. I launch again VDM, I start the job and the 1st pass start. Then at the end of the 1st pass again sometimes VDM close and I need to manually launch it again and start the 2nd pass by myself or this one is launched after the 1st finishes. It appears ramdomly. I'm using the Avisynth 2.56 build 31 Jan and have just see another Beta from february 21 is out. Will give a try.

Anyway cheers to both of you on the work done on these filters :)
I must say that it sounds odd it only happens with these two filter's because they don't share any code (unless Fizick used some of my code but I somewhat doubt it ;) ) The only bug I know of in fft3dgpu is that if you uses F5 to many times all the videomemory is used. This is caused by a memory leak somewhere (It must be microsoft's fault. DirectX or something :) )
Oh and thanks for the test. It's really amazing to see the interactions with Xvid