PhysX GPU support?!

Any idea when we will see PhysX GPU support in Unity?

Is it on the roadmap for V3?

 

bet on never
as neither ATI, Intel, OSX, iphone, android, webplayer would support it but any windows user (really any, independent of webplayer, ati, intel or nvidia) you have to install the PhysX GPU driver

 

I would find it very useful for my Windows work and a far as the last years have shown, they gave up the "it only will be implemented, if it runs on all platforms" mantra already. I think GPU physics acceleration is missing in Unity, the sooner, the better.

 

it has not even anything to do with platform.
On windows it works for < 50% of all users as it is NVIDIA hardware only. Neither intel nor ATI can use it.
But both of them must install the physx driver or will not even be able to run your game / the unity webplayer.

thats why I basically take it for granted that it will rather not happen on either of the two, only on x360 and ps3 where it is always "HW accelerated"

 

Who says that you always want to target all platforms/users?

An example: You have client wok where you have a lot of physics calculations and this machine stays at the client's place(s). Same for a functionality which is only available on the intranet for a specific group.

Beside of this even a few of the bigger games now support it and last but not least it might be just for your own amusement.

 

It has nothing to do with what you want.

You either use the dynamic version with HW support or you don't use it. You can't enable the physx driver requirement through a switch, its an integral part of the runtime.

That means if they decide to add it every single game created WILL require the driver independent on if you use HW or not actually

 

I don't know if i understad you properly here.

If you use a windows machine with a PhysX ready GPU by nVIDIA, will the current version of Unity then run the physics on the GPU or not?

 

No it will not.

As mentioned, for Unity to offer that, every single windows user who wants to use unity or play a unity generated game (standalone or webplayer) would have to install the PhysX Drivers.
This is independent on if this user can even use HW acceleration (so this also holds for NVIDIA gpus prior the 8400, this holds for all intel as well as all ATI).


There is a reason why there are so few PhysX HW accelerated games out there

 

When I first started working in UE3 I had an ATI GPU and I didn't have to install any PhysX drivers to run the game, Unless it was installed with the Unreal installation. If it was, then Surely Unity could do the same thing.

 

@Dreamora
So fine, this matches with my understanding of Unity.

Now back to the original question: Why can't it be supported?

If you have the proper drivers and hardware installed you could take the GPU and if not the CPU route.

 

You seem to missunderstand.
The PhysX driver is an additional software package you must install, it is not your regular graphic card driver.

It would need to be installed on every single windows machine that wants to play back any unity content at all, independent on if HW physics is activated on the project or not, independent on if physics is even used, independent on if the HW can support it at all. Also aside of those with NVIDIA DX10+ hw that enabled the usage of their gpu for physx in the driver panel, nobody would gain anything from this aside of the useless driver install etc.

This for casual gamers is a big no go and on the webplayer is suicide as it will ensure that no further installations will happen.
Also it logically would require all to be on admin accounts, AGAIN (after that was removed as webplayer install requirement with 2.6)


If you want physx hw support use a technology that has no proper websupport and installs like T3D but don't expect flash or unity with a general webplayer and wide support to offer it cause for them it would be a major step backward.

HW physics support won't happen until the physx hw acceleration is done through OpenCL or until UT replaces physx with havok or bullet

 

No, actually it seems that you haven't understood the reason why i was asking for it.

Maybe rereading what i already wrote above helps. I'm not after your examples, where it does not make so much sense, i'm after my examples where it makes quite a lot of sense and where the support of it is missing.

 

I fully understand why you are asking for it.
But it doesn't change the fact that a 40mb+ extra download in addition to the unity content that requires admin rights to install, is a true system level driver and that only gives 30% and less of the users anything at all is neither favorable nor anything you will find any reasonable support for unless you lie to people by omitting the fact that they will no longer be able to reasonably spread their game through webplayer builds at all (as the webplayer installbase growth will break in seriously to completely as most don't install drivers they aren't 100% and many just can't as they aren't admins of their networks) and that the performance delta between nvidia and ati / windows - osx users will be in the range of 300% to 1000% depending on the explicit feature

 

Sorry, but the way you are arguing again indicates that you haven't understood what i was talking about.

Its' a no brainer that you have to install the driver on your own there and that it's limited to a specific hardware. That's not the problem at all. The problem is that it's not supported in Unity.

 

You don't seem to get the problem I guess as you still talk about "is not supported in unity"

You are still thinking in terms as if unity could add a flag for you to enable or disable it on a per project base and all is fine, which is exactly whats not the case.

If unity would offer HW accelration then every single game developed with unity as well as the unity editor would require the physx hw driver (not nvidia driver nor any gpu driver thing at all) to be installed or the engine will not even initialize anymore.

Unity is linked against the static library for PhysX likely which you can use alternatively if you license the pricy thing, this one allows you to get rid of the requirement that the physx driver must be present to run at all at the price of no longer being able to use it

EDIT: Just to clarify that - PhysX runs through the physx drivers you must install either 100% of the time or never. if that code that goes through the driver ends on the gpu or not depends on the gpu and nvidia graphics driver panel settings as well as the hw flag on physx you set when you create it

 

From what I understand, you can actually just include the physX dll's with your distribution which adds about 1.5Mb.

 

That dll is the engine, that is not the physx driver.
Unity has the static library counterpart (or the part of it which it uses which likely falls more into the 300k range) present, otherwise physics wouldn't work at all.

the physx driver is independent and required. Games that offer physx hw support install it silently normally.
This is also the part not present on osx (and the part that never will happen on osx as apple does not allow fake control-overriden relay drivers like the physx. hw accelerated physx will not happen on osx till nvidia implements it through OpenCL instead of a layer thats closed source and fully under their control)


there is another good reason to not use that driver: its well known that nvidia artificially crippled the cpu implementation to favor the gpu one.
no idea when they are going to end that joke there cause they lost some major projects to havok which only requires any kind of SM3 hardware for gpu acceleration (unlike physx which requires the physx hw driver additional install and an NVIDIA DX10+ card)

 

I don't understand why you seriously think that it's impossible to provide a functionality through Unity which already is present in a number of games out there and which enables users to consume their content in different ways according to their setups.

 

I don't think it makes sense to repeat the same thing again a 20th time.

this is nothing about what you can or what not.
its about whats bullshit if you want to want to have any future webplayer build support for windows at all

If you don't get that at all that adding a hardbind against an additional fake driver layer, resulting in an enforced presence of the same and admin rights to install is among the worst thing that could happen then there is nothing to help you understanding at all as you either don't want to understand the fundamental problem behind the physx hw support or think that your personal requirements are more worth than the one of all webplayer projects and other users.

 

and just to make that clear: its not about me not wanting it from the performance gain view.
I have a GTX280 + 8800GTS in my system where the gts is dedicated exclusively to CUDA usage ie physx and CUDA acceleration in applications and own code I've written. I've also worked on the C++ side against the physx sdk directly and know what massive performance gains I have on the various usages and that although I've a Core i7 920 in my box

But in this case here it just gets a massive no as I am not willing to accept the defakto kill blow against the webplayer because the amount of new installations will drop to a fraction of what it is now, ensuring that it never gets a broad enough install base to be even considered as a thread for flash.

 

Sorry, contrary to the last days i have zero time right now to discuss this further. I'll come back when i find some more...until then you're signed as beeing wrong! ;O)

 

I wonder why Unity went with physX instead of Havok. Maybe just a price thing? I have no idea how much havok costs to license..

 

at the time physx was integrated, we had SM1 and early SM2 cards around and were years from actual hw acceleration. not even the novodex PPU was released back then I think.

havoc at these days either didn't exist at all or was in its earlier childhood.

"PhysXs main competitor" back then was likely newton, if at all. on middleware level physx was largely on its own but the amount of games that used physic middleware was rather small too as 400-1000mhz cpus and alike didn't really offer the power to waste it on numerical physics simulation anyway

and since then Unity hasn't switched technology, likely because project upgrading would become impossible if they did (I hoped for Bullet in U3 which is not only open source and widely adopted but also has one of the best cpu multicore codes of all, I think only havoc is able to compete with it, but am aware that switch away from physx = many unhappy devs if their projects cease to work due to physics)

 

I believe the latest nvidia drivers are physx enabled, no need to download something separate. So you just have to have updated drivers.

Plus I don't see why there couldn't be an option to use or not use HW physx. I saw games that were like that (Mirror's Edge?)

 

It will obviously never be supported.

 

Sorry to reopen a dead thread but I just gotta say something and opening another one just doesn't seem right since this is the thing you get when you search google...

First I am with Taumel... Unity SHALL support hardware PhysX. GPU physics just looks awesome and can greatly enhance the gameplay or even be fundamental (like in mine). Having one CPU core (which Unity has at the moment) instead of up to 2048 GPU cores is a no go. I mean if Unity would at least spread PhysX to all CPU cores we could live a while longer .

Back to your posts, dreamora. I think your reasoning is just wrong.
First of all, GPU PhysX for webplayer is a nobrainer. Webplayer is for something lite and causual, I see no need for GPU PhysX in there. But this doesn't apply to Windows Games. And I am about sure that it should work on Mac OS and Linux too ^^, since I wonder what Unreal and CryTek are doing otherwise. But I might be mistaken. Anyway, the majority of PC games runs on Windows, so it doesn't really matter, as we are talking about high-end games.

Second, you are most likely wrong about the driver dependency. I don't know how it is in your Mac world, but on Windows it looks different, certainly. Unity could dynamically load either one of two PhysX abstraction DLLs (which they will have in some form modularized anyway, already). One with GPU bindings and one with CPU bindings. If they now dynamically load the CPU bound DLL, everything will work just fine, because it has no dependency on the driver, just like it is right now. But if the caps are there, and HW support is requested, it may as well load the GPU bound DLL, which of course now requires the driver. This might even work for the webplayer, at least I see no reason why it shouldn't and I doubt the browsers will scan the DLLs for dependencies. So if Unity doesn't try to load the GPU bound version, there doesn't need to be a driver installed... Plain and simple, we are not in medieval ages anymore.

Last but not least, Aras recently pointed out that one of the major reasons there is no GPU acceleration is founded in the fact that they actually have "S***tons" of bugs fixed in CPU code that are not fixed in GPU code.

 

if you want hw acceleration physic, maybe you can write a c++ plugin wrap the new physics instead of the unity original physics .

 

problem with Aras reason (the fixes) is that they are sitting on a nearly 2 year old PhysX version (2.x) where as the current is 3.x so for them there is also the reason of porting the whole thing again (unity 2.x was on physx 2.3 and the upgrade to the 2.8+ was already a partially breaking one) with the risk that even more titles couldn't be ported easily or that it will require a massive amount of work to get the physx 3.x unity exposure to behave like the outdated one did.

Also its a matter of platforms. Unity supports more platforms than PhysX, any update of physx, especially ones like the one in question to 3.x, hence mean a lot of portation work.

Oh and lets not forget that Unity uses the source license and cuts large large parts of the physx code actually and forcefully remove or at least disable its multithreading. No simple job to do either without F***ing it up completely.

 

I know it's late and this topic was bumped but havok physics was fully stable in 2004, before unity was released. Indeed, it was used for Unreal 2004's networked physics (and 3 to a lesser extent).

I'm fairly happy with physx, especially mobile performance. It is usable on mobile if you keep it simple, and I've got it in one shipped game and it's even being used in the next.

Wheel colliders and character controllers are a bit slow to use en-masse however...

Sometimes I think you invent stuff. The new physx is designed from the outset to be cross platform friendly.

 

I don't really get why you need backward compatibility, first across major versions of Unity, and second for older titles. I mean if I once developed a game, published it and it runs fine, why would I expect it to run fine on a brand-new Unity version. A philosophy like that really holds back innovation, especially in gaming, where technology changes so quickly. If I developed a game, then it is done. And if I want to take advantage of the latest Unity, I just gotta bite the bullet and do the whole conversion work...

So be it, but they get paid .

 

I see, so a missassumption on my end.
I assumed that all those subsystems that Unity does not support anyway (which is a large enough part of it actually) would be cut to reduce the engine size on webplayer (install size), mobile and consoles (build size).

 

Wouldn't it be possible to have both versions of physx implemented into the webplayer and use the appropriate version? In addition, wouldn't it be possible to make the newer version of physx an option for those that do not want to change for fear of breaking existing gameplay? While I agree backwards comparability is important, it should not be that much of an issue I would think.

 

I have decent experience with 3.2 and it certainly is different than 2.x, but I'd be curious what is/are the big blocking elements for missing features, if you don't mind saying. I certainly can understand even without missing features wanting to let the new version of PhysX mature a bit as well.

 

User can have both Unity 3.0 and Unity3.5 and Unity4.2 ... web players installed and use that one that needs by content.

 

Yea, but that's a real maintenance problem sustaining that approach, since you have to make sure all those old versions still work, since changes outside your application can create/expose a bug or problem you have to deal with in yours. Maintaining backwards compatibility is not without it's issues, but I would say it's the best choice.

At a certain point, the benefits of moving forward are worth it, I'm on the fence about whether or not PhysX3 is worth it for Unity. Switching physics engines is likely the most dangerous subsystem they could change, since even without missing/changed features, there's the chance of behavioral changes. Ultimately the thing I want most from physics that has been discussed here is performance improvements, not GPU physics, and it appears Unity's physics doesn't run asynchronously (could be wrong on that though). That improvement could be done in 2.8, and would be the same work in either version, using an actual multi-threaded physics engine (IE physx 3.X) is certainly nice, my experience with it was underwhelming in that respect, but YMMV.

 

Getting real tired of your s***, Unity.

 

I don't think that Unity need back compatibility after such major change.
I think that new Physx can be in Unity 5.0 with Mono 3.x.x and I do NOT want back compatibility or abbility to run old projects Unity 5.0

All I want is step forward from UT, and I can rebuild and fix my old project myself. If i do not wat to change my project I just will use old Unity and all

 

There's really no reason a new webplayer wouldn't have the same code paths, I mean it's abstracted. A physx replacement in a future replacement wouldn't necessarily break things. Things might feel different but with enough care and attention for the most part things should just work the same. This is because Physx has never been deterministic. It's never been reliable. You can't rely on it being 1:1 with itself or even in the same ballpark on different platforms. It's ideal for driving games, etc. If someone is relying on it running the same each time, they're only fooling themselves.

With this in mind, it's probably not an insane concept for unity to carefully wrap 3.x and replace existing physx entirely. It's a big job but with enough tests, both should pretty much behave the same, with new one just being faster. How much faster? That all depends. As a customer I say "yes". But I understand it being something desirable to wait and see on.

 

Necroing this thread to get some kind of update.

I'd really like to know if and when GPU Accelerated Physics solving will be available for any platform.

 

@Aras how are you now that years and years have gone by it would be great is someone from unity could update on "hardware PhysX"

(One point, there seems to be a lot of talk about how this would "break" for folks who don't have nvidia's HW Physx installed. But that's silly. Of course it would work both ways, with/without HWPhysX.)

Anyone got an update on this?

 

Recently, with physX went to open source, it's probably possible to run openCL version of physx insdead of CUDA. I would love to get 5x to 10x performance boost on physx as well love to hear some official statement update on the matter.

 

Still no optional hardware acceleration for NVIDIA users? It's like 75% of Windows users. It weird not to have this opt-in.