POPPUR爱换

标题: CUDA 和DX11 Compute Shader 的差异， [打印本页]

作者: tomsmith123 时间: 2008-8-26 10:48
标题: CUDA 和DX11 Compute Shader 的差异，
CUDA 和CS 相比，其实多一个层次的东西，CUDA 在和CS 同样提供了计算的API 的同时，还提供了面向US 架构的逻辑抽象工具，让编程着可以从相对容易的角度写GPGPU 程序，这方面CS 还没有，MS 会推出DX11 的SDK，也许会有类库，但是缺乏较好的类库开发手段，这方面CUDA 要好很多。

理论上AMD 也可以支持CUDA 的逻辑抽象，从API 的角度支持CUDA，从而和NV 的显卡站在同一起跑线上，但是如果真这样做了，AMD 卡基于CUDA 的各种评测性能，会比NV卡低，舆论上自然吃亏，DX11 CS 的推出，让AMD 没有必要支持CUDA，而和MS 配合，尽量把CS 中支持A卡的部分做好，就足以和CUDA 来抗衡了，而NV 会面临选择，CS 和CUDA 都不能放弃，孰轻孰重呢？

MS 把CS 放到DX11 里面，而不推出自己的物理计算标准，其实很简单，一旦CS 成熟了，物理加速，就变成纯软件的加速了，标准或者不标准都无所谓，软件的弹性足以客服标准的困难，这对于Physx 或者Havok 都是釜底抽薪的。

作者: rogerguy 时间: 2008-8-26 10:51
提示: 作者被禁止或删除内容自动屏蔽

作者: tomsmith123 时间: 2008-8-26 11:03
影响会很大，也许今天很卖点的技术，明天就完全淘汰了。

作者: Edison 时间: 2008-8-26 11:07
NVIDIA 支持 Compute Shader，他对于能卖掉自己 GPU 的标准都很支持。

作者: darkangel308 时间: 2008-8-26 11:08

原帖由 Edison 于 2008-8-26 11:07 发表
NVIDIA 支持 Compute Shader，他对于能卖掉自己 GPU 的标准都很支持。

必须支持啊，除非NV不想支持DX11了

作者: darkangel308 时间: 2008-8-26 11:09

原帖由水银于 2008-8-26 11:08 发表
AMD不是有CAL/Brook+ 么
CS的意义在于dx11规范之内，这得以使所有显卡都支持这一标准，而不是各厂家依照自家硬件结构开发封闭的GPGPU API

嗯，CS与CUDA最大的区别就是一个是通用的，一个是独家的~

作者: RacingPHT 时间: 2008-8-26 11:12
提示: 作者被禁止或删除内容自动屏蔽

作者: tomsmith123 时间: 2008-8-26 11:12

原帖由 Edison 于 2008-8-26 11:07 发表
NVIDIA 支持 Compute Shader，他对于能卖掉自己 GPU 的标准都很支持。

CS 对于目前NV 的技术优势，CUDA 和GPU Physx 确实是一种打击，甚至会从根本上动摇物理加速存在的意义，从某种意义上，CS 的发布，对于Larrabee 是巨大的利好。

作者: tomsmith123 时间: 2008-8-26 11:15

原帖由 RacingPHT 于 2008-8-26 11:12 发表
这跟Physx 或者Havok有什么关系？

物理加速最初面世是针对特定硬件的类似协处理器处理，对于软件来说，就是API 调用，从不同的硬件，形成了不同的硬件标准，在互相争夺游戏制造商的支持，从而扩大市场份额。
CUDA Physx 为NV 的显卡增加了卖点，也帮助Physx 增加了硬件支持的范围，这本来是极好的布局，不过CS 的出现，让物理加速标准不再重要了，想支持什么API，只要软件里面调用就好了。

作者: boris_lee 时间: 2008-8-26 11:17
cs不等于物理加速...
cuda也不等于物理加速.....

作者: tomsmith123 时间: 2008-8-26 11:22

原帖由 boris_lee 于 2008-8-26 11:17 发表
cs不等于物理加速...
cuda也不等于物理加速.....

都不是物理加速，但是都有可能通过软件手段利用GPU 计算资源，来做现在物理加速卡做的事情。

作者: Edison 时间: 2008-8-26 11:24
PhysX 和 Havok 都不是什么标准，物理引擎本身也不可能存在什么标准，现在的开发商并不需要 Compute shader 就能实现硬件加速，等 Compute Shader 出来后，仍然会有大量的开发商需要完整的物理引擎。

作者: tomsmith123 时间: 2008-8-26 11:26

原帖由 Edison 于 2008-8-26 11:24 发表
PhysX 和 Havok 都不是什么标准，物理引擎本身也不可能存在什么标准，现在的开发商并不需要 Compute shader 就能实现硬件加速，等 Compute Shader 出来后，仍然会有大量的开发商需要完整的物理引擎。

引擎某种意义上就是一种标准，看各人的理解了，基于某一引擎编程，必然要按照某种标准来调用，或者说适应某种引擎的标准接口。

作者: lunew 时间: 2008-8-26 12:23
DX11必然是要支持的, 无论a/n
dx11提供了物理计算, 那px就没啥意义了, 除非nv给足够多的钱, 几个厂商会做重复工作?

作者: darkangel308 时间: 2008-8-26 12:27

原帖由 lunew 于 2008-8-26 12:23 发表
DX11必然是要支持的, 无论a/n
dx11提供了物理计算, 那px就没啥意义了, 除非nv给足够多的钱, 几个厂商会做重复工作?

目前来看，DX11并没有提供物理计算，而是提供了用GPU进行物理计算的途径

作者: tomsmith123 时间: 2008-8-26 12:32

原帖由 darkangel308 于 2008-8-26 12:27 发表

目前来看，DX11并没有提供物理计算，而是提供了用GPU进行物理计算的途径

也就是提供了物理计算的灵活性，可以自行选择需要的物理API。

作者: darkangel308 时间: 2008-8-26 13:52

原帖由 望君珍重 于 2008-8-26 12:35 发表

那也就是说用Px做的游戏，A卡通过CS也能实现物理加速了？就好像现在的N卡通过CUDA实现Px的物理加速一样？

对，当然前提是有人用CS来实现PhysX。其实即便是现在A卡也可以通过CAL来实现PhysX，只不过AMD没这样做。同样，通过CUDA，CS，CAL也可以实现在GPU上跑Havok，而不是像某些人声称的Havok FX已死，不可能在GPU上实现Havok，不过没人来做这个工作而已。当然，除了能不能做到之外，还牵涉到能不能做的问题，毕竟PhysX在NV手上，Havok在Intel手上，只要他们不授权，能做到也不能做

作者: tomsmith123 时间: 2008-8-26 13:55

原帖由 darkangel308 于 2008-8-26 13:52 发表

对，当然前提是有人用CS来实现PhysX。其实即便是现在A卡也可以通过CAL来实现PhysX，只不过AMD没这样做。同样，通过CUDA，CS，CAL也可以实现在GPU上跑Havok，而不是像某些人声称的Havok FX已死，不可能在GPU上实现H ...

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

作者: darkangel308 时间: 2008-8-26 13:57

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

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

这个公开授权是指AMD可以通过GPU来实现Havok加速而不侵权么？我就是对这点不太清楚。

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

作者: boris_lee 时间: 2008-8-26 13:59

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

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

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

作者: boris_lee 时间: 2008-8-26 14:02

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

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

作者: darkangel308 时间: 2008-8-26 14:03

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

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

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

作者: toshibacom 时间: 2008-8-26 14:50

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

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

作者: RacingPHT 时间: 2008-8-26 14:54
提示: 作者被禁止或删除内容自动屏蔽

作者: toshibacom 时间: 2008-8-26 14:56

原帖由 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 时间: 2008-8-26 15:08

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

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

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

作者: tomsmith123 时间: 2008-8-26 15:15

原帖由 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 时间: 2008-8-26 15:17

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

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

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

作者: boris_lee 时间: 2008-8-26 15:20

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

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

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

作者: boris_lee 时间: 2008-8-26 15:57

原帖由 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 时间: 2008-8-26 16:15

原帖由 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 时间: 2008-8-26 16:19

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

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

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

作者: 天下18 时间: 2008-8-26 16:22
提示: 作者被禁止或删除内容自动屏蔽

作者: demonpumpkin 时间: 2008-8-26 16:30
提示: 作者被禁止或删除内容自动屏蔽

作者: darkangel308 时间: 2008-8-26 16:34

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

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

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

作者: toshibacom 时间: 2008-8-26 16:38

原帖由 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 时间: 2008-8-26 16:39

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

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

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

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

作者: darkangel308 时间: 2008-8-26 16:40

原帖由 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编程接口

作者: tomsmith123 时间: 2008-8-26 16:43

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

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

你恐怕又类比错了。
C++ 是主流不假，但是基于C++开发的各种中间技术，一般寿命都很短，往往是一个新的技术出现，会导致旧技术被边缘化。
GPU 支持的物理加速，已经把硬件物理加速存在的意义基本否定了，而同时基于统一的GPGPU 编程接口，可以极大的改善物理计算的效率和代码复用的效率，推动游戏厂商尝试用CS 接口来实现各种物理特效，在这样的背景下，现有的物理引擎很难不被边缘化。
顺便说一下，activex 现在就是一种边缘化的技术。

作者: darkangel308 时间: 2008-8-26 16:46
其实有一种可能是物理计算成为游戏引擎本身的一部分~

作者: Edison 时间: 2008-8-26 16:47
即使 PhysX 和 Havok 采用CS 实现 GPGPU 加速，游戏开发人员依然完全不需要学习 CS 写物理加速代码。

作者: darkangel308 时间: 2008-8-26 16:49

原帖由 Edison 于 2008-8-26 16:47 发表
即使 PhysX 和 Havok 采用CS 实现 GPGPU 加速，游戏开发人员依然完全不需要学习 CS 写物理加速代码。

不过不需要不代表就不会去做了。就像现在游戏公司有买游戏引擎的，也有做游戏引擎的

作者: 奶牛老仙 时间: 2008-8-26 16:51
提示: 作者被禁止或删除内容自动屏蔽

作者: tomsmith123 时间: 2008-8-26 16:53

原帖由 Edison 于 2008-8-26 16:47 发表
即使 PhysX 和 Havok 采用CS 实现 GPGPU 加速，游戏开发人员依然完全不需要学习 CS 写物理加速代码。

如何做一般是公司的意思，一般来说，有自己的引擎会比较灵活可靠而有扩展性，前提是有一个可靠的投资和长期的roadmap。
CS 对做游戏引擎的公司意义巨大，不仅仅是物理加速，有时候AI 也会需要大量的计算。

作者: tomsmith123 时间: 2008-8-26 16:57
CS 最大的问题是，除了VISTA 或者WINDOWS7，还有其他系统可以用吗？

作者: Edison 时间: 2008-8-26 16:59

原帖由 darkangel308 于 2008-8-26 16:49 发表
不过不需要不代表就不会去做了。就像现在游戏公司有买游戏引擎的，也有做游戏引擎的

没错，游戏开发商可以完全一脚踢所有的模块，但是从成本而言，许多公司都会选择采用外购模块授权的方式，而且 PhysX 、Havok 的二进制授权是完全免费的，在物理引擎开发上的时间、人力、金钱成本可以大为节约。

作者: Edison 时间: 2008-8-26 17:00

原帖由 tomsmith123 于 2008-8-26 16:53 发表
如何做一般是公司的意思，一般来说，有自己的引擎会比较灵活可靠而有扩展性，前提是有一个可靠的投资和长期的roadmap。
CS 对做游戏引擎的公司意义巨大，不仅仅是物理加速，有时候AI 也会需要大量的计算。

许多 AI 的行为也可以使用物理引擎来实现。

作者: darkangel308 时间: 2008-8-26 17:00

原帖由 tomsmith123 于 2008-8-26 16:57 发表
CS 最大的问题是，除了VISTA 或者WINDOWS7，还有其他系统可以用吗？

其它系统估计只能靠OpenCL了

作者: boris_lee 时间: 2008-8-26 17:01

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

你恐怕又类比错了。
C++ 是主流不假，但是基于C++开发的各种中间技术，一般寿命都很短，往往是一个新的技术出现，会导致旧技术被边缘化。
GPU 支持的物理加速，已经把硬件物理加速存在的意义基本否定了，而同时基 ...

GPU支持的物理加速不是硬件的难道还是软件的?
厂商当然可以重新发明轮子:w00t):

作者: darkangel308 时间: 2008-8-26 17:02

原帖由 Edison 于 2008-8-26 16:59 发表

没错，游戏开发商可以完全一脚踢所有的模块，但是从成本而言，许多公司都会选择采用外购模块授权的方式，而且 PhysX 、Havok 的二进制授权是完全免费的，在物理引擎开发上的时间、人力、金钱成本可以大为节约。

问题是会永远免费么？另外一个问题就是PhysX 、Havok 会有CS版本么？

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

作者: darkangel308 时间: 2008-8-26 17:02

原帖由 boris_lee 于 2008-8-26 17:01 发表

GPU支持的物理加速不是硬件的难道还是软件的?
厂商当然可以重新发明轮子:w00t):

何谓硬件的何谓软件的？难道你是根据是否跑在CPU上来区分的？

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

作者: tomsmith123 时间: 2008-8-26 17:06

原帖由 Edison 于 2008-8-26 16:59 发表

没错，游戏开发商可以完全一脚踢所有的模块，但是从成本而言，许多公司都会选择采用外购模块授权的方式，而且 PhysX 、Havok 的二进制授权是完全免费的，在物理引擎开发上的时间、人力、金钱成本可以大为节约。

30－40％的有实力的游戏公司会自己开发引擎，免费的二进制授权是便宜了，但是技术上就滞后了，一般来说，我在做一个引擎的概要设计的时候，就可以在新游戏上用了，而不是等到引擎完全完成，游戏才开始开发，这个时间差是大公司选择自己的引擎，而不是购买的主要原因。
自己的引擎修修补补可以用很久，一次次升级而已，而买回来的，很多地方要受制于原始设计。

作者: Edison 时间: 2008-8-26 17:07

原帖由 darkangel308 于 2008-8-26 17:02 发表
问题是会永远免费么？

目前都是免费的，你现在下载的都是免费的，以后的事情谁也说不准，但是免费的事情一般是回不了头的。

NVIDIA PhysX 收费的项目只有源代码部分，二进制是免费的。

作者: draft 时间: 2008-8-26 17:25

原帖由 darkangel308 于 2008-8-26 05:02 PM 发表

问题是会永远免费么？另外一个问题就是PhysX 、Havok 会有CS版本么？

肯定会有的，与px、hk相比，cs才是真正的标准，amd/nv也应该参与了标准制定吧，应该会鼎力支持。

作者: darkangel308 时间: 2008-8-26 17:28

原帖由 draft 于 2008-8-26 17:25 发表

肯定会有的，与px、hk相比，cs才是真正的标准，amd/nv也应该参与了标准制定吧，应该会鼎力支持。

问题是如果nv推出cs版的pk，那就意味着所有显卡都能支持，N卡就会少一个卖点。另外CUDA相比CS的唯一优势也没了

作者: singohuang 时间: 2008-8-26 21:51
现在好难定那个才是未来标准，像当年的 HD 和 BD.........

作者: 电解质 时间: 2008-8-26 23:12
{mellow:] {mellow:]

作者: gaiban 时间: 2008-8-26 23:28
你们越说越离谱了。
根据理解compute shader应该是pixel shader的二级处理器，是为了图像处理。以前GPU是图形处理，而没有图像处理，通过compute shader，可以实现图像处理应用了。

从实际角度看，
你说compute shader搞AI搞物理，等于说用pixel shader做AI做物理一样搞笑。 pixel shader确实是可以搞AI与物理，但是实效就是个笑话。
[attach]912793[/attach]

作者: complexmind 时间: 2008-8-26 23:37
不知道谁说的对了:funk:

作者: gaiban 时间: 2008-8-26 23:45
根据M$的定位,compute shader与CUDA是处于同一层级，两者存在竞争关系。而所有的DX11显卡必须强制支持compute shader， CUDA无法让所有的DX11显卡都支持它。
[attach]912803[/attach]

作者: tomsmith123 时间: 2008-8-27 00:07

原帖由 gaiban 于 2008-8-26 23:28 发表
你们越说越离谱了。
根据理解compute shader应该是pixel shader的二级处理器，是为了图像处理。以前GPU是图形处理，而没有图像处理，通过compute shader，可以实现图像处理应用了。

从实际角度看，
...

不难理解，在pipeline 时代，GPU 就可以做一些密集计算了，US 时代的GPU 计算能力更强，而编程方式更加灵活。

作者: gaiban 时间: 2008-8-27 01:10
除非GPU变成CPU，很难高效跑AI与游戏物理。

一般而言，为了降低难度， AI都给CPU跑，游戏物理也给CPU跑，而特效物理可以交给开源通用的物理引擎。 5年后的通用的物理引擎有可能会调用compute shader计算特效物理，这要看物理引擎厂商的支持了。

作者: darkangel308 时间: 2008-8-27 08:06

原帖由 gaiban 于 2008-8-26 23:28 发表
你们越说越离谱了。
根据理解compute shader应该是pixel shader的二级处理器，是为了图像处理。以前GPU是图形处理，而没有图像处理，通过compute shader，可以实现图像处理应用了。

从实际角度看，
...

[attach]912852[/attach]
[attach]912853[/attach]

作者: jackpeng33 时间: 2008-8-27 08:18
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-8-27 09:43
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-8-27 10:08

原帖由 darkangel308 于 2008-8-27 08:06 发表

912852
912853

DX模式下并没有。可能是写了玩的。

作者: darkangel308 时间: 2008-8-27 10:10

原帖由 gaiban 于 2008-8-27 10:08 发表

DX模式下并没有。可能是写了玩的。

什么DX模式下没有？

作者: gaiban 时间: 2008-8-27 10:11
考虑后台老板的关系，Havok都用CPU,要么就用larrabee native。 Physx也会类似。

作者: tomsmith123 时间: 2008-8-27 10:22

原帖由 RacingPHT 于 2008-8-27 09:43 发表

我想你可能根本没有游戏开发经验，所以说出来的东西总感觉不靠谱。
1：物理引擎本身就是跨平台的，不论Havok, 还是Physx。在所有的硬件层面上，调用习惯是几乎一致的，根本不需要理会底层究竟是什么硬件。
2： ...

我想你有想错了，我恰恰做过一段游戏的PM，后来才转架构。
你反复强调的就是可以直接调用，而忽视了开发过程中需要的灵活性，很简单的例子是，我需要的特效，物理引擎没有，怎么处理？另一个问题是，除了物理引擎外，事实上做相关游戏的厂商，手头都有一些自己的模型，代码，游戏公司和软件公司一样，积累最多的就是各种模块，当模块足够丰富的时候，会组合成为一套引擎，进一步开发，可能会对公司长久的发展很有帮助。当游戏公司有一定实力和前瞻性的时候，自己做引擎都是很自然的事情，之所以用Havok Physx 一方面是比较简单省事，硬件配合上是标准化的，另一方面是物理引擎公司的推广，当有另外的选择的时候，比如GPU 软件加速，可以在自身引擎中加入适合自己的特效，很多游戏公司都会自己做的，同时还有专门的游戏引擎公司也来做，对于通过硬件完成市场初步布局的Havok Physx ，这都不是好消息，你还是无法理解？

作者: tomsmith123 时间: 2008-8-27 10:26
换言之，在CS 和CUDA 之前，游戏公司自己开发一套物理引擎，或者基于Havok Physx 扩展，有很多技术壁垒，而现在，相对要容易很多，有了CS，对于任何显卡都支持，那么在DX 下开发需要的物理特效，完全可以不考虑硬件支持的情况，而保持较高的运行效率。

作者: toshibacom 时间: 2008-8-27 10:36
微软在DirectX8中，首次引入了Pixel Shader和完善了Vertex Shader，在DX9中又发展了PS和VS，到DX10中PS和VS就和在一起了，现在DX11中引入Computer Shader，说不定在DX12或DX13中，CS也最终会和PS VS合一起了。

作者: jackpeng33 时间: 2008-8-27 10:44
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-8-27 11:13
提示: 作者被禁止或删除内容自动屏蔽

作者: tomsmith123 时间: 2008-8-27 11:25

原帖由 RacingPHT 于 2008-8-27 11:13 发表

既然你觉得，CS有助于“增加特效”，那么我想问问究竟是什么CS特效呢？
至于扩展问题，我觉得大公司授权的时候，很多都要求源代码或者技术支持。至少我手上，就有一份Physx早期的源代码。
而CS，会让物理引擎的 ...

有些事情，是不方便到处说的。
CS 的计算能力，我的理解和CUDA 是一致的，也就是说CUDA 可以做的，CS 也一般可以做，我目前手头的项目就包括CUDA 做石油地质和药物分子对接的移植优化，效果是非常好的，DX11发布后，任何显卡都可以有类似的接口，只会更方便。
CS 或者CUDA 释放的GPGPU 能力，对于物理计算或者AI 都会很方便，只要游戏设计中适当考虑负载均衡，这不是个问题吧？
可以通过商业授权拿到源代码，但是如果需要进一步的开发扩展，恐怕源代码授权也是不够的，更何况每个公司有自己的开发风格，基于自身代码扩展和他人代码扩展，不是一个复杂度。从游戏开发的角度，往往做引擎的人完成功能和接口设计，做游戏代码的人就已经准备好用这个引擎了，这也是现成商业引擎很难提供的便利性。
CS 相对于物理引擎，好象是路和车的关系，路修宽了，修平了，就没必要等公共汽车了，自己买车开多好？

作者: RacingPHT 时间: 2008-8-27 11:30
提示: 作者被禁止或删除内容自动屏蔽

作者: tomsmith123 时间: 2008-8-27 11:38

原帖由 RacingPHT 于 2008-8-27 11:30 发表
呵呵，我的经验可以告诉你，用CS做物理引擎的技术门槛比C++只高不低。

我考你几点：
1: CS/CUDA如何有效构造Hash table?
2: CS和CPU使用什么方法进行有效同步，或者说lock-step式的合作？
3: CS上怎样使用物理 ...

你想说DHT 在CUDA 上如何用？或者数据一致性如何保证？这些都是并行计算的经典问题。
C++ 其实没什么门槛的，描述性语言而已，CUDA 的TLP 和MPI OPENMP 当然不好比，不过和CELL BE 比，复杂性基本是一个数量级的，甚至还要低一点。
我想你恐怕还没有CELL BE 或者CUDA 的编程经验，所以你有这样的经验模式，对于CFD 类似的计算，在CUDA 和CELL BE 上效果都不错，不过某些强DD 的计算，在GPU 或者CELL 都有问题，这也是我为什么更倾向软件物理引擎，因为可以吧不同的计算合理分配到不同的计算部件上。

作者: tomsmith123 时间: 2008-8-27 11:43

原帖由 RacingPHT 于 2008-8-27 11:30 发表
呵呵，我的经验可以告诉你，用CS做物理引擎的技术门槛比C++只高不低。

我考你几点：
1: CS/CUDA如何有效构造Hash table?
2: CS和CPU使用什么方法进行有效同步，或者说lock-step式的合作？
3: CS上怎样使用物理 ...

顺便说一下，你还没有表现出你对GPGPU 计算的任何了解或者经验。
我可以给你出个题目，你用CUDA 试一下，你会发现CUDA 做线程同步，没有那么可怕。
模拟一个闭系统的分子运动，每个分子有其质量，相互引力，初速度随机产生，空间位置随机，基本均匀分布，取离散时间间隔为1us，其他条件可以自己设定。

作者: RacingPHT 时间: 2008-8-27 11:55
提示: 作者被禁止或删除内容自动屏蔽

作者: boris_lee 时间: 2008-8-27 12:01

原帖由 tomsmith123 于 2008-8-27 11:25 发表

CS 相对于物理引擎，好象是路和车的关系，路修宽了，修平了，就没必要等公共汽车了，自己买车开多好？

我觉得您是想造车....:sweatingbullets::sweatingbullets:

作者: RacingPHT 时间: 2008-8-27 12:01
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-8-27 12:02
提示: 作者被禁止或删除内容自动屏蔽

作者: boris_lee 时间: 2008-8-27 12:03

原帖由 RacingPHT 于 2008-8-27 11:55 发表
为什么不回答我的问题呢？连一条都答不上就扯东扯西？我问你的是物理引擎。不关分子运动什么事。如果你是分子运动专家，很好，但是不要对你不熟悉的领域大肆评论。你这样除了误导别人没有好处。

呵呵，对于CELL ...

分子运动算是物理模型之一吧....

作者: boris_lee 时间: 2008-8-27 12:04
强烈要求本贴加精华!

作者: tomsmith123 时间: 2008-8-27 12:04

原帖由 RacingPHT 于 2008-8-27 11:55 发表
为什么不回答我的问题呢？连一条都答不上就扯东扯西？我问你的是物理引擎。不关分子运动什么事。如果你是分子运动专家，很好，但是不要对你不熟悉的领域大肆评论。你这样除了误导别人没有好处。

呵呵，对于CELL ...

我觉得没必要回答你的问题，顺便告诉你，物理引擎中很大部分，要做的加速，就是针对CFD 或者分子粒子运动模拟。
如果你熟悉CUDA 或者CELL BE，你应该知道在CUDA 上有CUDA Physx，在CELL BE 上也有Havok，能否说明在类似的部件上做物理引擎，至少不是太复杂的事情呢？或者你感觉除了极少数公司外，其他人根本做不了呢？

作者: tomsmith123 时间: 2008-8-27 12:06

原帖由 RacingPHT 于 2008-8-27 12:01 发表
随便扯个“这些都是并行计算的经典问题”就糊弄过去了？很好。那我告诉你，这个问题是经典的GPGPU不擅长解决的问题。幸好CUDA/CS还是提供了一线希望。随便考一下都过不去了么？

或者我再问你：如何在CUDA上实现内 ...

并行计算可不是GPGPU，而是向量机先导的目前以集群为主的计算模型。
对不起，你的这个问题我感觉莫名其妙。

作者: jhj9 时间: 2008-8-27 12:08

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

物理加速最初面世是针对特定硬件的类似协处理器处理，对于软件来说，就是API 调用，从不同的硬件，形成了不同的硬件标准，在互相争夺游戏制造商的支持，从而扩大市场份额。
CUDA Physx 为NV 的显卡增加了卖点，也 ...

Havok就是纯软的，为什么有那么多人在用呢？自己开发工作量、成本更高不说，效果也不见得好。
有现成成熟的东西为什么不用呢？

作者: boris_lee 时间: 2008-8-27 12:08

原帖由 tomsmith123 于 2008-8-27 12:06 发表

并行计算可不是GPGPU，而是向量机先导的目前以集群为主的计算模型。
对不起，你的这个问题我感觉莫名其妙。

gpgpu不是高度并行化的向量机么?:sweatingbullets:

作者: tomsmith123 时间: 2008-8-27 12:11

原帖由 boris_lee 于 2008-8-27 12:08 发表

gpgpu不是高度并行化的向量机么?:sweatingbullets:

GPU 的特点是ALU 是简化的，针对图形处理的，以管线组织的一类处理器，和向量机或者普通处理器差距比较大。

作者: jhj9 时间: 2008-8-27 12:11

原帖由 tomsmith123 于 2008-8-27 11:25 发表

有些事情，是不方便到处说的。
CS 的计算能力，我的理解和CUDA 是一致的，也就是说CUDA 可以做的，CS 也一般可以做，我目前手头的项目就包括CUDA 做石油地质和药物分子对接的移植优化，效果是非常好的，DX11发布后 ...

CS的具体接口和细节都还没有出来，就说“只会更方便”并不现实。
要兼顾各种硬件，在功能和性能上恐怕会打折扣的，虽然对硬件的支持广度确实只会更好。

路是修好了，但是每个人都要自己造车来开吗？
如果要走这条路必须自己造车(因为你说的是用CS来自己写一套物理引擎)，而走另外一路（比如铁路）有现成的、低成本的成熟交通工具可以搭乘，有多少人会去选择自己造车呢？
按你说的，C++是不是条路？怎么没见多少人用C++写一套物理引擎出来，而是去用现成的Havok或者PhysX呢？

[ 本帖最后由 jhj9 于 2008-8-27 12:17 编辑 ]

作者: jhj9 时间: 2008-8-27 12:22

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

额外装个CUDA开发包，和在新版本VS中原生支持（要用也的专门指定引用特定包），我看不出有多少太大的区别。

作者: boris_lee 时间: 2008-8-27 12:27

原帖由 jhj9 于 2008-8-27 12:22 发表

额外装个CUDA开发包，和在新版本VS中原生支持（要用也的专门指定引用特定包），我看不出有多少太大的区别。

msdn library还是很nb 的:wacko:
不过dx在vs中都没有原生支持,别说 cs了:shifty:

作者: Edison 时间: 2008-8-27 12:42
游戏开发人员使用 PhysX 根本不需要再安装 CUDA Toolkit 了吧，硬件实现完全是透明的。

作者: tomsmith123 时间: 2008-8-27 12:49

原帖由 jhj9 于 2008-8-27 12:11 发表

CS的具体接口和细节都还没有出来，就说“只会更方便”并不现实。
要兼顾各种硬件，在功能和性能上恐怕会打折扣的，虽然对硬件的支持广度确实只会更好。

路是修好了，但是每个人都要自己造车来开吗？
如果要 ...

CS 如果要做的话，会针对不同的硬件厂商，由不同硬件厂商协助开发面向硬件驱动的部分，而由MS 统一抽象出接口，与CUDA 这样直接针对硬件驱动开发的接口比，效率会略低。
MS 推出CS 的目的，上面的PPT 也很清楚了，希望游戏厂商利用CS 做物理和相关的计算，不一定每个游戏厂商都来做自己的引擎，但是对于自己有引擎的厂商，在其中加入一些需要的有特点物理特效，很明显是方便的。

作者: 疯一样的男子 时间: 2008-8-27 12:50

原帖由 jhj9 于 2008-8-27 12:11 发表

CS的具体接口和细节都还没有出来，就说“只会更方便”并不现实。
要兼顾各种硬件，在功能和性能上恐怕会打折扣的，虽然对硬件的支持广度确实只会更好。

路是修好了，但是每个人都要自己造车来开吗？
如果要 ...

如果你这条路只能某些车通过的话，还不如自己造一条所有车都能通过的路，因为人家要收路费过日子的。

作者: RacingPHT 时间: 2008-8-27 12:59
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-8-27 13:05
提示: 作者被禁止或删除内容自动屏蔽

作者: tomsmith123 时间: 2008-8-27 13:12

原帖由 RacingPHT 于 2008-8-27 13:05 发表

其实物理计算，实现并行化当然很困难，因为物体之间的依赖性比较复杂。然而实现物理计算即便是做一个单线程的数值稳定版本就非常困难。

可能一般人理解的游戏物理只是高中的那几条公式，然而对于一个多成员的 ...

恩，碰巧我最近都在做类似的项目，物理模型的复杂度可能会很高，但是可以计算的物理模型据简单多了。
为什么我说CUDA 能够解决相当一大类的问题呢？复杂物理现象的模拟，很多时候是有局部性的，依次计算局部各点的属性变化，整体叠加一下，这是CFD 基础下的分子模拟计算，要到了流体向量场的规模，就复杂多了。普通分子模拟是散布，回收，更新，再散布的工作模式，而很多计算的数据依赖很严重(DD)，很难理想散布出去，或者很吃带宽，这样的计算如果局部重量级不够，最好在CPU 上做。
复杂的计算如果原理很清楚，编程还是不难的，不过物理和其他强调算法的计算一样，需要程序员从原理上理解算法，或者是熟悉算法的专业人员自己编程，后者的代码优化余地非常大。。。

作者: boris_lee 时间: 2008-8-27 14:00

原帖由 疯一样的男子 于 2008-8-27 12:50 发表

如果你这条路只能某些车通过的话，还不如自己造一条所有车都能通过的路，因为人家要收路费过日子的。

铁路上只能跑火车
怎没见铁路乘客纷纷投资自建高速了:whistling:

欢迎光临 POPPUR爱换 (https://we.poppur.com/)