Jump to content

Unity can take advantage of GPU Accelerated Physics with NVidia PhysX


/not/pol/

Recommended Posts

Is it possible for a mod to be made that can shift some of the physics over to the (heavily underutilized by unity games) GPU. Unity 5 Has support for it but i want to know if its possible for a mod to do it or if squad needs to add this function in for nvidia cards

Edited by /not/pol/
Link to comment
Share on other sites

I found an old topic about it:

 

But personally, I don't think it will make a lot of a difference, like doubling your FPS. (when your rig is balanced. WIth an underpowered CPU and overpowered GPU, slight change it will)
GPU aren't made for the calculation bit of a game. I think you only get a difference of 10% to 25%...
Also, from what I understand, it is more to help the GPU to render things; "It allows better simulation of things like smoke/fog, fire, water, cloth and bounding/falling/rolling objects giving games that support it a more detailed and realistic look and feel." quote from coozie7 at www.tomshardware.co.u 

I can be wrong, maybe some other guys here have knowledge of the whole thing. :) 

Edited by DrLicor
Link to comment
Share on other sites

@/not/pol/ You need to understand the difference between CPUs and GPUs.

A CPU has a small number - usually 2 to 6 - of really capable, intelligent, super high clocked cores. It can do anything you throw at it, and it can do it better and faster than any other thing inside your computer, but it can only do a few things at once.

Meanwhile, a GPU has a ridiculously large number - usually over a thousand - of extremely simple, dumb and moderately clocked cores. It can do only a limited number of specialized tasks, and it can't do them very fast. Complex tasks need to be emulated by breaking them down into simple tasks, which makes their execution even slower and less efficient. However, the GPU can do an extremely large number of these tasks at the same time.

The first takeaway is that each of these two units is better suited for certain tasks. Give a single, very complex task to a GPU, and it will perform really badly, because it will struggle with the difficulty while 99% of its hardware lies unused. Give a ton of super simple tasks to a CPU, and it will perform really badly, because it has to go through them one after the other. In order to unlock the full potential of a CPU, you need to give it a task that's worthy of its abilities; in order to unlock the full potential of a GPU, you need to give it a massively parallel heap of simple tasks.

So if you want to accelerate the physics simulation of KSP via the GPU, you need to ask yourself two questions: one, is the task simple? And two, is the task massively parallel?

Regarding question one: physics simulation is largely maths. Pure maths is a simple task. GPUs are good at pure maths. This means that the answer is positive.

Regarding question two: physics simulation attempts to determine the action and reaction of every member of a system of actors. There are different kinds of actor systems: one in which each actor is affected by outside influences alone, and one in which the way each actor behaves is strongly dependant on the way all other actors behave. And example of the former is the simulation of smoke, cloth or liquid. Each particle or sub-area is influenced by things like gravity and wind, but do not care much about what other actors are doing. This means that each individual actor can have the vast majority of its math calculated individually. If you have ten thousand particles, you can do ten thousand times the same math in parallel.

KSP, however, is an example of the latter. Each actor (in this case, a part on a vessel) is strongly dependant on the other actors. Specifically, a part interacts directly with the part it is attached to, and the parts attached to itself; all of which also do this, causing a chain reaction of interdependence without a clear start or end. A part can begin oscillating around its own joints because a part way up or down the stack, which the part in question isn't even connected to, isn't properly strutted. Then, you have vessel-wide effects, such as: is this part shielded from aerodynamic drag, or is it exposed, based on the geometry of the vessel as a whole? And all of these facts can spontaneously change everytime the player clicks the mouse or hits the spacebar, or even as a result of an environmental event.

This is why the physics simulation of a single ship in KSP is single-threaded. That is, only one core at a time takes care of one whole ship at a time, to ensure that the result of the physics simulation accounts for all of the parts and all of their interdependence at the same time. If you decided to treat every part as an individual physics object, and have it calculated in an individual thread on an individual core, then that core would have to look a the state of the vessel from the last frame, and take all of the relevant interdependence parameters from there. It would then calculate its part's behavior based on this 'best guess' of the situation around it. But it uses past data, not current data, and therefore this only works fine if nothing changes on the vessel. However, between that last frame and the current one that's being calculated, the player could be starting a steering input, or throttling up, or even staging. The individually calculated part would be unable to account for the fact that a different part is suddenly exerting thrust or torque, or that the vessel just lost half its mass, or that the decoupler force is effecting a sudden attitude shift. Therefore the independent calculation of the part will introduce a tiny, imperceptible error into the finished frame. And then, the next frame starts, and each individual core must again make a best guess for the vessel's situation based on past data. But the past data now has an error in it, which causes false input conditions, which causes the output to be wrong again - likely more wrong than before. It gets worse with each frame, and it's really hard to recover from. So the answer to the question "is it massively parallel" is negative. This is not something you can easily split up.

Perhaps this problem could be solved by introducing management processes which track the vessel state and issue the correct input conditions to the calculation units on the GPU. But then, what did you gain? In order to avoid the CPU doing work, you just introduced a new job for the CPU to do, which is largely identical to the job you wanted it to avoid doing in the first place! Remember, math is easy. It's the tracking and consistency keeping that's the hard part. So you gain almost nothing by splitting off the easy part. However, the resulting code would be orders of magnitude more complex to troubleshoot, bugfix and maintain. Everytime the physics simulation did something it's not supposed to do, you'd need to try and tell apart the case where it's actually doing something wrong, and the case where one parallel calculation unit among hundreds is simply not properly synched. These things look virtually identical. It's extremely troublesome to deal with, and certainly not worth the minor advantage that may or may not even manifest. Would you accept 10% more FPS for a less stable, less predictable physics engine combined with greatly increased development and bugfixing times? I'd guess not!

So KSP does the next-best thing it can. It bundles the physics simulation of a single ship into a single thread that keeps track of itself in the best possible manner, and then gives that complex task to the unit which is most suited to complex tasks and runs at the highest individual clock speed: a CPU core.

Link to comment
Share on other sites

5 hours ago, Streetwind said:

@/not/pol/ You need to understand the difference between CPUs and GPUs.

A CPU has a small number - usually 2 to 6 - of really capable, intelligent, super high clocked cores. It can do anything you throw at it, and it can do it better and faster than any other thing inside your computer, but it can only do a few things at once.

Meanwhile, a GPU has a ridiculously large number - usually over a thousand - of extremely simple, dumb and moderately clocked cores. It can do only a limited number of specialized tasks, and it can't do them very fast. Complex tasks need to be emulated by breaking them down into simple tasks, which makes their execution even slower and less efficient. However, the GPU can do an extremely large number of these tasks at the same time.

The first takeaway is that each of these two units is better suited for certain tasks. Give a single, very complex task to a GPU, and it will perform really badly, because it will struggle with the difficulty while 99% of its hardware lies unused. Give a ton of super simple tasks to a CPU, and it will perform really badly, because it has to go through them one after the other. In order to unlock the full potential of a CPU, you need to give it a task that's worthy of its abilities; in order to unlock the full potential of a GPU, you need to give it a massively parallel heap of simple tasks.

So if you want to accelerate the physics simulation of KSP via the GPU, you need to ask yourself two questions: one, is the task simple? And two, is the task massively parallel?

Regarding question one: physics simulation is largely maths. Pure maths is a simple task. GPUs are good at pure maths. This means that the answer is positive.

Regarding question two: physics simulation attempts to determine the action and reaction of every member of a system of actors. There are different kinds of actor systems: one in which each actor is affected by outside influences alone, and one in which the way each actor behaves is strongly dependant on the way all other actors behave. And example of the former is the simulation of smoke, cloth or liquid. Each particle or sub-area is influenced by things like gravity and wind, but do not care much about what other actors are doing. This means that each individual actor can have the vast majority of its math calculated individually. If you have ten thousand particles, you can do ten thousand times the same math in parallel.

KSP, however, is an example of the latter. Each actor (in this case, a part on a vessel) is strongly dependant on the other actors. Specifically, a part interacts directly with the part it is attached to, and the parts attached to itself; all of which also do this, causing a chain reaction of interdependence without a clear start or end. A part can begin oscillating around its own joints because a part way up or down the stack, which the part in question isn't even connected to, isn't properly strutted. Then, you have vessel-wide effects, such as: is this part shielded from aerodynamic drag, or is it exposed, based on the geometry of the vessel as a whole? And all of these facts can spontaneously change everytime the player clicks the mouse or hits the spacebar, or even as a result of an environmental event.

This is why the physics simulation of a single ship in KSP is single-threaded. That is, only one core at a time takes care of one whole ship at a time, to ensure that the result of the physics simulation accounts for all of the parts and all of their interdependence at the same time. If you decided to treat every part as an individual physics object, and have it calculated in an individual thread on an individual core, then that core would have to look a the state of the vessel from the last frame, and take all of the relevant interdependence parameters from there. It would then calculate its part's behavior based on this 'best guess' of the situation around it. But it uses past data, not current data, and therefore this only works fine if nothing changes on the vessel. However, between that last frame and the current one that's being calculated, the player could be starting a steering input, or throttling up, or even staging. The individually calculated part would be unable to account for the fact that a different part is suddenly exerting thrust or torque, or that the vessel just lost half its mass, or that the decoupler force is effecting a sudden attitude shift. Therefore the independent calculation of the part will introduce a tiny, imperceptible error into the finished frame. And then, the next frame starts, and each individual core must again make a best guess for the vessel's situation based on past data. But the past data now has an error in it, which causes false input conditions, which causes the output to be wrong again - likely more wrong than before. It gets worse with each frame, and it's really hard to recover from. So the answer to the question "is it massively parallel" is negative. This is not something you can easily split up.

Perhaps this problem could be solved by introducing management processes which track the vessel state and issue the correct input conditions to the calculation units on the GPU. But then, what did you gain? In order to avoid the CPU doing work, you just introduced a new job for the CPU to do, which is largely identical to the job you wanted it to avoid doing in the first place! Remember, math is easy. It's the tracking and consistency keeping that's the hard part. So you gain almost nothing by splitting off the easy part. However, the resulting code would be orders of magnitude more complex to troubleshoot, bugfix and maintain. Everytime the physics simulation did something it's not supposed to do, you'd need to try and tell apart the case where it's actually doing something wrong, and the case where one parallel calculation unit among hundreds is simply not properly synched. These things look virtually identical. It's extremely troublesome to deal with, and certainly not worth the minor advantage that may or may not even manifest. Would you accept 10% more FPS for a less stable, less predictable physics engine combined with greatly increased development and bugfixing times? I'd guess not!

So KSP does the next-best thing it can. It bundles the physics simulation of a single ship into a single thread that keeps track of itself in the best possible manner, and then gives that complex task to the unit which is most suited to complex tasks and runs at the highest individual clock speed: a CPU core.

You missed the point. i was just asking if it was possible to implement PhsyX into KSP via a mod. since PhsyX is supported by Unity for physics acceleration. im going to take your answer as a no, and next time please put a TL;DR, although this is a good in depth explanation when someone asks why KSP Physics are single threaded.

Edited by /not/pol/
Link to comment
Share on other sites

Graphics cards (GPUs -- graphics processing units) are immensely powerful supercomputers on a chip.  But like other supercomputers, they achieve their processing power through massively parallel computations.  Saying "Graphics cards are good for rendering but not much else" is not correct.  Any problem that is suitable for a supercomputer (i.e., weather forecasting) could be done on GPUs.  There are many real-world applications out there that take full advantage of the processing power of GPUs.  (Google "CUDA" or "OpenCL" for more information.)

Whether or not KSP's physics computations could be done on a GPU depends on how easily the code lends itself to massive parallel processing.  I suspect that it is not a good fit for running on a GPU.  This isn't because GPU's are dumb, or limited, but because the basic problem isn't one that can be efficiently split into thousands of parts.

Link to comment
Share on other sites

It could be done. It would be a pain to do so. And it is not done in Unity. As far as I know the Physx bundled in Unity is not built with GPU accel enabled. If you have an article that says otherwise I would love to read it.

And it most likely would not improve perf all that much given how ksp vessel are made (Vessel are full of joint and that (AFAIK) prevents parallel processing. GPU physic does fine with many distinct object)

Link to comment
Share on other sites

6 hours ago, sarbian said:

It could be done. It would be a pain to do so. And it is not done in Unity. As far as I know the Physx bundled in Unity is not built with GPU accel enabled. If you have an article that says otherwise I would love to read it.

And it most likely would not improve perf all that much given how ksp vessel are made (Vessel are full of joint and that (AFAIK) prevents parallel processing. GPU physic does fine with many distinct object)

Unity 5 does have GPU Accelerated physics on CUDA but it is very limited.  Cloth rendering only AFAIK.  So they could make the flag at KSC more realistic, but that's about it.

Link to comment
Share on other sites

8 hours ago, Alshain said:

Unity 5 does have GPU Accelerated physics on CUDA but it is very limited.  Cloth rendering only AFAIK.  So they could make the flag at KSC more realistic, but that's about it.

Physx has flags to push more of the physics in the GPU and those are not enabled :)

Edit : on 3.4, and Unity is still on 3.3...

Edited by sarbian
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...