Log in

View Full Version : fft3dGPU 0.8.2


Pages : 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19

tsp
29th November 2005, 14:14
Ai : thanks for the report. The time is reported in seconds. Strange that increasing the core ratio slows the download down. The x700 is pci-express?

AI
30th November 2005, 05:27
The x700 is pci-express?
Yes, of course... (buy special for fft3dGPU and upgrate CPU special for FFT3DFilter)

Strange that increasing the core ratio slows the download down
Becouse "CPU more busy memory" (or "memory more busy from CPU" - my English is very bad)

in A64 memory controller integreted in core (more exactly in CPU chip)

PS What about speed? (How many Mb/s on my timings(?))

PPS Why "bt=2 uses the current and next frame",
but "bt=4 uses the two previous frames, the current and next frame"?

ariga
30th November 2005, 07:57
ariga: I don't get any errors with 0.51, fft3dgpu() and a Geforce fx 5200.
Still no change with 0.51 and 5600 Ultra. I'll try installing the latest DirectX update and drivers. Just 9.0c with the d3dx9_27.dll may not suffice. :(

acrespo
30th November 2005, 12:22
fft3dfilter 1.8.4 include muti-plane option (luma + all chroma planes > plane=4). Can be develop in fft3dgpu too?

acrespo
1st December 2005, 05:50
acrespo:the default overlap is ow=bw/2 oh=bh/2 currently that can't be changed. Also there where a bug in 0.5a that assigned the value from svr to degrid. So the default value was 0.3. That might explain it. That is fixed in 0.51. Another difference is the precision used. By default fft3dgpu uses 16 bit floating point precission while fft3dfilter uses 32 bit precision. You can change that by setting useFloat16=false. This slows down the filter and uses more memory on the GPU.


The new 0.51 version degrid is function correctly now. Also I think bw and bh defaults is producing grid. When I try 48 (fft3dfilter defaults) I don't have grid, so I think that change bh,bw defaults to 48 is good.

AI
1st December 2005, 09:14
The new 0.51 version degrid is function correctly now. Also I think bw and bh defaults is producing grid. When I try 48 (fft3dfilter defaults) I don't have grid, so I think that change bh,bw defaults to 48 is good.

RTFM


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. Default=32

IMHO

i.e. then you use bw=bh=48 - realy bw=bh=64 (possible)

ariga
1st December 2005, 12:33
Still no change with 0.51 and 5600 Ultra. I'll try installing the latest DirectX update and drivers. Just 9.0c with the d3dx9_27.dll may not suffice. :(

Updated to the latest Nvidia drivers and it works ! Sorry for the trouble. However it's still slow (~4fps). Will update DirectX too and see if it makes any difference.

tsp
1st December 2005, 17:28
PS What about speed? (How many Mb/s on my timings(?))

to find the speed divide 0.39551 (=720*576/1024/1024) with the time i took. So 7.5*10^-4 sec becomes ~530MBytes/sec and 1.2*10^-3 sec is ~330MBytes/sec.

PPS Why "bt=2 uses the current and next frame",
but "bt=4 uses the two previous frames, the current and next frame"?

sorry bt=2 does use the current and the previous frame. An error in the documentation (maybe it did use the next frame in version 0.1?)

Updated to the latest Nvidia drivers and it works ! Sorry for the trouble. However it's still slow (~4fps). Will update DirectX too and see if it makes any difference.

Good to hear. Just curious what version did you use before? Also I think the main reason you are seeing such a low speed is because a Geforce FX 5600 Ultra is very slow. It does only have 2 pixel pipeline(Meaning it can only process two pixel at a time) running at 350 MHz. It doesn't support MRT(Multiple Render Targets) meaning it needs more passes to do the fft (and kalman filtering). The good thing about having a slow videocard is the cpu-utilization should also be very low so it is possible to run some very slow filters before fft3dgpu(like a deinterlacer) or use a slower codec ;)

fft3dfilter 1.8.4 include muti-plane option (luma + all chroma planes > plane=4). Can be develop in fft3dgpu too?

sure no problem (but it will become plane=3 because plane=1 process both the U and V chroma plane)

The new 0.51 version degrid is function correctly now. Also I think bw and bh defaults is producing grid. When I try 48 (fft3dfilter defaults) I don't have grid, so I think that change bh,bw defaults to 48 is good.

As AI said fft3dGPU uses bw=64 and bh=64 instead. Also the default setting is mode=0 that does produce some nasty griding(but is faster). When I implement the variable overlap I think I will use mode=1 as the default. If you use:
FFT3DGPU(sigma=5, bh=32, bw=32, mode=1, sharpen=1.0)
Does the griding appear?

acrespo
1st December 2005, 20:53
I need some more tests but I think mode=1 and useFloat16=false can avoid grids with bw=bh=64. I will take some screenshots to compare side by side with bw=bh=32, but with useFloat16=true I see grids with all bw/bh and modes (less than v0.47 and 0.5a).

I have a doubt about other planes. In readme.txt you wrote about fft3dgpu in plane=0 and other instance in plane=1 can decrease speed more than fft3dfilter. Is it correct to all situation/video cards?

For your information, I have forceware 81.89 and the speed is great.

Fizick
1st December 2005, 21:47
tsp,
IMHO, for FFt3dFilter plane=4 you may consider using plane=4 too,
and for plane=3 consider plane=3 (as alias of your 1 and 2).

tsp
1st December 2005, 21:50
I need some more tests but I think mode=1 and useFloat16=false can avoid grids with bw=bh=64. I will take some screenshots to compare side by side with bw=bh=32, but with useFloat16=true I see grids with all bw/bh and modes (less than v0.47 and 0.5a).

So it seems like it is more the Float16 that are causing it. Could you post a screenshot with the grid artifacts? I made a special version for you that might produce better result with useFloat16=true. Get it here (http://www.tsp.person.dk/fft3dgpu0.51_acrespo_edition.exe)

I have a doubt about other planes. In readme.txt you wrote about fft3dgpu in plane=0 and other instance in plane=1 can decrease speed more than fft3dfilter. Is it correct to all situation/video cards?

I think it mainly was a problem with some of the older versions. It shouldn't cause any problem with the current version. You can also mix fft3dfilter and fft3dgpu and let one of them process the luma plane and the other the chroma plane (just remember to place fft3dgpu after fft3dfilter). BTW what GPU do you use?

IMHO, for FFt3dFilter plane=4 you may consider using plane=4 too,
and for plane=3 consider plane=3 (as alias of your 1 and 2).

Might be a good idea.

acrespo
1st December 2005, 22:46
Well here is some screens using bh=bw=32 and bh=bw=64 and the original without fft3dgpu.
fft3dgpu_screens.rar (http://rapidshare.de/files/8457526/fft3dgpu_screens.rar.html)

edit:Your special version is slight better than v0.51.

tsp
1st December 2005, 23:20
acrespo: I'm not sure that the grid you are seeing is the same grid artifact that I'm talking about. For me it looks like the gridsize is about 4x4 pixels when using bh=bh=32 and if you look closely at the original the 4x4 grid is ever sligtly present. If you want to see how the grid artifacts looks like with fft3dgpu try this (the grid that then appears has a gridsize of bw/2, bh/2):
fft3dgpu(mode=1,sigma=1000,degrid=0.0)
But you are right about the grid disappears when using bw=bh=64. It looks like the the image is more blurry with that setting. What codec is the capture file saved in? It could be that the grid is caused by enhancing the artifacts from the compression.

acrespo
2nd December 2005, 02:02
I always capture with PIC MJPEG 3 quality 19 (or decrease some chrominance and luminance to between quality 18 and 19).

I understood the grid you explain now.

Well I don't understand why bh=bw=64 resolved my problem, because this setting have closely to fft3dfilter with bh=bw=48 (defaults). Can be something wrong with 32 setting?

ariga
2nd December 2005, 10:54
Good to hear. Just curious what version did you use before?Don't know, since I don't have the original CDs right now. The Nvidia tab in graphics panel, didn't display the version earlier. The UI seems to have changed a little now and the version is also being displayed. The good thing about having a slow videocard is the cpu-utilization should also be very low so it is possible to run some very slow filters before fft3dgpu(like a deinterlacer) or use a slower codec ;) You make even the bad sound so good! (Marketing depts anywhere would love to have you :p )
Slower codec ? Hmm... DivX at "Insane quality" ?
Until an upgrade, it's fft3dfilter for me...

Mug Funky
2nd December 2005, 11:13
slower codec like snow or dirac...

x264 is always good (it's pretty fast too).

definitely not divx at insane quality... it's not worth it (the insanity lies in wondering why something could take so long while not looking as nice as an xvid encode...)

puffpio
2nd December 2005, 22:40
x264 w/ Sharktooth's HQ Insane profile... :)

AI
5th December 2005, 13:57
tsp, I have guestions for you... (best phrase on my bad English :rolleyes: )
1) I can't found reduceCPU on last docs
2) I found about you comment "reduceCPU"

3) CPU busy 100% -
--------------
FFT3DFilter(bt=4,plane=0)
FT3DGPU(bt=4,mode=1,plane=1)
--------------
my CPU busy 80% -
--------------
FT3DGPU(bt=4,mode=1,plane=1)
FFT3DFilter(bt=4,plane=0)
--------------
I undestend about it... (You sad about it already)
but earlier 20% busy kernel (in taskmanager)

4) --------------------
i=DePanEstimate(Last,dxmax=24,dymax=0,fftw=True)
Pre2=DePan(Last,i,offset=+2,subpixel=1,matchfields=false,mirror=3).Crop(80,0,-80,0)
Prev=DePan(Last,i,offset=+1,subpixel=1,matchfields=false,mirror=3).Crop(80,0,-80,0)
Next=DePan(Last,ir,offset=-1,subpixel=1,matchfields=false,mirror=3).Crop(80,0,-80,0)

Clip

Interleave(Pre2,Prev,Last,Next)
FFT3DFilter(sigma=5,sigma2=4,sigma3=3,sigma4=2,bt=4,plane=0)
SelectEvery(4,2)

Interleave(Pre2,Prev,Last,Next) # a) Busy 80%
#Interleave(Last,Pre2,Prev,Last,Next) # b) Busy 80%
#Interleave(Last,Pre2,Prev,Last) # c) Busy 100% - Good!
#Interleave(Pre2,Prev,Last,MergeLuma(Next,Trim(1,0))) # d) Busy 100% - Good! - My Idea about a+c (or b+c)

FFT3DGPU(sigma=7,bt=4,mode=1,plane=1)
SelectEvery(4,2) # a)
#SelectEvery(5,3) # b)
#SelectEvery(4,3) # c)
#SelectEvery(4,3) # b)
-------------------

tsp
5th December 2005, 15:12
AI:
1 and 2: I removed reduceCPU in version 0.5 so that is why you can't find it.
3: That is because fft3dGPU is about 6-7 times faster than fft3dfilter in that script so the reason you see a 80% cpu utilization is that fft3dfilter uses most of the time. In this case it might be worth it to set UseFloat16=false to increase the quality. This shouldn't affect the process time very much but try and see:

FTT3DGPU(bt=4,mode=1,plane=1,usefloat16=false)
FFT3DFilter(bt=4,plane=0)

or compare it to this(try useFloat16=false if you have 256 or 512 MB ram on the graphics card):

FTT3DGPU(bt=4,mode=1,plane=1)
FFT3DGPU(bt=4,mode=1,plane=0)


4:
a) look right to me. Might be a little faster like this:

i=DePanEstimate(Last,dxmax=24,dymax=0,fftw=True)
Pre2=DePan(Last,i,offset=+2,subpixel=1,matchfields=false,mirror=3).Crop(80,0,-80,0)
Prev=DePan(Last,i,offset=+1,subpixel=1,matchfields=false,mirror=3).Crop(80,0,-80,0)
Next=DePan(Last,ir,offset=-1,subpixel=1,matchfields=false,mirror=3).Crop(80,0,-80,0)

Clip

Il=Interleave(Pre2,Prev,Last,Next)
MergeChroma(il.FFT3dFilter(sigma=5,sigma2=4,sigma3=3,sigma4=2,bt=4,plane=0),il.
FFT3DGPU(sigma=7,bt=4,mode=1,plane=1))
SelectEvery(4,2)


acrespo: I think some of the grid might come from interlacing.

AI
6th December 2005, 06:36
next question:

FFT3DGPU().FFT3DFilter() - GPU first, CPU secont (in script, realy on the contrary)

Why v0.47 Busy Kernel = 20% (i.e. wait when work GPU, and CPU busy = 100%)
now (v0.51) CPU idle = 20% (Kernel Busy =1-2%, i.e. I/O only)

tsp
6th December 2005, 11:33
AI: I change the inner working of this filter somehow in version 0.5. The frame is now uploaded to the GPU while the GPU is working on the frame and the number of passes needed to process the frame is also reduced(that might save a switch to the kernel to process the commands to the GPU). But I think it is a good thing that the kernel and cpu utilization is lower now.

AI
6th December 2005, 13:56
ask again: (possible error on your optimize algoritm)

usual script:i=DePanEstimate(Last,fftw=True)
Pre2=DePan(Last,i,offset=+2,subpixel=1,matchfields=false,mirror=3)
Prev=DePan(Last,i,offset=+1,subpixel=1,matchfields=false,mirror=3)
Next=DePan(Last,i,offset=-1,subpixel=1,matchfields=false,mirror=3)

Interleave(Pre2,Prev,Last,Next)
MergeChroma(FFT3DFilter(bt=4,plane=0),\
FFT3DGPU(bt=4,mode=1,plane=1))
SelectEvery(4,2)(then FFT3DGPU ask from AVISynth next frame, work only DePan)

optimize script:i=DePanEstimate(Last,fftw=True)
Pre2=DePan(Last,i,offset=+2,subpixel=1,matchfields=false,mirror=3)
Prev=DePan(Last,i,offset=+1,subpixel=1,matchfields=false,mirror=3)
Next=DePan(Last,i,offset=-1,subpixel=1,matchfields=false,mirror=3)

Interleave(Pre2,Prev,Last,Next)
FFT3DFilter(bt=4,plane=0)
SelectEvery(4,2)

Interleave(Last,Pre2,Prev,Last,Next)
FFT3DGPU(bt=4,mode=1,plane=1)
SelectEvery(5,3)When GPU work in VRAM n-2,n-1,n and n+1 frames...
FFT3DGPU ask from AVISynth frame n+2, (on this script n+1 after Interleave().FFT3DFilter().SelectEvery())
But this script not use 100% CPU

not right,but realy optimize script:i=DePanEstimate(Last,fftw=True)
Pre2=DePan(Last,i,offset=+2,subpixel=1,matchfields=false,mirror=3)
Prev=DePan(Last,i,offset=+1,subpixel=1,matchfields=false,mirror=3)
Next=DePan(Last,i,offset=-1,subpixel=1,matchfields=false,mirror=3)

Interleave(Pre2,Prev,Last,Next)
FFT3DFilter(bt=4,plane=0)
SelectEvery(4,2)

Interleave(Last,Pre2,Prev,Last)
FFT3DGPU(bt=4,mode=1,plane=1)
SelectEvery(4,3)now CPU busy 100%...

And I fount decision:
First script string
"Interleave(Pre2,Prev,Last,Next)" change to
"Interleave(Pre2,Prev,Last,MergeLuma(Next,Trim(1,0)))"
now CPU use 100% and all frames (n+1 too) is compensation.

PS very difficult write on not native language :(

tsp
6th December 2005, 15:17
What about the framerate? Also how does my script above perform?

tsp
7th December 2005, 01:13
from my latest development. Guess what it is (texture is missing).
http://img524.imageshack.us/img524/6992/fft3dgpu3sy.th.png (http://img524.imageshack.us/my.php?image=fft3dgpu3sy.png)

puffpio
12th December 2005, 09:42
from my latest development. Guess what it is (texture is missing).
http://img524.imageshack.us/img524/6992/fft3dgpu3sy.th.png (http://img524.imageshack.us/my.php?image=fft3dgpu3sy.png)
hmm the new plane in fft3dfilter where it process YUV all at once?

tsp
12th December 2005, 23:49
Nope. Compare it to the overlap picture (http://www.avisynth.org/fizick/fft3dfilter/fft3dfilter.html) in the fft3dfilter documentation. Yellow= 4 block overlap. red=2 block overlap and turquoise=no overlap.
the YUV option will be implemented as it is in fft3dfilter so the filter converts:
fft3dgpu(plane=4)
to
fft3dgpu(plane=0)
last.fft3dgpu(plane=1)

puffpio
13th December 2005, 10:17
the YUV option will be implemented as it is in fft3dfilter so the filter converts:
fft3dgpu(plane=4)
to
fft3dgpu(plane=0)
last.fft3dgpu(plane=1)

Is that really how fft3dfilter does it? because in the fft3dfilter doc it has an example for how to do it w/o using plane=4 like this:

YToUV(fft3dfilter(sigma=3, plane=1).UToY,\
fft3dfilter(sigma=3, plane=2).VToY,\
fft3dfilter(sigma=2, plane=0))

Is that equiv to what you are saying is the way to process all planes?

tsp
13th December 2005, 13:18
sorry didn't look closely at the fft3dfilter sourcecode. Fizick implemented it like you said but I don't understand why because it produces the same result as my script just with more copying from one plane to another. Try this script. It should be grey if the result is the same:

src=avisource("f:\20051210-143802.avi")
motion=src.DepanEstimate(trust=2.5, fftw=true)

src.DepanInterleave(data=motion)
YToUV(fft3dfilter(sigma=3, plane=1).UToY,\
fft3dfilter(sigma=3, plane=2).VToY,\
fft3dfilter(sigma=2, plane=0))
a=SelectEvery(3,1)


src.DepanInterleave(data=motion)
fft3dfilter(sigma=3, plane=1)
fft3dfilter(sigma=3, plane=2)
fft3dfilter(sigma=2, plane=0)
b=SelectEvery(3,1)

subtract(a,b).Levels(127, 1, 129, 0, 255)

AI
14th December 2005, 05:39
tsp
What about speed?
first script faster!

Give "filter" with matrix 121 (as Convolution3D but only temporal)
filter.filter = "filter" with matrix 14641
filter.filter.filter = "filter" with matrix [1 6 15 20 15 6 1]

if pre filter = matrix [1] then
1
1 2 1
1 4 6 4 1
1 6 15 20 15 6 1
i.e. triangle Pascal (SelectEvenString :) )

i.e. if use several temopral filters, it more temporal

i.e. needDePanInterleave(...)
filtre1()
selectevery(3,1)
DePanInterleave(...)
filtre2()
selectevery(3,1)
DePanInterleave(...)
filtre3()
selectevery(3,1)orDePanInterleave(prev=3, next=3)
filtre1()
filtre2()
filtre3()
selectevery(7,3)or
if filters "independent"DePanInterleave(prev=1, next=1)
MergeChroma(filtre1(),filtre2())
selectevery(3,1)
PS my English is bad up to this date

tsp
14th December 2005, 13:17
AI: that is what the build in cache is for. So in my script the filterchain really look like this:
src.DepanInterleave(data=motion)
InternalCache()
fft3dfilter(sigma=3, plane=1)
InternalCache()
fft3dfilter(sigma=3, plane=2)
InternalCache()
fft3dfilter(sigma=2, plane=0)
InternalCache()
b=SelectEvery(3,1)
Most of the pascal triangle is in the cache so the same amount of work is done by fft3dfilter compaired to the YToUV approach just with less copying from one colorspace to another=second script is faster.
[EDIT]
sorry you're right. The InternalCache reduces the number of extra calls to fft3dfilter(plane=2) and fft3dfilter(plane=1) to 4. But the YtoUV is still inefficient with the copying from one plane to another. I will implement it better in fft3dgpu so they write to a common frame.

tsp
16th December 2005, 02:49
new version ready:
Added wintypes, plane=4 and variable overlap size (ow,oh). Change useFloat16 to precision. Changed default value for mode to 1

in the next version I will see if I can add support for interlaced frames (time to experiment with the stencil buffer).

puffpio
16th December 2005, 03:32
AWESOME..will try it out tonight (w/ my 5900 non ultra...hopfully still faster than using fft3dfilter)

puffpio
16th December 2005, 09:28
FFT3DFilter(sigma=3, plane=4, bt=4, degrid=1, sharpen=0.7)
2.6FPS encoding with x264 first pass

FFT3DGPU(sigma=3, plane=4, bt=4, precision=1, degrid=1, sharpen=0.7)
3.7FPS encoding with x264 first pass

AWESOME!
Athlon XP 3000+, Geforce 5900

tsp
16th December 2005, 13:34
Forgot to add support for the Geforce FX 5xxx in variable overlap. That is fixed now.

puffpio: Hopefull that is not a 4 hour video you encode with that blazing speed ;)

tsp
16th December 2005, 14:39
:angry: Forgot to change the default for mode to 1. Changed that and reuploaded the file. (I couldn't understand how puffpio could run that script with only 128 MB ram if mode=1 but that was because of that little error. So two bugs fixed thanks to puffpio)
I guess that this thing happends when you release a new version at 3 AM.

puffpio
19th December 2005, 06:59
well..what worked with 0.6 doesn't work with 0.6.1

video = video.FFT3DGPU(sigma=3, plane=4, bt=4, mode=1, precision=1, degrid=1, sharpen=0.7)

I tried setting precision to 0 and bt to something smaller but it still doesn't work (thinking I was attempting to use more video memory than I have)

it looks like only the top row of macroblocks gets written, and everything else turns out black

puffpio
19th December 2005, 07:01
btw I set the plane to something else like 0 or 1, the result seems to only be one plane (ie the planes don't get recombined)

tsp
19th December 2005, 14:05
puffpio: I get the same error on my Geforce fx 5200. Will try to see what goes wrong and fix it.

tsp
19th December 2005, 15:41
ok I sort of figured out what the problem is. The Geforce FX doesn't support repeating a non power of two texture so the analysis window only got applied to the first block. The wierd thing is that the texture that the analysis window is stored in is a Power Of Two texture so it should work but it doesn't.
The radeon 9x00 also have the same limitation so if someone with a radeon 9x00 would try to see if they get the same error I could figure out if it's a bug in the driver or my code.

ok know I know whats wrong. Always a good thing to read the manual. From nvidia's gpu programming guide:
A32B32G32R32F*
*Exposed in DX9.0c without wrapping or mipmapping capability
will make a fix for that.

TEB
20th December 2005, 12:06
Hi. I started testing ure filter on my ATI x700 pcie GFX card.. works fine.. But i have some questions i hope someone can anwser in this thread:
1.How do u benchmark the fps of the encode besides taking the time manually?
2.My source material is of a very noisy kind, interlaced (all frames are interlaced, no need for ivct), in a framebased structure. Any reccomendations for a fast interlacer that would work good with fftgpu noise removal? Should one deinterlace before or after fftgpu does its work?

best regards teb

tsp
20th December 2005, 16:30
1) Sometimes I add this to my script for shorter clip:

l=last
global ts="%X"
WriteFile(l,"time.txt","current_frame",""" " " ""","Time(ts)",append=false)

this will create a file called time.txt that contains the time each frame where created so subtracting the first frame time from the last and divide it with the number of frames produces the framerate (that will be a little lower due to the overhead but for relative difference that doesn't matter.). Else there are two filters Kronos and AvsTimer that can be used.
2. you should deinterlace before fft3dgpu. LeakKernelDeint (http://forum.doom9.org/showthread.php?t=81322&page=1&pp=40) and TDeint (http://forum.doom9.org/showthread.php?t=82264) are two good deinterlacers else take a look at this (http://forum.doom9.org/showthread.php?t=101395) thread (please don't turn this thread into a discussion about with deinterlacer is best). And remember if your cpu utilization is not 100% when encoding with fft3dgpu it is safe to use slower filters before fft3dgpu.

TEB
20th December 2005, 16:40
1. Thx, ill check that out..
2. Np, ill not turn it into a deint thread :) I just want the best possible baseline for ure filter to work on :)

My current test is :

MPEG2Source("h:\46391.d2v")
tdeint()
fft3dGPU(bt=3,sigma=2,precision=2) which works pretty good on my ATI x700 and P4 3,6EE with HT on. The noise in the picture is gone, but i need to sharpen it a bit and try to kill some of the colour bleeding..
Keep up the good work.. Ill retest on my machine at home (nvidia 7800gt+dualcore amd)

aberforthsgoat
20th December 2005, 16:49
Say -

Has anyone had any luck getting the filter to run in real time? I have Radeon 9500 that I've softmodded and overclocked - but mostly just for the heck of it, since all it's doing is spitting out DVDs from zoomplayer. So it seems like using fftgpu would be a grand chance to make it work for its keep while I enjoy myself.

My first tests haven't been very encouraging, though. I get the impression that it's not very happy about playing along with zp. In overlay and VMR9 normal, it worked, but with a very peculiar stutter. When I tried to jump out to renderless, I got a crash.

Any hope here?

Mike

tsp
20th December 2005, 21:27
TEB: please report back what framerate you're getting with the latest version of fft3dgpu and a geforce 7800 GT. I'm really curiuous how fast that is. Try the build in sharpening in fft3dgpu(sharpen=1) or lower it if it's to much.

aberforthsgoat: The framerate are a little unstable on my machine to. I captured a screenshot with zoneplayer, FFT3DGPU(sigma=8,bt=1, mode=0, precision=0, nvperf=true) and NVPerfTool.
http://img45.imageshack.us/img45/6307/zp6mt.th.png (http://img45.imageshack.us/my.php?image=zp6mt.png)
The yellow line is the time per frame. It should be 0.40 sec or below for 25 FPS and as you can see the line is not very stable. I don't know what causes this (yet).
Also could you be a little more specific about what you do to crash zoneplayer?

tsp
21st December 2005, 01:08
puffpio: I made a new version that should fix the error with mode=1. Unfortunately I'm stil getting artifacts with ow or oh values other than the default also the chroma plane cleaning is somewhat bugged (very high values of sigma should result in a greyscale frame but with the geforce fx it result in a green frame.). I can't reproduce these two errors on my geforce 6800 and it is not clear what is wrong (like the other error).
You can try the new version here:
http://www.avisynth.org/tsp/fft3dgpu0.6.1.9.exe
and if someone with a radeon 9x00 couldt test if the following produces a greyscale image or a green image:
fft3dgpu(sigma=2500,plane=1,mode=1)
and this one produces black boxes:
fft3dgpu(plane=0,mode=1,ow=8,oh=8)
with the above version.

puffpio
23rd December 2005, 01:07
I will test it over the weekend...no time to spend doign fun stuff at home till then :P

puffpio
25th December 2005, 10:27
tried the new version and it works now
although gridding is more pronounced than it used to be

I used: FFT3DGPU(sigma=3, plane=4, bt=4, mode=1, precision=1, degrid=1, sharpen=0.7)

The video is 512x384 so somehow it manages to work w/ 128mb of video ram

tsp
25th December 2005, 13:37
puffpio: What setting did you use before, that produced less griding?

puffpio
25th December 2005, 18:51
I used the exact same setting as before

well, you didn't have a plane 4, so I used a 2 step process with both planes, luma plane first followed by the chroma planes. sigma, bt, precision, degrid, and sharpen are all the same

BigDid
25th December 2005, 19:58
puffpio: ...and if someone with a radeon 9x00 couldt test if the following produces a greyscale image or a green image:
fft3dgpu(sigma=2500,plane=1,mode=1)
Not completely greyscale, more greys for sure and greenish sometimes

and this one produces black boxes:
fft3dgpu(plane=0,mode=1,ow=8,oh=8)
with the above version.
No black boxes

I also tried Puffpio script: not working. Extracted this one that works: FFT3DGPU(sigma=3, plane=4, mode=1, degrid=1, sharpen=0.7)

GPU is an Asus 9600 pro, 128Mb ram, overclocked: 418/594
Hope that helps, continue the good work, happy holidays to you.

Did