POPPUR爱换

标题: PS3的Deferred Shading [打印本页]

作者: Edison 时间: 2007-11-12 01:28
标题: PS3的Deferred Shading
这其实放在SCEA上有一段日子的pdf了。

http://research.scea.com/ps3_deferred_shading.pdf

文章讨论了在PS3上使用Cell来跑Cone Culled Soft Shadows，并且和Linux上的GF 7800GTX作对比，5个SPE（在包括DMA传输时间在内）的执行时间大致上和7800GTX相当，其中DMA占用的时间为27%左右。

作者: RacingPHT 时间: 2007-11-20 17:53
提示: 作者被禁止或删除内容自动屏蔽

作者: kern999 时间: 2007-11-20 19:01
Deferred Shading 让我想起来 nVidia的那本什么 Game Programming Gem 2...

作者: Edison 时间: 2007-11-28 18:51

原帖由 kern999 于 2007-11-20 19:01 发表
Deferred Shading 让我想起来 nVidia的那本什么 Game Programming Gem 2...

里面介绍的是STALKER的光照渲染方式，最后提到的GI实现是用了500个无定向光照实现的，当时他们认为这个GI还需要大约2年的时间才能获得普及。

作者: 来不及思考 时间: 2007-11-28 18:56
提示: 作者被禁止或删除内容自动屏蔽

作者: Ben Tse 时间: 2007-11-28 19:00
stalker开GI 88GTX帧数折半

作者: feel囝 时间: 2008-7-20 20:26
柔化影子是softshadow么????不是说STALKER里的软阴影都是贴多几层使其看起来软么???

作者: hsy-x 时间: 2008-7-20 21:00
softshadow 实现还是比较困难吧现在的3d软件在渲染softshadow都还要比较多的时间去渲染更别提游戏的时实运算了

作者: hsy-x 时间: 2008-7-20 21:02
柔化影子应该还是用一种方法去模范或者几接近softshadow而已

作者: YY小熊猫 时间: 2008-7-23 09:16
游戏了都是PRE BAKE玩出来的所谓GI吧？例如GOW2和CRYSIS用的AO。PS3玩Deferred Shading哪来那么多显存用？指望KZ2那玩意太不现实了吧？

[ 本帖最后由 YY小熊猫于 2008-7-23 09:19 编辑 ]

作者: insect2006 时间: 2008-8-22 18:37
KZ2至少还实现了4XAA下的Deferred Shading，已经很NB了

作者: hdfeel 时间: 2008-9-10 08:32
最近的kz2 图片，连影子都没有了。

作者: YY小熊猫 时间: 2008-9-17 16:15

原帖由 insect2006 于 2008-8-22 18:37 发表
KZ2至少还实现了4XAA下的Deferred Shading，已经很NB了

看到的东西是开发机上的还仅仅是视频片断？这些东西不可尽信，别忘了05年和06年的闹剧。

作者: shaolin711 时间: 2008-12-10 18:33
可惜这个文档十分笼统。

作者: YY小熊猫 时间: 2008-12-10 18:53
GOW2已经出来了，AO是没少用到。KZ2还在继续放视频，而且截图里也看不出体现在哪里。

作者: gfboy02 时间: 2009-1-18 20:03
基本上现在的游戏都是通过某些讨巧的方式实现类似Global illuminate，soft shadow之类的效果的
要达到目前普通cpu渲染器的效果目前的GPU速度还差得远

作者: ff10fans 时间: 2009-1-30 07:16
看看怎么样

作者: cloudol 时间: 2009-1-30 11:04

GOW2已经出来了，AO是没少用到。KZ2还在继续放视频，而且截图里也看不出体现在哪里。
YY小熊猫发表于 2008-12-10 18:53

kz2 ign review 已经出了 9.4

图像部分 9.5

作者: hl790 时间: 2009-3-24 22:32
有ps3的支持一下

作者: ic.expert 时间: 2009-3-27 14:31
这东西和Imagine的编程模型类似，不能上纹理特效，一上纹理特效马上就死。目前用处不大。

作者: minminsk 时间: 2009-4-24 17:42
看不明白，一头雾水

作者: wsx 时间: 2009-4-24 22:06
玩了KZ2的Demo，没觉得画面有啥高明阿2

作者: 零舞酒妖 时间: 2009-5-19 11:43
明白了吗？？？？？？？？？？？？

作者: RacingPHT 时间: 2009-5-21 21:48
提示: 作者被禁止或删除内容自动屏蔽

作者: ic.expert 时间: 2009-5-21 22:41
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 时间: 2009-5-22 00:37
使用 Deferred Shading 做 post processing 的话，很多时候只要处理分辨率较低的 render target ，例如 1/4 甚至 1/64 的屏幕尺寸即可，而且 Intel 的那个研究中提到的速度变化，包括了纹理压缩、带宽等因素造成的影响，而在 Deferred Shading 传统的纹理压缩问题根本不会影响到发挥。

作者: ic.expert 时间: 2009-5-22 01:03
我不太明白什么叫做传统的纹理？

根据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 时间: 2009-5-22 01:11
当然，这里术语有些混淆，我在这里帖子里说的Deferred Shadering是没有HW支持TMU的，比如Cell这种Chip。但是，如果说在GPU上DS，那的确不会影响Tex fillrate。

作者: RacingPHT 时间: 2009-5-22 01:56
提示: 作者被禁止或删除内容自动屏蔽

作者: ic.expert 时间: 2009-5-22 02:55
本帖最后由 ic.expert 于 2009-5-22 03:04 编辑

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 时间: 2009-5-22 03:05
楼上可以传一些值得推荐的资料上来，一起研究一下：〉

作者: Edison 时间: 2009-5-22 09:54
"传统的纹理压缩" 是相对而言，例如 DXTC/S3TC，这是相对 RGBE 等 DX10 引入的"压缩"纹理格式而言。

作者: RacingPHT 时间: 2009-5-22 10:38
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2009-5-22 10:47
提示: 作者被禁止或删除内容自动屏蔽

作者: ic.expert 时间: 2009-5-22 18:32
赫赫，一块芯片在设计的时候总是先有编程模型才有体现机构的，而且影响体系结构的也不仅仅使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等公司也是有自己的研究院的。只不过能不能把这些东西拿出来到工业中用，这不是工程师能说得算得。

作者: RacingPHT 时间: 2009-5-22 19:47
提示: 作者被禁止或删除内容自动屏蔽

作者: ic.expert 时间: 2009-5-22 21:43
本帖最后由 ic.expert 于 2009-5-22 21:50 编辑

首先，感谢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的未来，恐怕很难有大的作为。

作者: RacingPHT 时间: 2009-5-25 09:59
提示: 作者被禁止或删除内容自动屏蔽

作者: ic.expert 时间: 2009-5-25 19:10
本帖最后由 ic.expert 于 2009-5-25 20:16 编辑

其实也没有说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 时间: 2009-5-25 19:12
其实灵活并不是目的，对于合适的计算平台来说，充要条件中：有效的计算是必要条件，而灵活的计算是充分条件。没有前者，“计算”便无从谈起。

作者: ic.expert 时间: 2009-5-25 19:19
本帖最后由 ic.expert 于 2009-5-25 21:45 编辑

其实兼容也不是说学术界不齿，学术界每个人都有自己的领域，有人就是研究如何兼容的（比如各种BT/VM技术等等），有人就是研究如何提高性能的，有人就是研究如何将低功耗的。这就像图形里面的很多效果，彼此都是正交性很强的东西。但是工业领域就需要是把所有的成果融合到一起而已，而我们看见的也是这个成果。

那图形举例子来说，比如，我们所看到的Graphics Pipeline。上面每个Feature都是一个不同的学术方向，在学术界届都会有不同的人研究，有人准们研究Texture Compression ，有人专门研究visibility Test，有人专门研究如何OIT，有人专门研究如何更好的更快的Texture Filter，有人专门研究AA。有人专门研究几何压缩，甚至连Depth Buffer Compression都有人专门研究。每个方向看上去都是很简单的，所展示的效果都是很让人感觉这帮人和工业界比就是混饭的学术骗子……但是他们所有的效果复合在一起就会变了很绚丽了，至于如何组合，那就是大多是工业界的事情了。所以如果没有学术界的技术积累，工业界是不会发展的很快的。当然，一个researcher不可能像我上述说的仅仅研究那么窄的一个领域。

所以，其实学术界里面只是分工不同罢了~~。国内有的时候很浮躁，往往不能认清学术和工业的关系，大家都钓到钱眼里了。所以很容易产生学术界大大的不如工业界的感觉，无论是学校还是公司，大家都拼命往工业靠，有的很多大公司连个研究院都没有。其实“格物穷理”才能“知行合一”，但是大多数人只看到了科技致富，却没有看到科技兴邦~

作者: zhangjingy 时间: 2009-7-2 11:46
Deferred Shading，XO玩不起啊。

作者: hanjiny 时间: 2009-7-28 16:14
觉得PS3比较强大

作者: xuejue01 时间: 2009-10-14 10:32
值得尝试。

作者: mgzzzz 时间: 2009-11-30 15:42

... 其实从Cell在体系结构设计的时候如果考虑到C++的话，那么根本不会用LS作为SPE的层次化存储方案，肯定会用Gloabl Addr Spaces Cache+ Scratch Memory。
ic.expert 发表于 2009-5-22 21:43

Fermi?

作者: blueskys 时间: 2009-12-12 18:41
stalker开GI 88GTX帧数折半

作者: ic.expert 时间: 2009-12-13 06:10
回复 45# mgzzzz

差不多：〉呵呵

作者: hadelex 时间: 2009-12-13 13:31
很感兴趣，看看。

作者: wofengnish 时间: 2009-12-13 19:00
学习了。。。

作者: 胡小华 时间: 2009-12-16 16:04
学习了~~~~~

作者: 大碗喝酒 时间: 2009-12-17 09:04
提示: 作者被禁止或删除内容自动屏蔽

作者: kglceo 时间: 2010-2-4 18:31
PS3到底破解没啊？韩国棒子不是破解了吗？

作者: kaven 时间: 2010-2-13 19:43
gpu和cpu之争，cpu派的观点就是将来肯定是cpu的天下，原因gpu需要和cpu通讯，天生的瓶颈，gpu越快，这个瓶颈越明显，而cpu内的集成的向量单元则不存在这些问题。
这类例子里面提到DMA占27%，感觉应该就是cell超过8800的最大原因。

作者: 中国高科 时间: 2010-2-16 00:34
提示: 作者被禁止或删除内容自动屏蔽

作者: baker1010 时间: 2010-5-23 14:31
纹理效果很吃带宽啊~

作者: squallzoe 时间: 2010-11-18 17:48
受教了~~~谢谢LS各位大大的精彩分析~~

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