AGEIA PhysX Technology and GPU Hardware

First off, here is the low down on the hardware as we know it. AGEIA, being the first and only consumer-oriented physics processor designer right now, has not given us as much in-depth technical detail as other hardware designers. We certainly understand the need to protect intellectual property, especially at this stage in the game, but this is what we know.

PhysX Hardware:
125 Million transistors
130nm manufacturing process
128MB 733MHz Data Rate GDDR3 RAM
128-bit memory bus interface
20 giga-instructions per second
2 Tb/sec internal memory bandwidth
"Dozens" of fully independent cores


There are quite a few things to note about this architecture. Even without knowing all the ins and outs, it is quite obvious that this chip will be a force to be reckoned with in the physics realm. A graphics card, even with a 512-bit internal bus running at core speed, has less than 350 Gb/sec internal bandwidth. There are also lots of restrictions on the way data moves around in a GPU. For instance, there is no way for a pixel shader to read a value, change it, and write it back to the same spot in local RAM. There are ways to deal with this when tackling physics, but making highly efficient use of nearly 6 times the internal bandwidth for the task at hand is a huge plus. CPUs aren't able to touch this type of internal bandwidth either. (Of course, we're talking about internal theoretical bandwidth, but the best we can do for now is relay what AGEIA has told us.)

Physics, as we noted in last years article, generally presents itself in sets of highly dependant small problems. Graphics has become sets of highly independent mathematically intense problems. It's not that GPUs can't be used to solve these problems where the input to one pixel is the output of another (performing multiple passes and making use of render-to-texture functionality is one obvious solution); it's just that much of the power of a GPU is mostly wasted when attempting to solve this type of problem. Making use of a great deal of independent processing units makes sense as well. In a GPU's SIMD architecture, pixel pipelines execute the same instructions on many different pixels. In physics, it is much more often the case that different things need to be done to every physical object in a scene, and it makes much more sense to attack the problem with a proper solution.

To be fair, NVIDIA and ATI are not arguing that they can compete with the physics processing power AGEIA is able to offer in the PhysX chip. The main selling points of physics on the GPU is that everyone who plays games (and would want a physics card) already has a graphics card. Solutions like Havok FX which use SM3.0 to implement physics calculations on the GPU are good ways to augment existing physics engines. These types of solutions will add a little more punch to what developers can do. This won't create a revolution, but it will get game developers to look harder at physics in the future, and that is a good thing. We have yet to see Havok FX or a competing solution in action, so we can't go into any detail on what to expect. However, it is obvious that a multi-GPU platform will be able to benefit from physics engines that make use of GPUs: there are plenty of cases where games are not able to take 100% advantage of both GPUs. In single GPU cases, there could still be a benefit, but the more graphically intensive a scene, the less room there is for the GPU to worry about anything else. We are certainly seeing titles coming out like Oblivion which are able to bring everything we throw at it to a crawl, so balance will certainly be an issue for Havok FX and similar solutions.

DirectX 10 will absolutely benefit AGEIA, NVIDIA, and ATI. For physics on GPU implementations, DX10 will decrease overhead significantly. State changes will be more efficient, and many more objects will be able to be sent to the GPU for processing every frame. This will obviously make it easier for GPUs to handle doing things other than graphics more efficiently. A little less obviously, PhysX hardware accelerated games will also benefit from a graphics standpoint. With the possibility for games to support orders of magnitude more rigid body objects under PhysX, overhead can become an issue when batching these objects to the GPU for rendering. This is a hard thing for us to test for explicitly, but it is easy to understand why it will be a problem when we have developers already complaining about the overhead issue.

While we know the PhysX part can handle 20 GIPS, this measure is likely simple independent instructions. We would really like to get a better idea of how much actual "work" this part can handle, but for now we'll have to settle for this ambiguous number and some real world performance. Let's take a look a the ASUS card and then take a look at the numbers.

Index ASUS Card and Test Configuration
Comments Locked

101 Comments

View All Comments

  • DerekWilson - Friday, May 5, 2006 - link

    We will be taking a look at CellFactor as soon as we can
  • Egglick - Friday, May 5, 2006 - link

    quote:

    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....

    You've certainly got a point there. Seeing as how a physics card is more like a co-processor than anything else, the PCI bus is probably even more of a limitation than it would be with a graphics card, where most of the textures can simply be loaded into the framebuffer beforehand.

    I still believe that the best option is to piggyback PPU's onto graphics cards. Not only does this allow them to share the MUCH higher bandwidth PCIe x16 slot, but it would also mean nearly instant communication between the physics chip and the GPU. The two chips could share the same framebuffer (RAM), as well as a cooling solution. This would lower costs significantly and increase performance.
  • DerekWilson - Friday, May 5, 2006 - link

    combo boards, while not impossible to make, are going to be much more complex. There could also be power issues as PhysX and today's GPUs require external power. It'd be cool to see, and it might speed up adoption, but I think its unlikely to happen given the roi to board makers.

    The framebuffer couldn't really be shared between the two parts either.
  • Rolphus - Friday, May 5, 2006 - link

    On page 2: "A graphics card, even with a 512-bit internal bus running at core speed, has less than 350 Mb/sec internal bandwidth." - er, I'm guessing that should read 350Gb/sec?
  • JarredWalton - Friday, May 5, 2006 - link

    Yes. Correcting....
  • Rolphus - Friday, May 5, 2006 - link

    Thanks for the quick response - I've just finished the article. It's good stuff, interesting analysis, and commentary and general subtext of "nice but not essential" is extremely useful.

    One random thing - is images.anandtech.com struggling, or is my browser just being a pain? I've been having trouble seeing a lot of the images in the article, needing various reloads to get them to show etc.
  • ATWindsor - Friday, May 5, 2006 - link

    Anandtech images doesn't work properly if you disable referer logging (pretty annoying), can that be the root of your problem? (adblock disabling it or something)
  • JarredWalton - Friday, May 5, 2006 - link

    Seems to be doing fine from our end. If you're at a company with a firewall or proxy, that could do some screwy stuff. We've also had reports from users that have firewall/browser settings configured to only show images from the source website - meaning since the images aren't from www.anandtech.com, they get blocked.

    As far as I know, both the images and the content are on the same physical server, but there are two different names. I could be wrong, as I don't have anything to do with the system administration. :)
  • Rolphus - Friday, May 5, 2006 - link

    Weird, seems to be fine now I've disabled AdBlock in Firefox... that'll teach me. It's not like I block any of AnandTech's ads anyway, apart from the intellitxt stuff - that drives me NUTS.
  • JarredWalton - Friday, May 5, 2006 - link

    Click the "About" link, then "IntelliTxt". You might be pleasantly surprised to know it can be turned off.

Log in

Don't have an account? Sign up now