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

101 Comments

View All Comments

  • DrZoidberg - Sunday, May 7, 2006 - link

    Yes dual core CPU's aren't being properly utilised by games. Only handful of games like COD2, Quake4 etc.. have big improvements with the dual core CPU patches. I would rather game companies spend time trying to utilise dual core so the 2nd core gets to do alot of physics work, rather then sitting mostly idle. Plus the cost of AGEIA card is too high. Already I'm having trouble justifying buying a 7900gt or x1900 when i have a decent graphics card, cant upgrade graphics every year. $300 for physics card that only handful of games support is too much. And the AT benchies dont show alot of improvement.
  • Walter Williams - Friday, May 5, 2006 - link

    We are starting to see multithreaded games that basically do this.

    However, it is very difficult and time consuming to make a game multi-threaded, hence why not many games are this way.
  • Hypernova - Friday, May 5, 2006 - link

    Physx API claims to be multy core compatiable, what will happen is probably is the the API and engine will load balance the calculation between any available resources which is either the PPU, CPU or better yet both.
  • JarredWalton - Friday, May 5, 2006 - link

    Isn't it difficult to reprogram a game to make use of the hardware accelerated physics as well? If the GRAW tests perform poorly because the support is "tacked on", wouldn't that suggest that doing PhysX properly is at least somewhat difficult? Given that PhysX has a software and hardware solution, I really want to be able to flip a switch and watch the performance of the same calculations running off the CPU. Also, if their PhysX API can be programmed to take advantage of multiple threads on the PhysX card (we don't have low level details, so who knows?), it ought to be able to multithred calculations on SMP systems as well.

    I'd like to see the CellFactor people add the option of *trying* to run everything without the PhysX card. Give us an apples-to-aplles comparison. Until we can see that sort of comparison, we're basically in the dark, and things can be hidden quite easily in the dark....
  • Walter Williams - Friday, May 5, 2006 - link

    PPU support is simply achieved by using the Novadex physics engine or any game engine that uses the Novadex engine (ex/ Unreal Engine 3.0). The developers of GRAW decided to take a non-basic approach to adding PPU support, adding additional graphical effects for users of the PPU - this is similar to how Far Cry 64 advertises better graphics b/c it is 64bits as an advertising gimmick. GRAW seems to have issues in general and is not a very reliable test.

    At quakecon '05, I had the opportunity to listen to the CEO of Ageia speakd and then meet with Ageia representatives. They had a test system that was an Athlon64 X2, a top of the line video card, and a PPU. The demo that I was able to play was what looked to be an early version of the Unreal Engine 3.0 (maybe Huxley?) and during the demo they could turn on and off PPU support. Everytime we switched between the two, we would take notice of the CPU usage meter and of the FPS and there was a huge difference.

    It will be really interesting to see what happens when Microsoft releases their physics API (think DirectX but for physics) - this should make everyones lives better.
  • johnsonx - Friday, May 5, 2006 - link

    Having downloaded and viewed the videos, my reaction is "so what?". I guess the physx sequence has a bit more crap flying around, but it's also quite alot slower (slower probably than just letting the CPU process the extra crap). It seems obvious that this game doesn't make proper use of the physx card, as I can't otherwise imagine that Aegia would have wasted so much time and money on it.
  • DerekWilson - Friday, May 5, 2006 - link

    quote:

    (slower probably than just letting the CPU process the extra crap)


    We'd really love to test that, but it is quite impossible to verify right now.
  • Walter Williams - Friday, May 5, 2006 - link

    Have you seen the CellFactor videos yet?
  • Spoonbender - Friday, May 5, 2006 - link

    Well, looking at the videos, I know what I prefer. The framerate hit with physx is definitely too noticeable. I'm curious to see how this turns out in other games, and with driver revisions and newer versions of the hardware (and probably pci-e would be a good idea as well)

    In any case, I read somewhere they weren't expecting these cards to evolve as fast as GPU's. Rather, it'd have a life cycle about the same as for soundcards. That seemed a bit encouraging to me. Having to fork out $300+ for yet another card every year or two didn't sound too attractive. But if I just have to buy it once, I guess it might catch on.
  • tk109 - Friday, May 5, 2006 - link

    With quad cores around the corner this really isn't looking to promising.

Log in

Don't have an account? Sign up now