PhysX

[Max Power]

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]

oh I see. Now I Understend

[Sethos]

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.

[James2464]

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]

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?

[Max Power]

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]

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]

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]

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]

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