CUDA 和DX11 Compute Shader 的差异，

boris_lee

原帖由 tomsmith123 于 2008-8-26 13:55 发表

Intel 的Havok 是公开授权的，AMD 应该是等MS 的CS 或者类似的产品，他们私下应该有过沟通。

公开是非商业授权.
否则前几天也不会出现MS拿到havok永久授权的新闻了
而且,授权是可以随便用,不是可以随便改.....

boris_lee

原帖由 darkangel308 于 2008-8-26 13:59 发表
相比CUDA，CS其实还有一个很大的优势，那就是微软能在VS中提供原生支持，并对其进行优化，相信windows下的程序员不用VS的应该不多吧？

vs里连dx的原生支持都没有吧,要安sdk...
当然vs比nvcc用起来方便得多.dx sdk的一些设计也更符合win程序员的习惯

darkangel308

原帖由 望君珍重 于 2008-8-26 14:00 发表
AMD能过将来的CS跟CUDA实现Px跟Ha。。。通吃{blush:]
比较梦哈

如果CS把CUDA灭掉了，NV还是很有可能推出cs版的physx的

tomsmith123

AMD 加入Havok 的标志，就是Intel 给AMD 授予了Havok 的授权，应该和普通游戏开发商的授权不同。
MS 也差不多。

toshibacom

原帖由 tomsmith123 于 2008-8-26 14:17 发表
AMD 加入Havok 的标志，就是Intel 给AMD 授予了Havok 的授权，应该和普通游戏开发商的授权不同。
MS 也差不多。

Havok需要AMD的支持，PhysX也需要AMD的支持，AMD倒向任何一方，任何一方就会有很大的优势，PhysX和Havok对于AMD来说都是免费送上门的待选标准，期望得到AMD的支持，目前看来AMD支持Havok。

toshibacom

原帖由 kvip 于 2008-8-26 14:53 发表


对于这种墙头草现在扮演着很重要的角色,不过如果等HAVOK和PX定下来了.就没什么好果子吃了.

这怎么是墙头草呢？AMD从来没有说过支持PhysX，一直都是支持Havok的，倒是NV，一开始支持Havok，后来收购physX，反而是NV才是2边倒的墙头草。{lol:]

[ 本帖最后由 toshibacom 于 2008-8-26 14:57 编辑 ]

boris_lee

原帖由 toshibacom 于 2008-8-26 14:56 发表

这怎么是墙头草呢？AMD从来没有说过支持PhysX，一直都是支持Havok的，倒是NV，一开始支持Havok，后来收购physX，反而是NV才是2边倒的墙头草。{lol:]

physx 在amd cpu上可以运行吧
好像还是要把物理api和物理api加速分开

tomsmith123

原帖由 RacingPHT 于 2008-8-26 14:54 发表
你根本就没搞明白物理加速和编程接口的关系。
比方说，Havok是用C语言写的，那么是不是所有可以使用C语言的程序员/公司都不需要Havok了呢？很简单的逻辑套在CUDA或者CS上也是一样的。

我想你误会了，我要说的就是这个问题，为什么会有Havok 和Physx 两种引擎或者标准，因为分别有两家公司做了物理卡出来，进一步Havok Physx 把物理卡的接口标准向其他硬件转移，CPU，GPU，包括Cell 在内，但是标准调用习惯，还是遵守其物理卡时制定的接口，CUDA Physx 的出现已经动摇了物理引擎作为标准的基础，对于任何开发商来说，按照物理加速的编程习惯做物理效果和按照自己的习惯调用CUDA 做物理效果，是没有本质性的差别的，后者会更灵活，CS 的出现进一步说明了MS 的立场，从软件调用GPU 资源来实现物理加速，是否遵守Havok Physx 标准开发，游戏厂商可以看着办，第三方软件商也可以提供新的物理引擎，更加适合游戏需要的计算也会逐步增加，所以我说CS 的出现很可能会让Physx Havok 边缘化，物理标准的战国时代也许就此展开，最终统一到某个标准进入DX。

toshibacom

原帖由 boris_lee 于 2008-8-26 15:08 发表

physx 在amd cpu上可以运行吧
好像还是要把物理api和物理api加速分开

能跑，不代表支持，windows上还能运行firefox呢，MS支持firefox还是IE？

boris_lee

原帖由 toshibacom 于 2008-8-26 15:17 发表

能跑，不代表支持，windows上还能运行firefox呢，MS支持firefox还是IE？

看来接下来要讨论"支持"的定义了:funk::funk:

boris_lee

原帖由 tomsmith123 于 2008-8-26 15:15 发表

我想你误会了，我要说的就是这个问题，为什么会有Havok 和Physx 两种引擎或者标准，因为分别有两家公司做了物理卡出来，进一步Havok Physx 把物理卡的接口标准向其他硬件转移，CPU，GPU，包括Cell 在内，但是标准调 ...

CS的level低于havok/px....
isv当然 可以和crytek一样选择从 x86或者cuda或者cal,自己写物理处理
也可以不做重新发明轮子的工作,直接拿havok/px用,havok/px 底层用cuda /x86/cal/ppc实现,isv无需关心,是intel 和nv的事情
havok/px是中间件
和UE3这样的东西是类似的,
难道有了dx,ue3就没前途了?

tomsmith123

原帖由 boris_lee 于 2008-8-26 15:57 发表

CS的level低于havok/px....
isv当然 可以和crytek一样选择从 x86或者cuda或者cal,自己写物理处理
也可以不做重新发明轮子的工作,直接拿havok/px用,havok/px 底层用cuda /x86/cal/ppc实现,isv无需关心,是intel 和 ...

现有的物理加速标准，优点在于支持完善，但是和软件相比，灵活性比较差，不同公司间的技术差很难体现。
当硬件加速比较流行的时候，很多公司会用现成市场现有率大的物理加速引擎，而软件加速成为主流的情况下，和软件引擎一样，物理加速变成多样化的产品，在CS 或者CUDA 广泛使用的时候，会有越来越多的公司开发自己的物理引擎，或者出售自己的物理引擎，这种情况下，现有物理引擎标准，很容易被边缘化。

boris_lee

原帖由 tomsmith123 于 2008-8-26 16:15 发表

现有的物理加速标准，优点在于支持完善，但是和软件相比，灵活性比较差，不同公司间的技术差很难体现。
当硬件加速比较流行的时候，很多公司会用现成市场现有率大的物理加速引擎，而软件加速成为主流的情况下，和 ...

再次重复一遍
"物理引擎" 和"物理引擎硬件加速"是两码事.
c++成为主流,也没见activex被边缘化吧....

darkangel308

原帖由 demonpumpkin 于 2008-8-26 16:30 发表
可以这样分层次

app -> Physx or Havok  -> Dx11 Conpute shader -> Driver (cuda) -> GPU

分错了，CUDA和CS是一个层次的东西

toshibacom

原帖由 demonpumpkin 于 2008-8-26 16:30 发表
可以这样分层次

app -> Physx or Havok  -> Dx11 Conpute shader -> Driver (cuda) -> GPU

NV理想状态是：
app -> Physx -> CUDA -> Driver  -> GPU，如果cuda在Driver一级，用来解释执行DX11 Computer Shader，那以后大家都会用CS编程，CUDA就会成为NV内部的东西，NV大力推广CUDA就会变成无用功了。

darkangel308

原帖由 boris_lee 于 2008-8-26 16:19 发表

再次重复一遍
"物理引擎" 和"物理引擎硬件加速"是两码事.
c++成为主流,也没见activex被边缘化吧....

我想你是误解了tomsmith123 的意思。他应该是指GPGPU使得无需专门的硬件支持便可以开发出复杂的物理引擎（可能叫“引擎”不是很准确），从而降低了物理引擎的门槛，比较大的公司可能会因此自己开发物理引擎。在只有CPU的情况下一些公司已经这样做了，再加上CS等GPGPU接口带来的强大计算能力，可能会有更多的公司这样做

[ 本帖最后由 darkangel308 于 2008-8-26 16:47 编辑 ]

darkangel308

原帖由 toshibacom 于 2008-8-26 16:38 发表

NV理想状态是：
app -> Physx -> CUDA -> Driver  -> GPU，如果cuda在Driver一级，用来解释执行DX11 Computer Shader，那以后大家都会用CS编程，CUDA就会成为NV内部的东西，NV大力推广CUDA就会变成无用功了。

事实也确实如此，CUDA和CS是对手，都是GPGPU编程接口