PCINLIFE特约：深入浅出谈CUDA by hotball

Edison

原帖由 GZboy 于 2008-6-6 13:11 发表
第二个想告诉你的是，早在X264 还是R37版本的时候，就自己编译源码做测试了，对于X264的了解我不会比你差。

linux下这是最常见的动作，没什么好炫耀的。

Edison

问题是你认定CUDA只能做到低容量、低质量的说法毫无根据，而且在我已经给出实际播放截图的情况下依然顽固坚持，其依据仅仅就是你个人毫无依据的猜想。


3Mbps 720p by CUDA 60fps编码速度：

Edison

CUDA不是一个固化的编程模型，是作为异质运算架构出现，没有一个硬件编码器在里面，在作h264编码的时候同样支持多样化的设置，这完全取决于你自己的需要以及编码器本身开放的设置上，上面的截图就是平均码率为3Mbps下的效果，而目前普遍的BDrip 720p都接近3Mbps的水平，CUDA完全适合于在相当码率下提供高质量的BDRip或者HDrip。

daniel_k

GZ说的是可变bit率编码吧？另老陈说的东西恐怕就是CUDA编码264处理器资源占用高的原因吧？:loveliness:
PS下哈：CUDA的1.0和1.1还有2.0有啥区别没？现在下载的CUDA驱动都是基于G8X的，也就是CUDA1.0，用在G9X上面是不是效率会降低亚？

[ 本帖最后由 daniel_k 于 2008-6-6 16:35 编辑 ]

Edison

CUDA 1.1增加了G9X、WinXP 64bit的支持，提供了新版驱动。

CUDA 2.0 beta Vista支持以及可能的下一代产品支持。

有些运算还是适合于CPU上跑的，例如一些无法并行化的模块——CABAC等，这样的模块在CPU上同样无法并行化。

Norways_Winter

这套文章不错

虽然只是简单的算法 但是整个演进的过程很详细 看着十分赏心悦目啊

NV 的优势在于可以通过强大的软支持 在维持原有 C/C++ 开发习惯的前提下提供支持 GPU 的编译器

这点对加速推广和提升普及度是很有好处的

EDIT: 突然发现打扰 LS 几位了 - -

看了下帖子 GZboy 有些说的不错 闪人

[ 本帖最后由 Norways_Winter 于 2008-6-6 20:24 编辑 ]

yyzjp

非常精彩, 我仔细的看了一下 平方数求和的那个函数, 矩阵预算没看

本文的很多灵光一闪让我恍惚回到了 学习计算机系统的大学时光,  作者有非常丰富而清晰的Cycle, 连续内存, Bandwidth, 线程并行, Register 知识, 最兴奋的是 平方数求和那个, 256个线程开始看起来貌似是一个线程同时存取一块连续的内存, 然后作者告诉我们Lantency原因, 必须跳着访问, 这个和CPU上 编程还是很大不同的,  怪不得微软公司的架构师 (Microsoft SPP部门的 ) 都跳槽去做图形芯片并行库开发区了

然后是那个什么 Bank Conflict? 貌似是16倍的字节对齐可以解决部分问题, 这个和C编译器自动对齐结构 方便CPU寻址是异曲同工之妙啊

我的看法是, 如果想矩阵运行, 加解密, 平方和累加等等 各种函数封装成完备的接口， CUDA 能自动实现并行优化就好, 我给你一个数组, 你自己觉得 并行多少个Thread, 利用多少个Block 和SharedMemory, 就好了

否则ＣＵＤＡ程序员的门槛还是很高的，　要对ＮＶ的ＧＰＵ的架构非常熟悉，　对于内存带宽，　ＰＣＩ　Ｅｘｐｒｅｓｓ，　ＣＰＵ，　操作系统都要有非常深刻的认识，　才能写出很漂亮的程序

无论如何，这是一个软件＋硬件高手写的漂亮文章，　收益匪浅

谢谢楼主的转载！　以后自己攒机了一定写程序试试．:loveliness:

[ 本帖最后由 yyzjp 于 2008-6-6 22:07 编辑 ]

Edison

现在是有一些这样的东西出来，例如那个cuDPP。

http://www.gpgpu.org/developer/cudpp/

（可能需要代理才能访问上面的连接，我用Foxmail+T or）

Edison

原帖由 daniel_k 于 2008-6-6 16:32 发表
GZ说的是可变bit率编码吧？

也许他当时是这样的想法，不过后来他在另一CUDA h264编码讨论的主题中也都承认了CUDA是变码率的，再后来在那里就说兼容性之类的问题，我也把一个不需要安装任何显卡驱动都能用CPU跑的CUDA程序提供给他了，最后说到软件开发人员应该也考虑其他显卡的加速，这个其实不是问题的问题我也都回答他了。

leedio

关键还是配套的软件的易用性，
现在制片组用的那几压片软件，都已经有自己的经验了， 用起来非常顺手了，
怕就怕CUDA的配套软件，期待有完整的样片放出

Edison

原帖由 GZboy 于 2008-6-7 08:43 发表
我说的并不是可变码率，因为这个容易实现！ 我认为通CUDA 编程GPU也是可以做到可变码率编码的。
但像X264中的 Mixed refs 、trellis 等等高级复杂功能只能由CPU来执行。

我没有看到x264 CUDA，但是像CABAC这样的特性本身在CPU上执行也都是无法并行处理的，换句话说你要质疑CUDA不能跑CABAC，不如质疑多线程能应用于多少h264编码的模块上，这样的处理在CPU上也都是无法并行处理的。

CABAC本身是可以在非CPU的芯片上执行的，透过流水线化完全可以在其他芯片上高效的执行。

基本上是能从CPU多线程化得益的模块在CUDA上也是能获益的，对于无法从多线程或者是其他并行化方式获益的计算，留在CPU上跑好了，这就是异质架构运算。

后来你提供的“不用安装任何显卡驱动都能用CPU跑的CUDA程序” 程序其实里面是2套代码，一套是GPU跑，
另一套是CPU跑。程序里面的指令 ATI 的GPU能执行吗？？！ 使用ATI 的GPU 有加速功能吗？？！
难道这就是NV对友商的GPU的兼容性！！？

Intel的编译器有没有对Power、SPARC、MIPS这样标准定义非常严格公开的ISA提供支持呢？

同理，完全不同ISA、编程模型差异巨大、资料几乎没有公开的其他GPU类型，NVIDIA CUDA为啥要提供直接的支持？他只要保证这个代码能让搭配这些GPU的系统运行即可。

回过头来看看 INTEL的 SSE ，即使在友商AMD的U上也是能被硬件执行的，实实在在的兼容性，行业标准。
NV的市场占有率仅有3成多一点，CUDA 的"潜在顾客" 数量远比 SSE少，做软件开发不能不考虑占6成多的非 NV 用户，
况且CUDA的编程难度很高，正如你自己说的话“对于无法实现或者难以实现以及市场占用率很少、甚至只会导致性能
下降的产品，开发人员不选择对其支持是非常合理的。”

你有看到过Intel提供3D Now!的支持？你有看到过Intel对MMX+的支持吗？对于对手完全没有公开资料的ISA，CUDA怎么提供支持？

在其他ISA的GPU上执行CUDA完全是对手的问题，与NVIDIA何干？

你对CUDA的许多非技术问题本身你只要稍微动动脑筋就能得出答案，但是却因为你对CUDA的偏见让你无法得以正常的心态来思考问题。

pz1350822

请问AMD的显卡支持CUDA吗 ？如果不支持，那AMD的显卡不是没多大的潜在价值吗。。生存空间将会越来越小

Edison

原帖由 pz1350822 于 2008-6-7 12:02 发表
请问AMD的显卡支持CUDA吗 ？如果不支持，那AMD的显卡不是没多大的潜在价值吗。。生存空间将会越来越小

AMD有CAL/Brook+，Intel有Ct。

Prescott

Ct不是Larrabee的编程语言。
我再强调一遍，Ct只是研究项目，不是产品。

Edison和几年前一样，还是暴力计算能力的拥护者。缺乏的是对程序设计的基本了解，所以很容易就被Cell/CUDA的超高理论计算能力吸引，于是认为找到了灵丹妙药。我在Edison吹嘘Cell的时候就明确的说过，Cell没有前途，Cell的理论计算能力想要发挥出来几乎不可能。当时的Edison是绝对不会认同我的看法的。但是事实已经证明了了一切。

今天Edison还是不会认同我的看法，但是事实还是会证明一切。

我的观点是：异构计算是未来的方向，数量不多的几个复杂处理器核心负责处理逻辑和事物，加上数量庞大的简单核心负责高并行度的浮点计算。nVidia应该说在提供大规模的浮点并行能力方面是先走了一步，Intel也看到了这个趋势，所以才会有Larrabee。相对于Cell，NV最大的优势是业已存在的庞大用户群。而且Cuda的编程也比Cell简单。

但是具体到实际的产品和某个公司的前途，我并不认为NV和Cuda会是最终的胜利者。原因很简单，NV要面对的是摩尔定律。这个定律决定了最终PC或者计算设备中除了一块主芯片之外，其他的芯片都会被边缘化。NV有能力成为整个计算机产业的中心吗？

另外关于Larrabee，千万不要小看Intel的决心，如果Intel不打算在独立GPU市场上占据领导地位，慢慢的发展集成显卡就是了，何必搞个性能不伦不类的GPU出来

[ 本帖最后由 Prescott 于 2008-6-7 17:32 编辑 ]