Nvidia has hit out at claims it's deliberately hobbling CPU PhysX, describing the reports as "factually inaccurate."
Speaking to THINQ, Nvidia's senior PR manager Bryan Del Rizzo said "any assertion that we are somehow hamstringing the CPU is patently false." Del Rizzo states that "Nvidia has and will continue to invest heavily on PhysX performance for all platforms - including CPU-only on the PC."
The response follows a recent report on the Web claiming CPU-PhysX was unnecessarily reliant on x87 instructions, rather than SSE. The report also suggested PhysX wasn't properly multi-threaded, with the test benchmarks showing a dependence on just one CPU core.
Let's start with multi-threading, which Del Rizzo says is readily available in CPU-PhysX, and "it's up to the developer to allocate threads as they see fit based on their needs." He points out that you only need to look at the scaling shown in the CPU tests in 3DMark Vantage and FluidMark (opens in new tab) to see that CPU-PhysX is perfectly capable of scaling performance as more cores are added.(opens in new tab)
However, he notes that the current PhysX 2.x code "dates back to a time when multi-core CPUs were somewhat of a rarity," explaining why CPU-PhysX isn't automatically multi-threaded by default. Yet despite this, Del Rizzo says it's easy enough for a developer to implement multi-threading in PhysX 2.x.
"There are some flags that control the use of 'worker threads' which perform functions in the rigid body pipeline," he says as an example, "and each NxScene runs in a separate thread."
The point appears to be moot in the long-term anyway, as Nvidia is apparently planning to introduce new automatic multi-threading features in the forthcoming PhysX 3.0 SDK.
This "uses a task-based approach that was developed in conjunction with our Apex product to add in more automatic support for multi-threading," explains Dell Rizzo.
The new SDK will automatically take advantage of however many cores are available, or the number of cores set by the developer, and will also provide the option of a "thread pool" from which "the physics simulation can draw resources that run across all cores."
Continued on Page 2...
In addition to the new multi-threading features, Del Rizzo also says "SSE will be turned on by default" in the new SDK. However, he notes that "not all developers want SSE enabled by default, because they still want support for older CPUs for their software versions." The original
Why do games developers still want to provide support for CPUs that are over ten years old? Del Rizzo says it's up to the game devs and what they demand, but he reiterates that it's definitely not a deliberate attempt to hobble CPU PhysX.The original report by Real World Technologies (opens in new tab) showed the Dark Basic PhysX Soft Body demo (below) made heavy use of x87 instructions, rather than SSE.(opens in new tab)
"We have hundreds of developers who are using PhysX in their applications," he says, "and we have a responsibility to ensure we do not break compatibility with any platforms once they have shipped. Historically, we couldn't become dependent on any hardware feature like SSE after the first revision has shipped."
He also points out that the PhysX 2.x SDK does feature at least some SSE code, and SSE isn't necessarily faster anyway. "We have found sometimes non-SSE code can result in higher performance than SSE vector code in many situations," he says. However, in the long-term SSE will apparently be the way forward for CPU-PhysX in the long term. "We will continue to use SSE and we plan to enable it by default in future releases," says Del Rizzo.
In short, it looks as though there's a fair bit of legacy detritus in the current PhysX SDK, partly due to the demands from games devs. Nevertheless, there are already ways in which developers can use multi-threading in CPU-PhysX, and full SSE support and improved multi-threading will be coming shortly.
This doesn't look like a company trying to deliberately cripple CPU-PhysX to make its GPUs look good.