fft3dGPU 0.8.2 [Archive] - Page 12

barbapapa5800

11th January 2007, 16:13

oke, maybe i didn't use the right words to explane myself.
i have the FFT3dGPU working (diko allows me to this time) but the speed is only 1.
but i can tell by the temp of the GPU that it is doing something.
where do i put fft3dgpu(sigma=2,plane=4,sharpen=0.5)

putting is anywhere in the above script gives me no speed profits.
even try'd using onle the fft3dgpu(sigma=2,plane=4,sharpen=0.5) in a script.
nothing of a speed increase...

G_M_C

11th January 2007, 16:32

Well start off by editing out all other noise-filters; And rewrite the scrip that is only calls for blockbuster() once, and AFTER the noise filters; Now your adding noise, and subsequently filtering it out, before adding some new noise ? And if I read blockbuster's readme, I understand that it isnt SSE/MMX optimized ... so it's probably quite slow; If there is no specific reason for adding noise (why should there be) i would loose it from the script alltogether.

Also try use AviSynth's commands in stead of the DivX-versions; For instance replace the resizer and the borders-thingy; When encoding to XviD i might not even be needed to add borders. Is there a special reason for doinig it, encoding for DVD/full PAL and/or NTSC reso's for instance ?

But you still have the chance is will run slow, because youre graphics board isnt too fast. When you have a fast CPU the regular version (fft3DFilter) might even be faster.

I think your script could do better looking like this;

converttoyv12()
Spline16Resize(WIDTH, HEIGHT) # fill in the desired size
FFT3DGPU (sigma=2,plane=4,sharpen=1.1) #filter noise and sharpening a little
Blockbuster(method="noise",detail_min=1,detail_max=10,variance=0.3,seed=2) # might not even be nesessary
AddBorders(HEIGHT,OVERSCAN) #look in AviSynths manual for the correct syntax
AddAudio() #Add what audio ?

barbapapa5800

12th January 2007, 06:57

i'll give it a try this afternoon.
i have a E6600 @ 3.5 ghz and a 6800GT.

Also try use AviSynth's commands in stead of the DivX-versions; For instance replace the resizer and the borders-thingy; When encoding to XviD i might not even be needed to add borders. Is there a special reason for doinig it, encoding for DVD/full PAL and/or NTSC reso's for instance ?

i use a divx as a source and make a mpeg out of it.
i never make a dvd with a divx as source.

barbapapa5800

13th January 2007, 07:08

this is the script that diko makes:

*knip - all the plugins*
Import("C:\Program Files\DIKO\avisynth plugins\addaudio.avsi")
Import("C:\Program Files\DIKO\avisynth plugins\fmin.avsi")
Import("C:\Program Files\DIKO\avisynth plugins\jdl-interlace.avsi")
Import("C:\Program Files\DIKO\avisynth plugins\jdl-util.avsi")
Import("C:\Program Files\DIKO\avisynth plugins\resize.avsi")
#
# Script begins here... #
#########################
#
Avisource("C:\Program Files\DIKO\Temp\American.avi",false)
AssumeFPS(25)
WIDESCREEN=0
Overscan=1
source_widescreen=1
WIDTH=480
HEIGHT=576
INTERLACED=false
addborders(8,0,0,0)
addborders(0,14,0,0)
converttoyv12()
Spline16Resize(WIDTH, HEIGHT)
FFT3DGPU (sigma=2,plane=4,sharpen=1.1)
AddBorders(HEIGHT,OVERSCAN)
Blockbuster(method="noise",detail_min=1,detail_max=10,variance=0.3,seed=2)
addaudio()
Subtitle("@ SKVCD.NL - CREW @", 130, 450, 75, 150, font="verdana", size=18, text_color=$ffFFFF)letterbox(8,8,8,8)
TextSub("C:\Program Files\diko\Temp\movie0.srt")
MonitorFilter
Converttoyv12()

when i leave the AddBorders(HEIGHT,OVERSCAN) out of the script, all the work is done by the GPU and the ripo takes about an hour of 10.

when i put the command back in nothing is done by the GPU and the rip is done in 15 minutes @ speeds of 30.

a normal rip with my old script is about 1 hour.

tsp

13th January 2007, 12:24

barbapapa5800: the GPU is only used to do the filtering inside fft3dgpu so the rest of the script is still processed by your cpu. So it will of course be slower with fft3dgpu than without it. Especially when you have a very fast cpu and a mid-end GPU. You might try my mt plugin if your cpu utilization is below 100% when encoding instead of fft3dgpu.

barbapapa5800

13th January 2007, 12:31

oke, thnx.
i have tried it before, but without succes.
maybe i'll try it again.

i know there whas a problem because diko genarates a script.

huang_ch

19th January 2007, 14:51

HeadBangeR77

19th January 2007, 15:52

tsp, I ran into another problem these days, may be somewhat related to the strange FPS problem I described in a previous post (http://forum.doom9.org/showthread.php?p=901772#post901772)
The problem is also about FPS, when I try fft3dgpu with plane=4 for a video, I test its performance with VirtualDub, it gives about 33-36fps, but when I replace the plane=4 with plane=0 and a plane=3, the fps increased to ~65fps. If I only run plane=3 or plane=0, I got ~80fps.
Anyone met this kind of issue?
The same by me, only the speeds are worse because of my hardware. As I'm not a prof, I can only assume the filter does its job for every plane separately (?). The default plane=0 (luma processing) is always the fastest for me, more or less the same speed as processing both chroma planes (plane=3). When I decide to process all possible planes (plane=4) it gets almost two times slower.

So I've got the same issue. The question is, should it really be like that? :confused:

EDIT: I get it now (banging his head against the nearest wall ;)) - plane=0 & plane=3 at the same time are plane=4, so there shouldn't be any difference in speed, should it?

tsp

19th January 2007, 22:28

hmm yes it seems like it is slower with plane=4 than with plane=0 and plane=3. I will see what is going on.

HeadBangeR77

19th January 2007, 23:54

I've just tested 'n I can confirm the above issue, although the difference by me is not so large as by huang_ch.

totya

20th January 2007, 11:15

Hi all!

My video card is ATI x1950Pro (580/1400)

Speed example :

Source : TV (captured video), PAL, 720x576
script line : FFT3DGPU(sigma=2, interlaced=false)
Speed is 31,94FPS

Good plugin, thank you.

Warpman

20th January 2007, 18:53

so tsp keeps ignoring me :/

my luma is 1 frame ahead of crome using
fft3dgpu()

but not with fft3dgpu(oldfft=true), so its a bug in the new code i guess

System
Geforce fx 5900xt 128mb (gainward)
Winxp Pro
Detonator tried 64.xx 84.xx 72.xx (all certified) even some omega drivers --> makes no difference

:thanks:

tsp

22nd January 2007, 00:30

Warpman: Thanks for figuring out that the problem lies in the new fft code. I will try testing if it is the lack of multiple render target in the fx code that are causing it. does interlaces=true also solve it?

Warpman

22nd January 2007, 21:18

i used
fft3dGPU(interlaced=true)

on a progressive clip (because i had no interlaced content atm)

did not change anything :(

webzeb

31st January 2007, 23:10

Hi,

I'm pure newbie.
So, please, be forbeading. ;)

I tried FFT3DGPU inside FFDShow :
FFT3DGPU (sigma=2,plane=0,sharpen=1.2)
playing HD x264 movies (resized to 1024*576px before FFT3D filering).

CPU Usage is OK (about 50% per core).
But framerate is really unstable.
Sometimes the video freezes, and restart playing smoothly for 1 or 2 seconds.
More suprisingly, sometime the video freezes, go backward of several frames (!), and the it start again to play smoothly.
No problem without FFT3DGPU...

Regards,

Fred

PS : I've nVidia 7900GTX. ForceWare 93.71 WHQL.

HeadBangeR77

31st January 2007, 23:29

I'm not sure, if even the strongest video cards could denoise (using fft3dgpu) in realtime, especially when it's HD content. I doubt it, sorry. Nevertheless a few tips to check:

1) Play some other video (DixV, XviD, lower resolution) and see, if it stattres or freezes, and if so, then how it is compared to the clip you've tested.

2) Download and open your aviscript with AVSP editor and do the same using the preview function (MPC required), If everything is ok, then blame ffdshow & avisynth cooperation, not the filter itself ;)

3) Try fft3dfilter (non-gpu version) using both of the above methods.

And report back, soldier :D
good luck!

Adub

31st January 2007, 23:38

Actually, yes, my ATI 1950 pro card runs fft3dgpu fine in realtime.

Also, webzeb, are you getting 50% total cpu usage or 50% per core, for a 25% total?
I ask because sometimes you need to multithread a little, or else the threads will all build up on one core, which to the program will look like it is using 100% total, and results in frame dropping and so on.

Although that backwards play is kind of weird.

webzeb

31st January 2007, 23:59

Actually, yes, my ATI 1950 pro card runs fft3dgpu fine in realtime.

Also, webzeb, are you getting 50% total cpu usage or 50% per core, for a 25% total?
Hi

About 50% usage for each core -> 50% total usage.
(Charge is corrrectly divided between the two cores of my overclocked E6300.)

I was think about the fact that my video card uses reduced frequencies (250Mhz instead of 650MHz) in 2D mode.
I increse GPU frequency which seems to reduce the problem...

Merlin7777
Does it runfine with HD material ?
(In my case, it's "only" a 1024*768px @23.976fps material...)

Thanks,

Fred

HeadBangeR77

1st February 2007, 00:21

I was think about the fact that my video card uses reduced frequencies (250Mhz instead of 650MHz) in 2D mode.
I increse GPU frequency which seems to reduce the problem...
How could I forget about that? :D
Well, in my case starting fft3dgpu switches on 3D mode (my custom one), so I totally forgot about such a possiblity.

Have you tried the original fft3dfilter?

cheers

Btw. sssss, it's a developement thread ;)

foxyshadis

1st February 2007, 11:30

About 50% usage for each core -> 50% total usage.
(Charge is corrrectly divided between the two cores of my overclocked E6300.)

I'm not sure why this myth keeps popping up lately, but 50% of each core is exactly the same as 100% of one core, for single threaded apps. Just because the scheduler distributes the requests across all the cores doesn't mean it has extra headroom; it's still limited to 100% of a single core, however that gets split up. (Maybe because in some cases XP splits them between cpus, and in others keeps it all to one.)

If you actually have multiple threads interacting and no single one is using 100% of one core (50% on dual-core), then you aren't cpu-limited, unless the threads are totally linear and can't parallelize anything. The only way to determine that is perfmon or process explorer.

The best advice I can tell is to ensure ffdshow is up to date for the most bug fixes, make sure some other filter isn't driving it over the limit, and try playing with some of the settings (esp. bt) if you still can't get smooth playback.

webzeb

1st February 2007, 12:36

I'm not sure why this myth keeps popping up lately, but 50% of each core is exactly the same as 100% of one core, for single threaded apps. Just because the scheduler distributes the requests across all the cores doesn't mean it has extra headroom; it's still limited to 100% of a single core, however that gets split up. (Maybe because in some cases XP splits them between cpus, and in others keeps it all to one.)

If you actually have multiple threads interacting and no single one is using 100% of one core (50% on dual-core), then you aren't cpu-limited, unless the threads are totally linear and can't parallelize anything. The only way to determine that is perfmon or process explorer.

The best advice I can tell is to ensure ffdshow is up to date for the most bug fixes, make sure some other filter isn't driving it over the limit, and try playing with some of the settings (esp. bt) if you still can't get smooth playback.
Hello,

Thank you for the advice. :)

However my filters (except resize) are multithreaded using MT.
My video decoder uses multihtreading too (CoreAVC Pro).

I thought I found what causes the problem.
If I disable LimitedSharpen, everything goes smoothly.

I keep you inform of the new tests (with lower resolution, etc.)

Regards,

Fred

fofwp

6th February 2007, 16:44

Can someone help me out?

I am trying to get this to work with the following script, but it either gives me an out of memory error or freezes Megui

DGDecode_mpeg2source("...")
trim(10000,11000)
crop( 0, 0, -2, -2)
LanczosResize(720,384)
fft3dgpu(sigma=2,plane=4,sharpen=0.5)
MT("LimitedSharpenFaster(ss_x=1.0, ss_y=1.0, Smode=3, strength=50, overshoot=1)", 3)

Anyone have any suggestions?

Thanks.

Boulder

6th February 2007, 16:57

Have you tried disabling filters one by one to see which one causes the issue? You might also want to try using LSF without MT.

fofwp

6th February 2007, 20:38

Have you tried disabling filters one by one to see which one causes the issue? You might also want to try using LSF without MT.

If I remove LFS then it is able to encode the video, but there is a line or a tear going down the middle of the image. I tried playing it in MPC w/ ffdshow and VLC, and both show the same effect.

Boulder

6th February 2007, 20:39

Uhm, what was your script like when that occurred?

fofwp

6th February 2007, 20:45

same as before, but with LSF commented out.

Boulder

6th February 2007, 20:53

Have you tried with plane=0, or different values for bw and bh in FFT3DGPU? Does the error occur when you load the script in VirtualDub?

fofwp

6th February 2007, 21:08

I can't really test anything right now (at work...), but I will play around with those settings when I get home.

When I view the avisynth script in VirtualDub I see some banding, is this normal?

Boulder

6th February 2007, 21:27

Banding should be visible only during playback, otherwise the video should look as it is.

webzeb

7th February 2007, 15:21

Hello,

I did more tests playing HD stuff, with FFDShow.

Hardware :

Core 2 Duo E6300 @3.3Ghz
1GB DDR2 @470Mhz
GeForce 7900GTX @667/907MHz (PCIe @105MHz)

Software :

Windows XP Professionnel Service Pack 2
DirectX 9.0c (4.09.0000.0904)
nVidia ForceWare 96.89 Beta
Media Player Classic 6.4.9.0
CoreAVC 1.2.0 Professional (for h264 and x264) / FFDShow Mpeg4 Decoder (for XviD)
FFDShow Tryout build 885 SSE
Avisynth 2.5.7
WMR9 Renderless (RGB32; YV12->RGB32 conversion made by FFDShow)

FFDShow config' (filters are given by order of use) :

Resize : Spline->1024*768px
Avisynth :
FFT3DGPU(plane=0,sigma=1.0,sigma2=1.0,sigma3=1.0,sigma4=4.0,precision=0,mode=2)
ColorMatrix(source=0,dest=2,threads=2,opt=2)
Sharpen : aSharp 1/4/0
DeBand : 1.1

Results :
Performance could vary in a HUGE proportion. It seems to be depending on CPU usage, as if FFT3DGPU was waiting for the other filters (or reciprocally).
For example :

Underworld 2 720p Xvid playback is perfectly smooth (Core #1 : ~20% / core #2 : ~55%)
Domino 1080p x264 playbak is very jerky : it freezes and go back of several frames about every second (Core #1 : ~40% /Core #2 : ~70%). If I take off FFT3DGPU from the filter chain, everything goes smoothly, and CPU usage remains almost the same.
In the same way, if I introduce a "CPU time eater" filter in the avisynth script (LSF for example, as mentioned in my previous post), playback becomes again jerky. Without FFT3DGPU, no problem.

I do not understand how filters interact under FFDShow. I thought FFT3DGPU simultaneously runs with other filters of the avisynth script...

Regards,

Fred

PS : I forgot an important thing : thank you for that great plugin !

tsp

7th February 2007, 19:34

webzeb

7th February 2007, 19:46

webzeb: It is a known issue that the framerate can be erratic at times with fft3dgpu. This does unfortunately makes it rather hard to use it for realtime filtering. It also appears when not using directshow. I don't know what causes it (the GPU driver uses a rather large amount of cpu resources at times so it might be sensitive to the current cpu utilization (maybe)). Also fft3dgpu runs simultaneously with the filters before fft3dgpu (it simply request what it believes is the next needed frame while the GPU is working on the current frame.
Hi,

Thank you for your quick answer.

I'll correct filter order.

I noticed that sometimes FFT3DGPU ran out of memory with HD stuff (always resized in 1024*xxx).
However it never did it the first time I lauched the player. Overall the performances seem to be better for the first played file.
It's pure speculation (of a pure newbie ;) ), but isn't it possible that a part of the video memory wouldn't be free as it should after FFT3DGPU was used ?

Regards,

Fred

HeadBangeR77

8th February 2007, 19:01

@ tsp
Just a short question (yet not so easy, I suppose ;)): has anyone reported much different results as to the strenght of denoising between fft3dgpu (I'm using the latest 0.8.2) and fft3dfilter (I'm using the latest 2.1.0), while using identical sigma values?

I'll describe the matter briefly:
I'm doing some very gentle denoising on a very noisy and grainy source (I would like to preserve most of the grain). I've been using fft3dgpu all the time, since it's running a bit faster on my hardware, with my current avs scripts (packed with Didee's stuff ;)). Today I wanted to try the latest fft3dfilter, mostly to compare the speed, and finished with differently denoised clips, what surprised me totally! :eek:

1) Resizing only (Lanczos3) : 163 MB.

2) Deblocking, BlindDeHalo3 PP, LimitedSharpenFaster, Soothe + a few more small things : 188 MB.

3) As above +
fft3dgpu(sigma=0.5,bt=3,plane=3,mode=1,degrid=1.0)
fft3dgpu(sigma=0.5,bt=3,plane=0,mode=1,degrid=1.0)
167 MB.

4) As above +
fft3dfilter(sigma=0.5,bt=3,plane=3)
fft3dfilter(sigma=0.5,bt=3,plane=0)
177 MB!

The difference isn't mariginal imo. I've tried the fft3dfilter also with just plane=4, as well as with the script:
YToUV(fft3dfilter(sigma=0.5, plane=1).UToY,\
fft3dfilter(sigma=0.5, plane=2).VToY,\
fft3dfilter(sigma=0.5, plane=0))
and the results are always identical, though much different from those of fft3dgpu. (?)

I've checked the default parameters: bw=bh=32 for both your gpu version and the normal one (used to be 48, was changed with 1.9.2). The only ones that differ are:

ow=bw/2 ,oh=bh/2 for yours vs. X/3 by Fizick's plugin
16 bit default precision by the gpu version

Could those two settings lead to more than 5% difference in the filesize?

cheers,
HDBR77

webzeb

8th February 2007, 21:39

webzeb: It is a known issue that the framerate can be erratic at times with fft3dgpu. This does unfortunately makes it rather hard to use it for realtime filtering. It also appears when not using directshow. I don't know what causes it (the GPU driver uses a rather large amount of cpu resources at times so it might be sensitive to the current cpu utilization (maybe)). Also fft3dgpu runs simultaneously with the filters before fft3dgpu (it simply request what it believes is the next needed frame while the GPU is working on the current frame.
Hello,

I'm sorry to mess around with you again.

Could you remove all doubt ?:confused:
If I run the following script in the Avisynth filter of FFDShow :
MT("Spline16Resize(1024,last.height)",threads=2,splitvertical=false)
MT("Spline16Resize(last.width,768)",threads=2,splitvertical=true)
FFT3DGPU(plane=4,sigma=0.5,sigma2=0.5,sigma3=1.5,sigma4=0.5,mode=2,precision=0)
will FFT3D GPU proceed resized frame (i.e. 1024*768px), original-sized frame ?

It might look stupid, but I'm not sure... :D

Thank you,

Fred

tsp

8th February 2007, 22:00

HeadBangeR77

8th February 2007, 22:23

HeadBangeR77: yes for some reason even with the 32 bit precision and same overlap fft3dgpu and fft3dfilter produces different result (with fft3dgpu producing a slight worse signal to noise ratio). It might be something to do with the floating point math not being as precisely implemented on the GPU (if this was the case a geforce 8800 should fare better).
First of all, thanks for the quick reply. :)

Secondly, I'm not sure if I get you correctly ... "slight worse signal to noise ratio"(?) But those were fft3dfilter's sample-encodes, that always came out with larger filesize. Should I assume that the gpu version swallows some details instead of noise, due to the probable worse precision? I can't mark that, I would have to analyze still frames, yet over sigma=1 (luma filtering only) I've marked some very slight details' loss with sharp & detailed sources, and I'm a quality-freak. :D

Btw. I've got Radeon 9800 PRO @ XT, if it matters.

tsp

8th February 2007, 22:43

HeadBangeR77

8th February 2007, 23:37

HeadBangeR77: I used the test from this (http://forum.doom9.org/showthread.php?t=114582) thread and fft3dgpu produced slightly worse result than fft3dfilter. But if it was because not as much noise was removed or some of the original details was removed I don't know. But as fft3dgpu creates a small compressed file it suggest that something is removed. It is up to your eyes to judge if it noise or something you want to keep. (and remember to look at the final compressed result when comparing the two filters). It might also depend on what encoder you are using (h264/xvid/mpeg2) and quantization matrix used.
Thanks again.
As to metrics, I've got similar attitude as Didee has, so judging on the base of metrics, with artificially added noise (or grain), isn't for me (and never would I turn my back on fft3dgpu from this reason ;) ;) ;)).

Guess I must have a look at still frames to mark the difference, although I really haven't seen any details loss using the gpu one with sigma values 0.5-0.8. That's why the difference I described in my posts above surprised me so much.

XviD 1.1.2, Heini's 6of9, preserves grain better than Didee's, and thus gives me less compressable results - good for testing denoisers. ;)

cheers,
HDBR77

ianken

10th February 2007, 08:13

Any chance of getting a version that uses SLI or Crossfire if its there? Right now on my system one GPU is smokin hot, the other is bored and twiddling its thumbs. :-)

webzeb

10th February 2007, 12:20

Any chance of getting a version that uses SLI or Crossfire if its there? Right now on my system one GPU is smokin hot, the other is bored and twiddling its thumbs. :-)
Hi,

As far as I'm concerned I think that making performances more constant between two sessions would be the first step.

I tested ~10 denoisers, and I love what FFT3DGPU gives.
I really appreciate the fact I could filter even lower frequency that other filters leave...

Edit : I did more tests with the latest Beta ForceWare (i.e. 96.89 Beta). I noticed a HUGE performance drop when playing the video on secondary screen (WMR9 Renderless is used). Nothing like that without FFT3DGPU.
It really has a strange behavior !
May be I have a software configuration/setup problem ?

tsp

10th February 2007, 15:18

webzeb: Sometimes there are some problem with hardware acceleration on the secondary display. It might be that you are experiencing.

As far as I'm concerned I think that making performances more constant between two sessions would be the first step.

you mean a more consistent framerate?

ianken: It is not high on the TODO list as I don't have a SLI configuration to test it with.

Fizick

10th February 2007, 15:36

The only ones that differ are:

ow=bw/2 ,oh=bh/2 for yours vs. X/3 by Fizick's plugin

It is the key difference,
try compare with explicit same ow, oh

webzeb

10th February 2007, 16:52

webzeb: Sometimes there are some problem with hardware acceleration on the secondary display. It might be that you are experiencing.

you mean a more consistent framerate?

ianken: It is not high on the TODO list as I don't have a SLI configuration to test it with.
Yep,

Framerate changes too much from one time to another, which (as you previously highlighted it) makes it uneasy to use for realtime playback.

Regards

PatchWorKs

19th February 2007, 10:33

Dunno if can help, but seems that NVIDIA released an interesting SDK:
NVIDIA® CUDA™ technology is a fundamentally new computing architecture that enables the GPU to solve complex computational problems in consumer, business, and technical applications. CUDA (Compute Unified Device Architecture) technology gives computationally intensive applications access to the tremendous processing power of NVIDIA graphics processing units (GPUs) through a revolutionary new programming interface. Providing orders of magnitude more performance and simplifying software development by using the standard C language, CUDA technology enables developers to create innovative solutions for data-intensive problems. For advanced research and language development, CUDA includes a low level assembly language layer and driver interface.

NVIDIA CUDA Homepage (http://developer.nvidia.com/object/cuda.html)

tsp

19th February 2007, 16:57

PatchWorKs: Yes CUDA is very cool but unfortunately it only works with geforce 8xxx and later. When I get my hands on a geforce 8800 I might try using CUDA to rewrite fft3dgpu for it.

devaster

28th February 2007, 21:19

try rapidmind more better as brookGPU...
i have a good experiences with it (setiGPU)

ianken

13th March 2007, 09:59

ianken: It is not high on the TODO list as I don't have a SLI configuration to test it with.

That's fine. Just asking.

FWIW it does not run on Vista. Surprise. Whose fault? NVIDIA (the drivers are WEAK) or MS? Dunno. Another low priority item to add to the list I guess.

G_M_C

13th March 2007, 11:20

PatchWorKs: Yes CUDA is very cool but unfortunately it only works with geforce 8xxx and later. When I get my hands on a geforce 8800 I might try using CUDA to rewrite fft3dgpu for it.

Since i use this filter on allmost every encode i do, i'm itching for news about update ... are there any in your planning atm ?

AssassiNBG

20th March 2007, 16:51

Hello,

I have a big problem. VDub keeps crashing with an Access Violation caused by d3dx9_30.dll associated with fft3dgpu. I have updated to the latest drivers for my 6600GT, and the latest DirectX version from February 2007, but I still get this error which prevents me from finishing a two pass encode in virtualdub (I've tried both stable and latest beta versions, I also tried the MPEG2 mod version, no use).

I hope someone could help me, or at least, upload the dll you have and is supposed to work fine.

Thanks!