第1页 - CUDA是什么？能吃吗？

第2页 -  CUDA Toolkit的安装

第3页 -  第一个CUDA程序

第4页 -  改良第一个 CUDA程序

第5页 -  第二个 CUDA程序

第6页 -  GPU 的硬件架构

SF.....

提问：CUDA或者说G80里的constant memory是做什么用的，为什么要把它单独划分出来呢？

constant memory和texture memory都在device memory（显卡内存）中，但是它们都是cached的，访问效率较高，而且都是read-only的，constant memory没有固定的数据模板，而texture memory是阵列方式的。

开发一个利用CUBA编码H。264的程序吧，现在光能硬件解码，不能硬件编码，可惜

http://forum.doom9.org/showthread.php?t=137459，x264的开发人员还在研究，例如什么活最适合在CPU上执行。

最后结论是，没什么活适合在GPU上执行。[lol>

不信的话，就等着看那个Lame能用CUDA快多少吧 哈

[ 本帖最后由 Prescott 于 2008-6-5 12:40 编辑 ]

初步结论是在目前在lowest seting上 x264 9600gt cuda 720p是quad core的3.8倍，就在我给的那个连接中。

lame encoder现在我昨晚看的时候也就是4个提交了，还有两个月的时间。

编者注：NVIDIA的GeFoce 8800GTX发布后，它的通用计算架构CUDA经过一年多的推广后，现在已经在有相当多的论文发表，在商业应用软件等方面也初步出现了视频编解码、金融、地质勘探、科学计算等领域的产品，是时候让我们对其作更深一步的了解。为了让大家更容易了解CUDA，我们征得Hotball的本人同意，发表他最近亲自撰写的本文。这篇文章的特点是深入浅出，也包含了hotball本人编写一些简单CUDA程序的亲身体验，对于希望了解CUDA的读者来说是非常不错的入门文章，PCINLIFE对本文的发表没有作任何的删减，主要是把一些台湾的词汇转换成大陆的词汇以及作了若干"编者注"的注释。

E大把这个能变个字体吗?斜着看起来不舒服,最主要是的是字体很细.

引用:

原帖由 GZboy 于 2008-6-5 20:37 发表
也就是Dark Shikari说的一句话而已，没test的祥细数据，也没相关程序提供测试
而且舍弃N多提升画质功能后的劣质压缩，不用cuda也能快几倍。
当X264 for GPU encoder 能达到CPU encoder 的PSNR再说吧。

Dark Shikari是x264的开发人员，他说的话比你说的可信度高多了，等你有他这个水平再来否定也不迟。

NVIDIA作演示时候采用的设置比在CPU上的更高，这你又不知道了吧。

引用:

原帖由 GZboy 于 2008-6-5 23:10 发表
哦哦~原来你的意思是名人说的话可信度就高~ 就不需要做实验去验证是否真实了~
看来我提出“  要做实验验证”，触及某些人的权威了。
"NVIDIA作演示时候采用的设置比在CPU上的更高" -->这个我倒是不知道你想说什么
我上面说的是做X264 GPU encoder 和CPU encoder的PSNR对比，你会错意了？

在没有条件验证的情况下，当然是听当事人本人的说法，x264就是他做的开发，又不是你我，你要对其质疑，大可上doom9上提出。

我这里有RadiHD压出来的视频，画面还不错，如果你要追求极致的品质，直接找原厂要2xxMbps的源盘好了，反正这个时间比你压片的时间还短

Dark Shikari现在是在一家广播服务公司做x264 CUDA的开发，他们这套东西就是要作为业务使用的，如果速度、画面品质不能取得均衡，他们还会花时间在这个上面吗？

gt200是不是支持64位的浮点啊

引用:

原帖由 以前的密码没了 于 2008-6-6 10:46 发表
gt200是不是支持64位的浮点啊

yes，1/8 fp32性能。

引用:

原帖由 GZboy 于 2008-6-6 12:23 发表
花时间不等于会有想要结果，说不定更多是出于商业的利益，
况且如果花这些时间去做SIMD的优化，效果是立杆见影的，因为有统一的标准，下几代U中还能享受现在优化的成果。
而CUDA风险太高，说不定某天出个 ...

x264很早已经是支持SSE2/SSE3了，对于一个源代码公开的程序你看都不看就信口开河地认为x264没有simd优化有意思吗？

写CUDA程序根本不需要考虑SIMD的问题，而写SSE程序你必须熟悉汇编，即使用intrinstic也是一样，而CUDA基本上就是切细程序以及考虑什么运算放在CUDA就是了。

引用:

原帖由 GZboy 于 2008-6-6 12:55 发表
拜托不要听到反对的意见就连别人的贴子都没看清楚就回复
我哪一句话信口开河地说了“X264没有simd优化”？？？
我的意思是将花在CUDA上的时间用作做SIMD优化，效果会是立杆见影的 (例如加入SSE4的优化，或进一步深化之前MMX,SSE,SSE2,SSE3的优化)
请不要歪曲我的原话。

x264很早就已经是支持SIMD/多线程，你在这里提出这个说法有什么意思呢，事实是上现在x264 CUDA的速度提升效果已经是相对SIMD/多线程版本的x264而言的，歪曲、贬低CUDA视频加速就是你在这里发帖本意。

引用:

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

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

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


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

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

基本上GZboy的意思就是intel的论调了，不过非常同意“低容量高质量”是终极目标