Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

High performance FFT on GPUs 274

Posted by Hemos from the testing-it-out dept.
A reader writes: "The UNC GAMMA group has recently released a high performance FFT library which can handle large 1-D FFTs. According to their webpage, the FFT library is able to achieve 4x higher computational performance on a $500 NVIDIA 7900 GPU than optimized Intel Math Kernel FFT routines running on high-end Intel and AMD CPUs costing $1500-$2000. The library is supported for both Linux and Windows platforms and is tested to work on many programmable GPUs. There is also a link to download the library freely for non-commerical use."
This discussion has been archived. No new comments can be posted.

High performance FFT on GPUs More

High performance FFT on GPUs

Comments Filter:

  • Final Fantasy Tactics? (Score:4, Funny)

    by Musteval ( 817324 ) on Monday May 29, 2006 @11:32AM (#15424911)
    Why use a GPU for Final Fantasy Tactics? Couldn't you just use the GBA?

  • It's nice... (Score:5, Informative)

    by non0score ( 890022 ) on Monday May 29, 2006 @11:34AM (#15424921)
    if you're only considering 32-bit floating point numbers and don't need full IEEE-754 compliance.

    • Re:It's nice... (Score:5, Interesting)

      by john.r.strohm ( 586791 ) on Monday May 29, 2006 @11:51AM (#15425003)
      Depending on what you're doing, for an FFT, you probably don't need 64-bit floating point, and you DON'T need full IEEE-754 compliance.

      If you are taking data off of some kind of sensor, there are damned few sensors with 24 good bits of data out of the noise floor. Radars work just fine with 16-bit A/D converters.

      IEEE-754 compliance helps you in the ill-defined corners of the number space. FFTs inherently work in the well-behaved arena of simple trig functions and three-function (add/subtract/multiply) math.

      I'm currently doing FFTs with 16-bit fractional arithmetic in Blackfin DSP. For what I'm doing with the results, it is good enough.

      Not to mention you could use a "GPU farm" to do a fast search, and take any "interesting" data regions and feed those to a 64-bit, fully-IEEE-754 compliant, slow-as-molasses-in-January x86 FFT.

      Eventually, with some more articles like this one and yesterday's Cell piece, people will start to figure out that the x86 architecture is brain-dead and needs to be put out of its misery.

      • Re:It's nice... (Score:5, Informative)

        by stephentyrone ( 664894 ) on Monday May 29, 2006 @12:37PM (#15425172)
        FFTs inherently work in the well-behaved arena of simple trig functions and three-function (add/subtract/multiply) math.
        add/subtract/multiply math is the area that 754 has had the biggest effect on - in fact, the spec has very little to say about transcendental functions, but is almost entirely concerned with the basic arithmetic ops. prior to 754, floating point was, in general, not algebraicly closed under +-*/, nor were the results correctly rounded.

        most highly parallel GPU-type chips lack support for gradual underflow, for example, one of those "ill-defined corners of the number space" where 754 has been a tremendous boon. flush-to-zero is fine if you're decoding MP3s or unpacking texture maps, but it causes a lot of problems when you start trying to do more general scientific computations. sometimes those low order bits matter a whole lot; sometimes they're the difference between getting an answer accurate to 4 digits and an answer with *no* correct digits.

        "simple trig functions" have their own problems on these architectures; try writing an acceptable range-reduction algorithm for sin or cos without having correctly rounded arithmetic ops. sin and cos are, in fact, two the hardest operations in the math lib on which to get acceptable accuracy.

        admittedly, none of these objections are an issue with FFTs. but the reason that FFTs will perform acceptably on such an architecture is that the operations are (usually) constrained to the domain in which you don't encounter the problems i mention, not because the operations themselves are inherently safe. the lack of support for gradual underflow will cause you to lose many, many bits in frequency components that have nearly zero magnitude, but you usually don't care about those components when you're doing FFTs, anyway.

        • You hinted at this, but didn't explicitly state: as you increase the number of samples, you lower the SNR of the output, due to increasing numbers of rounding errors in the calculation. So, while you may be ok with 16bit fracints for a small sample set, as you increase the number of samples, you will eventually find that your noise floor obscures your results.

      • Re:It's nice... (Score:4, Insightful)

        by edp ( 171151 ) on Monday May 29, 2006 @01:35PM (#15425376) Homepage
        "If you are taking data off of some kind of sensor, there are damned few sensors with 24 good bits of data out of the noise floor. Radars work just fine with 16-bit A/D converters."

        Take a look at their benchmarks [unc.edu]. The chart goes up to eight million elements. The accumulated rounding error in FFT outputs may be around n * log2(n) ULP, where n is the number of elements, and ULP (units in last place) is relative to the largest input element. (Caveats: That is the maximum; the distribution of the logs of the errors resembles a normal distribution. Input was numbers selected from a uniform distribution over [0, 1). The error varies slightly depending on whether you have fused multiply-add and other factors.)

        So with eight million elements, the error may be 184 million ULP, or over 27 bits. With only 24 bits in your floating-point format, that is a problem. Whether you had 24-bit or 1-bit data to start with, it is essentially gone in some output elements. Most errors are less than the maximum, but it seems there is a lot of noise and not so much signal.

        It may be that the most interesting output elements are the ones with the highest magnitude. (The FFT is used to find the dominant frequencies in a signal.) If so, those output elements may be large relative to the error, so there could be useful results. However, anybody using such a large FFT with single-precision floating-point should analyze the error in their application.

      • Re:It's nice... (Score:5, Informative)

        by Waffle Iron ( 339739 ) on Monday May 29, 2006 @02:38PM (#15425569)
        Eventually, with some more articles like this one and yesterday's Cell piece, people will start to figure out that the x86 architecture is brain-dead and needs to be put out of its misery.

        Why? Because the x86 isn't a DSP?

        The x86 is a general-purpose CPU. It isn't brain dead; historically it's almost always been at least half as fast as the latest expensive processor fad du jour, and sometimes it has actually been the fastest available general purpose processor. As these fads have come and gone, the x86 has quietly kept improving by incorporating many of their best ideas.

        The cell processor is basically a POWER processor core packaged with a few DSPs tacked onto the die. That sounds like a kludge to me, but if it turns out to be a success, there's nothing stopping people from tacking DSPs onto an x86 die.

        All a DSP is good at is fast number crunching. It usually has little in the way of an MMU, along with a memory architecture tuned mainly for vector-like operations, branch prediction tuned only for matrix math, etc. DSPs would make a bad choice for running general purpose programs, especially with cache and branch issues becoming the dominant performance bottleneck in recent times. DSPs would a horrible choice for running an OS with any kind of security enforcement. Using a GPU as a poor-man's DSP is interesting, but it suffers even more from these same limitations. If DSPs really offered a better solution for general-purpose problems, they would have replaced other CPU architectures decades ago.

      • The sizes of transforms they are using for comparison here are of lengths of the order of 1 million points. This is huge for an FFT, and truncation error will definitely come into play here using only 32-bit precision. It all depends on what you are doing whether this will be adequate or not. Also, it's not at all clear what they did on the other platforms. There are some tricks to doing very long sequences; essentially using a 2D transform to perform a long 1D transform. It's not trivial, and requires

      • Re:It's nice... (Score:3, Interesting)

        by SETIGuy ( 33768 )
        If you are taking data off of some kind of sensor, there are damned few sensors with 24 good bits of data out of the noise floor. Radars work just fine with 16-bit A/D converters.

        I think you are confusing the precision of the input data with the precision of the power spectrum. An FFTs do a scaled add of a large number of samples, so the precision in the output is dependent on the number of input samples.

        For example SETI@home uses 1 bit complex sampling. (Yes, the SETI@home ADCs are a pair of high spe

  • Rush hour math. (Score:3, Insightful)

    by Anonymous Coward on Monday May 29, 2006 @11:35AM (#15424928)
    ""The UNC GAMMA group has recently released a high performance FFT library which can handle large 1-D FFTs. According to their webpage, the FFT library is able to achieve 4x higher computational performance on a $500 NVIDIA 7900 GPU than optimized Intel Math Kernel FFT routines running on high-end Intel and AMD CPUs costing $1500-$2000. "

    GPUs are nice, but there's the little matter of getting data and results on and off the chip.

    • That's where PCIe is useful (Score:4, Informative)

      by WoTG ( 610710 ) on Monday May 29, 2006 @12:07PM (#15425045) Homepage Journal
      AGP was not very useful for bidirectional data flow, but PCIe is. GPU's are pretty sophisticated these days, so they've got the logic to handle moving stuff in and out of it's memory and over the bus to the CPU and the rest of the system.
    • GPUs are nice, but there's the little matter of getting data and results on and off the chip.

      Not to mention that their dollar figures are somewhat misleading, as they didn't include the cost of the host PC...and AMD Opeteron 280 processors don't cost ANYWHERE NEAR $2,000. They also didn't show us how cheaper processors do.

      You can buy a Tyan quad-CPU motherboard for about $1k, and the dual-core version of the 280 for $1k tops. So...that's $5-5.5K for a box with EIGHT processors that will do 6 million co

      • 8xx verses 2xx (Score:2, Informative)

        by Somegeek ( 624100 )
        Note that you can only use the 2xx Opterons in 1 or 2 CPU (2 or 4 core) motherboards. If you want to have 4 CPUs with 8 cores you need to use the 8 series Opterons. The Opteron 880 dual core currently starts at over USD 1,600.00 each, which makes your configuration start at about 7,500 just for the MB and CPUs. Then add the registered RAM, server case, big juicy power supply, drives, video, monitor, a UPS to protect all of that... It sounds sexy but realistically its going to be close to $10K if you bui
      • Not to mention that their dollar figures are somewhat misleading, as they didn't include the cost of the host PC...and AMD Opeteron 280 processors don't cost ANYWHERE NEAR $2,000. They also didn't show us how cheaper processors do.

        They also didn't say how cheaper GPU's do.

        You can buy a Tyan quad-CPU motherboard for about $1k, and the dual-core version of the 280 for $1k tops. So...that's $5-5.5K for a box with EIGHT processors that will do 6 million complex values in almost half the time as the $500 video c

    • Re:Rush hour math. (Score:5, Informative)

      by corvair2k1 ( 658439 ) on Monday May 29, 2006 @03:35PM (#15425743)
      Typically, when doing these measurements, the GAMMA group counts the upload/download time as part of the computation time. So, the 4x-5x speedup you're seeing is end to end, with results starting and ending in main memory.

  • FFTs in GPUs, eh? (Score:3, Funny)

    by Anonymous Coward on Monday May 29, 2006 @11:35AM (#15424929)
    Well, seeing as how the V.P. is such a V.I.P., shouldn't we keep the P.C. on the Q.T.? 'Cause if it leaks to the V.C. he could end up M.I.A., and then we'd all be put out in K.P.

  • Any 64 bit GPU's? (Score:3, Insightful)

    by ufnoise ( 732845 ) on Monday May 29, 2006 @11:36AM (#15424931)
    While interesting, I need IEEE 64 bit double precision for my scientific applications. Are there any 64-bit floating point GPU's out there?
    • Well, if their library gives you a 4x increase for 32 bit stuff, would that mean a 2x increase for 64 bit math?

      /no really, would it?

      • Re:Any 64 bit GPU's? (Score:3, Informative)

        by Fordiman ( 689627 )
        No.

        Implementing 'big numbers', or numbers larger than the proccessor's spec, is actually quite computationally heavy when compared to the operations you're replacing. As such, a 4x increase in the speed of computation can translate to a (to pull a number from my arse) 0.25x loss of performance when dealing with larger floats.

        However...

        With CPU/GPU cooperation, the floating gap can be handled by using the CPU to generate a lookup table of high-precision trig as, say, a texture, and treating the numbers as m
        • Addition is relatively light bignum math if the precision you're extending from is correctly rounded. GPU floating point usually isn't. Even if it is, you're usually talking about increasing your op count by a factor of 5 or more, which kind of blows the "4x performace speedup" out of consideration.
          • oops. I was thinking my times from the bigint lib.

            Though, the floating point trig table can be converted to fractional and - oh, wait.. fractional is pretty process heavy too.

            Ok, GP. The answer is quite a definitive 'No'.

    • Re:Any 64 bit GPU's? (Score:4, Interesting)

      by Surt ( 22457 ) on Monday May 29, 2006 @12:12PM (#15425059) Homepage Journal
      Not yet. But in the next or second generation out your wish will be fulfilled (more and more game developers are pushing for 64 bit color accuracy, which will necessitate a transition to fully 64bit GPUs in the not distant future).

      • Re:Any 64 bit GPU's? (Score:5, Interesting)

        by TheRaven64 ( 641858 ) on Monday May 29, 2006 @12:25PM (#15425117) Journal
        more and more game developers are pushing for 64 bit color accuracy, which will necessitate a transition to fully 64bit GPUs in the not distant future

        Current generation GPUs handle 64bit and 128bit colours already. A 64-bit colour value is just four channels of 16-bit floats (halfs in Cg parlance). A 128-bit colour value is a vector of four 32-bit colour values.

        If game developers wanted 256-bit colour, then GPUs would need to support 64-bit floating point arithmetic. This is unlikely to happen, however, since 64-bit colour (which is really 48-bit colour with a 16-bit alpha channel) gives more colours than the human eye can distinguish. In fact, even with 64- or 128-bit colour for the intermediate results, current cards only have a 10-bit DAC for converting the colour value to an analogue quantity that can be displayed on an analogue screen.

        It is worth noting that Pixar's RenderMan software doesn't use more than 128-bit colour, and films like Toy Story were rendered using 64-bit mode.

    • Re:Any 64 bit GPU's? (Score:3, Informative)

      by jthill ( 303417 )
      Yes. Some guys at LBNL took good look. /. had the story yesterday [slashdot.org]. When they were trying, they repeatedly toasted Cray's best. With a "naive" FFT implementation -- not half trying -- they got 80%.

    • While interesting, I need IEEE 64 bit double precision for my scientific applications.

      Depends on what you need 64 bit for - is it for the precision (i.e. mantissa size) or the range (i.e. exponent size)?

      If you can live with a double-precision mantissa but a single-precision exponent, it's possible to get that using single-precision building blocks with less than a 2x slowdown. Sorry, don't have the references to hand right now, but a dig around on Citeseer/Google should get you there.

      • It's the precision. I am solving a set of fully coupled partial differential equations. With only single precision, the matrices being solved may not be accurate enough and it may be impossible to get a solution.

  • FFT; (Score:2, Informative)

    by MrShaggy ( 683273 )
    FFT; Fast Fourier Transform - a specific algorithm, but used to indicate any algorithm attempting to determine the power versus frequency graph for a signal Dag-nadit

    • Nope! (Score:4, Informative)

      by woolio ( 927141 ) on Monday May 29, 2006 @06:51PM (#15426263) Journal
      Sorry, the FFT of a time-domain signal does **NOT** indicate how the power (or energy) of the signal is distributed.

      For the latter, you need a PSD (power spectral density) plot, which is obtained by finding the square of the magnitude of the freq-domain FFT (complex) outputs.

      And the term "FFT" usually describes a specific class of algorithms that finds a Discrete Fourier Transform of a signal in much less than O(N^2) time, where N is the number of elements/samples considered.

      However, the FFT is also useful to perform fast polynomial multiplication (and even fast multiplication of very very very long numbers). This application has nothing to do with power or frequencies in a signal.
  • So correct me if I'm wrong but, it's just a math library for sale, right?

    Don't get me wrong, new tools are cool, but can someone explain to me why this is newsworthy?
    • I don't know if it's exactly newsworthy, but it's kind of cute (and interesting) that the amount of specialisation that's going on in graphics cards leads to situations where one can persuade the graphics card to do one's (not graphics-related) work faster than one would be using the general purpose CPU for the same task. It's more amusement than anything else (although for those who want to do the computation, it's also useful).
    • This is probably making a lot of developers, myself included, very very happy people. FFT's are where the proverbial magic happens for a lot of signals and systems analysis, as well as for the multiplication of very large integers. So anyone involved in gaming that includes digital signal processing (voice chat in UT, karaoke-karaoke-revolution type games, analog user input, etc.) is going to be happy, and anyone who's involved in multiplying huge integers (crypto anyone?) may very well have wet themselves.

      • Precision limit. (Score:3, Informative)

        by DrYak ( 748999 )
        The limit is the floating-point precision of the GPU.

        Most GPU can do max up to 32-bit floating point operations (depending on the brand and the model), where as most scientific applications use 64-bit and higher (the old FP unit could do 80bit FP math, SSE registers in recent processors can do 128-bits FP math).

        So some user will be happy, like for sound processing (GPU have already been used to process reverberation to create realistic sound environnement - too lazy to do the search for the slashdot referen

    • IF (Score:3, Funny)

      by Mark_MF-WN ( 678030 )
      What is newsworthy is that this is a shameless attempt to secularize mathematics. It's right in the name -- Fast Fourier Transformation. That's idolatry. What can a man know about signals that God hasn't already made clear in the Word? Come to our website [answersingenesis.org], and you can learn all about Intelligent Factoring, which is on much sounder mathematical grounds because it develops entirely from biblical principles.

  • FFT=Fast Fourier Transforms (Score:5, Interesting)

    by amliebsch ( 724858 ) on Monday May 29, 2006 @11:41AM (#15424958) Journal
    Isn't that what SETI@home uses for the bulk of its signal analysis? Would be kind of neat to leverage the millions of idle GPU's out there.
    • It's also used by distributed mathematics projects such as GIMPS to multiply large numbers. Unfortunately, if this implementation only operates in 32-bit precision, it will probably be less useful for this purpose since you'd have to do subproducts with fewer digits at a time, to avoid rounding error. I'm not familiar with the details, though.

    • Interesting question... (Score:3, Interesting)

      by DrYak ( 748999 )
      The interesting question will be :
      Is the 32-bit precision enough for SETI@Home application ?
      Or does the project needs the higher precisions (64bit to 128bit) that can (for now) only be provided by the CPU ?

      IMHO, maybe this could be useful. They're trying to find which chunk contains candidate data. If there's some fast low-precision algorithm that can quickly mark chunks as interesting / recheck with higher precision / un-interesting, it'll be helpful to quickly tell appart interseting chunk, even if data n

      • Re:Interesting question... (Score:5, Informative)

        by SETIGuy ( 33768 ) on Monday May 29, 2006 @08:14PM (#15426455) Homepage
        Yes, 32 bits is quite enough for our FFTs. Our requirements are fairly low. 16bit floats may even do the job (although I've never tried 16bit floats in SETI@home). What has concerned us in the past is that bandwidth to GPUs was fairly assymmetric (on AGP cards), the seti@home working sets (A few buffers of 1M complex samples == 16MB each) were larger than the usable memory on many video cards and the length of the maximum shader routine was fairly small. SETI@home does quite a bit more than FFTs, so moves into and out of main memory were required. At the time we couldn't put more into the shader language. That may have changed, but right now we lack anyone who both has the time to do the job and is capable of doing it.

        Our tests on nVidia 5600 series AGP cards (this was several years ago) showed that the net SETI@home throughput using the GPU was at best 1/5 of what we could obtain with the CPU. This was primarily due to transfers out of graphics memory and into main memory.

        PCI Express allows for symmetric bandwidth to graphics memory and graphics memories are now typically larger than the size of our working set. The difficulty will be in benchmarking to see which is faster for a specific GPU/CPU combination.

        At any rate it's a fairly simple job to swap FFT routines in SETI@home. The source is available [berkeley.edu]. Someone may have done it by now...

  • This is news? (Score:2, Interesting)

    by Anonymous Coward
    I have an uncle who's a professor who's been using GPUs for scientific computation for years. Apparently he has systems with four GPUs running simulations.
    • It's old news in academic, computational, and HPC circles, yes.

      New or the 2nd or 3rd dup here on /. tho

    • Re:This is news? (Score:5, Funny)

      by Fex303 ( 557896 ) on Monday May 29, 2006 @12:02PM (#15425034)
      I have an uncle who's a professor who's been using GPUs for scientific computation for years.

      I'm sorry, but playing Quake at really high framerates does not count as research. He's not fooling anyone.

      The business cards which list him as 'Profess0r of Pwnage' probably aren't helping either.

      It's also bad when he refers to the undergrads as 'n00bs' during his lectures to them.

  • $1500-$2000? (Score:3, Insightful)

    by Wesley Felter ( 138342 ) <wesley@felter.org> on Monday May 29, 2006 @11:45AM (#15424976) Homepage
    I sense a little bias here; the fastest Intel and AMD processors are actually $1,000.

  • Cray-1 comparison (Score:5, Interesting)

    by Mostly a lurker ( 634878 ) on Monday May 29, 2006 @11:56AM (#15425016)
    The Cray-1A supercomputer, weighing in at 5.5 tons, had an absolute maximum peak performance of 250 megaflops. It, of course, cost millions and the power requirements (including for cooling) were in excess of 200 kW. I remember marveling at the advanced nature of this technological achievement.

    Thirty years later, a $500 GPU, weighing less than 1 pound, can produce 6 gigaflops. People complain about its power and cooling needs, but they are rather below 200 kW! We sometimes forget just how amazing the developments in computing have been over the last three decades.

    • Re:Cray-1 comparison (Score:2, Insightful)

      by Anonymous Coward
      People complain because they compare the power consumption to their old "home computer". Just look at the Apple II, the C64 or similar 8 bit computers, almost all of which had such low power demands that they could run without fans. Even the "IBM compatible" PCs up to and including 386s almost always had exacly one fan, the one in the power supply. My most recently purchase (second hand) computer has 6 fans, and draws enough power to justify most of them.

      You can probably make up your own flawed car analogy
      • You can probably make up your own flawed car analogy and compare top speed and fuel consumption of today's compact cars with the racing cars of 60 years ago.

        And then marvel at how automobile technology has advanced, which I think was the point.
    • People complain about its power and cooling needs, but they are rather below 200 kW! We sometimes forget just how amazing the developments in computing have been over the last three decades.

      Why compare it with Cray-1, compare it with the steam-powered calculators of the past that take minutes to multiply two simple numbers and the results are sometimes kinda off.

      People always demand more, this is why they develop more, so to get more. If people become suddenly satisfied with whatever state they're in, they'
  • At last a good occasion to explain what the FFT is! But huh, I'll rather link to Wikipedia, not that I couldn't explain by myself eh, pshhh!

    Note how many comments are about explaining what FFT is as opposed to how many comments consist in asking what FFT means. Quite a fucked up demand/offer ratio.

  • That thing is called GPUFFTW, one could assume that it is based on the FFTW library (which is after all the best performing FFT library around) but after looking at every page on this site, I couldn't find a single credit to FFTW.

    Are the two linked or is the W at the end of the name just a mere coincidence?

  • on this page [unc.edu] here they almost compare to a program called libgpufft (which is an open source BSD version of the same library here [sourceforge.net] ) I wonder how they do compared to the BSD licensed version---

  • Bytes/bits? (Score:3, Informative)

    by 4D6963 ( 933028 ) on Monday May 29, 2006 @12:23PM (#15425105)
    From the site :

    The Video RAM will determine the maximum array length that can be sorted on the GPU. A rough guideline for performing FFT on 32-bit floats is: Maximum array length in millions = Video RAM in MB / 32

    Max array length equals video RAM in megabytes divided by 32... bits? Correct me if i'm dumb but shouldn't it rather be "Video RAM in MB / 4"?

    • You would naturally need some kind of workspace to store the results. I think that a normal shader is not supposed to write data back to from where it was read, so there can be some quite significant "read, multiply, write to new location" going on.
  • Graphics Processing Units have always been better for FFTs and signal processing than general CPUs. I've read a journal article where machine vision was implemented on a GeForce 5200 at a 3x speedup over an AMD Athlon 3200+. The reason? This is what a GPU is made for; the small dedicated instruction set makes a GPU much more adept at signal processing than the 686's have ever been.

  • What's an FFT (Score:5, Informative)

    by Geoffreyerffoeg ( 729040 ) on Monday May 29, 2006 @12:31PM (#15425143)
    Apparently nobody knows what an FFT is. Here's the best description I can give without descending into math too much.

    The Fast Fourier Transform is an algorithm to turn a set of data (as amplitude vs. time) into a set of waves (as amplitude vs. frequency). Say that I have a recording of a piano playing an A at 440 Hz. If I plot the actual data that the sound card records, it'll come out something like this picture [pianoeducation.org]. There's a large fading-out, then the 440 Hz wave, then a couple of overtones at multiples of 440 Hz. The Fourier series will have a strong spike at 440 Hz, then smaller spikes at higher frequencies: something like this plot [virtualcomposer2000.com]. (Of course, that's not at 440, but you get the idea.)

    The reason we like Fourier transforms is that once you have that second plot, it's extremely easy to tell what the frequency of the wave is, for example - just look for the biggest spike. It's a much more efficient way to store musical data, and it allows for, e.g., pitch transformations (compute the FFT, add your pitch change to the result, and compute the inverse FFT which uses almost the same formula). It's good for data compression because it can tell us which frequencies are important and which are imperceptible - and it's much smaller to say "Play 440 Hz, plus half an 880 Hz, plus..." than to specify each height at each sampling interval.

    The FFT is a very mathematics-heavy algorithm, which makes it well suited for a GPU (a math-oriented device, because it performs a lot of vector and floating-point calculations for graphics rendering) as opposed to a general-purpose CPU (which is more suited for data transfer and processing, memory access, logic structures, integer calculations, etc.) We're starting to see a lot of use of the GPU as the modern equivalent of the old math coprocessor.

    If you're looking for more information, Wikipedia's FFT article is a good technical description of the algorithm itself. This article [bu.edu] has some good diagrams and examples, but his explanation is a little non-traditional.
    • Bravo. Just... bravo.

      I was going to karma-whore this myself, but you beat me to it, and probably did a better job. :)

  • Great for audio! (Score:3, Insightful)

    by radarsat1 ( 786772 ) on Monday May 29, 2006 @12:47PM (#15425206) Homepage
    Awesome, this is really good news for audio people.
    I want to see how I can take advantage of this... I hope the license isn't too restrictive.
    It might be a good example of how to use the GPU for general purpose (vector-based) computation, something I've been wanting to explore.

    Just curious, how does the use of the GPU for this kind of thing affect the graphics display?
    Are you unable to draw on the screen while it's running, or something?

  • Finally.... (Score:5, Funny)

    by Comboman ( 895500 ) on Monday May 29, 2006 @01:11PM (#15425299)
    Finally I have a good excuse to give the IT department why I need to upgrade my video card. I need to do FFTs faster (it has nothing at all to do with Doom3).

  • Unfair comparison (Score:2, Interesting)

    by daveisfera ( 832409 )
    The one thing that I haven't seen mentioned is that the benchmarks only show "compute timings" and not actual setup and retreval times. If the benchmarks showed the amount of time to get the data to the GPU and especially the time to get the result back to a place where a program could actually use it then it would be blown out of the water by the CPU. Future cards/drivers could speed up the process of retrieving the data, but for now there will always be lame benchmarks like this that are unfairly biased t
  • There are plenty of high-performance co-processor boards you could use. Often, they don't help at all because getting the data in and out is slower than just doing the operations on the CPU. Furthermore, the $500 is in addition to the CPU you already have. Third, the effort you invest in putting your code on the coprocessor is likely going to be a short-term investment, as these boards (whether GPU or otherwise) rapidly change, and as few other people are going to have exactly the same setup as you.

    Overa

  • stating the obviou... (Score:3, Interesting)

    by adolf ( 21054 ) <flodadolf@gmail.com> on Monday May 29, 2006 @02:06PM (#15425481) Journal
    Right then. So how long before they just include some weak general-purpose instructions in the GPU, add SATA and ethernet to the cards, and call it a budget PC?

  • FFTs are also useful for squaring large numbers with a modulo. That's what http://www.mersenne.org/ [mersenne.org] uses them for.

    Melissa
  • Someone in a parallel computing class I was taking did a parallel application using FFT to do processing. I wonder if they could incorporate this into MPI for parallel computations pretty easily?

  • Pro Audio applications? (Score:3, Interesting)

    by rekoil ( 168689 ) on Monday May 29, 2006 @04:01PM (#15425817)
    I'm wondering whether or not the DSP latency of these libraries is sufficient to use with real-time audio processing...if folks were to write RTAS/AU/VST plugins using the library, how they would compare to other hardware-assisted DSP solutions such as the PowerCore and Pro Tools farm cards. Then again, if you have to spend $500 on a card to get this goodness, it's hardly a bargain (albeit cheaper than the above products...)

Slashdot Top Deals

Is knowledge knowable? If not, how do we know that?

Close