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

Edison

我说的是 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能不能吃"的阶段。

ayanamei

..LS在做试题
名词解释 :CUDA ？
不是要写出在GPU上执行的程序
而是把适合GPU这种并行结构的应用 搬到GPU上来

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

ayanamei

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

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

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

51ft

楼主在用TOR啊:p

njs261

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

Edison

在我发表的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

原帖由 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 这样的运算是无法作平行化处理的。

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

Edison

我想在这里需要理清一下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，确保编码器、解码器都是同样的结果。

Edison

h264的transform不是DCT，只是DCT-like罢了，运算上只有加法和移位操作的transform，你看看真正DCT都包含了些什么运算。

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

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

Edison

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

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

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

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