Slashdot Mirror

← Back to Stories (view on slashdot.org)

Nvidia Physics Engine Almost Complete

Posted by ScuttleMonkey on from the close-only-counts-in-horseshoes-and-hand-grenades dept.

Nvidia has stated that their translation of Ageia's physics engine to CUDA is almost complete. To showcase the capabilities of the new tech Nvidia ran a particle demonstration similar to Intel's Nehalem demo, at ten times the speed. "While Intel's Nehalem demo had 50,000-60,000 particles and ran at 15-20 fps (without a GPU), the particle demo on a GeForce 9800 card resulted in 300 fps. In the very likely event that Nvidia's next-gen parts (G100: GT100/200) will double their shader units, this number could top 600 fps, meaning that Nehalem at 2.53 GHz is lagging 20-40x behind 2006/2007/2008 high-end GPU hardware. However, you can't ignore the fact that Nehalem in fact can run physics."

17 of 179 comments (clear)

  1. Duke! by wild_quinine · · Score: 5, Funny
    The best news about this is that it implies that if hardcore kit kills with it, then at least budget hardware (that many people have already!) can do it acceptably. That means finally seeing games that REQUIRE physics acceleration.

    It'll be like 1996 all over again, only from a physics not graphics perspective. That, and there might be a new Duke Nukem game due out within the next 12 years.

  2. I couldn't find anything specific - will nVidia... by mmell · · Score: 5, Interesting

    ...provide Linux drivers, or will the F/OSS community have to reverse-engineer this one?

  3. Re:It's just particles by grahamd0 · · Score: 5, Funny

    EA Presents: Cancun Wet T-Shirt Contest 2K9!

  4. Is particle motion a fair test case? by DoofusOfDeath · · Score: 5, Informative

    Is a particle motion simulator a abnormally easy test case?

    When I was getting up to speed on IBM Cell programming, IBM had a programmer's tutorial (excellently written, btw). The example problem they used for their chapter(s?) on code tuning were a particle simulator. It was a wonderful example problem, because it showed how to vectorize a program. But then when we went to vectorize our own algorithm, it didn't fit the Cell's vector programming instructions nearly as cleanly, so in the end we didn't get nearly the performance increase due to vector instructions as did the particle simulator.

    So I'm thinking that just even though CUDA can do a good job with particle motion simulations, we shouldn't remotely assume that it's good for particular algorithms for which each of us is responsible.

  5. Re:I couldn't find anything specific - will nVidia by karbonKid · · Score: 5, Informative

    http://www.nvidia.com/object/cuda_get.html offers: "NVIDIA Driver for Linux with CUDA Support (169.09)"

    So, physics should work on Linux, having been ported to CUDA already, and CUDA being cross-platform, but the question is if any Linux games will actually support and/or make use of it.

  6. Experts please explain something by Handlarn · · Score: 5, Interesting

    Anyone care to explain why there's such a big difference between a GPU and a CPU? I keep hearing how GPU's are this and that much faster than a CPU at calculations like graphics, physics and such, so naturally I assume there's a big difference that makes us still chose the x86 and x64 CPUs as the main processors of a PC. What are the limitations; why can't just the libraries be ported for GPUs instead of CPUs and why don't we then just run all calculations on a GPU, if they are anything from 2 to 50 times faster?

    It just seems to me that if a graphics card can calculate physics then it would also be able to do pretty much all the same types of calculations that a regular CPU can do, but I am obviously missing a big part of it.

    Experts, continue! :)

    1. Re:Experts please explain something by caerwyn · · Score: 5, Informative

      Particle systems are about as perfectly a parallel problem as it's possible to get- and not only that, the calculations are generally very straightforward with few (if any) general CPU control structures (branches, loops, etc).

      As a result, the massively parallel hardware on a GPU that exists to render many triangles/pixels/shader programs/etc at once can be exploited to calculate updates for many particles at once. The CPU is at an inherent disadvantage because it is only leveraging a small subset of it's full capabilities.

      The CPU is very good at *lots* of different tasks. The GPU is phenomenally good at a very specific set of tasks. Physics just happens to fit within that set.

      --
      The ringing of the division bell has begun... -PF
    2. Re:Experts please explain something by cowscows · · Score: 5, Informative

      In its most basic definition, a GPU is just a CPU that's been highly specialized towards graphics. It can't do anything that a CPU can't also do, it just is able to do particular things much faster. Basically, they take a lot of the common tasks that graphics require of a processor, and they put really efficient ways to do it directly into the hardware, and they put a whole lot of them.

      Think of a CPU as a big tool box. There's something in there for every task, including a screwdriver that can be used to put screws into things. Then next to it, you have a big cordless 18 volt drill (The GPU). Way easier to drive screws with that than the manual screwdriver in your toolbox. But when you need to drive a nail instead, yeah you could bash it in with your screw gun, but it's easier to go back to your toolbox and find a hammer.

      I guess that would make a physics processor the nail gun. Or something...

      --

      One time I threw a brick at a duck.

  7. Why particle systems? by Thanshin · · Score: 5, Interesting

    They should test physics systems with spheres on irregular ground, with uneven μ (coefficient of kinetic friction), and changing wind.

    Those are the kind of problems that force programmers to use approximations when using a physics engine.

    The next step is really abstracting the physics from the development, not having pretty water.

    1. Re:Why particle systems? by Animats · · Score: 5, Interesting

      They should test physics systems with spheres on irregular ground, with uneven (coefficient of kinetic friction), and changing wind.

      I always liked to test on the hard cases (see my web site) but, in fact, what game developers and animators want is not realistic physics. The game people want "infinitely destructible environments", where you can blow up anything. And, of course, eye candy. The animation people want physics they can direct, where the starting and ending positions are specified but what happens in the middle might be automated. So most character motion in video games is spliced-together motion capture bits, hand animation, and a bit of physics now and then.

      Most game physics engines today cheat on the hard cases, but by now, they usually cheat in ways that don't do something blatantly nonphysical.

      My original goal, back in 1996 when I was working on this, was to get to a two-person fighting game with real martial arts. The physics engine we had was good enough, although in the era of 200MHz CPUs, a bit slow. But a control system that can do a judo throw against an uncooperative opponent is still out of reach. Worse, controlling a physically realistic martial arts character through a game pad is just hopeless. Play would be like a typical day at the dojo: "You lost your center. Your left foot should have been further forward when you tried that throw." "Yes, sensi". Work out three times a week for a year, and you get to be halfway decent. As a game, that sucks.

      So I created the "ragdoll falling downstairs" cliche as a demo, licensed the technology to a middleware provider, and went on to other things.

  8. Real Physics engine goal by Anonymous Coward · · Score: 5, Funny

    I want to see 10^88 particles simulated at 10^33 frames / second.

  9. Re:It's just particles by Mastadex · · Score: 5, Funny

    With what is promised by this physics engine, you will be able to tell between all natural and fake boobs. Its all in the bounce!

    --
    A morning without coffee is like something without something else.
  10. Comment removed by account_deleted · · Score: 5, Funny

    Comment removed based on user account deletion

  11. FIrst you need a Windows version that won't crash. by mmell · · Score: 5, Funny

    Just sayin'. ;^)

  12. Re:Sync between machines with different cards? by Mr+Z · · Score: 5, Informative

    Huh? The local physics computations are only being used for presentation and local extrapolation. The server recomputes the relevant physics anyway, and can re-sync everyone periodically. That's how FPSes work to reduce lag--they do local extrapolation, and the server periodically snaps everyone back in line. It sometimes leads to what John Carmack calls "paradoxes" where locally displayed events get undone, but it works.

    So, if some portion of your local physics calculation is purely for local presentation (e.g. game outcome doesn't depend on exactly how dirt particles fly around or boobs bounce, but you want it to look realistic), the server doesn't need to reproduce any of that to model the game correctly. Your screen might look different than someone else's, but in an immaterial way. For the super-soaker example, the server will still compute actual "wetness," possibly with a simplified model that skips computing the goosebumps and most of the dripping water.

    --Joe
    --
    Program Intellivision!
  13. Re:I couldn't find anything specific - will nVidia by somersault · · Score: 5, Informative

    id seem to make all their games for Linux, and they also like using random accessories like that USB flak jacket thing that simulates you getting shot (by quickly puffing up pockets of air with pneumatic compressors). No doubt Quake 5 or whatever will support it at least.

    --
    which is totally what she said
  14. Re:It's just particles by Solder+Fumes · · Score: 5, Funny

    Slow motion

    (.)(.)

    (')(')

    (.)(.)

    Much faster

    (:)(:)

    So fast they're a blur

    (|){|)