走进并行时代之GPU篇(三)

传统的GPU架构前面两篇都介绍了，这篇主要聊聊Intel即将上市的新款X86的GPU——Larrabee

 

Fusion是AMD提出的融合GPU和CPU的概念，这也是收购ATI的一个主要目的吧。AMD从08年就开始造势说要出产品了，最后还是一拖再 拖，目前的说法是要在2011年的时候推出32nm的Fusion芯片。另一方面Intel也是在打算做融合，原本是今年下半年推出融合了GPU的 Nehalem架构Havendale和Auburndale，结果也是推迟了。把GPU跟CPU拼一块，未必就能提高显卡本身的性能，虽然数据传输的延 迟可能减小，但内存的带宽能否跟上也是个问题，Fusion的目标还是在GPGPU，提供一个软硬件的平台，充分利用GPU的的强大浮点能力做通用计算。 Fusion需要解决以下几个难点：一，内存架构。现在的GPU都是独立的显存，这点使得目前的GPGPU编程模型都不够优雅、灵活，就像一堵墙挡在 CPU和GPU之间。这样的编程模型一则是显式的数据传入传出会有比较大的开销，二来使得GPU被隔离，无法使用现有的库，也缺少了一个OS来调度资源。 如果统一了内存空间，那么OS就很容易来管理GPU的资源，为GPU创建线程以及线程间通信，如此大大提高了GPU的通用性，只不过内存带宽如果跟不上， 便会成为Fusion的性能发挥的瓶颈。二，编程模型。Fusion提供硬件平台的同时，软件平台也得跟上，最好的编程模型当然是自动化的方法，能够抽象 CPU及GPU平台，能够自动的创建GPU线程来负载大量的浮点计算。OpenCL或许承载了AMD的希望，不过从OpenCL公布的Spec来看，谨慎 的很怀疑它前景。三，工艺及能耗，现在的显卡的能耗越来越高，风扇做得越来越大，外接电源的功率也越来越高，要把GPU和CPU做进一个芯片，如何解决降 低能耗恐怕是个麻烦。另外就是工艺，根据AMD的官方说法是，2011年是32nm的的工艺基本成熟，Fusion会利用32nm的工艺来做Fusion 的设计。

 

Larrabee的介绍主要参考的是sig08的intel的那篇文章—Larrabee: A Many-Core x86 Architecture for Visual Computing。Larrabee是新型的GPU，指令集是X86的扩展，完全兼容 x86。

 

Larrabee市场定位是GPGPU，目标是满足计算，内存密集型程序的需求，诸如图像处理，物理模拟，光线跟踪等领域。它更像是多核的CPU，是 x86的扩展指令集，完全兼容x86，从架构上来看，跟Cell更有可比性。概括一下它的做法就是用多线程＋SIMD向量指令来提高浮点操作的吞吐量。 Larrabee利用软件来实现GPU的pipeline，整个芯片里唯一的Fixed Function Unit就是纹理存取单元，这是根据Intel的分析结果来作出的决定，利用软件来实现纹理存取、压缩性能会比硬件实现要差12－40倍。不过它并没有提 供测试结果。第一款的Larrabee可能会是16或者32个核，每个Core都是继承自Pentium P54C，在其基础上作了些修改，首先，现在工艺已经可以把当时的0.60µm 做成了现在的45nm。其次Larrabee加入了16-wide的VPU，利用向量指令提高浮动吞吐量。另外，Larrabee加入了4-way SMT，支持4线程，每个线程会有它自己的register set，线程间的切换省去了上下文的切换，只剩从L2 cache加载到L1 Cache的延时，所以Larrabee在处理4个线程有同样的dataset的时候会非常有效，比如绘制三角片到同一个tile之中。Larrabee 从P54C继承的特性有in-order以及非常短的流水级，in-order的x86核 比out-of-order要简单的多，可以省了不少晶体管，这样就可以更多的投入在浮点计算单元上，而由于缺少OOO所造成的损失，主要是靠4-way 的多线程间的切换来弥补，指令间遇到stall就靠线程间切换来弥补，而不是靠OOO。因此选择in-order是一种tradeoff。正是由于线程间 的切换比较频繁，因此流水级不宜过长，否则每次切换线程都必须清空流水线的话，代价会非常大。这种多个in-order的core组成的GPU到底能带来 多大的浮点吞吐量呢。一个2核，4-wide SSE的Core2 Duo的Vector throughput是8 per Clock，而一个10 in-order cores， 16-wide VPU带来的Vector throughput能达到160 per clock，当然这只是浮点能力，并不是综合性能，只是对于GPU来说，最看中的也就是这个峰值FLOPS。

 

Vector Processing Unit

 

Larrabee主要就是通过这个16-wide的VPU来得到计算密度的，VPU以及它的寄存器大概占了1/3的芯片面积。选择16也是在增加计 算密度跟保持高利用率之间作了tradeoff，16个32bit执行同一条指令的SIMD，只有16路全部填满才能达到峰值，如果这个宽度设得太高，那 么必然会影响利用率，在图形处理中，通常是按照一个个正方形的tile来处理，所以同时处理4＊4个像素还是很普遍的操作，因此可以达到一个不错的利用 率。Larrabee同时支持Gather/Scatter，16路的操作数可以来自16个不同的地址。Larrabee的VPU还有8个16 bit的Mask Register来控制这16路里的dest那些是可写的，由此可以用来把一些简单的if-else控制结构map到VPU，执行if-else的全部语句，用 Mask Register来控制分支，这个跟G80用的方法是类似的，这样作的好处是减少了branch指令，对于in-order的core来说，还是很有好处 的。除了向量单元外，larrabee还保留了标量单元，主要用来指令一些load，store，branch，cache manipulation还有一些简单的整数ALU指令。Larrabee所采用的双发射，是分为两级，主级流水线可以发射任何指令，而次级流水线就主要 发射一些标量指令，诸如上面提到的那些由标量单元执行的指令，这样可以简化编译器的静态调度算法，从而提高发射率。

 

Cache architecture

 

Larrabee的L1 cache是每个核私有的，32K的ICache和32K的DCache。而L2 cache则是共享的，每个核拥有256KB的local subset，cache一致性由硬件保证，这点是lrb跟cell的一个最大不同，cell的loacal memory是通过DMA指令来完成，而lrb则是靠cache的一致性协议，由核间的ring network来保持一致性，这点是对程序员透明的。关于coherent cache，采用什么样的协议，如此来保证一致性，intel的那篇文章里也没有细说。

 

Ring network

 

lrb采用双向的ring network来连接cpu core，16个核构成一个环网，每个核可以在偶数时钟里从一个方向得到数据，奇数时钟从另一个方向得到数据，这样简化了环网的路由算法，相比 crossbar能够提供更大的bandwidth。关于Scalability，如果核的数量超过16以后，lrb会把多个环网来连接起来。

 

Larrabee支持现有的OpenGL、DirectX，另外还提供了larrabee native api。从看到的资料来看，理论上作为完全兼容x86的Arch是可以运行OS的，不过lrb并没有支持所有PC兼容的特性，一开始的lrb还是作为 stand-alone的GPU，集成进CPU Arch，由QPI跟CPU相连。目前的lrb还只是处于模拟器阶段，一切都只有等芯片出来之后才好作评价。关于lrb新增的向量指令，可以参考如下网 址，lrb的一个C＋＋prototype library，用来模拟lrb的新指令集。

http://software.intel.com/en-us/articles/prototype-primitives-guide/