Squadcast Summary (2016/01/28) - What's not in 1.1 edition

[NoMrBond]

9 hours ago, BloodDusk said:

If you don't have an nVidia GPU, PhysX will do all the calculations on your CPU.

Unity doesn't use the CUDA branch of PhysX, calculations are done on the CPU regardless of your GPU brand.

Unity has said they would like to support the APEX framework for OpenCL compliant extensions eventually, but the feature remains unscheduled on their roadmap.

9 hours ago, BloodDusk said:

PhysX was never meant to take advantage of multiple CPUs/cores

The CPU branch of PhysX 3.x was developed for multiple cores (which is why its natively multithreading) and with SIMD support

[BloodDusk]

3 hours ago, NoMrBond said:

Unity has said they would like to support the APEX framework for OpenCL compliant extensions eventually, but the feature remains unscheduled on their roadmap.

But of course. They wouldn't want their nVidia sponsorship pulled out, would they?

3 hours ago, NoMrBond said:

The CPU branch of PhysX 3.x was developed for multiple cores (which is why its natively multithreading) and with SIMD support

While that is indeed true, that doesn't magically give your code multithread support. You have to implement it in your game. And this tends to be a pain on VM based languages, like the ones Unity supports and uses.

[NoMrBond]

25 minutes ago, BloodDusk said:

doesn't magically give your code multithread support.

That's why the physics threading was moved from internally possible but externally implemented in 2.x, to all internal implemented in 3.x

[BloodDusk]

31 minutes ago, NoMrBond said:

That's why the physics threading was moved from internally possible but externally implemented in 2.x, to all internal implemented in 3.x

Once again, you still have to implement it in the game you're programming, Being all internal doesn't make it magically there.

[godefroi]

20 hours ago, BloodDusk said:

But of course. They wouldn't want their nVidia sponsorship pulled out, would they?

While that is indeed true, that doesn't magically give your code multithread support. You have to implement it in your game. And this tends to be a pain on VM based languages, like the ones Unity supports and uses.

Multithreading is oh-so-much-easier in VM languages, compared to something like C++. .NET makes it especially easy, what with things like async/await and the TPL.

[Xavven]

2 hours ago, godefroi said:

Multithreading is oh-so-much-easier in VM languages, compared to something like C++. .NET makes it especially easy, what with things like async/await and the TPL.

Absolutely. I have some experience multithreading very simple applications in VB .NET, and the compiler enforces strict rules to keep you thread safe.

[BloodDusk]

On 2/5/2016 at 10:10 PM, godefroi said:

Multithreading is oh-so-much-easier in VM languages, compared to something like C++. .NET makes it especially easy, what with things like async/await and the TPL.

Unless you have the dreaded GIL. Plus, KSP would probably not be mod friendly if it had asynchronous  stuff in it.

 

22 hours ago, Xavven said:

Absolutely. I have some experience multithreading very simple applications in VB .NET, and the compiler enforces strict rules to keep you thread safe.

KSP is in C# (probably). Different language altogether.

[Xavven]

3 hours ago, BloodDusk said:

KSP is in C# (probably). Different language altogether.

KSP is in C# since it runs off of Unity.

C# and VB have different syntax but both use the .NET framework. They're like the fraternal twins of the programming world. That's why you see so many technet articles give examples in both C# and VB for any given object. Heck, here's an example of the backgroundworker class, which is a great tool for new programmers getting into light multithreading quickly and easily. Notice the example has C# and VB tabs and how similar they are https://technet.microsoft.com/en-us/library/h01xszh2%28v=vs.110%29.aspx