英特尔 Larrabee 体系架构讨论主题

Edison · 发表于 2009-4-2 13:14

Intel 的 GDC 09 文档可以下载了，对 Larrabee 感兴趣又没看过的建议下载看看，其实我对 LRBni 没啥感觉，倒是光栅化的实现比较有意思。

http://software.intel.com/file/15542
http://software.intel.com/file/15545

Edison · 发表于 2009-4-17 12:59

Dr. Dobb 的 Larrabee ISA 介绍文章：

http://www.ddj.com/hpc-high-performance-computing/216402188

其中提到：

"in the initial version of the hardware, a few aspects of the Larrabee architecture -- in particular vcompress, vexpand, vgather, vscatter, and transcendentals and other higher math functions -- are implemented as pseudo-instructions, using hardware-assisted instruction sequences, although this will change in the future. "

总之比单纯看那两个幻灯片有意义的多。

ic.expert · 发表于 2009-4-19 17:59

PPT中描述LRB的Rasterizer好像效率不高啊？

真正HW来实现Rasterizer都是个层次化的累加器阵列后面跟一个配套比较器阵列。好在这个东西DLP比较丰富，对于分支可以做Branch Spreading，但是效率能有多高呢？

huaqiu · 发表于 2009-4-19 23:21

高深的东西，只能看看评论

Eji · 发表于 2009-4-20 20:33

他們軟體可以optimize到一個境界，剩下的似乎就打算靠core數硬上了....
光論繪圖上Larrabee的資源感覺並不是很充裕。

ic.expert · 发表于 2009-4-20 21:42

光栅化东西用可编程单元，我觉得不靠普。全是累加-比较，连乘法都没有，可编程单元有啥好处？无非就是自适应的AA，呵呵，这东西我用其他模块也能代替实现。

Eji · 发表于 2009-4-21 01:14

光栅化东西用可编程单元，我觉得不靠普。全是累加-比较，连乘法都没有，可编程单元有啥好处？无非就是自适应的AA，呵呵，这东西我用其他模块也能代替实现。
ic.expert 发表于 2009-4-20 21:42

是啊是啊....所以我一直覺得ROP應該不是可以用software去取代的，
當然這是從IMR的角度啦，它已經整個換成tile rendering了，連rasterizer的流程都有變....
反正他們自認論文算的performance靠譜。

ic.expert · 发表于 2009-4-21 09:41

阿？ROP？
我们一般会区分Rastrizer和ROP，前者是"光栅化"，指Primitive-〉Fragment。后者是"光栅操作",指Fragment-〉Pixel，因为ROP这个概念是从2D继承过来的。

LRB的确是TBR，这个为了加速Depth/Stencil/Render Traget，不过就算这样，我也不认为LRB在图形上能强大到哪去。

Eji · 发表于 2009-4-21 15:00

原來你是在講rasterizer嗎XD 光柵化這個名詞少用所以常常看錯XD

ic.expert · 发表于 2009-4-21 19:33

ROP的效率还好吧~~毕竟都是Cache了，速度不会差到哪去。

关键是Rasterizer效率，我看了Intel之前释放的那个PPT，说的很奇怪~~~说什么他们本来想证明软件的光栅化是效率不高的，但是失败了，他们为此很高兴。怎么感觉有点此地无银三百两的意思？

Eji · 发表于 2009-4-22 03:16

ROP的效率还好吧~~毕竟都是Cache了，速度不会差到哪去。

关键是Rasterizer效率，我看了Intel之前释放的那个PPT，说的很奇怪~~~说什么他们本来想证明软件的光栅化是效率不高的，但是失败了，他们为此很高兴。怎么 ...
ic.expert 发表于 2009-4-21 19:33

well.... LRBni有rasterization專用的指令，問題的確是在結構上的適合度，看起來他們要做的其實主要是"把rasterization拆成很多個stage給很多core作"，不然的話其實現在的GPU大多也是單一的一個rasterization unit。

至於細部主要是一個16x16 blocks的tiling就是了，剩下的則是intra-tile的case問題，這時候會用另一個64x64的大tile來判斷。

所以他們的重點在於「論面積來說CPU的效率還是低於hardwired的rasterization unit；但是我們有限度地"平行化"了rasterization這個stage，所以我們嫌慢的的時候大可可以把整個chip上全部的core都投入rasterization stage(For example, can bring more mm^2 to bear – the whole chip!)」，因為他們的重點是要迴避專用硬體的專利，反過來說他們也對手上的製程承載能量自信滿滿。

ic.expert · 发表于 2009-4-22 09:57

本帖最后由 ic.expert 于 2009-4-22 09:59 编辑

Programmable Unit的坏处就是效率，同样的Area，Fixed Function可以放下更多的计算资源。关于对Rastrizer进行Parallelism操作。我有个问题，由于LRB是TBR的算法结构，我们确认一下LRB的工作流程：

首先，每个LRB Core在结束Geometry Pipeline之后把Primitive都声明到不同的Tile Buffer内，

然后当所有Primitive都跑完Geometry Pipeline之后，才能在LRBcore上面逐个启动Tile，从而进行Rasterizer。而这个Tile内部Pixel/Subpixel的数量，即tile Size是在Primitive进入Geometry Pipeline之前，即渲染启动前就设置好了的。

所以我的问题是。我觉得，在Tile启动Rasterizer以后，应该不能改变了。而你说的“們嫌慢的的時候大可可以把整個chip上全部的core都投入rasterization stage”。我觉得LRB core是不能把TIle切割并分发到不同的LRB Core上面的~~你知道你怎么看。

不过看似LRB可以在Rasterizer的时候自适应的自动判断是否需要AA，从而增加当前LRBcore内TIle的分辨率，即一个Tile内Subpixel的数量，并且切割TIle并把tile分发到不同的LRB Core上面去。

Prescott · 发表于 2009-4-22 22:12

所以我的问题是。我觉得，在Tile启动Rasterizer以后，应该不能改变了。而你说的“們嫌慢的的時候大可可以把整個chip上全部的core都投入rasterization stage”。我觉得LRB core是不能把TIle切割并分发到不同的LRB Core上面的~~你知道你怎么看。. ^' ], E- c' F" w! x; g

不过看似LRB可以在Rasterizer的时候自适应的自动判断是否需要AA，从而增加当前LRBcore内TIle的分辨率，即一个Tile内Subpixel的数量，并且切割TIle并把tile分发到不同的LRB Core上面去。ic.expert 发表于 2009-4-22 09:57

如果tile是64x64，那1920x1200的一帧可以分为560个tile，分到128个线程上，只要Tile之间不要太过不平衡，是不再需要切分Tile的。

ic.expert · 发表于 2009-4-22 23:05

128个线程怎么算出来的？确切地说是分派到560个LRB core上面去才对，每个LRB Core同一时间只能有一个Tile。

还有，这和场景复杂度没关系，只和当前L2 cache是否能放下Frame Buffer有关。

Prescott · 发表于 2009-4-23 12:27

128个线程怎么算出来的？确切地说是分派到560个LRB core上面去才对，每个LRB Core同一时间只能有一个Tile。

还有，这和场景复杂度没关系，只和当前L2 cache是否能放下Frame Buffer有关。
ic.expert 发表于 2009-4-22 23:05

LRB总共32个core，每个core有4路SMT，通常的编程模式是启动128个线程，然后将560个渲染任务放到任务队列中，每个线程处理完当前Tile之后再到队列中取下一个Tile。

ic.expert · 发表于 2009-4-23 19:41

第一，Sig08给出来的数据，每个LRB上面只有16个LRB Core。如果再大，Bidirection Ring NOC估计就受不了。要么使用两个Ring（这是Intel的标准做法），要么Topology Structure就得改成Mesh或是Torus。

第二，每个LRB Core只能放一个32*32到128*128个Pixel/Subpixel的TIle，具体选择哪种Size，则看当前TIle需要多少缓存而定，总之一个Core上不能放置超过1个TIle

Prescott · 发表于 2009-4-23 20:52

第一，Sig08给出来的数据，每个LRB上面只有16个LRB Core。如果再大，Bidirection Ring NOC估计就受不了。要么使用两个Ring（这是Intel的标准做法），要么Topology Structure就得改成Mesh或是Torus。

第二，每个LR ...
ic.expert 发表于 2009-4-23 19:41

佩服佩服

ic.expert · 发表于 2009-4-23 22:58

我还是没搞明白EJI兄台说的“嫌慢的的時候大可可以把整個chip上全部的core都投入rasterization stage”。”？

Eji · 发表于 2009-4-26 11:20

我还是没搞明白EJI兄台说的“嫌慢的的時候大可可以把整個chip上全部的core都投入rasterization stage”。”？
ic.expert 发表于 2009-4-23 22:58

For example, can bring more mm^2 to bear – the whole chip!
原文如此....
每個core同時頂多一個tile、最多投入16個core，這是我的認知....
不過一個core(的面積)都大大地大過一般GPU的rasterizer，何況16個core....這大概是Intel的認知。

ndf791212 · 发表于 2009-4-26 12:27

不知所云！谁来解释一下哦！

帐号		自动登录	找回密码
密码			注册

英特尔 Larrabee 体系架构讨论主题

浏览过的版块