We'll see if this improves anything.

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

They are pulling a bethesda it seems.

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

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

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

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

Indeed.

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

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

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

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)

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.

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.

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

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.

RejZoRMain 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

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

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

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.

www.pingcap.com/article/bsd-license-pros-cons-projects-open-source-insights/

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.

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

_roman_2008 source code - of course we need that

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

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.

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

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?

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

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

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

AusWolfThe 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?

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

It's already happening.

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

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

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

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

Physics have not changed in a few billion years, brother :P. 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.

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