NVIDIA PhysX and Flow Made Fully Open-Source

[btarunr]

NVIDIA late last week committed NVIDIA PhysX SDK and NVIDIA Flow as open-source software under the BSD-3 license. This includes the GPU source code—the specific way PhysX leverages CUDA and GPU compute acceleration, and should make it easier for game developers to understand and implement PhysX, including its various interactive 3D effects such as rigid body dynamics, fluid simulation, and deformable objects. More importantly, a deeper understanding of PhysX makes it possible for modders to develop fallbacks for their older 32-bit game titles that use PhysX to work with newer generations of GPUs, such as the RTX 50-series "Blackwell." It should come especially handy when NVIDIA is trying to push Remix—its first-party initiative to refurbish older games with modern graphics and higher resolution visual assets.



View at TechPowerUp Main Site | Source

 

[Scrizz]

We'll see if this improves anything.

 

[Event Horizon]

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

 

[RayneYoruka]

They are pulling a bethesda it seems.

 

[evernessince]

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

Judging by the train wreck that is Blackwell, I'm going to say Nvidia just doesn't care about the gaming market right now more than it being challenging to fix.

 

[Shihab]

Dunno. Me thinks this would be more helpful for recent and future products than past ones.

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

It's not a technical issue for it to be trivial or not, it's a financial one, and they obviously gauged it to be of no value solve.

What they are offloading to the others seems to be QA of future releases. Although this probably targets studios and engine devs more than it does modders.

 

[b1k3rdude]

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

Indeed.

 

[Rightness_1]

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

 

[qlum]

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

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

 

[ZoneDymo]

"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)

 

[ZeDestructor]

"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)

Yes, and community can also fork it to improve it - - either in it's base functionality, and/or just making new builds of it for non-nVidia and 32bit games; similar to how we have comunity dinput.dll hacks and glide wrappers for older games.

 

[RejZoR]

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.

 

[Chaitanya]

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

 

[Raiden85]

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.

 

[ZeDestructor]

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.

The fact it's historically been a driver-provided library is not a problem - just drop the relevant .dll(s) next to the games' .exes and it will have priority over the driver-supplied implementation

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 don't think the patents have expired just yet (PhysX was 2006 with patents from 2003-2004 iirc), but the value they offer nV certainly has. There will not be any dedicated PPUs though - Vulkan Compute or Direct3D Compute Shaders are omre than enough to run such a light workload (and has been for almost a decade at this point)

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.

nV is doing it now because the cost of maintaining it is larger than the benefit of keeping it in-house. No more, no less and certainly no malice beyond the required corporate greed.

 

[_roman_]

That topic should be more in depth about what the BSD license really means. For people group a, b, c, d.

Physx I hardly saw it in any games. Maybe I saw three or four times physx advertisement at game starts. That's it.

--

2008 source code - of course we need that.

BSD license is not to my liking. there are licenses which are far less restricted. BSD is one of the better ones - but there are better licenses. Make it truly open source or leave it.

BSD License: Pros and Cons for Projects

Understand the BSD License's pros and cons for projects. Explore its flexibility, cost-effectiveness, and challenges, with insights from PingCAP's open-source experience.

www.pingcap.com

Those licenses are the biggest headache. For laziness and personal use I do not care:
ACCEPT_LICENSE="*"
I had to add so many different licenses at some sort of point that i used the * for use anything. Every two weeks something did not install because of some other license which was not in the allow list.

 

[Shihab]

Yes, and community can also fork it to improve it - - either in it's base functionality, and/or just making new builds of it for non-nVidia and 32bit games; similar to how we have comunity dinput.dll hacks and glide wrappers for older games.

The issue with 32 bit support was CUDA-side, not PhysX side. Rebuilding the GPU-using PhysX libs would be pointless, as they'd still have to be 32 bit binaries (due to the games themselves being so) calling 32 bit CUDA libs (which is what's missing here).
What this *may* help are compatibility layers, which are seperate from physx itself (as much as proton/wine is independant fom games' WinAPI and D3D-calling binaries). Although I'm not very optimistic about the performance.

Making 64 bit Physx things run on non-Nvidia cards is something I do hope for, however. Me thinks it's quite feasible. People were already working/planning to start working on this. Waiting to hear their opinion on the matter.

2008 source code - of course we need that

The update is for the most recent SDK v5.something.

 

[Denver]

The truth is that they will take the code as a basis to create a hardware-agnostic solution. Good for everyone, as it should be.

 

[ZeDestructor]

The issue with 32 bit support was CUDA-side, not PhysX side. Rebuilding the GPU-using PhysX libs would be pointless, as they'd still have to be 32 bit binaries (due to the games themselves being so) calling 32 bit CUDA libs (which is what's missing here).
What this *may* help are compatibility layers, which are seperate from physx itself (as much as proton/wine is independant fom games' WinAPI and D3D-calling binaries). Although I'm not very optimistic about the performance.

Making 64 bit Physx things run on non-Nvidia cards is something I do hope for, however. Me thinks it's quite feasible. People were already working/planning to start working on this. Waiting to hear their opinion on the matter.


The update is for the most recent SDK v5.something.

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.

 

[AusWolf]

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?

 

[ZeDestructor]

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?

It will, but not immediately.

 

[Shihab]

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

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.

Either or they'll go OpenCL or Vulkan Compute, both of which can target CPUs.

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.

 

[ZoneDymo]

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?

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

 

[Denver]

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

It's already happening.

 

[atomsymbol]

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.

It is a misunderstanding of how CPUs and operating systems work.

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

ROCm is 64-bit only.

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.

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