POPPUR爱换

 找回密码
 注册

QQ登录

只需一步,快速开始

手机号码,快捷登录

搜索
楼主: Edison
打印 上一主题 下一主题

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

[复制链接]
301#
 楼主| 发表于 2009-4-2 13:14 | 只看该作者
Intel 的 GDC 09 文档可以下载了,对 Larrabee 感兴趣又没看过的建议下载看看,其实我对 LRBni 没啥感觉,倒是光栅化的实现比较有意思。

http://software.intel.com/file/15542
http://software.intel.com/file/15545
回复 支持 反对

使用道具 举报

302#
 楼主| 发表于 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. "

总之比单纯看那两个幻灯片有意义的多。
回复 支持 反对

使用道具 举报

303#
发表于 2009-4-19 17:59 | 只看该作者
PPT中描述LRB的Rasterizer好像效率不高啊?

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

使用道具 举报

304#
发表于 2009-4-19 23:21 | 只看该作者
高深的东西,只能看看评论
回复 支持 反对

使用道具 举报

305#
发表于 2009-4-20 20:33 | 只看该作者
他們軟體可以optimize到一個境界,剩下的似乎就打算靠core數硬上了....
光論繪圖上Larrabee的資源感覺並不是很充裕。
回复 支持 反对

使用道具 举报

306#
发表于 2009-4-20 21:42 | 只看该作者
光栅化东西用可编程单元,我觉得不靠普。全是累加-比较,连乘法都没有,可编程单元有啥好处?无非就是自适应的AA,呵呵,这东西我用其他模块也能代替实现。
回复 支持 反对

使用道具 举报

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


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

使用道具 举报

308#
发表于 2009-4-21 09:41 | 只看该作者
阿?ROP?
我们一般会区分Rastrizer和ROP,前者是"光栅化",指Primitive-〉Fragment。后者是"光栅操作",指Fragment-〉Pixel,因为ROP这个概念是从2D继承过来的。

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

使用道具 举报

309#
发表于 2009-4-21 15:00 | 只看该作者
原來你是在講rasterizer嗎XD 光柵化這個名詞少用所以常常看錯XD
回复 支持 反对

使用道具 举报

310#
发表于 2009-4-21 19:33 | 只看该作者
ROP的效率还好吧~~毕竟都是Cache了,速度不会差到哪去。

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

使用道具 举报

311#
发表于 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!)」,因為他們的重點是要迴避專用硬體的專利,反過來說他們也對手上的製程承載能量自信滿滿。
回复 支持 反对

使用道具 举报

312#
发表于 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上面去。
回复 支持 反对

使用道具 举报

313#
发表于 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的。
回复 支持 反对

使用道具 举报

314#
发表于 2009-4-22 23:05 | 只看该作者
128个线程怎么算出来的?确切地说是分派到560个LRB core上面去才对,每个LRB Core同一时间只能有一个Tile。

还有,这和场景复杂度没关系,只和当前L2 cache是否能放下Frame Buffer有关。
回复 支持 反对

使用道具 举报

315#
发表于 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。
回复 支持 反对

使用道具 举报

316#
发表于 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
回复 支持 反对

使用道具 举报

317#
发表于 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


佩服佩服
回复 支持 反对

使用道具 举报

318#
发表于 2009-4-23 22:58 | 只看该作者
我还是没搞明白EJI兄台说的“嫌慢的的時候大可可以把整個chip上全部的core都投入rasterization stage”。”?
回复 支持 反对

使用道具 举报

319#
发表于 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的認知。
回复 支持 反对

使用道具 举报

320#
发表于 2009-4-26 12:27 | 只看该作者
不知所云!谁来解释一下哦!
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

广告投放或合作|网站地图|处罚通告|

GMT+8, 2025-7-29 00:52

Powered by Discuz! X3.4

© 2001-2017 POPPUR.

快速回复 返回顶部 返回列表