引用:

原帖由 u571 于 2011-7-8 13:48 发表
如果搞融合概念的话，拿SPE来处理shader，买个powerVR的核心来做光栅化都比用AMD GPU上算。
如果PS4采用28nm的话集成32甚至48个SPE都够了

48个SPE得什么频率才能在傻多速应用方面赶上5870的那320组VLIW-5D？
AMD的融合概念实际实现还是要靠OpenCL这种东西把傻多速的工作由GPU分担一些，当然由于结构的原因可以避免一些不必要的data-transfer，但把GPU的‘部分’傻多速工作交给CPU或协处理器，并不见得合适或合算不是么？比如TMU部分如何处理？TMU和ALU部分的同步怎么处理？

引用:

原帖由 u571 于 2011-7-8 16:04 发表
4G下48个spe单精度浮点也有1.5T，虽然比5870理论性能差不少但是使用灵活性和效率比VLIW-5D高的多
OpenCL只是看起来很美好，实际使用难度比可直接使用C/C++的SPE高的多。
集成powerVR核心做TMU纹理读取和 ...

SPE只能直接操作Local store——这也是SPE之所以效率高的原因之一。而Local store的存取需由DMA编程完成。再者GPU中使用类似CMT的多线程结构，你打算怎么把它和SPE有效联系起来啊？随便给一段shader，假如有几处indirect texture lookup，怎么办？
OpenCL确实不如直接使用原生C/CPP处理通用程序方便，原因正在于GPU的结构适应于图形相关方面的运算。而要把这种结构运用于通用运算中，自然有这样或那样的不便和限制。道理反过来同样成立：你把ALU等运算单元剥离出去交给CPU运算，CPU这东西执行通用运算比较方便自由，但执行图形相关运算就是另外一回事，举个简单例子：GPU的话，你只管写shader就完事了，而SPE的话，哪怕全是ALU运算的shader，最起码你得写成SOA（struct of arrays）结构的程序才能发挥SPE的威力吧？其他的诸如Local Store和线程调度方面也不能不管吧？这难度显然比用GPU高不是么，这还不算要和TMU打交道的情况。
说到SPE图像辅助处理，基本就是Image space processing范畴，因为此时不需要TMU的参与，直接把ImageBuffer（或G-Buffer）分块交给各个SPE处理就可以保证很好的并行性（简单的fork-join嘛）。但想同时保持CPU对SPE的完整控制性又想让SPE去取代GPU中的ALU合作完成GPU的所有功能，在我看来至少短期内不现实。如果把SPE和GPU做紧密的绑定倒可以，但那还是SPE么？这不就走回GPU的老路了么？

就我看法，由于下代游戏机的渲染体系依然和本代相同（部分使用ray-trace是可能的）。所以并不需要过高的CPU Raw-power，主要还是强化GPU为主。什么48SPE必要性不大。CPU的主要工作依然是场景管理、AI、物理运算等。然后保持Console一贯的CPU-GPU间高速通信的特性就OK。

[ 本帖最后由 hourousha 于 2011-7-8 16:47 编辑 ]