PhysX通过GPU实现大规模性能？

Question

我最近比较了一些用于模拟和游戏开发的物理引擎。有些是免费的，有些是开源的，有些是商业的（1甚至非常商业化的）。 Havok，Ode，Newton（又名oxNewton），Bullet，PhysX和某些3D引擎中的“原始”内置物理。

在某个阶段，我得出结论或质疑： 除非由于GPU处理能否使用其惊人的性能（如果我需要），为什么我应该使用NVidia PhysX以外的任何东西？使用未来的NVidia卡，我可以期待进一步的改进，而不依赖于常规的CPU生成步骤。 SDK是免费的，也适用于Linux。当然它有点供应商锁定而且它不是开源的。

您的观点或体验是什么？如果你现在就开始开发，你会同意上述内容吗？

欢呼声

Answer 1

免责声明：我从未使用过PhysX，我的专业经验仅限于Bullet，Newton和ODE。在这三个中，ODE是我最喜欢的;它是数值最稳定的，另外两个有成熟问题（有用的关节没有实现，合法的关节/运动组合以不确定的方式表现，＆amp; c）。

您提到了问题中的供应商锁定问题，但值得重复一遍：如果您使用PhysX作为唯一的物理解决方案，使用AMD卡的人将无法运行您的游戏（是的，我知道它可以be made to work，但它不是官方的或NVIDIA支持的）。解决此问题的一种方法是使用ODE或使用AMD卡的系统上的某些东西来定义故障转移引擎。这有效，但它会使您的工作量翻倍。认为你能够隐藏通用界面背后的两个引擎之间的差异并且编写大量的游戏物理代码是很诱人的，但是你在游戏物理学中遇到的大部分困难都在于处理你特定的特性。物理引擎，决定接触摩擦和恢复原状等值。这些值在物理引擎中没有一致的含义，并且（大多数）不能正式推导出来，因此您无法通过实验找到好看，可玩的值。使用PhysX加上故障转移，你可以做两次scut工作。

在更高层次上，我认为任何流处理API都没有完全成熟，我不愿意承诺，至少我们已经了解客户对英特尔Larrabee的反应塑造人们的设计。

到目前为止，看到PhysX是高端游戏开发的明显选择，我认为应该避免这种情况，除非你不认为拥有AMD卡的人占你玩家群的很大一部分（极不可能）或者你有足够的编码和QA人力测试两个物理引擎（更合理，但如果你的公司是那么富有，我听说过关于Havok的好东西）。或者，我猜，如果你设计的物理游戏的性能要求非常强烈，只有流媒体物理才能满足你 - 但在这种情况下，我会建议你创办乐队并让摩尔定律做一年的事情或两个。

Answer 2

2013年初的更新答案：我为我认为的三大操作系统开发：Linux，OS X，MS。我还开发了三大物理库：PhysX，Havok，Bullet。

关于PhysX，我最近做了一些测试，截至撰写本文时，最新版本为3.2.2。在我看来，nVidia确实降低了图书馆的有效性。最大的问题是刚体缺乏加速度。 lib只会加速粒子和布料。即使那些不与一般刚体接触。我对nVidia这样做感到非常困惑，因为他们有一个巨大的营销驱动力推动GPU加速应用程序，专注于科学计算，具有很大的推动力，即物理模拟。

因此，虽然我对物理之王sim的期望依次是PhysX，Havok和Bullet，但我认为现实情况正好相反。 Bullet已经发布了lib 2.8.1，其中包含OpenCL支持的示例。 Bullet是一个相对较小的lib，拥有慷慨的许可。他们的目标是在第3版中使用完全集成的OpenCL刚体加速。

部分评论讨论了多个代码路径。我的意见是，这不是太大的交易。我已经支持三个操作系统，支持最少的硬件代码（大部分是线程，不使用特定于操作系统的代码;使用C ++和std lib模板）。它与物理库类似。我使用共享库并抽象出一个通用接口。这很好，因为物理变化不大;）您仍然需要设置模拟环境，管理对象，在环境中渲染迭代，完成后清理。剩下的就是闪光，在闲暇时实施。

随着OpenCL在主流库中的出现（nVidia Cuda非常接近 - 请参阅Bullet OpenCL演示），物理插件工作将会缩小。

那么，从头开始，只关注物理建模？ Bullet不会出错。小巧灵活的许可证（免费），非常接近生产就绪的OpenCL，它将跨三大操作系统和GPU解决方案跨平台。

祝你好运！

Answer 3

您可能会觉得这很有趣：

http://www.xbitlabs.com/news/video/display/20091001171332_AMD_Nvidia_PhysX_Will_Be_Irrelevant.html

它有偏见......它基本上是对AMD的采访......但是我认为在你的案例中我认为值得考虑的一些要点。

由于David Seiler指出的问题，未来某个时候切换物理引擎可能是一个巨大/不可逾越的问题......特别是如果游戏玩法与物理学紧密相关的话。

所以，如果你真的想在你的引擎中使用硬件加速物理，那么请选择Physx，但要注意，当本文中的AMD假设的解决方案可用时（他们绝对将但是他们还没到这里，你将面临不愉快的选择：

1）重写你要使用的引擎（插入新的跨平台硬件加速物理引擎的名称），可能会以糟糕的方式改变游戏的动态

2）继续使用Physx，完全忽视AMD用户

3）尝试让Physx使用AMD GPU（blech ...）

除了大卫的想法，使用CPU物理引擎作为后备（做两次工作并生成两个行为不同的引擎），你唯一的另一个选择是使用纯CPU物理。

然而，随着像OpenCL这样的东西成为主流，我们可能会看到ODE / Bullet / kin开始合并......如果你现在使用ODE / Bullet / kin进行编码，你可能（可能最终会）获得GPU加速稍后“免费”（不更改您的代码）。它仍然会与GPU版本略有不同（由于蝴蝶效应和浮点实现的差异，这是一个不可避免的问题），但至少你会让ODE / Bullet / kin社区与你合作以缩小差距

这是我的建议：使用一个开源物理库，目前只使用CPU，并等待它通过OpenCL，CUDA，ATI的流语言等使用GPU。当发生这种情况时，性能会快速尖叫，并且你会省去头痛。

Answer 4

未来gfx显卡的假设优势一切都很好，但额外的CPU内核也将带来未来的好处。你能确定未来的gfx卡总是有剩余的物理容量吗？

但可能最好的理由，虽然在这种情况下有点模糊，但表现并不是一切。与任何第三方库一样，您可能需要在未来几年内支持和升级该代码，并且您将要确保接口合理，文档良好，并且它具有您的功能需要。

可能还有更多的数学问题，例如某些API提供更稳定的方程求解等，但我会对专家发表评论。

Answer 5

我使用 ODE ，现在使用 PhysX 。 PhysX 使构建场景变得更容易（我的个人观点）看起来更加真实，但 PhysX 没有足够的文档。事实上几乎没有任何文件。另一方面， ODE 是开源的，有大量的文档，教程等。 PS：使用GPU加速技术可以帮助我和我的同事们;我们正在使用 APEX 销毁和 PhysX 粒子。

Answer 6

PhysX适用于非nVidia卡，它不会加速。让它处于相同的位置，其他引擎将开始。问题是如果你有一个只能用于硬件物理加速的物理模拟。

Answer 7

如果你的所有代码都是大规模可以兼容的，那就去吧！

对于其他一切，GPU非常不足。