PhysX Simulation on a 16-Core CPU

rickerlian

这说明那些用physx作为物理效果的游戏的编码是何其的烂？
抑或nv的physx还没找到多cpu的best practice，现在还在摸索？

很显然，physx需要一个scalable solution，并不是一个能把16核都满载的测试软件
也很显然，以之前physx的游戏表现来看，很容易让人认为physx不具备伸缩性，NV对此需要负上责任

rickerlian

你能找到几个可以充分利用4核心的havok物理引擎游戏呢？与其说physx烂，不如说物理引擎的并行化编 ...
westlee 发表于 2010-3-5 13:56

你概念模糊，我帮你理清
1.我没有说physx烂，physx是一个程序库，一个library，这个库写得烂不烂我不知道
2.client如何使用这个library，确实很讲究的，所以为什么要有best practice或者scalable solution
举个例子，windows操作系统其实是一个runtime library，提供很多api，你使用这些api实现同一个功能，可以有多种方法，程序会有很多种结构，api的调用序列会有很多种。有人按照msdn上的best practice，有人乱搞。乱搞的程序大多数是效率低，无法延伸，最后，用户体验，程序效率低。

好了，再看我的回帖，用physx作为物理效果的游戏的编码是何其的烂？是游戏编码烂，不是physx烂，更贴切，就是那些游戏，不懂得如何使用physx，已导致physx的效率低。这是我猜测之一。


不如说物理引擎的并行化编程本来就是需要相当的投入的，而很多游戏公司显然认为，他们的开发成本应该投在其他地方
如果一个程序库如何有效地使用都要client去投入去优化的话，这是可悲的，因为这意味着库作者也不知道如何有效地使用。所以我作出一下观点
抑或nv的physx还没找到多cpu的best practice，现在还在摸索？

很显然，physx需要一个scalable solution，并不是一个能把16核都满载的测试软件
也很显然，以之前physx的游戏表现来看，很容易让人认为physx不具备伸缩性，NV对此需要负上责任

kvipol

你概念模糊，我帮你理清
1.我没有说physx烂，physx是一个程序库，一个library，这个库写得烂不烂我不知 ...
rickerlian 发表于 2010-3-5 14:48

您是在指责全球过半数的程序软件商都很废吗?

rickerlian

您是在指责全球过半数的程序软件商都很废吗?
kvipol 发表于 2010-3-5 14:54

是啊，包括nv这个软件商啊

正题
如果你知道全球那些软件商符合废，那些不符合废，请罗列，不要开口埋口就全球，过半，全球的软件商都被你代表了
你就会向我发问这些关于废与不废的问题吗，如果你对lz的贴图有任何观点可以提出。全球的软件商都被你代表了，这些废问题难道就是你的观点

kaven

很多人还是没有理解physx啊

kvipol

是啊，包括nv这个软件商啊

正题
如果你知道全球那些软件商符合废，那些不符合废，请罗列， ...
rickerlian 发表于 2010-3-5 16:58

多的不说了...金山作为国产旗舰软件商已经被你例入废表了.

rickerlian

多的不说了...金山作为国产旗舰软件商已经被你例入废表了.
kvipol 发表于 2010-3-5 17:35

多的不说了，说吧，说了有不会禁言的
就列了一个就说全球了，过半了，吹牛吹到这份上了

Edison

NVIDIA 有 APEX 可以随 GPU 或者CPU 性能而调整特效密度，在 batman 中其实就有这个迹象，如果 benhcmark 的头几次跑得慢，再重跑，就会出现大量物理特效消失的现象。

rickerlian

如果一个程序库如何有效地使用都要client去投入去优化的话，这是可悲的，因为这意味着库作者也不知道如何有 ...
westlee 发表于 2010-3-5 17:57

请列出用havok作为物理引擎而用gpu进行物理加速的游戏的，以及havok用gpu加速跟cpu加速的速度对比
请举例havok用cpu作为运算载体时，不成熟的例子
否则，你把havok甩出来有什么用，能说明什么问题，以及你想说明什么问题

LuoboTixS

看NV已经超INTEL数十年了…
defv4 发表于 2010-3-5 08:34

    笑而不语……Intel才是技术狂人

defv4

笑而不语……Intel才是技术狂人
LuoboTixS 发表于 2010-3-5 19:25

    通常我只是看图说话别无它意~~如有雷同纯属巧合!