POPPUR爱换

标题: PCINLIFE特约：深入浅出谈CUDA by hotball [打印本页]

作者: Edison 时间: 2008-6-4 19:18
标题: PCINLIFE特约：深入浅出谈CUDA by hotball
第1页 - CUDA是什么？能吃吗？

第2页 -  CUDA Toolkit的安装

第3页 -  第一个CUDA程序

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

第5页 -  第二个 CUDA程序

第6页 -  GPU 的硬件架构

作者: liuweifeng 时间: 2008-6-4 22:03
提问：CUDA或者说G80里的constant memory是做什么用的，为什么要把它单独划分出来呢？

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

作者: shine 时间: 2008-6-4 23:37
开发一个利用CUBA编码H。264的程序吧，现在光能硬件解码，不能硬件编码，可惜

作者: Edison 时间: 2008-6-5 01:08
http://forum.doom9.org/showthread.php?t=137459，x264的开发人员还在研究，例如什么活最适合在CPU上执行。

作者: Prescott 时间: 2008-6-5 12:39
最后结论是，没什么活适合在GPU上执行。[lol>

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

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

作者: Edison 时间: 2008-6-5 12:52
初步结论是在目前在lowest seting上 x264 9600gt cuda 720p是quad core的3.8倍，就在我给的那个连接中。

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

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

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

作者: GZboy 时间: 2008-6-5 20:37
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-5 22:39

原帖由 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
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-5 23:32

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

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

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

作者: GZboy 时间: 2008-6-6 00:46
提示: 作者被禁止或删除内容自动屏蔽

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

作者: 以前的密码没了 时间: 2008-6-6 10:46
gt200是不是支持64位的浮点啊

作者: Edison 时间: 2008-6-6 11:14

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

yes，1/8 fp32性能。

作者: GZboy 时间: 2008-6-6 12:23
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-6 12:31

原帖由 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
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-6 13:05

原帖由 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
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-6 13:15

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

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

作者: GZboy 时间: 2008-6-6 13:37
提示: 作者被禁止或删除内容自动屏蔽

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

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

作者: GZboy 时间: 2008-6-6 13:57
提示: 作者被禁止或删除内容自动屏蔽

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

作者: daniel_k 时间: 2008-6-6 16:32
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 时间: 2008-6-6 17:04
CUDA 1.1增加了G9X、WinXP 64bit的支持，提供了新版驱动。

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

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

作者: Norways_Winter 时间: 2008-6-6 20:21
这套文章不错

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

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

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

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

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

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

作者: yyzjp 时间: 2008-6-6 22:05
非常精彩, 我仔细的看了一下平方数求和的那个函数, 矩阵预算没看

本文的很多灵光一闪让我恍惚回到了学习计算机系统的大学时光, 作者有非常丰富而清晰的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 时间: 2008-6-7 00:16
现在是有一些这样的东西出来，例如那个cuDPP。

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

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

作者: Edison 时间: 2008-6-7 01:44

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

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

作者: leedio 时间: 2008-6-7 08:33
关键还是配套的软件的易用性，
现在制片组用的那几压片软件，都已经有自己的经验了，用起来非常顺手了，
怕就怕CUDA的配套软件，期待有完整的样片放出

作者: GZboy 时间: 2008-6-7 08:43
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-7 10:13

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

作者: Edison 时间: 2008-6-7 12:21

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

AMD有CAL/Brook+，Intel有Ct。

作者: Prescott 时间: 2008-6-7 17:12
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 编辑 ]

作者: GZboy 时间: 2008-6-7 17:21
提示: 作者被禁止或删除内容自动屏蔽

作者: GZboy 时间: 2008-6-7 17:28
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-7 17:31

我说的是 Mixed refs 、trellis 等高级复杂的功能，你却转移到CABAC上了？是没看清楚还是跑题了？

前面还说对x264很精通？你去看看trellis什么情况下才能启用再说吧？

INTEL+AMD 的桌面市场占有率高达 99% 上， Intel的编译器有必要对Power、SPARC、MIPS等非X86的提供支持吗？
完全没有！
反观NV 在桌面市场占有率仅有3成，而且仅仅是G80以后的可以跑CUDA。

你有没有发现你越说越混了？CUDA是什么？你还是看看文章再说吧？

INTEL 完全没必要对3D Now! 提供支持，INTEL在桌面市场高达80% 多的占有率确保了它在行业的龙头地位，有能力有财力推动制定标准。而 AMD 当时仅有百分之10几的占有率就妄图推行自己的 3D Now! ，虽然当年的A 记爱好者也像你
这么兴奋和热情十足，但众多软件商可不卖账， 3D Now!最后的结果也就不用我说了。
今天在图形技术上领先的NV 推行CUDA也是企图确立自己的地位，但必竟NV没有强大到能像INTEL一样强推标准，
而且CUDA更多地挑起了 INTEL 和 AMD 对该领域的投入，CUDA的编程难度也是它难以普及的自身因素。

你还停留在"CUDA能不能吃"的阶段。

作者: GZboy 时间: 2008-6-7 17:58
提示: 作者被禁止或删除内容自动屏蔽

作者: ayanamei 时间: 2008-6-8 01:06
..LS在做试题
名词解释 :CUDA ？
不是要写出在GPU上执行的程序
而是把适合GPU这种并行结构的应用搬到GPU上来

而CUDA是实现这个目的一个平台
CPU与GPU互动互补的解决现有问题

作者: ayanamei 时间: 2008-6-8 01:08

原帖由 Prescott 于 2008-6-7 17:12 发表
Ct不是Larrabee的编程语言。
我再强调一遍，Ct只是研究项目，不是产品。

Edison和几年前一样，还是暴力计算能力的拥护者。缺乏的是对程序设计的基本了解，所以很容易就被Cell/CUDA的超高理论计算能力吸引，于是认 ...

CUDA是不打破现有格局的情况下最大化利用各自的优势的方案
Larrabee 先说服用户为这个东西买单再说

作者: 51ft 时间: 2008-6-8 09:18
楼主在用TOR啊:p

作者: njs261 时间: 2008-6-8 14:30
个人的理解，cpu是个大脑的话，CUDA就是一个算盘，虽然没有啥判断能力，但是在大脑的指挥下可以打得飞快，配合算盘一个头脑一般的人就可以和一个心算很强的人抗衡了，是不是这个意思？

作者: Edison 时间: 2008-6-8 15:20
标题: 回复 40# Prescott 的帖子
在我发表的Cell文章以及所有与之相关的话题、帖子中，我没有说过所谓的Cell的性能可以100%使用上。

在异质架构上，其实你的观点和我的观点并没有什么大的区别，这在我当初发表的Cell文章就有，例如Cell这种产品不会在x86主导的PC市场上有什么作为，但是会对PC处理器的发展方向产生一定的影响。

简单来说，我对你在Cell上理论性能发挥的看法没有任何意见，你所说的我认为100%发挥实际上在我看来就是对一些其他狂热SONY fans的胡说八道找一个出气的地方罢了。

不过对Larrabee采用x86我是有些不解的，Larrabee的内核属于"返璞归真"的简化结构，在显卡上用x86这样的ISA是比较让人困惑的。像Pentium，其decoder部分就达到了30%的占用，在Pentium Pro decoder上更是达到了40%，这很大程度上说明x86的问题，只是现在的x86拉进了一大堆cache后，这个问题才看起来没有那么显眼。

对现在的程序员来说，精通汇编并愿意花时间来写汇编的实在少之又少，在这样的情况下的Larrabee和CUDA相比在编程方便性上真正的优势其实来自于它的dictionary-based cache coherence而不是x86，而基于Larrabee的显卡能不能直接跑x86程序本身也是一个很大的疑问。

至于说使用x86可以让Larrabee无需考虑DX规格变迁则是一个经不起推敲的观点，DX的演进在历史上绝对不是仅仅的运算单元功能变迁问题，包括ROP、TMU等单元都是每一代DX规格都有新定义的，这类单元从成本、性能角度来看，在很长的一段时间里都不适合直接用通用单元来替代。Larrabee作为一块GPU，是集成上TMU、ROP这些功能固化的单元的，同一版本的Larrabee显卡注定只能支持某个规格的DX规格。

Larrabee的推动是相当容易的事情，它是Intel的产品，在技术支持（软件、文档）上是相当强的，长期的品牌耕植在用户认可度方面也要遥遥领先于对手，当年i740推出的时候就是一片风声鹤唳，而Larrabee的目标要比i740长远得多。

对Larrabee的重视程度，PCINLIFE哪里有你所说的那样小看，与之相反的是，我在体系架构分类中就专门开辟了Larrabee相关的讨论话题，当时提供的资料可是能公开找的文件中最新的，比所有的其他网站都更新。

作者: Edison 时间: 2008-6-8 15:34

原帖由 GZboy 于 2008-6-7 17:58 发表
trellis 的开启需要打开CABAC，是比CABAC更进一步的高级功能。
而且必须在 N PASS N>2 编码的情况下才会有相应的良好效果 <--- 这点可能你就不知道了
这个有点像我在说登月火箭的固态燃料发动机，而你跟我说的是如何造火箭外壳。

h264的bitstream的计算有CAVLC和CABAC两种，都是main profile以上的东西，H264中没有比对CABAC更高级的bitstream计算方式。
trellis在x264中是从属于CABAC的选项，是对CABAC的成本估算，或者说评估某一个系数对CABAC产生的bitstream长度造成什么样的影响。
当你要压缩一个8Mbps的bitstream的时候，就会需要做一些分配，例如I-frame分配了多少个bit，但是结果压缩出来frame会占都少个bit，是由CABAC决定的。
这个时候就需要一个方法进行评估，一般情况下是用Laplacian，但是可能不够精确，所以就会有一些更加精确的办法，例如trellis。
trellis实际上就是一个CABAC的估算办法之一，因此对于你说提到"trellis"，就当然是要指出 CABAC 这样的运算是无法作平行化处理的。

以你的火箭比喻，就是我们在讨论如何制造整个火箭，我指出其发动机的运作必须是符合一定规律，你却突然说这个发动机的某个零部件是一个比发动机更加高级的功能。

作者: GZboy 时间: 2008-6-8 23:41
提示: 作者被禁止或删除内容自动屏蔽

作者: GZboy 时间: 2008-6-8 23:49
提示: 作者被禁止或删除内容自动屏蔽

作者: GZboy 时间: 2008-6-9 00:09
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-9 01:24
标题: 回复 52# GZboy 的帖子
我想在这里需要理清一下DCT、CABAC、trellis三者的关系。

DCT是一个转换动作，理论上它是不会对任何资料构成变化的，只是改变了表示的方式而已，但是为了达到压缩额度效果，就需要作量化（quantization）处理，也是产生失真的原因。

例如有一对数据，经过DCT后，就会产生100 3 2 10 5 7......这样的数字，你会发现这些数字都很小，而quantization在这里就是要把表示数字的位数弄得更小，例如除以3。

DCT的好处是数据经过它的处理后，会变成一个frequency domain的东西了——频率越高的地方，即使有些不一样，会造成的影响也会越小，这就意味着频率越高的部分，你能quantization得越多，表示该数字的位数越少。

在视频压缩中时常会出现的问题是：必须想方设法达到某个码率（bitrate），这样你就不可能只用一个固定的quantization数值，而是需要若干个可以调整的quantization。

嗯，这个时候就大都会采用一个固定的quantization matrix，然后把这个quantization matrix的值乘以一个固定的因数（factor），利用改变这个factor来进行调整。

视频画面复杂度低，理论上需要存放的数据越少亚，这时候使用一个小的factor，就可以达到丢失较少数据，达到较高的品质（quality）。

如果画面复杂度高，就需要存放较多的数据了，这时候就需要调大factor，避免超出bitrate的范围。

现在的问题是，做好DCT后，你怎么才能知道factor需要设置成多少而又刚好可以落在bitrate的范围内。

当然，理论上你可以尝试逐个逐个尝试每个可能的factor，但是这样会很慢，效率很低亚。

这时候就需要一个方法，从"DCT的结果"，去[估计]factor应该设置成多少，trellis就是这样的办法。

打了这么多字...简而言之，trellis，其实是CABAC模块中，对DCT结果进行估计 factor应该设置为多少的东西，而不直接属于在 DCT 阶段的东西。

最后补充一下前面"DCT"的，因为h264的transformation其实根本不是用DCT，而是一个基于整数的transformation，DCT的系数都是小数——无限位数的小数，这是相当麻烦的事情。因为往往会因为不同的执行方法产生的精度不一，造成解码的结果和原先的有些微出入，为了避免这个问题H264改用了一个所有系数都是整数的transformation，确保编码器、解码器都是同样的结果。

作者: GZboy 时间: 2008-6-9 09:33
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-9 11:30
h264的transform不是DCT，只是DCT-like罢了，运算上只有加法和移位操作的transform，你看看真正DCT都包含了些什么运算。

akupenguin 说的是更加具体的执行，而CABAC、trellis的关系我在上面已经说得很清楚了。

之所以会说这些，其实还不是因为你认为x264的cuda在品质上是一个远不如CPU（你使用"CPU用劣质压缩也能开几倍"来做暗示）的方案，而这个东西实际上都还没正式公布呢。

作者: 天下18 时间: 2008-6-9 13:54
提示: 作者被禁止或删除内容自动屏蔽

作者: GZboy 时间: 2008-6-9 13:57
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-9 14:17
请再仔细看看，H264的transform不是DCT，它只是一种类似于DCT的transform，是基于整数的（这是最重要的差别），只有加法和位移操作，DCT是指那个特定的运算——discreet cosine transform。

至于一些H264 encoder沿用DCT的说法，那只是习惯上的。

总之H264的transform coding不是DCT就是了。

你可以查阅JVT的文档，看看他们是否说h264的transform coding是不是DCT。

作者: Athlon64fly 时间: 2008-6-9 15:18
提示: 作者被禁止或删除内容自动屏蔽

作者: GZboy 时间: 2008-6-9 18:20
提示: 作者被禁止或删除内容自动屏蔽

作者: 阿蓝2代 时间: 2008-6-9 21:36
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-6-10 11:16
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-10 11:34
CUDA其实是可以算是有一个ISA的：PTX。

作者: RacingPHT 时间: 2008-6-10 11:44
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-10 12:06
CUDA本身就是希望开发人员不需要怎么接触ISA就能完成程序的开发，即使把opcode提供了给你，你又能干些啥？CTM就是一个例子。

至于CUDA 1.0的硬件不能跑CUDA 1.1的代码这并不奇怪，这就好像Power等CPU都有不同的版本，只不过CUDA本身是直接相关于GPU硬件的，GPU发展比较快，旧的GPU也当然不能跑针对新GPU的代码。

不过我手头的CUDA 1.1代码都能在g80上运行。

作者: RacingPHT 时间: 2008-6-10 14:34
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-6-10 14:41
提示: 作者被禁止或删除内容自动屏蔽

作者: 痞子不俗 时间: 2008-6-10 21:58
学习学习！

作者: Edison 时间: 2008-6-11 10:51
这里推荐一篇Q/A，比较适合于一般的读者。

http://cuda.csdn.net/News.aspx?i ... 5-8930-496e06ca439c

作者: complexmind 时间: 2008-6-12 08:04

原帖由 Prescott 于 2008-6-7 05:12 PM 发表
Ct不是Larrabee的编程语言。
我再强调一遍，Ct只是研究项目，不是产品。

Edison和几年前一样，还是暴力计算能力的拥护者。缺乏的是对程序设计的基本了解，所以很容易就被Cell/CUDA的超高理论计算能力吸引，于是认 ...

又见p大,小弟这厢有礼了:-)看各位达人的帖感觉又回到了当初争论EE CELL到底在多大程度上能实现其理论性能的时候,结果无一是高并行结构失败…感觉并行计算只能在暴力计算场合
能占优势…而英伟达想让原来在cpu上的某些并行计算给gpu做,而不是取代它.

[ 本帖最后由 complexmind 于 2008-6-12 08:28 编辑 ]

作者: deem 时间: 2008-6-14 16:30
其实关键还是看应用范围，程序类型，CELL和CUDA这种东西在流体力学，大气分析等计算密集型应用方面
优势是不言而喻的，围着一小块数据拼命的计算，干这个东西再合适不过了。实际上也就只是适合干这个。

06年底参加过一段时间IBM的CELL研讨班(IBM自己弄得)，他们对于这个东西的期望也是非通用行业的，他们
期望的主要客户是石油，气象预报，能源等行业，其他的行业也没有报什么行业，在讨论编成模式的时候，他
们的技术人员也承认这个东西想要优化起来确实难度太大，很多东西都是理论上的性能，或者DEMO上的性能
实际应用中几乎不可能达到。

文中提到的延时隐藏也就是是在一些计算密集型程序里面容易实现，大型算法里面做这个简直就是要命。

作者: deem 时间: 2008-6-14 16:31
另外，现在的CPU都已经有数据预取指令了，如果充分优化程序，把访存的延时隐藏掉，同样可以
获得极大的性能提示。不过难度嘛......

作者: complexmind 时间: 2008-6-15 11:45

原帖由 deem 于 2008-6-14 04:31 PM 发表
另外，现在的CPU都已经有数据预取指令了，如果充分优化程序，把访存的延时隐藏掉，同样可以
获得极大的性能提示。不过难度嘛......

那也该比优化Cell小吧？

作者: Edison 时间: 2008-6-19 12:45
CUDA 2.0 beta 2的文档出来了，其中的5.1节有描述计算能力的部分：

A.1.2 Specifications for Compute Capability 1.1
Support for atomic functions operating on 32-bit words in global memory (see Section 4.4.4).

A.1.3 Specifications for Compute Capability 1.2
Support for atomic functions operating in shared memory and atomic functions operating on 64-bit words in global memory (see Section 4.4.4);
Support for warp vote functions (see Section 4.4.5);
The number of registers per multiprocessor is 16384;
The maximum number of active warps per multiprocessor is 32;
The maximum number of active threads per multiprocessor is 1024.

A.1.4 Specifications for Compute Capability 1.3
Support for double-precision floating-point numbers.

作者: Edison 时间: 2008-6-19 13:02
Specifications for Compute Capability 1.0

The maximum number of threads per block is 512;
The maximum sizes of the x-, y-, and z-dimension of a thread block are 512, 512, and 64, respectively;
The maximum size of each dimension of a grid of thread blocks is 65535;
The warp size is 32 threads;
The number of registers per multiprocessor is 8192;
The amount of shared memory available per multiprocessor is 16 KB organized into 16 banks (see Section 5.1.2.5);
The total amount of constant memory is 64 KB;
The cache working set for constant memory is 8 KB per multiprocessor;
The cache working set for texture memory varies between 6 and 8 KB per multiprocessor;
The maximum number of active blocks per multiprocessor is 8;
The maximum number of active warps per multiprocessor is 24;
The maximum number of active threads per multiprocessor is 768;
For a texture reference bound to a one-dimensional CUDA array, the maximum width is 213;
For a texture reference bound to a two-dimensional CUDA array, the maximum width is 216 and the maximum height is 215;
For a texture reference bound to a three-dimensional CUDA array, the maximum width is 211, the maximum height is 211, and the maximum depth is 211;
For a texture reference bound to linear memory, the maximum width is 227;
The limit on kernel size is 2 million PTX instructions;
Each multiprocessor is composed of eight processors, so that a multiprocessor is able to process the 32 threads of a warp in four clock cycles.

作者: Bocelli 时间: 2008-6-21 07:45
获益匪浅。比较认同Prescott的说法，NV的CUDA是占了先机，但Intel的决心不容小觑。

[ 本帖最后由 Bocelli 于 2008-6-21 08:02 编辑 ]

作者: Eji 时间: 2008-6-21 16:12
我在某P的發言內只看到了CPU is all.... :p

作者: los_parrot 时间: 2008-6-22 00:07
应该是intel is all.

这就是intel的思维方式(没有任何不敬的意思)

作者: littlemouse 时间: 2008-6-24 17:05
cuda和opencl有什么区别？
好像nv也是opencl成员？

作者: Prescott 时间: 2008-6-24 23:41
这么大的利好消息，E大怎么都不转？
http://anandtech.com/video/showdoc.aspx?i=3339

作者: Edison 时间: 2008-6-25 02:15

原帖由 Prescott 于 2008-6-24 23:41 发表
这么大的利好消息，E大怎么都不转？
http://anandtech.com/video/showdoc.aspx?i=3339

我这里目前用8800GS的速度和GTX280的速度一样，估计程序还没有优化好。NVIDIA说未来的软件版本可以做到480x360接近200fps的压缩，现在是130fps，720p可能可以做到100fps。

作者: RacingPHT 时间: 2008-6-30 10:05
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-6-30 12:16
目前的版本只是提供了baseline的压缩，所以要比速度的话，基本上只能是用baseline来对比。

作者: huangshidi 时间: 2009-1-19 14:20
n卡的cuda和一般民用关系不大，还是立体技术实用性大，看得见摸得着

作者: yanyu1984 时间: 2009-1-20 14:27
一直很期待NV对CUDA技术的开发，已经初步感受到了使用GPU运算所带来的快感（PS cs4、Folding@Home 、以及NV的那个视频转换软件），期待CPU GPU共同作战的那一天

作者: Alloy2005 时间: 2009-1-20 15:38
深入浅出{closedeyes:]

作者: parasite 时间: 2009-1-21 09:22
提示: 作者被禁止或删除内容自动屏蔽

作者: 飘逸 时间: 2009-1-22 09:18
赞一个{victory:]

作者: flying_7alone 时间: 2009-2-13 10:50
收藏
学习

作者: 冰火人 时间: 2009-2-14 19:43
提示: 作者被禁止或删除内容自动屏蔽

作者: PlumeOfWind 时间: 2009-2-14 22:51
CUDA牛B啊。。。。。。。

作者: DasBoot 时间: 2009-2-15 02:33
CUDA目前实际应用还没有展开

作者: yaoming114 时间: 2009-2-21 01:32
学习观望。。

作者: qdhr 时间: 2009-3-4 10:16
不错，GPU的潜力是很大的，在平时GPU的资源很浪费，还耗电多可惜。

作者: 回归年 时间: 2009-4-8 08:40
好像要真正把CUDA应用起来也不容易，还有很长的路要走。

作者: diabloking 时间: 2009-5-14 15:19
顶顶，为了活跃度

作者: wylliang 时间: 2009-5-16 07:47
这东西，什么时候才能出样品呢？

作者: y2kamd 时间: 2009-5-17 23:18
最近看重了simHD,但是不支持rmvb不爽

作者: complex1980 时间: 2009-5-18 08:39
物理加速的一种标准，关键是要别人开放的软件用到指令

作者: rocherone 时间: 2009-6-15 16:50
提示: 作者被禁止或删除内容自动屏蔽

作者: mulder009 时间: 2009-6-19 12:58
提示: 作者被禁止或删除内容自动屏蔽

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