PhysX

[-=Grunt=- 10]

At how fast technology is going, I imagine in 5-10 years, games will have that kind of physics. Real-time hair, cloth movement and destruction physics.

[onlyrazor 11]

At how fast technology is going, I imagine in 5-10 years, games will have that kind of physics. Real-time hair, cloth movement and destruction physics.

In that case, wait for Arma 6/7.

[max power 21]

In that case, wait for Arma 6/7.

Slightly OT, but I think it would be interesting to do a 'next arma' retrospective, to see what the community has suggested may come out in future armas in the past, and compare that with the versions as they come out. I wonder what people back in 2006, say, said about the features of some speculative 'arma 3'.

[mr.g-c 6]

Slightly OT, but I think it would be interesting to do a 'next arma' retrospective, to see what the community has suggested may come out in future armas in the past, and compare that with the versions as they come out. I wonder what people back in 2006, say, said about the features of some speculative 'arma 3'.

I like the idea :-)

[Choki 10]

I think PhysX will be an inefficient way to handle on-vehicle mobility, particularly when you imagine the lag involved during MP games. IMO the better way to handle such a feature would be to juggle the world context around a bit - make the vehicle a static "world" while animating the external world around it. I think this kind of happens already which is why you get the outside view jumping about when you're a MP passenger. But if this notion could be extended to allowing people to wander around a vehicle surface it might be a nice feature. However there's a sort of grey area with this idea when you think about large boats, or any open vehicle, what constitutes the player's local "world". It might simply create more issues than it would ultimately solve.

Physx=lag? I played more thant 20 games online whit physx and 0 lag.

[max power 21]

Physx=lag?

Seems like a classic strawman argument. That is a gross oversimplification of both what Dmarkwick said, and what the situation is. Physx implementations are like anything else. I have a powerful (relatively) computer in my house. I don't boot it up everytime I have to do simple math, even though it is quite capable of doing that. Just because you have physx in a game doesn't mean you use its full capability to simulate every little thing.

[Choki 10]

oh I see. Now I Understend

[sethos 2]

Seems like a classic strawman argument. That is a gross oversimplification of both what Dmarkwick said, and what the situation is. Physx implementations are like anything else. I have a powerful (relatively) computer in my house. I don't boot it up everytime I have to do simple math, even though it is quite capable of doing that. Just because you have physx in a game doesn't mean you use its full capability to simulate every little thing.

But PhysX, if CPU bound in this case could use resources that you'd otherwise use on rendering the game. Right now, with an i7 2600k I'm actually CPU limited in ArmA 2 with my settings ( On certain maps, certain situations ), as in it's using the available CPU cycles. Wouldn't any excess overhead needed for PhysX in such a situation lower the framerate to use cycles for PhysX instead? This is an honest question, I don't know. Maybe PhysX is using different threads or calls from the CPU that isn't allocated to the game itself.

This obviously wasn't meant for the 'simulating everything' argument, was merely going at the core of PhysX = Lag ( Lower FPS? ) and the overhead.

Edited April 23, 2012 by Sethos

[james2464 176]

But PhysX, if CPU bound in this case could use resources that you'd otherwise use on rendering the game. Right now, with an i7 2600k I'm actually CPU limited in ArmA 2 with my settings ( On certain maps, certain situations ), as in it's using the available CPU cycles. Wouldn't any excess overhead needed for PhysX in such a situation lower the framerate to use cycles for PhysX instead? This is an honest question, I don't know. Maybe PhysX is using different threads or calls from the CPU that isn't allocated to the game itself.

Are you sure you're CPU limited? I have a 2500K overclocked to 4.5ghz, very stable and I'm GPU limited with the GTX 550TI.

I doubt you're CPU limited unless you don't know how to overclock, what is your GPU?

[sethos 2]

Are you sure you're CPU limited? I have a 2500K overclocked to 4.5ghz, very stable and I'm GPU limited with the GTX 550TI.

I doubt you're CPU limited unless you don't know how to overclock, what is your GPU?

I have a GTX 680 4GB and on maps like Zargabad, you can look at a point where there's loads of buildings either in view or being rendered and it'll maintain 53 FPS. I can add AA, change 3D resolution ( Anything handled by the GPU ) and it'll still maintain 53 FPS. I can then overclock the CPU even further and it'll inch closer to the 60FPS. Obviously, when you have a large-scale warfare scenario with a good number of AIs, the CPU will also be a limiting factor. So it would be a shame for PhysX to eat up CPU cycles when you want to do large scale warfare that requires that extra CPU.

My game is running 60FPS ( Vsync locked of course ) 95% of the time but Zargabad seems to be very CPU bound, a map I really play a lot.

I currently have a second GTX 680 4GB for an upcoming build so I'll go SLI, meaning my upcoming CPU will probably be under the most pressure from here on out. So any additional CPU cycles used by PhysX will cost me FPS in the long run.¨

Also, has it been mentioned if it's possible to offload the CPU bound PhysX calculations to Nvidia's CUDA or does it need specific instructions before that will process it?

Edited April 23, 2012 by Sethos

[max power 21]

But PhysX, if CPU bound in this case could use resources that you'd otherwise use on rendering the game. Right now, with an i7 2600k I'm actually CPU limited in ArmA 2 with my settings ( On certain maps, certain situations ), as in it's using the available CPU cycles. Wouldn't any excess overhead needed for PhysX in such a situation lower the framerate to use cycles for PhysX instead? This is an honest question, I don't know. Maybe PhysX is using different threads or calls from the CPU that isn't allocated to the game itself.

This obviously wasn't meant for the 'simulating everything' argument, was merely going at the core of PhysX = Lag ( Lower FPS? ) and the overhead.

I don't know anything specific about physx itself, but i think increased complexity = increased resource load can be applied fairly generally. Whether or not that leads to lag depends on what kind of resources you have to use.

[james2464 176]

I have a GTX 680 4GB and on maps like Zargabad, you can look at a point where there's loads of buildings either in view or being rendered and it'll maintain 53 FPS. I can add AA, change 3D resolution ( Anything handled by the GPU ) and it'll still maintain 53 FPS. I can then overclock the CPU even further and it'll inch closer to the 60FPS. Obviously, when you have a large-scale warfare scenario with a good number of AIs, the CPU will also be a limiting factor. So it would be a shame for PhysX to eat up CPU cycles when you want to do large scale warfare that requires that extra CPU.

My game is running 60FPS ( Vsync locked of course ) 95% of the time but Zargabad seems to be very CPU bound, a map I really play a lot.

I currently have a second GTX 680 4GB for an upcoming build so I'll go SLI, meaning my upcoming CPU will probably be under the most pressure from here on out. So any additional CPU cycles used by PhysX will cost me FPS in the long run.¨

Also, has it been mentioned if it's possible to offload the CPU bound PhysX calculations to Nvidia's CUDA or does it need specific instructions before that will process it?

Oh you think 53-60fps is bottle-necked... hehe yeah I guess you can get CPU limits with a 680GTX, I think when Arma 3 comes around you can pick up the Z77 or X79 and a 3770K depending on performance figures.

SLI should do the trick I would think, but who knows how physx will affect the CPU or performance, imo I think it will be marginal.

[sethos 2]

Oh you think 53-60fps is bottle-necked... hehe yeah I guess you can get CPU limits with a 680GTX, I think when Arma 3 comes around you can pick up the Z77 or X79 and a 3770K depending on performance figures.

SLI should do the trick I would think, but who knows how physx will affect the CPU or performance, imo I think it will be marginal.

Already picked up an X79 Motherboard and a 3930k ( Maybe ArmA 3 will utilize 6 cores? Probably not :P ) - The 3770k performance figures and temperatures were really underwhelming, borderline a step back. So I'll wait until IB-E until my next big upgrade.

But as I said, GPU overhead in my case will be huge but the VBS engine is also very reliant on CPU power. So I'm naturally concerned over anything that will tap into additional CPU cycles such as PhysX.

I just remember in this or the previous thread, that the entire discussion was based off PhysX in ArmA would first be Nvidia proprietary, then concerns that CPU PhysX for AMD users would be a severe performance hog, then a mod / developer mentioned it'd be strictly CPU PhysX and everyone sighed in relief. Now I'm just curious whether it IS 'strictly CPU' or you can offload these PhysX calls to the CUDA cores with Nvidia, as the CUDA cores are there for the taking in the first place and not being used. Sure the impact would most likely be marginal ( 5FPS plus minus? ) but as a performance hungry man, 3-5FPS lost is a travesty :P

However reading up on VBS2 updates, it mentioned CUDA could be used - So I'm just looking for some clarification on ArmA 3 - Strictly CPU or optional CUDA.

[james2464 176]

Already picked up an X79 Motherboard and a 3930k ( Maybe ArmA 3 will utilize 6 cores? Probably not :P ) - The 3770k performance figures and temperatures were really underwhelming, borderline a step back. So I'll wait until IB-E until my next big upgrade.

But as I said, GPU overhead in my case will be huge but the VBS engine is also very reliant on CPU power. So I'm naturally concerned over anything that will tap into additional CPU cycles such as PhysX.

I just remember in this or the previous thread, that the entire discussion was based off PhysX in ArmA would first be Nvidia proprietary, then concerns that CPU PhysX for AMD users would be a severe performance hog, then a mod / developer mentioned it'd be strictly CPU PhysX and everyone sighed in relief. Now I'm just curious whether it IS 'strictly CPU' or you can offload these PhysX calls to the CUDA cores with Nvidia, as the CUDA cores are there for the taking in the first place and not being used. Sure the impact would most likely be marginal ( 5FPS plus minus? ) but as a performance hungry man, 3-5FPS lost is a travesty :P

However reading up on VBS2 updates, it mentioned CUDA could be used - So I'm just looking for some clarification on ArmA 3 - Strictly CPU or optional CUDA.

That'll be a nice setup, the 3770K performance was disappointing but they were engineering samples, this CPU was overclocked to 7Ghz+ on nitrogen so perhaps there's headroom for a 5Ghz on watercooling with the retail release, I don't know.

It will be interesting to see if Physx turns into a driver vs. driver race, I think it's a safe bet to buy Nvidia but i'm totally biased :P As for CUDA cores I know very little about them, I should read up.

[PuFu 4600]

But PhysX, if CPU bound in this case could use resources that you'd otherwise use on rendering the game.

Havok physics is CPU bound afaik, and no one ever complain about it. So is bullet.

Thing is, for some weird reason, ppl are mixing up the game phisics engine with additional physics controlled effects like cloth and particle simulation. AFAIK, for A3, nvidia physx will handle ONLY the ragdolls even though it will be implemented at the core, meaning that the world could behave a bit more real to life (no more 2000 ton tank in order not to skid and so forth).

That said, I would expect a better performance out of current generation hardware. Remember what was the norm back in the day A2 was released and what it is today, for both CPU and GPUs. Might also have something to do with going a notch up towards DX11 (especially when it comes down to the ratio of pretty gfx vs rendering performance).

For rendering via CPU, afaik the only rendering element bound to CPU (and hdd access speed) are the draw calls -> viewdistance.

VBS engine is also very reliant on CPU power. So I'm naturally concerned over anything that will tap into additional CPU cycles such as PhysX.

VBS runs on current generation of RV engine - ArrowHead.

Maybe is me hoping for the best regarding RVX engine in A3...

Edited April 23, 2012 by PuFu

[maddogx 13]

Regarding PhysX vs. performance, consider the following:

- The current iteration of the RV engine already has a physics engine. This engine is run on the CPU and thus already takes up some amount of processing power to calculate object movement, collisions, friction etc.

- PhysX is, at its core, just another physics engine. Its basic functions (object movement, collisions, friction) are also calculated on the CPU.

- From what I understand, PhysX will replace the current physics engine, not "extend" it. Essentially the engine is trading one set of calculations for another, not just adding extra.

- PhysX may be more efficient at the basic collision and friction calculations, meaning performance could even be improved in some respects.

- New engine features introduced by PhysX (like ragdoll) will probably add more CPU workload, but this can be optimized and made scalable.

[sethos 2]

Regarding PhysX vs. performance, consider the following:

- The current iteration of the RV engine already has a physics engine. This engine is run on the CPU and thus already takes up some amount of processing power to calculate object movement, collisions, friction etc.

- PhysX is, at its core, just another physics engine. Its basic functions (object movement, collisions, friction) are also calculated on the CPU.

- From what I understand, PhysX will replace the current physics engine, not "extend" it. Essentially the engine is trading one set of calculations for another, not just adding extra.

- PhysX may be more efficient at the basic collision and friction calculations, meaning performance could even be improved in some respects.

- New engine features introduced by PhysX (like ragdoll) will probably add more CPU workload, but this can be optimized and made scalable.

Those are excellent points but the key difference between PhysX and every other iteration of physics engine out there, proprietary or third party and PhysX is that PhysX

can in fact be offloaded to a GPU with no performance hit, so I'm just asking whether BI will make that possible or are they completely disregarding CUDA and making it CPU bound for

everyone. Because they seem very keen on optimization this time around and allowing Nvidia users a slight performance boost by offloading some CPU work to the GPU would be a good start.

Sure we can be theoretical but PhysX calculations aren't cheap, even the basic stuff and what ArmA has currently is next to no physics, but I'd still prefer knowing I can get all the physX features

for 'free', in terms of resource usage.

Oh and just to be clear, I'm not advocating against the use of PhsyX whatsoever I'm just advocating for the option of Nvidia users being allowed to offload PhysX for a ( possible ) performance boost.

Edited April 23, 2012 by Sethos

[maddogx 13]

PhysX can in fact be offloaded to a GPU with no performance hit

A common misconception. Only some advanced PhysX featues like cloth and fluid simulation can be off-loaded to the GPU via CUDA. All the standard stuff I mentioned above is processed on the CPU.

[sethos 2]

A common misconception. Only some advanced PhysX featues like cloth and fluid simulation can be off-loaded to the GPU via CUDA. All the standard stuff I mentioned above is processed on the CPU.

Ah I see, you learn something new every day :)

Thank you.

[dmarkwick 261]

I'd still prefer knowing I can get all the physX features

for 'free', in terms of resource usage.

As a quad-core CPU user, I note that even in very heavy ArmA2 missions, only about 25% of my CPU is being stressed. I would guess that among the candidates for threading, that PhysX would be a prime candidate :)

[Leon86 13]

Arma 2 uses over 50% on my quad, and physics isn't what bars better multithreading, it's dx9.

[Choki 10]

and what is the nvidia work on this?

[PuFu 4600]

and what is the nvidia work on this?

if i got the question correct, my answer would be: none.

if not, might wanna rephrase.

[Choki 10]

I mean. The physx are from nvidia or not?

[froggyluv 2136]

I mean. The physx are from nvidia or not?

It will be run from the CPU.