PhysX Performance

The first program we tested is AGEIA's test application. It's a small scene with a pyramid of boxes stacked up. The only thing it does is shoot a ball at the boxes. We used FRAPS to get the framerate of the test app with and without hardware support.

AEGIA Test Application

With the hardware, we were able to get a better minimum and average framerate after shooting the boxes. Obviously this case is a little contrived. The scene is only CPU limited with no fancy graphics going on to clutter up the GPU: just a bunch of solid colored boxes bouncing around after being shaken up a bit. Clearly the PhysX hardware is able to take the burden off the CPU when physics calculations are the only bottleneck in performance. This is to be expected, and doing the same amount of work will give higher performance under PhysX hardware, but we still don't have any idea of how much more the hardware will really allow.

Maybe in the future AGEIA will give us the ability to increase the number of boxes. For now, we get 16% higher minimum frame rates and 14% higher average frame rates by using be AGEIA PhysX card over just the FX-57 CPU. Honestly, that's a little underwhelming, considering that the AGEIA test application ought to be providing more of a best case scenario.

Moving to the slower Opteron 144 processor, the PhysX card does seem to be a bit more helpful. Average frame rates are up 36% and minimum frame rates are up 47%. The problem is, the target audience of the PhysX card is far more likely to have a high-end processor than a low-end "chump" processor -- or at the very least, they would have an overclocked Opteron/Athlon 64.

Let's take a look at Ghost Recon and see if the story changes any.

Ghost Recon Advanced Warfighter

This next test will be a bit different. Rather than testing the same level of physics with hardware and software, we are only able to test the software at a low physics level and the hardware at a high physics level. We haven't been able to find any way to enable hardware quality physics without the board, nor have we discovered how to enable lower quality physics effects with the board installed. These numbers are still useful as they reflect what people will actually see.

For this test, we looked at a low quality setting (800x600 with low quality textures and no AF) and a high quality setting (1600x1200 with high quality textures and 8x AF). We recorded both the minimum and the average framerate. Here are a couple screenshots with (top) and without (bottom) PhysX, along with the results:

Ghost Recon Advanced Warfighter

Ghost Recon Advanced Warfighter

The graphs show some interesting results. We see a lower framerate in all cases when using the PhysX hardware. As we said before, installing the hardware automatically enables higher quality physics. We can't get a good idea of how much better the PhysX hardware would perform than the CPU, but we can see a couple facts very clearly.

Looking at the average framerate comparisons shows us that when the game is GPU limited there is relatively little impact for enabling the higher quality physics. This is the most likely case we'll see in the near term, as the only people buying PhysX hardware initially will probably also be buying high end graphics solutions and pushing them to their limit. The lower end CPU does still have a relatively large impact on minimum frame rates, however, so the PPU doesn't appear to be offloading a lot of work from the CPU core.

The average framerates under low quality graphics settings (i.e. shifting the bottleneck from the GPU to another part of the system) shows that high quality physics has a large impact on performance behind the scenes. The game has either become limited by the PhysX card itself or by the CPU, depending on how much extra physics is going on and where different aspects of the game are being processed. It's very likely this is a more of a bottleneck on the PhysX hardware, as the difference between the 1.8 and 2.6 GHz CPU with PhysX is less than the difference between the two CPUs using software PhysX calculations.

If we shift our focus to the minimum framerates, we notice that when physics is accelerated by hardware our minimum framerate is very low at 17 frames per second regardless of the graphical quality - 12 FPS with the slower CPU. Our test is mostly that of an explosion. We record slightly before and slightly after a grenade blowing up some scenery, and the minimum framerate happens right after the explosion goes off.

Our working theory is that when the explosion starts, the debris that goes flying everywhere needs to be created on the fly. This can either be done on the CPU, on the PhysX card, or in both places depending on exactly how the situation is handled by the software. It seems most likely that the slowdown is the cost of instancing all these objects on the PhysX card and then moving them back and forth over the PCI bus and eventually to the GPU. It would certainly be interesting to see if a faster connection for the PhysX card - like PCIe X1 - could smooth things out, but that will have to wait for a future generation of the hardware most likely.

We don't feel the drop in frame rates really affects playability as it's only a couple frames with lower framerates (and the framerate isn't low enough to really "feel" the stutter). However, we'll leave it to the reader to judge whether the quality gain is worth the performance loss. In order to help in that endeavor, we are providing two short videos (3.3MB Zip) of the benchmark sequence with and without hardware acceleration. Enjoy!

One final note is that judging by the average and minimum frame rates, the quality of the physics calculations running on the CPU is substantially lower than it needs to be, at least with a fast processor. Another way of putting it is that the high quality physics may be a little too high quality right now. The reason we say this is that our frame rates are lower -- both minimum and average rates -- when using the PPU. Ideally, we want better physics quality at equal or higher frame rates. Having more objects on screen at once isn't bad, but we would definitely like to have some control over the amount of additional objects.

ASUS Card and Test Configuration Final Words
Comments Locked


View All Comments

  • Magnadoodle - Friday, May 5, 2006 - link

    Actually, if you look at this statement by Havok:"> (Already linked)

    They also arrive at the conclusion that it is not a GPU bottleneck.

    Furthermore, the only thing the PPU seems to do in GRAW is render a couple of particles, while not improving or accelerating *at all* the processing of physics. This particle effect could have been processed very well by a GPU.

    I guess Anandtech didn't notice that the physics were exactly the same, thus pointing out the somewhat elicit nature of better physics.
  • DerekWilson - Friday, May 5, 2006 - link

    The havok guys did miss a few things pointed out earlier in the comments. Some destructable objects do break off into real persistant objects under PhysX -- like the dumpster lid and car doors. Also, the debris in the explosions is physically simulated rather than scripted. While I certainly agree that the end effect in these cases has no impact on "goodness", it is actually doing something.

    I'll certainly agree that "better physics" is kind of strange to think about. But it is really similar to how older games used to do 3D with canned animations. More realtime simulation opened up opportunities to do so many amazing things that just couldn't be done otherwise. This should extend well to physics.

    Also, regardless of how (or how efficiently) the developers did it, there's no denying that the game feels better with the hardware accelerated aspects. Whether they could have done the same thing on the CPU or GPU, they didn't.

    I'd still love to find a way to test the performance of this thing running the hardware physics on the CPU.
  • JumpyBL - Saturday, May 6, 2006 - link


    Some destructable objects do break off into real persistant objects under PhysX -- like the dumpster lid and car doors.

    I see these same effects without PhysX.
  • DerekWilson - Saturday, May 6, 2006 - link

    When I play it without the PhysX hardware, doors just seem to pop open -- not fly off ... though I haven't exhaustively blown up every object -- there could be some cases where these types of things happen in software as well.
  • JumpyBL - Saturday, May 6, 2006 - link

    Shoot up the tires, car doors, etc enough and they come off. Same with the garbage can lid, throw a nade, it'll blow right off the container, all without a PPU.
  • Fenixgoon - Friday, May 5, 2006 - link

    how is the game going to "feel better" with a PPU when it slams your framerate down from buttery smooth to choppy? sorry, i'll take the FPS over any degree of better simulated physics, ESPECIALLY on a budget PC. i mean, look at the numbers! opteron minimum fps at 8x6 was 46, and with the PPU hardware it dropped to 12 - over a 75% decrease!!
  • DerekWilson - Friday, May 5, 2006 - link

    Note that the min framerate is much lower than the average -- with the majority of frames rolling along at average framerates, one or two frames that drop to an instantaneous 12-17fps isn't going to make the game feel choppy. The benchmark was fairly short, so even outliers have an impact on the average -- futher going to show that these minimum fps are not anything to worry about. At the same time, they aren't desierable either.

    Also, I would certainly not recommend this part to anyone but the hardcore enthusiast right now. People with slow graphics cards and processors would benefit much more by upgrading one or the other. In these early stages with little software support, the PPU will really only look attractive to people who already have very powerful systems and want something else to expand the capabilities.

    if you watch the videos, there's no noticable choppiness in the motion of the explosion. and I can say from gameplay experience that there's no noticeable mouse lag when things are exploding either. thus, with the added visual effects, it feels better. certainly a subjective analysis, but I hope that explains how I could get that impression.
  • mongo lloyd - Friday, May 5, 2006 - link

    You must be joking. Watching the videos, the PhysX one is WAY choppier compared to the software one. The PhysX video even halts for a split second, in a way that's more than noticeable; it's downright terrible.

    And the graphics/effect of the extra debris? Negligible. I've seen more videos from this game (for example:"> ) and the extra stuff with PhysX in this game is just not impressive or a big deal, and in some cases it's actually worse (like the URINATING walls and ground when shooting them). It's not realistic, it's not fun, not particularly cool, and it's slow.
  • Clauzii - Friday, May 5, 2006 - link

    I also think thats why we see such a massive FPS drop. We are trying to render, say, 100 times as many objects now?
  • DerekWilson - Friday, May 5, 2006 - link

    I was hoping we made this clear in the article ...

    While there is certainly more for the GPU to do, the numbers under a CPU limited configuration (800x600 with lower quality settings) we see a very low minimum framerate and a much lower average when compared to software physics.

    The drop in performance is much much less signficant when we look at a GPU limited configuration -- if all those object were bottlenecking on the graphics card, then giving them high quality textures and rendering them at a much higher resolution would show a bigger impact on performance.

    Tie that in with the fact that both the CPU and GPU limited configurations turn out the same minimum framerate and we really can conclude that the bottleneck is somewhere other than the GPU.

    It becomes more difficult to determin whether the bottleneck is at the CPU (game/driver/api overhead) or the PPU (pci bus/object generation/actual physics).

Log in

Don't have an account? Sign up now