Final Thoughts

More than each other however, there's one other thing that threatens the camps offering hardware physics acceleration: the CPU. Recent years have seen CPUs going multi-core, first with two cores and this week has seen the introduction of the (practically) cheap four core Q6600 from Intel. Being embarrassingly parallel in nature, physics simulations aren't just a good match for GPUs/PPUs with their sub-processors, but a logical fit for multi-core CPUs.

While both AMD and Intel have stated that they intend to avoid getting in to a core war as a replacement for the MHZ race, all signs point to a core war taking place for the foreseeable future, with Intel going so far as to experiment on 80-core designs. With the monolithic nature of games these cores will all be put to work in one way or another, and what better way than physics simulations which can be split nicely among cores? While not the floating point power houses that dedicated processors are, with multiple cores CPUs can realistically keep the gap closed well enough to prevent dedicated processors from being viable for consumers. In some ways Havok is already betting on this with their software physics middleware already designed to scale well with additional CPU cores.

Furthermore the CPU manufactures (Intel in particular) have a hefty lead in bringing manufacturing processes to market and can exploit this to further keep the gap closed versus GPUs(80nm at the high end) and the PhysX PPU(130nm). All of this leads to multi-core CPUs being an effective and low-risk way of going about physics instead of a riskier dedicated physics processor. For flagship titles developers may go the extra mile on physics, on most other titles we wouldn't expect such an effort.

So what does all this mean for hardware physics acceleration overall? In spite of the original battle being between the PPU and the GPU, we're wondering just how much longer Ageia's PhysX software/hardware package can hold out before losing the war of attrition, at the risk of becoming marginalized before any decent software library even comes out. Barring a near-miracle, we're ready to write off the PPU as a piece of impressive hardware that provided a technological solution to a problem few people ended up concerned about.

The battle that's shaping up looks to be between the GPU and the CPU, with both sides having the pockets and the manufacturing technology to play for keeps. The CPU is the safe bet for a developer, so it's largely up to NVIDIA to push the GPU as a viable physics solution (AMD has so far not taken a proactive approach with GPU physics outside of Havok FX). We know that the GPU can be a viable solution for second-order physics, but what we're really interested in is first-order physics. So far this remains unproven as far as gaming is concerned, as current GPGPU projects working with physics are all doing so as high performance computing applications that don't use simultaneous graphics rendering.

Without an idea of how well a GPU will perform with simultaneous tasks, it's too early to call to call the victor. At the very least, developers won't wait forever and the GPU camp will need to prove that their respective GPGPU interfaces can provide enough processing power to justify the cost of developing separate physics systems for each GPU line. However given the trend to move things back on to the CPU through projects such as AMD's forthcoming Fusion technology, there's an awful lot in favor of status quo.

PhysX
Comments Locked

32 Comments

View All Comments

  • Sunrise089 - Wednesday, July 25, 2007 - link

    Plus since most titles are GPU limited (and with more cores and very overclockable Intel chips will only become more so) it might be better to send the Physics stuff to the idle CPU cores rather than the saturated GPU, regardless of what offers ideal performance.
  • KeithP - Wednesday, July 25, 2007 - link

    We need a standard API so that a variety of solutions would be possible. All a manufacturer would then need to do is write drivers to interface with their hardware.

    -KeithP

Log in

Don't have an account? Sign up now