引用:

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

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

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

引用:

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

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

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

楼主在用TOR啊

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

在我发表的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相关的讨论话题，当时提供的资料可是能公开找的文件中最新的，比所有的其他网站都更新。

引用:

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

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

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

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

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

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

引用:

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

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

这个观点比较同意，目前的局势就是这样，NV的CUDA现在是占了先手，但最后到底鹿死谁手还是未知，还是觉的Larrabee 的推出要快一点比较好。

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

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

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

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

争论的关键在于CUDA能不能使用和CPU相同的并行化代码，并且没有精度损失的得到相同的结果，这一点在CUDA支持32/64bit float运算的情况下应该没有异议了不是吗，至于速度问题，难道真有人认为CPU现在的计算能力提高速度比GPU快吗？不光是X264编码计算，其他能够并行化处理的运算也是一样的

引用:

原帖由 Prescott 于 2008-6-7 17:12 发表
在Edison吹嘘Cell的时候就明确的说过，Cell没有前途，Cell的理论计算能力想要发挥出来几乎不可能。

cell怎么会没有前途，IBM的 Roadrunner已经出来了，就看这次6月的TOP500排名怎么样了

[ 本帖最后由 阿蓝2代 于 2008-6-9 21:38 编辑 ]

CUDA本身就非常的硬件相关，如果想直接使用C语言，更换一个编译器移植之后就希望CUDA跑得比CPU快是没有可能的。

CUDA的缺点有几个:
1: 硬件过于相关, 文档没有什么ISA方面的东西, 相反却通篇介绍的是G8x的结构。CUDA1.1已经在短短一年的时间后就无法在G80上面运行。
2: SIMD，而不是MIMD。即无法加速多个独立并行代码流。
3: 需要超大规模的数据并行性, 但仅仅是必要条件而不是充分条件。最简单的一个例子: 标准CRC32算法几乎不可能在CUDA上获得优化。
4: CUDA本身的限制。

基于这些原因，我预言Lame的CUDA版本的速度提升可能不及CPU并行化的性能提升，表现在
1: CUDA不可能独立高效完成Lame的压缩编码(CPU占用率为0)
2: CUDA加速后的Lame压缩速度提升比不及multi-Core的速度提升比(由于multi-Core可以并行多个Lame进程而无需并行化)，即Lame不可能获得400%级别的加速比。

CUDA其实是可以算是有一个ISA的：PTX。

相比结构上的性能陷阱而言，PTX的对性能的影响微乎其微。对GPU而言，单独指令的吞吐效率是很次要的考虑
这也是PTX文档单独那出来作为一个文件的原因, 而作用大多也是debug为主。

CUDA本身就是希望开发人员不需要怎么接触ISA就能完成程序的开发，即使把opcode提供了给你，你又能干些啥？CTM就是一个例子。

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

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

唔，CUDA1.1是Cuda1.0的超集, 类似于DX10.1。只有overlapped memory copies, 和atom_op这部分是新增的特性。
不过不管怎么说，这个结构更新速度还是太快了一点。尤其是在G80U还是高端产品的情况下。

噢，GT2xx估计还会升级到compute capability 1.2，增加一个shared memory atomics。
也就是说目前的CUDA尤其是1.0还不怎么具备完整的全局同步能力。

我并不是否定CUDA，相反我还是比较有兴趣的，他提供了一个低价的高性能计算平台，只是很目前有些被刻意神话了。甚至有Fanboy在NV的论坛上YY用CUDA来模拟CPU。。