拉娜芘的行为艺术larrabee
[font=宋体]软件就是新硬件[/font]—[font=宋体]超越可编程着色器[/font][font=宋体]硬件简介[/font]
[img]http://www.2000xg.com/attachments/month_0708/r20078611051.jpg[/img]
[font=宋体]拉娜芘主要硬件单元：[/font]
[font=宋体]大量[/font]x86[font=宋体]核心，新型[/font]x86[font=宋体]核心支持[/font]16[font=宋体]路单指令多数据指令集。[/font]
[font=宋体]全相联一级缓存[/font](L1D[font=宋体]容量[/font]32KB )[font=宋体]与二级缓存[/font](L2[font=宋体]容量[/font]256KB )
[font=宋体]硬件纹理单元，纹理采样单元支持[/font]DirextX/OpenGL[font=宋体]所有功能，并含有[/font]32KB[font=宋体]纹理缓存。[/font]
[font=宋体]高速双向环形总线[/font]ringbus[font=宋体]，支持多个二级缓存之间共享数据。[/font]
x86[font=宋体]核心[/font]
[font=宋体]新型[/font]x86[font=宋体]核心支持[/font]Pentium[font=宋体]处理器的所有指令以及[/font]64[font=宋体]位扩展指令。[/font]
[font=宋体]短流水线核心采用双发射顺序执行微架构，标量指令额外延迟为[/font]0[font=宋体]，即单周期延迟。向量指令为多周期指令，而延迟较短。[/font] [font=宋体]当出现分支预测错误，将刷新流水线，所以采用短流水线有利于减少性能开销。短流水线也有利于减少缓存遗失时的性能开销。[/font]4[font=宋体]路同步多线程[/font]SMT[font=宋体]，可以单周期线程切换，主要用于隐藏一级缓存遗失、向量指令延迟等。[/font]
[font=宋体]向量处理单元[/font]
[font=宋体]向量单元含有大量的[/font]512[font=宋体]比特寄存器。单指令多数据流水线可以一次处理[/font]16[font=宋体]个[/font]32[font=宋体]比特整数[/font]/[font=宋体]浮点数据，或[/font]8[font=宋体]个[/font]64[font=宋体]比特浮点数据。向量乘加法指令的吞吐率为一个周期，绝大多数向量指令的延迟远小于[/font]8[font=宋体]个周期。向量计算指令的两个源操作数可以是寄存器，其中有一个源操作数可以直接来自缓存，而延迟开销与寄存器一样。向量指令采用[/font]16[font=宋体]比特预测寄存器控制向量指令的[/font]16[font=宋体]路计算结果哪些应该写回到寄存器，哪些应该被绕过。向量浮点计算完全兼容[/font]IEEE754[font=宋体]标准。[/font]
[font=宋体]向量计算单元可以把[/font]float16,int8,int16[font=宋体]等数据自动转换为[/font]32[font=宋体]比特浮点/整数数据进行计算，因此缓存可以存放更多的数据。[/font]
[font=宋体]向量计算单元支持集[/font]/[font=宋体]散[/font](Gather/Scatter)[font=宋体]计算：一条指令可以从[/font]16[font=宋体]个不同的地址读写[/font]16[font=宋体]个数据结果。[/font] [font=宋体]如果与预测寄存器协作，还可以实现[/font]”[font=宋体]数据流[/font]”[font=宋体]处理模式[/font]:[font=宋体]自动向量化的执行标量代码，支持循环、条件、调用、堆栈等操作，良好的契合着色器语言的计算特点，[/font]16[font=宋体]路向量计算单元相当于[/font]16[font=宋体]个[/font]SP(Scalar Processors)[font=宋体]。[/font]
[font=宋体]全相联缓存[/font]
[font=宋体]全相联一级数据缓存容量[/font]32KB[font=宋体]，二级缓存容量[/font]256KB[font=宋体]，二级缓存之间可以共享数据。引入了缓存行为控制逻辑，例如，可以控制数据是否直接读写到显存还是读写到缓存；还有数据预取指令，缓存替换策略指令等。多种控制手段可以精细控制缓存行为，令其如同一块芯片内部[/font]RAM(scratchpad RAM)[font=宋体]一样。还具有可以自动预取大批量数据的自治逻辑单元。[/font]
[font=宋体]纹理采样单元[/font]
[font=宋体]为全功能[/font]DX/OGL[font=宋体]纹理采样单元，支持所有标准纹理格式，纹理缓存容量为[/font]32KB[font=宋体]。纹理采样单元本身是一个独立的协处理器，一个[/font]x86[font=宋体]核心配有一个纹理采样单元，[/font]x86[font=宋体]核心一次向纹理采样单元发送[/font]4X4—16[font=宋体]个像素的[/font]UV[font=宋体]坐标，而纹理采样单元把[/font]16[font=宋体]个采样过滤结果通过[/font]L2[font=宋体]返回给[/font]x86[font=宋体]核心，[/font]x86[font=宋体]核心与纹理采样单元双方都是通过二级缓存来交换命令与数据。软件需要通过内嵌函数[/font](inline-call)[font=宋体]来调用采样命令。[/font]
DirectX[font=宋体]软件渲染器[/font]
[font=宋体]除了纹理采样外，都是使用软件来实现。[/font] [font=宋体]顶点处理本质上和[/font]GPU[font=宋体]基本一样，[/font] [font=宋体]主要区别是像素处理。[/font]
[font=宋体]是把一帧图像分为多个小方格[/font](tile/bin)[font=宋体]，小方格的大小为[/font]64X64([font=宋体]或[/font]128X128)[font=宋体]，然后一个小方块单独由一个核心来负责渲染。[/font] [font=宋体]例如分辨率为[/font]1280X960[font=宋体]时，[/font] [font=宋体]就被分割为[/font]20X15=300[font=宋体]个小方块分开渲染，每个小方块大小为[/font]64X64[font=宋体]。[/font] [font=宋体]一个核心负责渲染一个小方块，当渲染好一个小方块后，就接着渲染下一个小方块，直到[/font]300[font=宋体]个小方块都被渲染好为止。当核心越多时，就有越多的小方块被同时并行渲染。一个核心执行编译器产生一个程序[/font](routine)[font=宋体]来负责多种渲染任务，主要是读三角形、顶点、插值、读像素、前期[/font]Z[font=宋体]变换、模板、后期[/font]Z[font=宋体]变换、像素着色器、混合等[/font]--[size=10.5pt]Readtriangles[/size]\[size=10.5pt]Read shaded verts & set up interpolants\Readfragments from bins\Early Z/stencil\Perspective correction & interpolation\Pixelshading\Late Z/stencil[/size]\[size=10.5pt]Render target blend[/size][font=宋体][size=10.5pt]。[/size][/font][font=宋体]一个程序[/font](routine)[font=宋体]里面含有[/font]4[font=宋体]个线程它们是由硬件同步多线程[/font]SMT[font=宋体]负责切换，而线程里面含有多个依靠软件切换的微纤线程[/font](fiber)[font=宋体]，常见情况下，一个纤程[/font](fiber)[font=宋体]一次可渲染[/font]4X4=16[font=宋体]个像素。[/font]
[font=宋体]拉娜芘的行为艺术[/font]--[font=宋体]和[/font]CPU[font=宋体]比[/font]3D[font=宋体]图形性能，和[/font]GPU[font=宋体]比通用运算性能。[/font]ifan[font=宋体]感动的痛哭流涕。[/font]
[[i] 本帖最后由 gaiban 于 2008-9-1 19:59 编辑 [/i]] 帮你顶了。。。。。。。。。。。。。。 囧。。。。。 有史以来最为详尽的公开描述。
涉及细节无数，GPU Fans要仔细看了哦
最后一句话应该改成：可以和CPU比通用性，和GPU比图形性能
[[i] 本帖最后由 Prescott 于 2008-9-1 17:30 编辑 [/i]] ”向量计算单元可以把float16,int8,int16等数据自动转换为32比特浮点数据进行计算，因此缓存可以存放更多的数据。“
这里应该错了， float16转换为float32， 而int8，int16转换为int32 看上去挺美好，晴空万里，祥云缭绕。 [quote]原帖由 [i]Prescott[/i] 于 2008-9-1 17:28 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18375593&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
有史以来最为详尽的公开描述。
涉及细节无数，GPU Fans要仔细看了哦
最后一句话应该改成：可以和CPU比通用性，和GPU比图形性能 [/quote]
一般人是很难看懂的，披露的细节程度确实超越了至今为止全部中文介绍larrabee的总和。
以前后藤乱说了很多的废话，被翻译了一下，照样呆在“体系架构”分类里。
正规的介绍来了，倒被E大强行移到“一般”了。 [quote]原帖由 [i]gaiban[/i] 于 2008-9-1 19:58 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18377152&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
一般人是很难看懂的，披露的细节程度确实超越了至今为止全部中文介绍larrabee的总和。
以前后藤乱说了很多的废话，被翻译了一下，照样呆在“体系架构”分类里。
正规的介绍来了，倒被E大强行移到“一般 ... [/quote]
{lol:]
可惜啊，可惜，真料来了，却没人看得懂。
我来总结一下吧，反正这里的人只关心性能：
从Larrabee的设计来看，单论shader性能，理论上32核心@2GHz的Larrabee相当于512 SP@2Ghz的G80。
这个值与Intel论文中模拟出来性能很一致，说明这个设计是达到了预期目标的。
[[i] 本帖最后由 Prescott 于 2008-9-2 02:07 编辑 [/i]] [quote]原帖由 [i]predaking[/i] 于 2008-9-1 23:57 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18380068&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
错误比较多，而且没有切中要点 呵呵
比如 P54C对于4way SMT怎么支持，Branch的机制对Inst Stream的影响，Stand和Fiber以及Thread之间的关系，Bin和Pixel以及Fragment的关系，Input Assambler和LBR Shader的关系， ... [/quote]
其实这些东西都是清楚的不能再清楚的东西，你搞不懂，只能说你对CPU体系架构还有太多东西要补，你已经彻底被NV洗了脑，已经没有办法跳出传统GPU的设计来理解一个真正的图形处理器应有的样子了。 {blush:] 意见保留,或许成为史上最暴力的PPU也说不定 {biggrin:] 言外之意4核的larrabee可以比得上9600GT超频版？ 看笑话，看笑话。 l like it. 希望早日买到{victory:] larrabee不需要H-Z，也不需要compression {mellow:] 看来有了这显卡，就不用CPU了？ P大是说单论shader如何如何，larrabee还要干其他活。
可能那是larrabee的向量单元奋斗目标， 结果还要看。 [quote]原帖由 [i]Prescott[/i] 于 2008-9-2 01:55 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18380778&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
{lol:]
可惜啊，可惜，真料来了，却没人看得懂。
我来总结一下吧，反正这里的人只关心性能：
从Larrabee的设计来看，单论shader性能，理论上32核心@2GHz的Larrabee相当于512 SP@2Ghz的G80。
这个值与Intel论 ... [/quote]
[b][color=blue]请问Prescott大，Larrabee每个核心每周期到底是发射1个512bit AVX还是发射两个啊？[/color][/b]
[b][color=#0000ff]如果是一个，貌似达不到单精度2Tflops[/color][/b]
[[i] 本帖最后由 itany 于 2008-9-2 10:05 编辑 [/i]] [quote]原帖由 predaking 于 2008-9-2 09:57 发表
是么，呵呵 ：〉
记得N年前，我的小组还在的时候我主持过Inorder MPU和4-way Superscalar OOO MPU的Design，也相当长的时间研究过SMT OOO MPU，主要是以DEC Alpha 21464的思想为原型，呵呵。这都是我们之前 ... [/quote]
你觉得SMT除了“表面的东西”还有什么呢？话说一半没什么意思，别人也不会因为这个当你是大拿。
[quote]原帖由 Prescott 于 2008-9-2 01:55 发表
可惜啊，可惜，真料来了，却没人看得懂。
[/quote]
什么料啊？好就没上来了 [quote]原帖由 [i]我奏是马甲[/i] 于 2008-9-2 02:46 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18380894&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
这样换算的话就是：16核心的P54C等于256SP 2GHZ，灭掉GTX280，然后因为GTX280勇超扣肉QX9770 NN倍，所以16核心的P54C足够把QX9770轰渣……
又或者两年之后NV在出GF CTU380..成为世界上最强大地CPU。。。intel就出 ... [/quote]
您这已经乱了
AMD的64个5D单元就相当于320个SP，为什么Intel的“16D”单元不能相当于512个SP呢？ 似乎只有 "向量指令采用16比特预测寄存器控制向量指令的16路计算结果哪些应该写回到寄存器" 这句话是 larrabee-manycore.pdf 里没留意到的。 预测寄存器其实很普通，可能他翻译的不大好，英文就是predicated register。我认为应该翻译为断言寄存器？ 另外加一句，predicated register在所有的SM3.0级别的GPU上都是存在的。ATI的predicated register因该是64bit, 对应一个wavefront的大小。 那就其实是这段内容了：
"Finally, Larrabee VPU instructions can be predicated by a mask
register, which has one bit per vector lane. The mask controls
which parts of a vector register or memory location are written
and which are left untouched. For example, a scalar if-then-else
control structure can be mapped onto the VPU by using an
instruction to set a mask register based on a comparison, and then
executing both if and else clauses with opposite polarities of the
mask register controlling whether to write results." [quote]原帖由 [i]RacingPHT[/i] 于 2008-9-2 10:12 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18382381&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
预测寄存器其实很普通，可能他翻译的不大好，英文就是predicated register。我认为应该翻译为断言寄存器？ [/quote]
哥们，这可是CSarch的基本功……，是条件寄存器。 至于L2/L1，本身就已经是GPU的标准设计了呀。只不过NV/ATI的L2 cache设计得太过简单，不存在一致性机制。所以只能作为read-only。
而Larrabee的L2$我觉得还是体现Intel的经验的。毕竟硬件进行一致性对一些scatter op来说我觉得还是有意义的。而这正好是传统GPU的弱项。目前NV/ATI的scatter都只能用uncached memory。
对于L2，我反倒觉得是LRB最特别的地方。 [quote]原帖由 [i]predaking[/i] 于 2008-9-2 09:57 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18382182&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
是么，呵呵 ：〉
记得N年前，我的小组还在的时候我主持过Inorder MPU和4-way Superscalar OOO MPU的Design，也相当长的时间研究过SMT OOO MPU，主要是以DEC Alpha 21464的思想为原型，呵呵。这都是我们之前 ... [/quote]
是硬件简介--以介绍几个关键硬件为主，软件仅仅是简单的形象的说一下而已，把tile/bin的特征说清楚--本质是分块渲染(比较适合larrabee，你要是从GPU的角度看，larrabee的cache就可以变成了GPU的寄存器了)。 也是说一些别人没说的，或者别人说错的。
可能有些细节有出入，但是基本处于“官方正史"的观念与角度来介绍larrabee。
往大处算strands， 32核心larrabee，4线程/核心，2-10 fiber/线程，16-64strands/fiber， larrabee是可以有上万个strands了。 从GPU角度看，32核心larrabee是一个512个高频SP/32个TMU，strands数量上万(32X4X10X64=8万多个"GPU线程")，大量向量寄存器(0级寄存器)，"一级寄存器"容量1MB，"二级寄存器"容量8MB。
至于"野史"的观念与角度--"偶是这么看问题的，偶是那么看问题的"。 那是个人自由了。
另外，larrabee与P54C的关系并非等价关系，如果可以就应该认为是一个兼容于pentium核心的新设计的SMT处理器--或许能降低误解出现的概率。 呵呵。如果你没有拿出更好的想法，说其他的什么公司是草包都好，别人都不会当回事。
至于TCC，我不明白为什么要在GPU上作? [size=4]想请问一下：这个拉拉比是不是在intel发布的业界首款DX10显卡（[size=6][color=red]G965[/color][/size]）的基础上研发出来的呢？[/size] [quote]原帖由 [i]itany[/i] 于 2008-9-2 10:01 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18382236&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
请问Prescott大，Larrabee每个核心每周期到底是发射1个512bit AVX还是发射两个啊？
如果是一个，貌似达不到单精度2Tflops [/quote]
一个，FMA算两个 [quote]原帖由 predaking 于 2008-9-2 10:45 发表
别的就不评价了就评价一点，LRB L2$相当于GPU fifo，不是RF。 [/quote]
这个要看他是怎么alloc的吧。
fiber肯定要用一块，这个相当于RF。
framebuffer用一块，相当于local tile memory。
还有command list一块。
至于fifo，不知道你是指什么部分的fifo。 [quote]原帖由 [i]predaking[/i] 于 2008-9-2 10:45 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18382807&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
别的就不评价了就评价一点，LRB L2$相当于GPU fifo，不是RF。 [/quote]
你可以看成是可以OOO的fifo，其实也是RF。 从向量指令的角度看，L1是RF,L2自然也可以是RF了，就是延迟有区别。 其实可以是有register cache概念来看问题，有些限制罢了。 [quote]原帖由 [i]predaking[/i] 于 2008-9-2 11:15 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18383197&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
着结论厉害……应该ISCA上面给哥们20分钟发言 [/quote]
三流处理器国家的research，天天鄙视一流处理器国家的产品， 概念是天天变化， 没有变化的是长期落后。
既然人家intel提出来那些看法，那些角度来思考，自然是有它内在原因。 缓存是全相联的哦。 某位仁兄也实在是太自大了。
何止是三流，根本就是不入流。
这个架构放在这里，已经是现有成熟技术的集大成者，可以说颠覆传统GPU的设计，这一步已经跨的足够大，业界已经是一片哗然。
做产品不是做research，把一大堆概念性质的东西往上堆，最终只能造成产品失败。G80连CC都没有，在这里就要求LRB有transactional CC，否则就是落后，这不是扯淡吗？
[[i] 本帖最后由 Prescott 于 2008-9-2 11:28 编辑 [/i]] [quote]原帖由 predaking 于 2008-9-2 11:09 发表
作Research，没有金钢钻，怎么敢说别人是草包。呵呵
因为Transactional CC比 Traditaional CC能获得更好的Parallel。 [/quote]
你这个结论做的。。。拿CPU的task parrallel的结论套在GPU上，本身就是大错啊。
GPU的parrallel本身就是架设完全不需要CC的前提得来的。而且TCC牺牲的是ALU cycle，这个在wide SIMD上的浪费又有多少，我不知道。 [quote]原帖由 predaking 于 2008-9-2 11:05 发表
只有一种FIFO，做ROB的Fifo，但是这里情况有些不一样，只是起到了ROB的Buffer功能，没起到其他作用。
$就是$，会有$ Inst，这在Microprocessor中很普通的技术，80年代就有了，Prefetch而已，不能算作RF。
呵呵，来这儿跟一群爱好者哥们好这切磋，有点张召忠的感觉……[/quote]
GPU的fifo实在太多了。。作为一个long pipeline, 几乎每一部分的连接都有fifo。
另外你也不必感觉太良好，这里有可以拿到GPU内部资料的程序员，有intel的人，这些人都是你说的“爱好者”？ [quote]原帖由 [i]predaking[/i] 于 2008-9-2 11:41 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18383561&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
恩，非技术论坛果然不一样
受教受教 ：〉 [/quote]
有话好好说， 何必冲头冲脑呢？
被河_蟹了吧 [quote]原帖由 predaking 于 2008-9-2 10:16 发表
哥们，这可是CSarch的基本功……，是条件寄存器。 [/quote]
我觉得不一样。传统的CPU并不会使用predicated, 除了IA64这类。
比如PowerPC上的条件寄存器就叫CR(Condition Register)。
condition reg是用作branch, 而predicate不用作true branch。 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 10:04 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18382281&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
似乎只有 "向量指令采用16比特预测寄存器控制向量指令的16路计算结果哪些应该写回到寄存器" 这句话是 larrabee-manycore.pdf 里没留意到的。 [/quote]
说明你没有好好看，而P大看的比较仔细。 有很多细节是 larrabee-manycore.pdf 里没有的，或者是没有直接说的。或者是没有被你们好好当成一回事来讨论的。
能看懂的人很少。
另外来的“predaking”哪是来讨论larrabee的？ 什么新的细节都没有提供，就来表个态偶是高手，nv与intel的设计都很差。
应该说，讨论的是目的是利用larrabee的更多硬件规格细节的披露，来和nv/ati的产品比较优劣得失， 设计理念上的差异， 有可能的坑在哪里，等等。。。。。。 [quote]原帖由 [i]gaiban[/i] 于 2008-9-2 12:37 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18384265&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
说明你没有好好看，而P大看的比较仔细。 有很多细节是 larrabee-manycore.pdf 里没有的，或者是没有直接说的。或者是没有被你们好好当成一回事来讨论的。
能看懂的人很少。
另外来的“predaking” ... [/quote]
这个不是我看得仔细，而是我原先就都知道。:a)
写这个的人一定看了相当详细的内部资料。 [quote]原帖由 [i]Prescott[/i] 于 2008-9-2 10:56 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18382959&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
一个，FMA算两个 [/quote]
那我就知道了，谢谢 确实很多细节没有说。一个很奇怪的问题，我不知道L1的作为指令操作数0延迟怎么做到的？或者难道寄存器不是0延迟？
如果是这样的话，那么ISA究竟有几个寄存器已经不重要了。 larrabee-manycore.pdf 还有些"配套"的 slide，我在 Larrabee 专题中就都给出过连接：
[url]http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf[/url]
我的看法是，楼主目前所说的的确并没有超越 Siggraph 08 上能看到的东西。 [quote]原帖由 predaking 于 2008-9-2 14:46 发表
建议先去看看Computer Architecture 再问这种问题不迟，这个问题对于基本的Pipeline Mechanism已经外行到了一定程度……
BTW，这种扫盲的文章也叫“看了很多内部文档”，一挑一堆错，费了上千字也没对Lrb的Id ... [/quote]
说错了不要紧，我不是做硬件arch的，我做软件附带需要了解一下硬件。
基本上吧，这里装外行，还不说出了多少错漏，而又没有营养的的就是你了。
你看看你这个回贴，有哪怕一点点的信息量么？ ps: predaking阁下不知道是不是NVidia的，如果不是，不妨去砸砸场子吧:D 就在张江，离你应该不远:p 经常去砸，那边没有做Arch的，离Arch最近的只有Verification。
我就是路过玩玩 ：〉 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 14:40 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18385700&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
larrabee-manycore.pdf 还有些"配套"的 slide，我在 Larrabee 专题中就都给出过连接：
http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf
我的看法是，楼主目前所说的的确并没有超越 S ... [/quote]
但是超越了所有基于中文的介绍。 问题是， 人家intel那里有正规的介绍，到了国内，就是变成了死的pdf，没人翻译没有说法了。
因为有了对后藤的翻译，后藤的一些废话到还继续流传。
而"predaking"所说偶是废话一千字，恰恰就是intel介绍larrabee硬件的正规幻灯片的中文翻译与细节，可能有些细节有点出入，但是该点的基本都点了一下，反正intel都是这么说larrabee硬件的。
正规的材料没有人来翻译整理， 就剩下乱说乱评流毒天下。
所以只有P大清楚没几个人弄清楚那是intel介绍的larrabee硬件。
软件上的事情是另外一回事情，要分开说的话还有好几篇。
[[i] 本帖最后由 gaiban 于 2008-9-2 15:28 编辑 [/i]] 偶就是告诉你们， intel是怎么介绍larrabee的硬件的. [quote]原帖由 [i]predaking[/i] 于 2008-9-2 15:32 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18386338&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
对本人的评价很好，受教受教 ：〉 [/quote]
偶用中文给了事实。
请问你对intel关于larrabee的硬件介绍有何感想？ 你认为intel的硬件idea是什么？ 先弄清楚，偶的介绍当前是针对硬件那一部分，还没有涉及programming/或软件问题上的idea， 你别扯远了谈软件。 看你就会酸。 你说了你的idea吧。看看和intel的原意有多大的落差？ {biggrin:] 双核gesher集成4核的larrabee……我来了…… [quote]原帖由 [i]RacingPHT[/i] 于 2008-9-2 15:13 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18386123&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
说错了不要紧，我不是做硬件arch的，我做软件附带需要了解一下硬件。
基本上吧，这里装外行，还不说出了多少错漏，而又没有营养的的就是你了。
你看看你这个回贴，有哪怕一点点的信息量么？ [/quote]
他就没有信息，只有他的idea。 而且还是搞不清楚别人是说软件还是说硬件，他都分不清的。 扁人是第一要务。
吵到现在，他到底说了什么啊。 既然他认为intel对larrabee硬件简介说的不好， 那就请他说说看吧。
小结一下他的开始一些说法， 他说larrabee就是P54C的SMT版，P54C实现SMT好大的课题啊， 怎么弄得啊， 你们都不懂吧？
偶就觉得larrabee的核心应该是重新设计的，至于说它是P54C后代也就是intel的一句话而已。 谈P54C如何实现SMT并没有太大意义。 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 14:40 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18385700&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
larrabee-manycore.pdf 还有些"配套"的 slide，我在 Larrabee 专题中就都给出过连接：
[url=http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf]http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf[/url]
我的看法是，楼主目前所说的的确并没有超越 S ... [/quote]
也许确实是没有超越，但是又有几个人真正理解了呢？
ISA中非常重要的mask register以前都没有人注意到，Gather/Scatter也没有太多人提。
这千把字起码点出了几乎所有LRB体系架构中最重要的地方，其实这个VPU的设计像极了G80的SM
[[i] 本帖最后由 Prescott 于 2008-9-2 16:14 编辑 [/i]] Gather/Scatter 部分其实在大家看到 iL2-sub CACHE/L1 D-cache/Ring-Bus 的设计后都明白是怎么回事了吧。 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 16:17 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18386861&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
Gather/Scatter 部分其实在大家看到 iL2-sub CACHE/L1 D-cache/Ring-Bus 的设计后都明白是怎么回事了吧。 [/quote]
是怎么一回事啊？ [quote]原帖由 [i]Edison[/i] 于 2008-9-2 16:17 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18386861&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
Gather/Scatter 部分其实在大家看到 iL2-sub CACHE/L1 D-cache/Ring-Bus 的设计后都明白是怎么回事了吧。 [/quote]
怎么一回事啊？
愿闻其详 Larrabee 在 G/S 的时候，只能做到单周期完成同一个 cache line 的 G/S，如果从不同的 cache-line G/S，就可能需要更多的时间，例如两条不同的 cache-line，可能就是两倍的时间，最糟糕的情况应该是16倍，这样的设计显然是没有做 multi-ported。
CUDA 目前的 shared memory 是 multi-bank (8-bank），刚好对应两个 4D Vector，所以在同一个 Cycle 内的话，两个 4D Vector 是可以同时存取不同的 bank（只要没有 bank conflict 的话）。 Larrabee 就没法实现这点，除非它把 G/S 做到 cache 内，只是这样会变得很复杂。 [quote]原帖由 [i]aeondxf[/i] 于 2008-9-2 16:03 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18386705&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
{biggrin:] 双核gesher集成4核的larrabee……我来了…… [/quote]
你你你你你.....
跪下!!! [quote]原帖由 [i]Edison[/i] 于 2008-9-2 17:03 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18387408&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
Larrabee 在 G/S 的时候，只能做到单周期完成同一个 cache line 的 G/S，如果从不同的 cache-line G/S，就可能需要更多的时间，例如两条不同的 cache-line，可能就是两倍的时间，最糟糕的情况应该是16倍，这样的设计 ... [/quote]
同一个cache line的G/S？
你有没有想过一个cache line多大？一个Vector register多大？ 这个 06 年的 paper 已经说得很清楚了：cache line 是 512bit aka. 64B。 怀念从前多家图形芯片厂商竞争的年代，希望能做成三家鼎立的状态，要不然老是两家没劲 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 17:12 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18387522&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
这个 06 年的 paper 已经说得很清楚了：cache line 是 512bit aka. 64B。 [/quote]
vector register也是512bit，那存在从同一个cache line G/S的可能性吗？ 那我准确一点说好了，从同一个 cache-line 里 G/S 。 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 17:17 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18387581&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
那我准确一点说好了，从同一个 cache-line 里 G/S 。 [/quote]
那还叫G/S啊，就是一普通load嘛 难道同一条 cache-line 里 load 就一定是等于连续地址的 load ？ 寄存器大小=cache line大小，都是64Byte，你怎么从同一条cache line中load出不连续地址的64B数据来？ 游戏性能难说，用这东西跑3Dmark06 CPU分数肯定超过3万{lol:] [quote]原帖由 [i]Prescott[/i] 于 2008-9-2 17:28 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18387716&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
寄存器大小=cache line大小，都是64Byte，你怎么从同一条cache line中load出不连续地址的64B数据来？ [/quote]
Siggraph 的 paper 的确是这样说的。 我上面说的是指不同 cache-line 需要多次 access，需要的时间就是 n 倍。
G/S 可以从不同的 cache-line 抓，也可以从同一条 cache 里抓。
你来说说 register size = cache line size 和 从同一条 cache line 里能不能 G/S 不连续地址数据是有啥关系吧？ 这个延迟可以避开吗？还是必须死等？
DX10的constant buffer就有类似的问题。如果不能达到很高的load/store本地性，就必须死等，multi-thread没有办法在这种情况下切换出去。类似于bank-conflict。 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 17:43 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18387854&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
Siggraph 的 paper 的确是这样说的。 我上面说的是指不同 cache-line 需要多次 access，需要的时间就是 n 倍。
G/S 可以从不同的 cache-line 抓，也可以从同一条 cache 里抓。
你来说说 register size = ... [/quote]
很简单，如果G/S必然是从不同的cache line中取数据，那你就不要认为Intel工程师会笨到不会处理这种明显的性能问题 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 17:03 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18387408&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
Larrabee 在 G/S 的时候，只能做到单周期完成同一个 cache line 的 G/S，如果从不同的 cache-line G/S，就可能需要更多的时间，例如两条不同的 cache-line，可能就是两倍的时间，最糟糕的情况应该是16倍，这样的设计 ... [/quote]
话说游戏的时候，GPU主要应该是到显存去G/S吧？
由于tile/bin，而larrabee主要是到cache里面G/S吧？
为何说cuda呢？ 通用性能，larrabee天下无敌。 [quote]原帖由 [i]Prescott[/i] 于 2008-9-2 18:06 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18388102&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
很简单，如果G/S必然是从不同的cache line中取数据，那你就不要认为Intel工程师会笨到不会处理这种明显的性能问题 [/quote]
The speed of gather/scatter is limited by the cache, which typically only accesses one cache line per cycle.
现在的问题是程序不会完全是由 Intel 的工程师来编写的吧，而且如果软件、编译器能解决这个问题，还需要 G/S 吗？ [quote]原帖由 [i]gaiban[/i] 于 2008-9-2 18:13 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18388169&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
话说游戏的时候，GPU主要应该是到显存去G/S吧？
由于tile/bin，而larrabee主要是到cache里面G/S吧？
为何说cuda呢？ 通用性能，larrabee天下无敌。 [/quote]
谁说游戏的时候是不会动那个 "scratchpad" 的，只是图形运算的时候可能不触及，用 GPU 跑物理、AI 加速的时候不就是游戏运用上 scratchpad 的情况了吗？如果说是 deferred rendering，到了 DX11 世代我想大都会采用 compute shader 实现一些需要 data re-use 的状况，compute shader 支持 shared register。
Tile/binning 做图形运算的时候需要多少机会用到 G/S ？ 说实话，我完全不在乎图形性能，我对任何游戏都没兴趣，从扫雷到crysis。我只在乎通用计算性能。世界上我这样的人应该不止一个，也许甚至可以跟玩游戏的比一比数目呢。我不是ifan，我现在用的就是nvidia的卡跑cuda。
对于cuda，gtx260/280的双精度性能只是单精度的1/8，这很不爽。
[[i] 本帖最后由 larrabee 于 2008-9-2 18:24 编辑 [/i]] [quote]原帖由 [i]Edison[/i] 于 2008-9-2 18:18 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18388226&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
谁说游戏的时候是不会动那个 "scratchpad" 的，只是图形运算的时候可能不触及，用 GPU 跑物理、AI 加速的时候不就是游戏运用上 scratchpad 的情况了吗？如果说是 deferred rendering，到了 DX11 世代我想大都会采 ... [/quote]
你要是说，当前游戏里，驱动会自动使用scratchpad来参与渲染，还有点说服力。
要是你说的那些，那等到GPU 跑物理、AI、或compute shader的时候， 那就基本就无关了。 larrabee跑那些会很强大，另外那些还用得到G/S？ 目前跑 D3D/OGL 的时候，g8x/g9x/gt200 的 shared memory 应该根本就没启用，除非配合 CUDA ，但是这必须游戏开发人员来采用而不是驱动来做。
如果你用 compute shader 计算一些范围是 100x100 或者更大并且涉及到 data-reuse 的 filter，scratchpad + G/S 的设计就会非常有意义。 好东西，慢慢研究一下 我想这里有两种可能：
1：按照CUDA那种bank或者DX10 constant buffer那种结构设计，即shared/constant的fetch是一个atom操作，没有办法切换出去。
2：类似SPU那种设计，所有的mem fetch都是DMA式的。SPU在issue之后可以选择立即执行别的指令。
联系到LRB的texture L2 op可以用fiber切换来看，可能所有的fetch都是可以避开的（因为所有的fetch/write都可以看做是cache op，而不是显式的LS）。
如果是这种理想状况，那么LRB的scatter就只是一个bandwidth的问题了。如果ALU是bottleneck，那么g/s可以做到不影响性能。
以上乱猜。 [quote]原帖由 [i]Edison[/i] 于 2008-9-2 18:39 发表 [url=http://we.pcinlife.com/redirect.php?goto=findpost&pid=18388458&ptid=995205][img]http://we.pcinlife.com/images/common/back.gif[/img][/url]
目前跑 D3D/OGL 的时候，g8x/g9x/gt200 的 shared memory 应该根本就没启用，除非配合 CUDA ，但是这必须游戏开发人员来采用而不是驱动来做。
如果你用 compute shader 计算一些范围是 100x100 或者更大并且涉及到 ... [/quote]
若游戏没有用到的话，那GPU就是要去显存G/S了，需要好多好多个cycles了。
偶主要说物理、AI这些哪用得到G/S。 compute shader还比较远的事情。 [quote]原帖由 gaiban 于 2008-9-2 10:41 发表
往大处算strands， 32核心larrabee，4线程/核心，2-10 fiber/线程，16-64strands/fiber， larrabee是可以有上万个strands了。 从GPU角度看，32核心larrabee是一个512个高频SP/32个TMU，strands数量上万(32X4X10X64=8万多个"GPU线程")，大量向量寄存器(0级寄存器)，"一级寄存器"容量1MB，"二级寄存器"容量8MB。 [/quote]
计算的单元目前没有看到基于int8或者int16的MMX/SSE2 style的运算方式。看起来所有运算需要在fp32的精度下？
那么就不存在64strands/fiber。最多8/16。 对于图形渲染来说，数据的读取大都是非常非常规则的，使用到 G/S 的机会并不大，如果需要使用的话，NVIDIA 这里有 CUDA，AMD 过两个星期也都有支持 RV770 scratchpad 的 SDK 推出，开发人员可以根据其游戏的渲染特别决定是否使用。
我的确不知道 Compute Shader 或者说 DX11 什么时候会正式出来，但是以目前资料的发布详细度看，明年应该就能出来了吧，谁能告诉我 Larrabee 什么时候出来呢？
如果是进行特征识别的话，我想 G/S 还是可以使用上的，特征识别在 AI 上是时常使用到的。
页:
[1]
2