XboxChina 论坛 » Xbox 360 技术讨论 » XBOX360 構成細部公開
http://pc.watch.impress.co.jp/docs/2005/0823/kaigai205.htm 注意的話，HDD是SATA。 此外，250MHz底下256GB/s的話，eDRAM內部是1024bit的構成。 GDDR3則是64x2的構成.... 接著，後藤老爹也提到一個過去我們注意到的重點： 考慮R420系的電晶體數量(160M)，C1則是總和252M(加上eDRAM的ROP)， 增加了50%的電晶體總數，但是卻從22個Shader增加到48個Shader.... 很簡單的想法就是，每個Shader的規模減小了。 首先，R3x0系的VS是4D+1D，PS則是兩個3D+1D(Main + Mini)。 C1的Shader因為是Unified Shader的關係，所以都是4D+1D。 單獨論大小的話，由於TMU的關係，PS通常遠大於VS， 所以既然US的單獨Shader都是與VS類似的構成，顯然每個Shader都變小了；TMU則是分離式的。 此外，必須要考慮的是所謂的"Bank"。 C1的ALU構成是3banks、16ALU per Bank， 代表實際上接受指令的單元有相當程度的共用， 亦即可以視為所謂3x16的構成，這應該也會相當程度減少電晶體。 反過來說，R520與C1之間的差異其實不小，所以R520的大小與C1顯然不能相提並論； R6x0與R5x0的大小關係可能也會有不小的差異。
TOP
\"PE\"部分的细节其实还没有公开，例如LATENCY等，这些要是都爆出来，估计XBOX360的指挥者都会感到失望。
其實我覺得大部分PPE的東西都和Cell共享資訊了.... 除了那個可以被GPU lock的L2。 SPE要傳資訊給PPE的時候，應該也會需要Lock L2， 但是因為都在chip裡面，透過EIB傳.... 造成的latency顯然不會像Waternoose這樣， 因為要讓off-chip的GPU lock東西，而得增加很多的延遲與控制時程。 當然，這東西顯然是有需要才做的，不然的話L2的容量會很快就被耗盡。 我是覺得交換比看下來不會真的很糟糕。
C1的US单元简化到如此程度显然是非常看重成本的，这样的单流水线规模几乎精简到GF256的水平！比通常的VS单元还要小1/4——60%！我现在真地认为C1到了让人不可思议的地步！这样的东西如何在复杂的PS效果下保持高效能？
pc.watch.impress.co.jp/docs/2005/0823/kaigai205.htm Xbox 360 CPU構成図 Xbox 360 CPUシステム構成推定図 PDF版はこちら Xbox 360のGPUダイ写真 Xbox 360 GPU詳細構成図(一部推定) Xbox 360 CPU詳細構成図(一部推定) 以下是EG一位知名硬件达人的分析: CPU 是单芯片多核心封装技术，一块芯片封装3个各自独立的物理内核做smp，技术比intel那种更先进，功耗低，电气性能稳定；cpu是12级流水线设计，延迟小效率高，尤其是数据指令在CACHE寻址命中如果出错，等待的时钟周期低很多；每个核心都有独立的i/o通道连接一条共用的fsb（前端总线），独占的全速率L1 cache，都是32k，而且都有一组独立的128位vmx单元和fpu浮点运算单元，两个vmx单元分别处理样本和序列，提高标量和浮点运算能力。集成内存控制器mmu，也是各自独立的，壶不干扰，不象intel的会争抢前端总线出口带宽，非常有利于降低整体的延迟提高效能，vmx单元可以提显著高多媒体性能和矢量加速，有专用指令集优化；CPU还可以支持直接c++编程，接口简单人机界面友好，直接面向用户，比靠寄存器编程或完全汇编简直不可同日而语；有专门DEBUG临时数据时钟传感器，这个也是一大便利，看来MS为开发用户确实费了不少心思啊，实在体贴。L2有1 MB 虽然不大，但是对处理游戏已经足够。 GPU gpu的封装采用球形反向封装，这样好处是每个pin引脚可以更好的接触和接地，有利于改良电器性能，也有利于高速运行下的稳定，而且每个引脚连线距离段，信号衰减少，抗干扰。子核心外置，估计是因为单个芯片集成核心尺寸太大，不利于提高良品率，这样处理就目前技术来说虽然保守成本高，但是更可靠而且可以方便提高产能，是个很稳妥的好主义，因为现在90纳米工艺，全世界都不是太好，产能比较低下，次品也多，不好保证品质。sony现在的很多困难碍事就是因为工艺困扰，其实技术已经成熟，但是加工成问题。所以说好大喜功太激进不好呢，何况toshiba的ic工艺比tsmc落后，至今12寸晶原生产线只有一条，新厂fab3（就是ps3用的）才刚开工试运行。 主机没有北桥芯片的设计，gpu可以通过cpu支配，数据交换直接借助主频半速的 L2 cache,有专门的node crossba这条独立的高速通道，1g带宽，另外还有两个dir寻址单元辅助，没有处理的数据暂时在二级换存划出来的缓冲区存储，相当于桢缓存里面等待，其余的在专门的uncache unit区域等待，都是由dir单元分组归类排好队的，可以直接对号入座。这样处理不但可以实现gpu的完全可编程，而且数据交换速度几乎没延迟，要知道缓存的速度显存根本不能望其项背。开发人员可以靠引擎直接支配gpu的像素着色器，顶点着色器，完全可以不在乎是否需要cpu编译，汇编可以一边凉快了，gpu已经靠cpu“思考”聪明到可以认基于c语言的hlsl语言，就是高阶着色语言，这在现在的pc上简直不可想像。而且以前gpu要靠显存当桢缓存，和cpu交换数据通过agp,北桥,或者pcie，现在一步到位，少了n个环节，一步登天，况且再快的图形总线能和cpu二级换存比么？显然不可能，何况这样还耗带宽，node crossbar是独立的，消耗也是消耗那和子内核交换数据的256g的超大带宽，完全可以忽略了。 图形芯片的设计完全人为可控，还都是基于简单的高级语言，命令行都少得多了，如果程序员有水平，简直可以为所欲为，靠引擎支配任何物理层上的东西，反正dx早就有现成函数库和api接口，以前的阻碍就是不能程序直接访问硬件，现在完全没隔阂，无拘无束了。日！ms这次的设计简直太无敌了！ 桥接总线 芯片组只有一个南桥，gpu与南桥借助pcie总线连接，南桥只负责控制sata,usb等串行通道，支持红外，100mb以太网络，集成采用xma 的dsp芯片充当声效芯片，算法由creative labs和ms提供，api是基于d3d的。南桥还支持flash读卡器，外接wifi接口等等，功能比较简单，不在赘述，我就顺道说，因为和gpu还有一个pcie连接界面，速度1g,上下行各500mb，不高，但是足够了，毕竟主要就是个dsp，pci的才33mb都够，何况500。 继续说gpu。gpu集成了显存控制界面和数模转换，视频输出，和cpu之间的交换带宽上行下行各10.8g，不是很高，不过这没啥关系，我上面不是提到了cpu的 L2的妙用么，有那么一个绿色通道带宽根本已经不是问题了。主内核和子内核之间有hsio总线连接，带宽高达256g。子内核使用10mb eram组成的192个单元的门电路，可以处理抗锯齿，线性滤波和模板缓冲等数据，模板缓冲极其消耗资源，尤其是带宽，但是这在处理即时光影作用很大，在doom3里就是大量使用的动态阴影的模版缓冲，狂吃显存和带宽，其实不是gpu处理不了，多数时候还是带宽不够。c1这么设计很有前瞻性，这是以后的趋势，以后游戏肯定是即时光影为主。 gpu将数字信号通过数模转换通过专门的界面输出，看样子肯定是使用shder video技术靠渲染流水线对视频直接优化，应该支持硬件的hd.264解码，这样视频信号显然有保证了。 显存是gddr3，内存显寸一体化了，都是128bit的，两个模组，各64位，由一个内存控制器统一支配，就是cpu集成的那个。带宽22.4g，虽然位宽比较低，不过应该看到是1.4gb的，频率极高，看来ms是出于速度考虑，因为本身xb360占带宽的大头不在显存hub上，不象pc或者ps3，所以用主频极高的显存显然对提高性能效果更显著，ps3开发机的显寸才700mhz而已，xdr虽有3.2g主频，可那是串行的，只有16位，算下来带宽还是低。而且xb360内存显存可以任意支配，ps3由于xdr和ddr使用不同内存控制界面和总线，所以上限就是256，算下来只有比xb360低，游戏机os内核就没几个进程，而且还是直接访问物理层，要那么多主内存有啥用？！ 最后的一些总结 xb360是基于现有成熟技术上采用颠覆传统的创造思维组合设计的产物，其根本设计指导思想是面向用户，而不是堆积lsi电路。设计均衡，技术成熟，但不乏创意，越是细节越见功底，高效能且人性化，尤其是关键技术非常有前瞻性，而不是搞些没用的华而不实的噱头冒充高科技，结构紧凑，不浪费任何设计，几乎找不到瓶颈和不均衡的地方，属于实力派下盘扎实那种。在技术和可行性上找到了很好的切合点，尤其gpu双核心封装，很具代表性，如果不是这么个点子，已现在的工艺，xb360很可能要延期，3.23亿晶体管的东西良品率能上去才见了鬼了。
[quote]Originally posted by Lan at 2005-8-26 04:54 PM: 浪漫跑车：
fans到上面那種地步實在是不太可取.... 同一個狀況在PS3上就是問題，在360上面就是過人優勢？ 有點好笑。 C1比較重大的問題是ROP與Shader的規模， 因為DRAM 10MB需要80M是省不了的，既然它有100M的總數， 那ROP與HSI就大概只有20M左右，然後有192個FP unit，共8組ROP。 這下每個Unit大概只有十萬個電晶體.... well，這並不是什麼大問題，只是有點意外而已； 不過這讓人必須重新建立ROP到底多大的觀念。 其次是US的Data Fetch，我以為應該是有省掉一些.... 因為16ALU是共用一個大queue，而不是可以單獨自行load的。 這樣應該會比每個ALU單獨都具備一個fetch unit要來得小。 然後sequencer因為要跑64個thread，所以可能單元也不會很小。
waternoose的pipeline是21 stages，和northwood p4相当，而不是12 stages。 waternoose的L2 cache latency高达31 cycle，什么概念？K8的L2 cache latency实测只有12个cycle，waternoose多费两倍的时间才能抓到L2 cache的数据。 31 stage的Prescott的L2 cache latency也只需要28个cycle，pipeline stage和waternoose相当的Northwood L2 cache latency也都只需要19个cycle。 waternoose的L2 cache是半速运行，即1.6ghz。 waternoose、cell、k8、p4的L1 cache都是全速的，这点似乎并没有什么特别值得夸耀。 waternoose没有像K8、CELL那样集成任何内存控制器，访问主内存的延迟是500+个周期。K8、CELL访问XDR只需要120+个周期。 waternoose的vmx指令集支持和CELL的PPE是一样的，因为两者的cpu内核单挑来看的话实际上是一样的，一样的ALU、一样的FPU、一样的VMX单元。 waternoose不能直接跑c++程序。cell、waternoose、p4、k8都能采用C、C++等高级语言进行编程，PS2 EE的MIPS CPU内核也类似，但是EE的VU则需要使用汇编，CELL的PPE、SPE编程都是C、C++，warernoose在编程语言上没有半点优势。CELL、Waternoose都使用IBM的编译器技术。 CELL有2.5MB片内内存，2.5倍于waternoose的1MB L2 cache，CELL的PPE、SPEs能以类似NUMA的方式高效地互相读取对方的片内内存。 CELL、Waternoose、Xenos、RSX都采用FPBGA的方式封装，其中Xenos采用了c1+eDRAM/ROP的双芯片MCM封装，成本高昂。RSX的芯片尺寸大约是200mm^2（根据NVIDIA在Graphicshardware.org上的文件），芯片面积和目前的Prescott差不多，大规模量产完全不成问题，加工、封装、测试成本更是要比Xenos低不少。 在制造工艺方面，索尼/东芝在2002年4月达成半导体工艺合作协议，在这个持续4年协议里面IBM会提供包括50nm线宽、300mm晶圆以及最先进的SOI（FD-SOI？）等工艺给索尼、东芝。PS3的CELL、RSX的生产工艺初期是90nm，索尼和IBM生产CELL，RSX是索尼自己生产。我没看出IBM的90nm SOI的工艺会在什么地方比TSMC落后，事实上这部分对用户来说基本上意义不大，关键是售价订在什么价位，这才是用户最关心。 waternoose和xenos的数据交换总线是双向各10.xGB/s，说没有\"北桥\"实际上是有些误导，因为Xenos的设计实际上就是GPU+北桥的设计，和PC上945G芯片组/XBOX NV2A(NV2B)类似，所不同的是CPU连到北桥的FSB要比PC 945G芯片组/NV2A大一些、效率更高一些。 Xenos抓waternoose L2 cache的数据主要是类似dislpay list、部分模型顶点、shader之类的东西，绝大多数的纹理/render target数据还是要跑到GDDR3系统内存中提取、写入。 在这点上，Xenos+Waternoose的运作方式并不比RSX+CELL高明，在PS3上RSX还能向XDR执行读取写入等操作，实际可用的带宽要高于XBOX 360。 程序员可以在某种程度上对Xenos、RSX的硬件直接控制，但是在实际中这样的情况很少发生，大都还是采用HLSL、Cg、GLSL之类的高级shader语言和D3D、OGL ES之类的API。 如果在游戏中封装的代码还是HLSL、Cg或者GLSL以及其他半成品shader程序的话，还是需要经过CPU的JIT编译器进行编译，因此说采用HLSL就不需要CPU编译是错误的理解。当然，游戏开发人员在封装游戏的时候，完全可以把shader都编译并加密在游戏运行的时候再解码以保护产权，但是这和xenos、rsx的先进性毫不相干更谈不上什么不需要CPU编译之类的话。 Xenos没有集成RAMDAC，RAMDAC或者说CRTC是M$以额外芯片的方式实现，缺点是增加不少成本。 Xenos的子芯片基本上就只是一个消耗了100M晶体管的FSAA加速器，此消彼长，Xenos的shader性能因此相对削弱了不少，今后的游戏都将是大量的shader、长shader为主，动态阴影、动态光照、动态柔和阴影都是会严重吃掉C1（Xenos 父芯片）shader计算能力，结果1亿晶体管的FSAA加速器就得等待C1抓狂。 RSX有16个ROP做4XMS FSAA，在游戏设计为偏重shader的情况下，FSAA也能接近Free。 此外，原文作者对内存带宽的描述把握不准，GDDR 700MHz实际上是指GDDR3 1400MT/s，PS3使用的GDDR3和XBOX 360属于同一个档次，而且PS3上的GDDR3基本上是RSX独享。 PS3使用的XDR位宽是32bit*2 = 64 bit，不是16bit，XDR提供带宽25.6GB/s。 XBOX 360：采用UMA内存结构，CPU和GPU共享22.4GB/s主内存 Playstation 3：采用类NUMA内存结构，GPU有22.4GB/s本地带宽，CPU有25.6GB本地带宽，GPU可以以存取系统主内存的方式读写XDR内存，CPU有必要的话，也能存取GPU的GDDR3内存，但是这样的情况并不会经常发生。 如果游戏开发人员不善于管理纹理、场景模型、音频文件，512MB内存将会被轻易地突破。
cell、waternoose、p4、k8都能采用C、C++等高级语言进行编程，PS2 EE的MIPS CPU内核也类似，但是EE的VU则需要使用汇编，CELL的PPE、SPE编程都是C、C++，warernoose在编程语言上没有半点优势”----这个能用不说明问题，能用和好用不是一回事，以cell的架构，它写c/c++不可能和对称架构的waternoose难度一样，要借助大量的intrinsic function才能工作，spe的调度也很困难，而waternoose没有这个问题
我说的主要针对原文所谓的能\"C++\"就好像就很了不起的样子。 在SIMD的利用上，VMX、SPE都需要intrinsic才能发挥较佳的SIMD效能，在这点上waternoose、cell没有什么本质区别。 从SPEC OMP2001的测试结果来看，IBM的网络化分发优化效果相当好，同样的性能提升幅度在SPEC.org上来看需要4倍甚至更大规模的处理器才能实现。 IBM对这部分描述是： “Our compiler-controlled software-cache, memory hierarchy optimizations and code partitioning techniques assume all data resides in shared system memory, and enables automatic transfer of code and data while preserving coherence across all the local SPE memories and system memory. ” \"Our current compiler enables this via OpenMP Pragmas, but our techniques will easily support the existing auto-parallelization techniques in the compiler framework. Other parallelization paradigms such as UPC could be developed on this framework.\" \"Our current compiler implementation supports parallelization through user-inserted OpenMP pragmas to denote the parallel sections of code.We generate a PPE binary that when executed spawns threads on the SPEs, initiates DMAs to transfer the appropriate SPE code to the SPE local stores, and co-ordinates execution of all threads in the program. The figure illustrates the steps in compiling OpenMP for the Cell architecture. Outlining. We outline each parallel code section, i.e., we replace it with a call to a newly created function, and move the code corresponding to the parallel code section into the newly created function. Cloning. We clone outlined functions corresponding to parallel code regions, so that we have two copies of these functions, one to be compiled to execute on the PPE and the other to execute on the SPEs. When cloning outlined functions, we also clone any other functions that may be invoked when these functions execute\" 要用好CELL当然要花更多的功夫，不过这样的架构是大势所趋，CELL在开发阶段其实已经充分考虑了这方面的问题，并非一个单纯追求指标而不顾实际使用效果的产品。 如果大家觉得有更好的方式能在同样面积的芯片上实现CELL的效能，欢迎提出，一起讨论。
