CUDA 和DX11 Compute Shader 的差异，

boris_lee

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

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

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

boris_lee

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

呵呵，对于CELL  ...

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

boris_lee

强烈要求本贴加精华!

tomsmith123

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

呵呵，对于CELL  ...

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

tomsmith123

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

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

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

jhj9

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

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

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

boris_lee

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

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

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

tomsmith123

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

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

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

jhj9

原帖由 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

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

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

boris_lee

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


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

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

Edison

游戏开发人员使用 PhysX 根本不需要再安装 CUDA Toolkit 了吧，硬件实现完全是透明的。

tomsmith123

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


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

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

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

疯一样的男子

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


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

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

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

tomsmith123

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


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

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

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

boris_lee

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


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

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