No PhysX on OpenCL soon

OpenPhysics is CUDA based. The OpenCL port is in progress (or may be done by now). The reason you haven't heard of it is that it's still under development and no games use the hardware accelerated bits yet.

 

Being faster with 0% load is not nearly enough to be faster in the real world for those of us with quad cores.

Lets take the cause celebre, Batman, if the CPU implementation of PhysX ran 3 times faster (in all likelihood it would run quite a bit faster than that when properly optimized). Would it still be outperformed with the GPU implementation on a GTX285?

 

Did Nvidia lower the performance of PhysX when they acquired Ageia? Reading around a bit it seems that PhysX was widely regarded as being very fast, if not the fastest of the available libraries even back in 2007. A quick google turns up quite a few discussions among devs that are diametrically opposite to the assumptions being made in this thread.

The funny thing is that most of the comparisons revolve around the interface and easy of use. Not a single mention of performance differences (on the CPU).

In this recent thread there's mention of multi-threaded support in Havok though but no word on performance implications - http://www.gamedev.net/community/forums/topic.asp?topic_id=547097&whichpage=1

 

Overall, the game is liable to run better in that situation. Enabling PhysX in Sacred 2 made it unplayable for me, and likewise for Batman until I lowered other settings. And this is on a GTX 285 running alongside a i7 965.

 

Given the huge variability in performance for PC gaming they probably didn't intend to push the load into double digit percentages to begin with ... so speed was secondary to ease of use. It's only when it starts heavily impacting framerates that the speed becomes important and it took NVIDIA sponsorship for developers to start doing that.

Except Red Faction 2 perhaps (which didn't actually use Havok for destructible geometry).

 

I'm only talking about CPU PhysX which silent_guy mentioned. I.e. his argument was that PhysX - the SDK - has an advantage because it works on the CPU (too). I'm saying the performance of running it on the CPU is fundamental in knowing if this is truly an advantage in reality.

I have no word, but I'm hinting exactly what you said. People (that want PhysX in OpenCL) must understand the only way for nV to see a benefit in doing this is if there is an alternative. NV will face the music if their decision (NOW - without competition) turns out to be wrong, but you can't fault their reasoning.

Agreed. But that isn't an advantage of PhysX, it's just parity with other SDKs. It would be bad if PhysX didn't work on the CPU at all, yes.

You state, rightfully so, that we don't know exactly how PhysX-CPU relates to other SDKs/middleware (that run on the CPU) in terms of features & performance. Having said that, in my experience, Havok-based games with physics settings enabled run - significantly - faster than PhysX-based games with physics settings enabled when running on the CPU with comparable physics effects.

Like I mentioned to trini, this evaluation is incomplete if we don't also examine the workloads of these games but, anedoctaly, that's my experience. Depends on the games, developers, exact effects, quality fidelity of effects, etc. etc.

To be clear, I'm not making that argument so I'll leave that here.

 

See that doesn't mesh with what I'm reading though. Nvidia is definitely pushing GPU PhysX very hard in order to sell hardware. But it looks like PhysX was pretty popular and highly regarded by developers long before Nvidia got involved and that still seems to be the case today.

Yep, exactly. At the moment there is no impetus for them to either port PhysX to OpenCL or to expend effort on a faster CPU implementation. Both moves would require competition to force their hand. It's going to come eventually but they're going to milk any advantage they have until that time.

What does it mean for AMD? Who knows, I don't know what they're actively doing. So far it seems that they're hanging on the coat-tails of other people (Bullet, Havok) while dissing PhysX from the sidelines. They certainly can't honestly tout OpenCL as a unique advantage (though their marketing would indicate they think it is).

 

How does that contradict what I said?

 

In the googling that you reference is it clear whether it was widely regarded as fast on the PC (where AGEIA were working on their own hardware implementation which they were trying to sell), or just on consoles (where there was no option for proprietary hardware and no potential conflict of interest)?

Just curious. I don't know the answer myself.

As to it being a fast implementation on PC CPUs at the moment - it's hard to see how a highly parallel physics solver can be regarded as fast if it's only using one of the available CPU cores on a multi-core machine....

http://techreport.com/articles.x/17618/13

Unless the solver takes the basic step of parallelising across cores, debating the optimization (or lack thereof) of the lower levels of the implementation (effective use of SSE, for example) would hardly seem to matter.

 

Seems a lot of guys were hobbyists so I'm assuming PC.

Well sure, but I have a problem with doing that evaluation in a vacuum. IMO there are no absolutes in a competitive environment. The only thing that matters is whether you're faster than the other guy, not whether you're "fast" in an absolute sense based on an arbitrary set of criteria.

 

That's the question everyone's asking. No answer yet.

 

Not an unreasonable position - I guess we would need someone to send a bunch of similar workloads through the various competitors - I haven't seen anywhere where such a comparison has been officially carried out. It would be bizarre for implementations that are fully dependent on the CPU not to take advantage of all the CPU cores available, at which point it's hard to see how any implementation that only ever used one core would have much chance given the parallel nature of the task...

In the linked example the CPU implementation certainly doesn't seem "fast" in absolute terms. In relative terms I guess the only thing we could compare it to would be the GPU implementation at the same point. One interesting question is whether the CPU implementation could be competitive to the GPU one if it used all the cores.

The page states that when running CPU PhysX on a 5870 the low frame rates seen were about 3-4 fps (in this specific example).

When running a GTX295 (with one GPU dedicated to PhysX) the low frame rates seen were apparently about 10 fps (from the graph above). The low frame rate was 16 fps in the case where the second GPU was not dedicated to PhysX alone, but was allowed to time-slice between PhysX and rendering.

So if CPU PhysX performance scaling were linear with number of CPU cores used, and the other 3 CPU cores were actually being utilised it can be extrapolated that the low frame rates could fall into the 10-15 fps ballpark, which would be intriguingly close to matching the GTX 295 low frame rates (with dedicated PhysX).

Now there's much too much hand-waving going on here to draw any conclusions, and it would be interesting to see an equivalent study at low resolutions (to take rendering bottlenecks out of the picture), but it at least forms food for thought.

 

Does the fact that Physx's CPU implementation seems quite poor in the scheme of things mean that developers themselves cannot even think to use a real PhysX implementation as they would want consistant performance for all people, not just those with dedicated Nvidia GPUs for the job? Perhaps if the CPU implementation were to be better then developers would use more effects and thus the actual usefulness of having an Nvidia GPU for the task vs say a better CPU would be highlighted?

Essentially are Nvidia shooting their GPU/PPU implementation in the foot by having weak CPU performance? Also this can't be good PR as it looks to me and many others as a deliberate attempt to weaken the CPU runtime to make the GPU runtime look better.

 

Absolutely not, the only reason for the existence of PhysX (currently) is to sell graphics cards, if they allow a CPU implementation to get close to a GPU implementation (in a direct comparison) then they've lost.

I expect Nvidia to completely drop PhysX as soon as they don't think it's moving video cards anymore or has the potential to move video cards.

Regards,
SB

 

I thought their mantra for the longest time has been 'get a faster GPU instead of an expensive CPU for the best bang for the buck'. If they don't get PhysX used in decent implementations and the other non Nvidia centric physics implementations catch up they have lost as well.

 

They have to do a hell of a lot more than catch up. That's what the freebies and sponsorship are for ... when even Tim Sweeney just waves goodbye to having source code for so integral a part of his engine how can the lesser gods not be swayed by the lucre?

PS. as I said before, there really is no physics engine left with the same kind of reach which ATI could buy, optimize for themselves and give away for free ... Bullet can effectively not be made proprietary and Intel already got Havok. All the other players have fallen by the wayside long ago. Even if Havok was available for purchase in the end it would be a pretty piss poor situation for the rest of us to have two proprietary physics engines (with token support for the competition).

 

To me at this point it doesn't feel to me that PhysX is a physics engine! Whats the point in PhysX if the engine itself doesn't perform well enough to use it? If the effects are too small to justify even having the specialist add-in graphics card then what point is there to it all? To have real gameplay changing physics it needs to run on everyones machines, even those whom aren't running G80+ level hardware.

 

You seem to be confusing this with that.

 

Any CPU based physics I have seen is pretty bad, havok or otherwise. Playing mirrors edge with GPU phsyX was also unsatisfying (but I had an 8800) in that it had issues in the "museumy" room after the chat with sis.

I really do look forward to better physics calculations in general, but they will always have some sloppiness if they want to run fast enough to be useful. That should be their goal in general. Run fast enough first, and list exactly what hardware it will do so on. Reccomended settings in other words for CPU/GPU speed.