PS3的Deferred Shading

minminsk

看不明白，一头雾水

wsx

玩了KZ2的Demo，没觉得画面有啥高明阿2

零舞酒妖

明白了吗？？？？？？？？？？？？

ic.expert

http://cva.stanford.edu/projects/imagine/
Imagine可以看上面那里，基本上来说就是Stream processing的编程模型，这一点和Brook很类似，但是大大的有别于CUDA的编程模型。其实Cell也是属于这种编程模型的。

我说纹理特效这个词的确有点外行话，主要就是说Stream Processing编程模型和Shader Model 4/3是互不兼容的，所以目前的Shader都需要重新写才能跑在Stream Processing风格的语言环境下。还有一点就是Cell/Imagine都没有Fixed Function TMU，这就会导致纹理效率的下降，根据Intel的研究，可能导致12-40X的减速。所以上纹理的话很吃亏。

Edison

使用 Deferred Shading 做 post processing 的话，很多时候只要处理分辨率较低的 render target ，例如 1/4 甚至 1/64 的屏幕尺寸即可，而且 Intel 的那个研究中提到的速度变化，包括了纹理压缩、带宽等因素造成的影响，而在 Deferred Shading 传统的纹理压缩问题根本不会影响到发挥。

ic.expert

我不太明白什么叫做传统的纹理？

根据03年NOKIA的Research Project，TBR的尺寸一般会维持在16*32Pixel以上就可以有效避免跨越TIle的Primitive了，LBR那个主要是依靠L2Cache来自适应的调解Tile大小。这些是Tile划分的主要依据，而并没有考虑到纹理。所以这个和纹理没有关系把？

Intel给出来的纹理性能下降主要归结为4条，Paper上都有，我没有看到哪一项原因和Tile Size有关系？Performance Degradation都是因为Texture Decode等问题引起的，Paper上也有简单描述，并且的确可以理解，包括寄存器容量以及小位宽操作等原因都是杀手级的。并没有牵涉到Tile Size。反而有文章说，TBR反而会引起TMU性能退化，不过我没有发现明显的证据，我在这里又对这方面的简单论述 http://www.opengpu.org/bbs/viewt ... page%3D1&page=2

ic.expert

当然，这里术语有些混淆，我在这里帖子里说的Deferred Shadering是没有HW支持TMU的，比如Cell这种Chip。但是，如果说在GPU上DS，那的确不会影响Tex fillrate。

ic.expert

kernel和Shader还是有区别的，Kernel主要的是依靠Prefetch来隐藏延迟，而Shader是依靠TLP。Brook在GPU上面做了很多妥协，这是Brook在GPU上面做的妥协之一。严格意义上来说，SM3下层的实现和SM4有本质不同，SM3可以通过对Prefetch-based Graphics Pipeline 进行简单改进从而得到想要的设计，而SM4则必须使用基于Multi-threading的TLP模型作为体系结构的设计基础。所以从这个角度上来说，Brook的妥协并不大。 所以，关于SM3和SM4的实现还是有很大区别的。之前我并没有特意强调这一点。

至于SPE上使用C++，被有些观点认为是一件费力不讨好的事情，至少面向的DLP学术领域是这样的。而且Cell本身的设计就是Stream Arch的设计，可以说它是一种IPL（命令式语言）下的Dataflow模型，如果还是使用C++这种所谓的“老旧的”IPL，那开发DLP也根本无从谈起。包括Cell在的SPE之间使用了Message Passing和Ring NOC来组建他的Hierarchical Storage Structure，也是为了DLP的考虑。所以StreamC是Cell最好的编程模型之一。而不是C++。

至于“一般, GPU会准备好G-buffer, 这样CELL只需要做很确定的寻址, 几乎没有什么性能损失.”可能我理解有误，我的条件是说，没有GPU参与的情况下，单凭Cell来Rendering。如果GPU填充好纹理数据到G-buffer，那倒是无所为，但是这会影响到灵活度。G-buffer的Size毕竟有限。不知道LS怎么看？

最后，CS我实在不敢恭维，就是CUDA翻版，是典型的SM4的进化版本，其实SM4就是导致GPU设计复杂度的最大的醉鬼祸首。从编程模型角度上来说，Graphics Pipeline本身就是一个Data-driven的东西，包括Shader也一样，微软却一再在这里大搞IPL来提高所谓的“灵活性”。的确，灵活度是提高了，同时复杂度也直线上升，并且在大规模并行的情况下，由于纹理部分的存储接口很难得到改进，所以更加导致随着并行性不断提高 ，复杂度和功耗呈几何级数增长。在某些学术界人士着这边看来，这并不是一个明智之举，Imagine的老大曾经大致这样说，“我们失去了最重要的东西，那就是带宽”。带宽不但会制约性能，还会给设计的复杂度添加无尽的麻烦。而且带宽在Graphics应用上更显得珍贵，所以如此下去，恐怕DX会在不久将来的某天终将彻底推倒了重来。实际上，前几年我们就有了这样的认识，并且去年NV美国方面已经有其他的工程师，就DX12的实现，给微软发过多封Email了，来探讨如何Data-Driven。当然，不仅仅为了简化，这也是Raytracing的目的之一。

回到主题上来，如果说PS3仅仅是在一个GPU的环境下坐位一种Image-based rendering 平台，而我们称之为基于Cell的Deferred Shading，那的确和TMU和Tile是一点关系也没有。实际上，这种类图像处理的工作，这也是Cell的强项之一，这也是无需商量的事情。

ic.expert

楼上可以传一些值得推荐的资料上来，一起研究一下：〉

Edison

"传统的纹理压缩" 是相对而言，例如 DXTC/S3TC，这是相对 RGBE 等 DX10 引入的"压缩"纹理格式而言。

ic.expert

赫赫，一块芯片在设计的时候总是先有编程模型才有体现机构的，而且影响体系结构的也不仅仅使Pipeline。一个编程模型对于体系结构影响主要来于如何Hierarchical Storage Structure，而Pipeline只是层次化存储的一部分，是为了包装RF然后给ALU提供数据的一种结构而已。

Cell的体系结构其实和80年代Vector Machine大型机没有本质区别，只不过是On-chip了，并且对On-chip做了一些适应性改进。而VM从来就是Stream Processing的编程模型，这一点从Cary-1开始就已经奠定了，尽管当时还不那么称呼。

至于C++，的确是现在工业标准里面面很重要的编程语言，使用很广泛。但是，在学术领域，首先可以看看每年ACM上的Paper产出比？还有多少学者相信C++会有未来？现在有很多实事和论文证明了，C++/C这种基于指针操作数据的IPL是在Memory Size不充足并且Single Thread或是Multi-Thread数量很少的强况下发展起来的产物，这种编程模型只能开发开发单线程的ILP，对于TLP和DLP开发，C++的效率的确有待商榷。而且对于未来的基于Manycore的虚拟机方向，C++也是他们的恶梦。IBM中国研究院有很多哥们在Cell做大规模数据处理的Reasearch，每次对于C++/C在这方面的表现，都是一脸很无奈的样子。如果楼上有兴趣可以去交流交流。

至于“所谓Stream processing, C++是完全可以做到的。”，如果按照这个理论推导的话，那是不是可以说RISC能做到的CISC也能做到，而且CISC工程师还会嘲笑RISC工程师对于设计简化来提高性能的思路，并且说，CISC同样可以做到RISC的所有特性，并且更加灵活！其实在80年代初，RISC刚刚诞生不久的日子及，这种言论的确“甚嚣尘上”。这话从一定程度上说的是没错的，但是这仅仅是工业实现角度而言。从学术角度来说，RISC和CISC最大的区别就在于RISC非常好的优化了Hierarchical Storage Structure，这包括定长指令字，包括存储器指令和一般ALU指令的分离（实际上这也是一种指令正交化的副产物）等等，带来的结果就是，微观上，更好的优化了ALU的效率，宏观上，更好的利用的数据带宽。所以RISC被人为的追认为是上一代体系结构的革命。如今我们所面对的的情况也是同样的，毕竟在RISC设计之初并没有考虑到如何DLP/TLP，仅仅为优化了ILP提供了很好的和潜在的支持。这点从IPC的数据上就可以得到很好的证明。

而对Cell来说，它最失败的地方就在于并没有好好利用Stream Processing，而是让人们用C++。当然，这并不是说SP是多么高明的技术，其实很多技术看上去很有“价值”，譬如我们可以研究一下近年来的Trips/RAW/Vector Memory等等体系结构，就会发现，比起工业思维中强调的“我们如何在现有条件下实现一个东西”，学术更看重“我们如何更有效的实现一个东西”，其实NV/AMD/Intel/IBM等公司也是有自己的研究院的。只不过能不能把这些东西拿出来到工业中用，这不是工程师能说得算得。

ic.expert

首先，感谢ls精彩的评论，者能让很多看帖子的人明白中国大陆的学术是个什么东西…，其实我本人不是学术界的。关于"我们写什么可以发一篇论文"，如果抱有这个观点作学术是研究不出什么有价值的东西的，很多美国的学者在一个领域一研究就是十几二十几年，把科研当成生活或是爱好的一部分。反观，中国大陆的高校和研究所把发国外会议或是期刊，叫做“我们在XX会议上‘中’了一篇”，这个“中”字本身就是自贬身价自取其辱，这方面，在亚洲也就是日本会很一些。至于共和国的香港特区的学术氛围，我自己的感受是，还不如民国的台湾地区，这一点从两地的Reasearch Project对比就能看得出来。别的不说，人家在CPU和GPU方面都有很多Project，就拿GPU来说 ，不同的学校已经做过好几个硬件实现了，最近一个GPU Implement是民国96年完成的。对于共和国管辖的地区，这方面还是“零”，包括HK，并且对于一个商业港口来说，学术潜力是非常有限的。当然，对于解放军的一些保密项目来说，我就不评价了。

其次，就c++来说，对于当前的LRB或是其X86对应得体系结构，它是属于比Stream processing更底层的东西，所以实现起来当然可以。Stream Processing是更抽象的一种表示，写DLP程序会更具有效率，能够让人们在DLP模式下减轻存储本身所带来的程序复杂度问题。对于Cell本身，Sony的意图很明显，不想再计算机语言方面吃螃蟹，所以考虑折中方案就是附带Runtime的C++。实际上这会令很多程序员误入歧途，以为Cell支持C++，从而不断的抱怨Cell对C++支持的又多差，LS有多小不足以放下他们的数据，等等 。其实从Cell在体系结构设计的时候如果考虑到C++的话，那么根本不会用LS作为SPE的层次化存储方案，肯定会用Gloabl Addr Spaces Cache+ Scratch Memory。

所以从宏观上来说，这也是一种通过设计简化和引入新的规则来提高计算效率的方式，这方面和CISC到RISC的革命是没有区别的。如果没有编程模型上的进步，那是不可能有新的体系结构诞生的。RISC相比于CISC在编程模型上的进步就是Prefetch，把Load尽量提前，并且增加大量的增加GPR数量来存放Load进来的数据。而Stream Processing的进步在于在粒度上扩大了这个概念，这一点可以参考Imagine这种极端的实现方式。而Cell这种体系结构也是为此孕育而生的，在Cell上，不靠Prefetch是没办法编程的，但是作为一般的C++程序员，也许很难理解此为何物……所以会抱怨“LS让Cell变得不灵活”……

当然，学术会比工业超前一段时间，并且学术中假设条件更加理想化，所以学术的东西一般都很难直接应用到工程当中去，考虑到技术的惯性从学术到工业的道路还是很长的。像C++这种东西在TLP的未来，恐怕很难有大的作为。

ic.expert

其实也没有说CISC不好，在存储器紧张以及功耗要求严格的领域里传统的CISC还是很有作为的，众所周知比如很多工控都80c51。仅仅是应为底层技术变了，上层的编译技术也变了，所以CISC的很多在60年代看起来非常先进的特性变得有些不具有效率了，所以要删节以下而已。其实技术没有什么是落后的，都是这样的来来去去，只是和系统匹配程度的问题而已。

不过，当前的X86 CISC技术到现在基本上已经名存实亡了，内部都是Post-RISC实现，仅仅有一个硬件DBT来做一个Binary Translation的工作，可以说，X86 ISA以及那些特权寄存器仅仅是一层皮。如果在15或是20年前，这种技术可以说很先进很有想法，但是目前底层器件的技术又进步了，所以这种Trick太多的设计对当今来说并不是一个好的风格，技术上的简化是不可避免的，我们需要的是更有效的设计，更有效的计算。这也是21世纪以来各种体系结构会议上研究的重点。

举个例子。比如，从计算本身来说，其实是可以被分类的，有些计算就是为了响应中断，所以就是会串行并且就是不会太快，而有些计算就是为了大规模的数据处理，所以一定要并行要快。如果全部混在一起跑，混在一起写程序，这个是得不偿失的。而C++这种语言并不能从根本上解决并行计算程序的简易化设计，哪怕是OpenMP和MPI也无法解决这个问题。但是未来需要一种更简单的语言来实现简单的并行程序的书写，这方面的研究现在很多，有些看上去的确很有前途。

当然，我只是说个例子，还有很多需要考虑的东西，C++这种命令式语言的确很难应用在Manycore上。所以对于未来的高性能计算，C++很值得商榷 ：〉

ic.expert

其实灵活并不是目的，对于合适的计算平台来说，充要条件中：有效的计算是必要条件，而灵活的计算是充分条件。没有前者，“计算”便无从谈起。