NVIDIA PhysX and Flow Made Fully Open-Source

[ZeDestructor]

I'm more worried about the mode switching from 32 to 64 this will require. To be honest, I don't have much info about the cost of these ops, but considering mixed 32/64bit programs aren't that common (heck, I know of none!), I'm not very optimistic.


I doubt that. This would entail writing a CUDA-like infrastructure that does provide what CUDA does. Most feasible solution would probably be leveraging existing APIs; AMD's ROCm and Intel's equivalent.

Mode-switching isn't too much of a problem. Iirc you can access AVX2 registers and instructions from a 32bit IA-32 contexts just fine (exactly like MMX and SSE; AVX2 is just a faster and wider successor to SSE, which was a successor to MMX).

As for the CUDA part, between ZLUDA (as mentioned by Denver) and just reimplementing the necessary bits internally, it's not that much of a problem - just changes the timescale really.

But isnt it like aged beyond believe? like dont we have far superior modern solutions?

Physics have not changed in a few billion years, brother . Sure, there are better, more accurate physics engines like newer version of Havok and others that I don't remember the names of, but PhysX is very good, even in it's "frozen" state.

I suspect that even recent CPUs such as Ryzen 9700X might not be fast enough to outperform older GPUs when running PhysX simulations.

It's more than just speed - you also have to factor data transfer between main memory and VRAM, setting up and tearing down GPU kernels. This is why something like Path of Exile which can generate frankly *ridiculous* amounts of physics particles does their graphical (meaning no interaction back into the gameloop) physics entirely on CPU - the latency of back and forth CPU-GPU processing is just too high.

 

[AusWolf]

But isnt it like aged beyond believe? like dont we have far superior modern solutions?

Better late than never, I guess.

 

[Vya Domus]

They locked 32Bit at the driver level on Blackwell, so this won't help unlocking it.

It does, maybe. If the CUDA kernels are the same going back to older versions of PhysX that are problematic now on 32bit games then people can write a back end that just uses regular shaders now. Or multithread the CPU version so that it doesn't even need to run on the GPU (if that's being made available as well, haven't looked into it).

 

[hsew]

I can’t remember the last time a PhysX title was launched.

 

[Shihab]

A single app cannot be switched from 32-bit to 64-bit mode or vice versa. Neither the CPU, nor the OS, supports this. Mixing 32-bit and 64-bit libraries is not possible in a single process. You would need to have 2 apps communicating via message passing, via filesystem or via shared memory: one process running in 64-bit mode and another process running in 32-bit mode.

I'm aware of that fact. I was referring to interoperability between 32 bit apps and 64 bit libraries, as was explained in previous post.

ROCm is 64-bit only.
Also aware of that fact. Again, check my previous posts.

An only viable choice is that Wine/Proton will use the just released PhysX source code to derive a 32-bit Windows DLL for use by 32-bit games (such as Batman: Arkham City), which could then enable PhysX on any recent AMD/Intel/NVIDIA GPU in Linux.

CUDA is natively supported on Linux. Proton/Wine already do pass the calls to the linux-native implementations from Windows-specific PhysX-using applications. But it doesn't allow for cross-vendor use. And most likely also have the same limitations facing Blackwell on Windows.

Perhaps someday they could adopt ZLUDA or something for that, but we're not there yet.

Mode-switching isn't too much of a problem. Iirc you can access AVX2 registers and instructions from a 32bit IA-32 contexts just fine (exactly like MMX and SSE; AVX2 is just a faster and wider successor to SSE, which was a successor to MMX).

Sorry, I was referring to GPU-run PhysX.

 

[TumbleGeorge]

Freedom means no licensing policy at all. If there is one, it's not freedom, even if the license description says "free".

 

[ZeDestructor]

Freedom means no licensing policy at all. If there is one, it's not freedom, even if the license description says "free".

Dude, what the hell are you on about? Have you actually read the terms of the license?

tl;dr: you can do literally whatever you want with the code, including making your own builds, modifications and more, as long as you don't claim that your version/build was made by Nvidia (unless you get written permission from Nvidia to do so).

 

[agent_x007]

Is this 32-bit only side of GPU-accelerated PhysX, or is it 64-bit side too ?

 

[Readlight]

This graphics setting makes game run on 1 frame per second.

 

[TheinsanegamerN]

With how fast modern CPUs are, they can probably just make it use AVX2 and it will be no slower than running it on GPU (which is what I'm expecting to happen). Either or they'll go OpenCL or Vulkan Compute, both of which can target CPUs. It's not gonna happen overnight though, so if you're hoping for a release in 2 months' time for your 5090, you're gonna be disappointed.

Stripping the nV lock may or may not be fast... depends how CUDA-dependent the thing is. Given it predates CUDA, there is some hope that it's not too CUDA-dependent, but I dunno, having not looked at the source code myself.

Even the fastest modern CPUs are toddlers compared to a GPU's compute output. CPU based Physx still struggles on the newest ryzen chips, sure some newer instructions may help this, but there's a reason physx was GPU based to begin with...

So the patent that Aegia was awarded have expired then? Hopefully there will be someone brave enough to make dedicated Physx accelators once again.

I'm guessing its more like nvidia has no interest in continuing PhysX support going forward, and seeing the outrage decided to earn some good boi points by open sourcing it instead of locking it away. .

 

[igormp]

No but it could be rewritten to run on opencl for example.

Nvidia also dropped 32-bit opencl with blackwell, given that it ran on top of CUDA as well.
Rewriting it in OpenCL wouldn't really help games that have the whole 32-bit issue.

"as open-source software under the BSD-3 license"

Anyone know what this actually means? can anyone now use the old physics system in their games (not that I think you would want to be but still)

BSD-3 Is pretty permissive, you can even make your own proprietary fork and do whatever you want with it. Just don't use Nvidia's name to promote your thing.

The first truly positive Nvidia-related news in recent years. I hope developers will make good use of it. I'm also wondering if this will improve things on Linux and/or maybe PhysX on AMD?

Not really relevant for Linux since Physx has been supported in Wine since 10 years ago.
Only relevance for AMD would be with something like ZLUDA, which was mentioned before, but it's also 64-bit only.

With how fast modern CPUs are, they can probably just make it use AVX2 and it will be no slower than running it on GPU (which is what I'm expecting to happen). Either or they'll go OpenCL or Vulkan Compute, both of which can target CPUs. It's not gonna happen overnight though, so if you're hoping for a release in 2 months' time for your 5090, you're gonna be disappointed.

Stripping the nV lock may or may not be fast... depends how CUDA-dependent the thing is. Given it predates CUDA, there is some hope that it's not too CUDA-dependent, but I dunno, having not looked at the source code myself.

The CPU implementation has been open source for years already, yet no one tried to do such optimizations.
Physx just isn't that relevant for people to care, the whole 32-bit drama was truly overblowing its relevance.

ZLUDA Continues Working On PyTorch Support, Eyes 32-bit PhysX Support - Phoronix

It's already happening.

Not happening, at least for now. The author themselves explicitly said they won't work on it, and seems like no one has stepped up to work on it either.
There's also 2 distinct things going on that people are talking about: the 32-bit support for older physx versions, and just getting any version of physx running on top of AMD. Each has their own particularities, and 32-bit support is way more annoying given how all modern libraries are 64-bit only.

Freedom means no licensing policy at all. If there is one, it's not freedom, even if the license description says "free".

No licensing actually restricts how you can use stuff since you do not have explicit authorization to do stuff.

Even the fastest modern CPUs are toddlers compared to a GPU's compute output. CPU based Physx still struggles on the newest ryzen chips, sure some newer instructions may help this, but there's a reason physx was GPU based to begin with...

CPU-based physx sucks because it was never made to run properly on CPUs. Many modern physics engines run on CPU still, such as havok, chaos from unreal or unity's physic stuff. There aren't many GPU-based physics frameworks meant for games, bullet is one of the few and even then the CPU backend is preferred afaik.

 

[R-T-B]

With how fast modern CPUs are, they can probably just make it use AVX2 and it will be no slower than running it on GPU

The cpu implementatiom of PhysX had been open source for even longer and it isn't quite that simple.

 

[john_]

About 15 years too late.

 

[Vya Domus]

The cpu implementatiom of PhysX had been open source for even longer and it isn't quite that simple.

Not the older implementations as far as I know, those are the real problem, only V4 and up is open source. They could absolutely be made to run faster and it wouldn't be that difficult, I remember from back in the day it was found that the CPU backend was using really old x87 instructions apparat from not being multithreaded and vectorized, which would explain why it runs like absolute dogshit even though single thread performance improved a lot since then.

 

[Pedetes Lucidos]

Oh no! The will create HAVOK!

 

[Visible Noise]

I suspect they would have fixed it themselves if it was trivial. Now they're hoping modders will do it for free.

Do you feel the same about AMD’s open source projects?

Main problem with PhysX is the fact it's relying on driver and doing driver things is pain in the ass on Windows 11 these days.

The most I can think of it is that people will add translation layer that would run 32bit hardware PhysX using OpenCL or DirectCompute, allowing it to run on any graphic card. Wishful thinking I guess.

PhysX is a CUDA app. It has nothing to do with the driver.

About 15 years too late.

As an AMD user you care because?

 

[Beermotor]

Main problem with PhysX is the fact it's relying on driver and doing driver things is pain in the ass on Windows 11 these days.

What specifically changed in the Windows driver model?

 

[Dawora]

I can’t remember the last time a PhysX title was launched.

Short memory?
Witcher 3 and borderlands 2

 

[lexluthermiester]

I personally think this was a very gracious move for NVidia to answer the problems that were introduced with the removal of the 32bit run-times. For all the criticisms we have for NVidia ATM, they at least did this right. It would have taken time to put all of this together, so it was clearly a part of the plan from the moment they made the choice to remove it from the drivers.

We'll see if this improves anything.

Can't see why it wouldn't. They opened the source and now devs/modders can patch all of the 32bit code to work with modern hardware.

I suspect they would have fixed it themselves if it was trivial. Now they're hoping modders will do it for free.

You misunderstand. They no longer support 32bit anything, so opening up the source opens the door for devs/modders to freely do for themselves what they need instead of relying on NVidia to do it for them.

They locked 32Bit at the driver level on Blackwell, so this won't help unlocking it.

You misunderstand what NVidia did. They removed the 32bit code from their drivers some time ago and this was the only 32bit parts left. Put another way, they didn't lock anything up so much as they removed it entirely. However, it will give devs/modders all the tools they need to get around these limitations.

But isnt it like aged beyond believe? like dont we have far superior modern solutions?

Short answer, yes. 32bit Physx is all legacy code at this point. No one is using it. More advanced and 64bit versions had replaced the legacy code many years ago. This is why NVidia has dropped support for it.

I suspect that even recent CPUs such as Ryzen 9700X might not be fast enough to outperform older GPUs when running PhysX simulations.

No. Modern CPUs and GPUs will run circles about the older hardware. Not sure where this logic is coming from but it's not meritful.

 

[R-T-B]

Not the older implementations as far as I know, those are the real problem, only V4 and up is open source.

They absolutely all are available but as I said, only the cpu code. (The gpu code is the news here). This is why cpu physx is literally baked into Unity as the default physics engine, for better or for worse (mostly worse because yes it is singlethreaded dogshit in cpu collidable form).

The cpu side code is far less fast than the gpu code because of how parellizable non-collidable physics are (gpu physx does not support collisions to my knowledge)

No. Modern CPUs and GPUs will run circles about the older hardware.

Nah, if you are looking for cores, any gpu within a decade will run circles around a cpu, and thats precisely what physx needs.

 

[TheDeeGee]

I can’t remember the last time a PhysX title was launched.

2025

 

[Vya Domus]

They absolutely all are available

You go ahead and show me where I can find the source code for older versions than PhysX V4. Unity is using CPU PhysX post V4, which is a lot more optimized, that's why it runs relatively well.

 

[lexluthermiester]

Nah, if you are looking for cores, any gpu within a decade will run circles around a cpu, and thats precisely what physx needs.

You misunderstood, they were saying that older GPU hardware would run better than newer CPU hardware(at least that's what they seemed to have implied), which is daft, silly and totally incorrect. All modern CPUs run circles around the old 32bit GPU hardware. Now if I misunderstood what they were saying, then yeah ok, I'm silly.

You go ahead and show me where I can find the source code for older versions than PhysX V4. Unity is using CPU PhysX post V4, which is a lot more optimized, that's why it runs relatively well.

Release PhysX 4.0.0 Release · NVIDIAGameWorks/PhysX

NVIDIA PhysX SDK. Contribute to NVIDIAGameWorks/PhysX development by creating an account on GitHub.

github.com

There you go. They released it in 2018.

 

[Rightness_1]

Only about a decade late. But I wonder if someone out there can make physx work on Blackwell. If they manage to then Nvidia should be ashamed of themselves.

It's just about figuring out what NV did to block it in the driver. But some kind of wrapper would probably be the way forward.

 

[Vya Domus]

Release PhysX 4.0.0 Release · NVIDIAGameWorks/PhysX

NVIDIA PhysX SDK. Contribute to NVIDIAGameWorks/PhysX development by creating an account on GitHub.

github.com

There you go. They released it in 2018.

Do you people just like, not read ?

It's version V4, you're not gonna find source code for older SDKs because there aren't any. Those old games that run like crap which people are complaining about were using SDKs prior to V4.