NVIDIA PhysX and Flow Made Fully Open-Source

[ZeDestructor]

Yes, but the source you cited also states that AVX-512 on Zen5 will be severely limited by cache-and-memory bandwidth. In other words, in a real-world scenario it is unlikely for AVX-512 in Zen5 to outperform AVX-512 in Zen4 by a large margin - unless the dataset can fit in Zen5's L1D or L2 cache.

The nuance that you're missing is that when PhysX runs, it's not using a whole GPU, it's using a very small fraction of the GPU. like 1/4 core of AVX2 on a modern CPU should be enough for the vast majority of games that require GPU PhysX I reckon.

 

[lexluthermiester]

The nuance that you're missing is that when PhysX runs, it's not using a whole GPU, it's using a very small fraction of the GPU. like 1/4 core of AVX2 on a modern CPU should be enough for the vast majority of games that require GPU PhysX I reckon.

Yup, that's about the sum of it.

 

[RayneYoruka]

Is that only about this particular nVidia's move? Huge number of publishers already have pulled the "Bethesda", and have put their entire game making on the "rails" of such arrogant approach, for many years already. They give the players the barely functionaly buggy barebones, and "let" modders to make entire QA, and QoS stuff, "for free", and later grab all the merrits to themselves. Or, even sell the mods as own paid DLCs.

Ah! No of course not. The industry is on shambles. They can't make anything right and expect users to buy everything on launch. These should be the time users do actually vote with their wallets despite.. "new and shiny."

 

[cal5582]

kind of a shame, i bought my 4070ti specifically to run physx and AI. guess im going solely radeon next gen.

 

[Scattergrunt]

I didn't comment on this; as I did not have the time too (I have been swamped with work) but, NVIDIA retiring their old physics tech that wasn't received super well and giving it back the community is nice. I would of appreciated though that they had still giving 50 series 32 bit PhysX support and then done this, but at least it means alot of the issues with PhysX in general can be worked out by Modders (if they wanna even bother).

As for Flow? Don't particularly care for it.

 

[lexluthermiester]

kind of a shame, i bought my 4070ti specifically to run physx and AI. guess im going solely radeon next gen.

You realize that NVidia removed 32bit Physx from the RTX5000 series, right? Your 4070ti still has it and it'll be supported for the lifetime of the card.

 

[cal5582]

You realize that NVidia removed 32bit Physx from the RTX5000 series, right? Your 4070ti still has it and it'll be supported for the lifetime of the card.

yeah, its just a pain that something that was always a supported function got removed and i have no more reason to buy their cards. i liked offloading physx, it made borderlands 2 run smooth.

 

[lexluthermiester]

yeah, its just a pain that something that was always a supported function got removed.

Ok, name one game or program released in the last 6 years that has put the 32bit Physx functions to use. It's being removed because no one is commonly using it. To my knowledge no one is commonly using the 64bit Physx functionality either. So at the end of the day, NVidia removed something that takes time to continue coding support for that no one is commonly using. This is why they opened the source for it. That way if someone does need it, they can reference the source code and write their own support for it into their program or game.

and i have no more reason to buy their cards.

While AMD is catching up in the raytracing arena, NVidia is still king of the hill there. That's not enough reason?

i liked offloading physx, it made borderlands 2 run smooth.

That's a 13year old game. Seriously? Your 4070ti can run that game perfectly with half it's cores disabled and it's clock cut in half. Not a solid argument there.

 

[R-T-B]

no one is commonly using the 64bit Physx

Well, no one is using the gpu one yeah. But a metric shitton use the CPU one...

The nuance that you're missing is that when PhysX runs, it's not using a whole GPU, it's using a very small fraction of the GPU. like 1/4 core of AVX2 on a modern CPU should be enough for the vast majority of games that require GPU PhysX I reckon.

I really doubt this. GPU physics like PhysX love thousands of cores to do noncollidable effects because that kind of work is very simple and highly parellizable, thus the literally thousands of shader cores on a gpu can unlock massive power. A cpu simply cannot compete here, with like 16 cores at most, and their raw ST power does not really change that much because each spawned thread isn't doing all that much. It just ends with massive wasted potential, cpu side. Take a look at the antiwonder of OSS cpu physx (which has been open far longer, and IS widely deployed) if you doubt this.

 

[cal5582]

Ok, name one game or program released in the last 6 years that has put the 32bit Physx functions to use. It's being removed because no one is commonly using it. To my knowledge no one is commonly using the 64bit Physx functionality either. So at the end of the day, NVidia removed something that take time to continue coding support for that no one is commonly using. This is why the opened the source for it. That why if someone does need it, they can reference the source code and write their own support for it into their program or game.

While AMD is catching up in the raytracing arena, NVidia is still king of the hill there. That's not enough reason?

That's a 13year old game. Seriously? You're 4070ti can run that game perfectly with half it's cores disabled and it's clock cut in half. Not a solid argument there.

average user is also fine with a single pcie slot and nvme drive. i genuinely hope we never get to that level of locked in hell.
as far as nvidia goes, i dont feel like paying 1.5x the cost for 35% more performance. 7900xtx gets along just fine. id rather just buy the highest end amd card.
doesnt help the majority of the games that feature heavy raytracing are slop right now. gaming industry isnt in the best place creatively, but i dont want to derail the conversation on that.
backwards compatibility is always useful. retro-gaming is a pretty big hobby.

 

[lexluthermiester]

average user is also fine with a single pcie slot and nvme drive. i genuinely hope we never get to that level of locked in hell.

You're comparing removing old and unused code from a driver set to something completely unrelated. That's grasping at straws.

backwards compatibility is always useful. retro-gaming is a pretty big hobby.

And that very reason is why they released the source for it.

 

[AnotherReader]

Well, no one is using the gpu one yeah. But a metric shitton use the CPU one...


I really doubt this. GPU physics like PhysX love thousands of cores to do noncollidable effects because that kind of work is very simple and highly parellizable, thus the literally thousands of shader cores on a gpu can unlock massive power. A cpu simply cannot compete here, with like 16 cores at most, and their raw ST power does not really change that much because each spawned thread isn't doing all that much. It just ends with massive wasted potential, cpu side. Take a look at the antiwonder of OSS cpu physx (which has been open far longer, and IS widely deployed) if you doubt this.

No GPU has thousands of cores; you are falling for Nvidia's CUDA core nonsense. The equivalent would be counting each AVX-512 execution unit in a Ryzen 9700X as 512/32, i.e. 16 cores. Given that each core of a 9700X can sustain 2 FMA and 2 FADD per cycle, it would be the equivalent of a 384 CUDA core GPU clocked at 5 GHz which would be more processing power than a GTX 680. This is ignoring that Kepler frequently had relatively low utilization of its SMX which is the bulk of the reason that the slimmed down SMX of Maxwell could keep up with Kepler. GPUs of that vintage were well suited to PhysX so there's no reason that CPUs with greater capabilities can't handle physics.

 

[ZeDestructor]

Well, no one is using the gpu one yeah. But a metric shitton use the CPU one...


I really doubt this. GPU physics like PhysX love thousands of cores to do noncollidable effects because that kind of work is very simple and highly parellizable, thus the literally thousands of shader cores on a gpu can unlock massive power. A cpu simply cannot compete here, with like 16 cores at most, and their raw ST power does not really change that much because each spawned thread isn't doing all that much. It just ends with massive wasted potential, cpu side. Take a look at the antiwonder of OSS cpu physx (which has been open far longer, and IS widely deployed) if you doubt this.

Besides what @AnotherReader already mentioned about making the core counts equivalent and factoring the clockspeeds in, you also have to compare the amounts of computation involved. Compared to rendering a frame (ie, geometry, shaders, AA, etc), physics processing is a rounding error. On top of that, you also have to deal with data locality and how closely-coupled physics simulation is with the core gameloop with modern games - that close-coupling often makes is faster to just simulate the physics "slower" (but still fast enough) on the CPU because of the latencies involved in moving data back and forth between main memory and VRAM.

 

[R-T-B]

No GPU has thousands of cores

It was slight hyperbole there, but the point still stands, especially with how little math is actually done on the streaming processors.

Besides what @AnotherReader already mentioned about making the core counts equivalent and factoring the clockspeeds in, you also have to compare the amounts of computation involved. Compared to rendering a frame (ie, geometry, shaders, AA, etc), physics processing is a rounding error. On top of that, you also have to deal with data locality and how closely-coupled physics simulation is with the core gameloop with modern games - that close-coupling often makes is faster to just simulate the physics "slower" (but still fast enough) on the CPU because of the latencies involved in moving data back and forth between main memory and VRAM.

Yes but this is exactly why why "but the cores are powerful!" really doesn't amount to anything but waste. There isn't really a healthy way to serialize a large number of n-bodies without compromising the game loop but you can parallize it pretty easily.

But what do I know, I just wrote a replacement planetarium for some game in cpu physx. I wish the gpu route had been available when I started, honestly.

 

[Koozwad]

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

According to even just steamdb, 10887 titles on Steam currently use PhysX(don't think that includes the many delisted games either, so the number will be quite a bit higher). That's also not even counting Apex tech. If you are referring to strictly GPU-accelerated PhysX however, the list is far smaller.

 

[Raffles]

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)


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

?

The PhysX integrated in Unity has been multithreaded for years. You can see it first hand in the profiler.

When I started using Unity it was one of the things I was pleasantly surprised about. I had previously developed my own physics engine, that had a massive amount of effort put into optimisation, but it still couldn't match PhysX even though is faster thread for thread, as it was singlethreaded and PhysX is multithreaded.

Incidentally, Unity 2019 is when I had to move to Unity, and I'm 99% sure PhysX was already multithreaded then.

As I said it was one of the things that impressed me the most about Unity, the CPU PhysX implementation. Both the broadphase and narrowphase are very efficient. Even on very slow ARM CPUs, it's capable of hundreds of simultaneous collisions, even upping the fixed update to 100hz. It's remarkably close performance wise to the DOTS implementation of Havok.

Unity's render pipeline could still do with some work, ideally merging DOTS and GOs, but the physics is excellent, even if it's essentially Nvidia's work

 

[R-T-B]

The PhysX integrated in Unity has been multithreaded for years. You can see it first hand in the profiler.

Not in Unity 2019 it wasn't, and I really doubt they ever multithreaded rigid bodies (the math on that limits you pretty hard). Maybe things have changed. I generally do work on 2019 era stuff because ksp. I may admitedly be out of date from that.

 

[Raffles]

Not in Unity 2019 it wasn't, and I really doubt they ever multithreaded rigid bodies (the math on that limits you pretty hard). Maybe things have changed. I generally do work on 2019 era stuff because ksp. I may admitedly be out of date from that.

Ksp?

 

[R-T-B]

Ksp?

Kerbal Space Program. It's the game most of my OSS work targets.

 

[Raffles]

Kerbal Space Program. It's the game most of my OSS work targets.

Ah I see. I have it, and like the look of it, but haven't got round to playing it.

Is KSP where your knowledge of PhysX in Unity comes from? It's possible KSP used a version of PhysX before it became multithreaded.

If you're interested, I'll show you a demo of PhysX's speed in current Unity.

 

[R-T-B]

Is KSP where your knowledge of PhysX in Unity comes from? It's possible KSP used a version of PhysX before it became multithreaded.

Largely yes, which is why I admitted I could be very outdated. 6 Years have passed since 2019.

Although they updated the Unity version in KSP 2 and it did not exactly do better, but that whole project was kind of a joke...

If you're interested, I'll show you a demo of PhysX's speed in current Unity.

Nah it's all good I take your word for it. I'm glad things have improved.