POPPUR爱换

标题: 拉娜芘的行为艺术larrabee [打印本页]

作者: gaiban 时间: 2008-9-1 12:44
标题: 拉娜芘的行为艺术larrabee
软件就是新硬件—超越可编程着色器

硬件简介

拉娜芘主要硬件单元：
大量x86核心，新型x86核心支持16路单指令多数据指令集。
全相联一级缓存(L1D容量32KB )与二级缓存(L2容量256KB )
硬件纹理单元，纹理采样单元支持DirextX/OpenGL所有功能，并含有32KB纹理缓存。
高速双向环形总线ringbus，支持多个二级缓存之间共享数据。

x86核心
新型x86核心支持Pentium处理器的所有指令以及64位扩展指令。
短流水线核心采用双发射顺序执行微架构，标量指令额外延迟为0，即单周期延迟。向量指令为多周期指令，而延迟较短。当出现分支预测错误，将刷新流水线，所以采用短流水线有利于减少性能开销。短流水线也有利于减少缓存遗失时的性能开销。4路同步多线程SMT，可以单周期线程切换，主要用于隐藏一级缓存遗失、向量指令延迟等。

向量处理单元
向量单元含有大量的512比特寄存器。单指令多数据流水线可以一次处理16个32比特整数/浮点数据，或8个64比特浮点数据。向量乘加法指令的吞吐率为一个周期，绝大多数向量指令的延迟远小于8个周期。向量计算指令的两个源操作数可以是寄存器，其中有一个源操作数可以直接来自缓存，而延迟开销与寄存器一样。向量指令采用16比特预测寄存器控制向量指令的16路计算结果哪些应该写回到寄存器，哪些应该被绕过。向量浮点计算完全兼容IEEE754标准。
向量计算单元可以把float16,int8,int16等数据自动转换为32比特浮点/整数数据进行计算，因此缓存可以存放更多的数据。
向量计算单元支持集/散(Gather/Scatter)计算：一条指令可以从16个不同的地址读写16个数据结果。如果与预测寄存器协作，还可以实现”数据流”处理模式:自动向量化的执行标量代码，支持循环、条件、调用、堆栈等操作，良好的契合着色器语言的计算特点，16路向量计算单元相当于16个SP(Scalar Processors)。

全相联缓存
全相联一级数据缓存容量32KB，二级缓存容量256KB，二级缓存之间可以共享数据。引入了缓存行为控制逻辑，例如，可以控制数据是否直接读写到显存还是读写到缓存；还有数据预取指令，缓存替换策略指令等。多种控制手段可以精细控制缓存行为，令其如同一块芯片内部RAM(scratchpad RAM)一样。还具有可以自动预取大批量数据的自治逻辑单元。

纹理采样单元
为全功能DX/OGL纹理采样单元，支持所有标准纹理格式，纹理缓存容量为32KB。纹理采样单元本身是一个独立的协处理器，一个x86核心配有一个纹理采样单元，x86核心一次向纹理采样单元发送4X4—16个像素的UV坐标，而纹理采样单元把16个采样过滤结果通过L2返回给x86核心，x86核心与纹理采样单元双方都是通过二级缓存来交换命令与数据。软件需要通过内嵌函数(inline-call)来调用采样命令。

DirectX软件渲染器
除了纹理采样外，都是使用软件来实现。顶点处理本质上和GPU基本一样，主要区别是像素处理。
是把一帧图像分为多个小方格(tile/bin)，小方格的大小为64X64(或128X128)，然后一个小方块单独由一个核心来负责渲染。例如分辨率为1280X960时，就被分割为20X15=300个小方块分开渲染，每个小方块大小为64X64。一个核心负责渲染一个小方块，当渲染好一个小方块后，就接着渲染下一个小方块，直到300个小方块都被渲染好为止。当核心越多时，就有越多的小方块被同时并行渲染。一个核心执行编译器产生一个程序(routine)来负责多种渲染任务，主要是读三角形、顶点、插值、读像素、前期Z变换、模板、后期Z变换、像素着色器、混合等--ReadtrianglesRead shaded verts & set up interpolantsReadfragments from binsEarly Z/stencilPerspective correction & interpolationPixelshadingLate Z/stencilRender target blend。一个程序(routine)里面含有4个线程它们是由硬件同步多线程SMT负责切换，而线程里面含有多个依靠软件切换的微纤线程(fiber)，常见情况下，一个纤程(fiber)一次可渲染4X4=16个像素。

拉娜芘的行为艺术--和CPU比3D图形性能，和GPU比通用运算性能。ifan感动的痛哭流涕。

[ 本帖最后由 gaiban 于 2008-9-1 19:59 编辑 ]

作者: duron111 时间: 2008-9-1 12:52
帮你顶了。。。。。。。。。。。。。。

作者: zyr488 时间: 2008-9-1 14:22
提示: 作者被禁止或删除内容自动屏蔽

作者: Prescott 时间: 2008-9-1 17:28
有史以来最为详尽的公开描述。
涉及细节无数，GPU Fans要仔细看了哦

最后一句话应该改成：可以和CPU比通用性，和GPU比图形性能

[ 本帖最后由 Prescott 于 2008-9-1 17:30 编辑 ]

作者: 54wo 时间: 2008-9-1 17:35
”向量计算单元可以把float16,int8,int16等数据自动转换为32比特浮点数据进行计算，因此缓存可以存放更多的数据。“
这里应该错了， float16转换为float32，而int8，int16转换为int32

作者: shu0202 时间: 2008-9-1 17:46
看上去挺美好，晴空万里，祥云缭绕。

作者: gaiban 时间: 2008-9-1 19:58

原帖由 Prescott 于 2008-9-1 17:28 发表
有史以来最为详尽的公开描述。
涉及细节无数，GPU Fans要仔细看了哦

最后一句话应该改成：可以和CPU比通用性，和GPU比图形性能

一般人是很难看懂的，披露的细节程度确实超越了至今为止全部中文介绍larrabee的总和。
以前后藤乱说了很多的废话，被翻译了一下，照样呆在“体系架构”分类里。
正规的介绍来了，倒被E大强行移到“一般”了。

作者: Prescott 时间: 2008-9-2 01:55

原帖由 gaiban 于 2008-9-1 19:58 发表

一般人是很难看懂的，披露的细节程度确实超越了至今为止全部中文介绍larrabee的总和。
以前后藤乱说了很多的废话，被翻译了一下，照样呆在“体系架构”分类里。
正规的介绍来了，倒被E大强行移到“一般 ...

{lol:]
可惜啊，可惜，真料来了，却没人看得懂。
我来总结一下吧，反正这里的人只关心性能：
从Larrabee的设计来看，单论shader性能，理论上32核心@2GHz的Larrabee相当于512 SP@2Ghz的G80。

这个值与Intel论文中模拟出来性能很一致，说明这个设计是达到了预期目标的。

[ 本帖最后由 Prescott 于 2008-9-2 02:07 编辑 ]

作者: Prescott 时间: 2008-9-2 02:01

原帖由 predaking 于 2008-9-1 23:57 发表
错误比较多，而且没有切中要点呵呵

比如 P54C对于4way SMT怎么支持，Branch的机制对Inst Stream的影响，Stand和Fiber以及Thread之间的关系，Bin和Pixel以及Fragment的关系，Input Assambler和LBR Shader的关系， ...

其实这些东西都是清楚的不能再清楚的东西，你搞不懂，只能说你对CPU体系架构还有太多东西要补，你已经彻底被NV洗了脑，已经没有办法跳出传统GPU的设计来理解一个真正的图形处理器应有的样子了。

作者: 茉莉花GT 时间: 2008-9-2 02:15
{blush:] 意见保留,或许成为史上最暴力的PPU也说不定

作者: aeondxf 时间: 2008-9-2 02:24
{biggrin:] 言外之意4核的larrabee可以比得上9600GT超频版？

作者: shu0202 时间: 2008-9-2 08:49
看笑话，看笑话。

作者: hundrix 时间: 2008-9-2 09:11
l like it. 希望早日买到{victory:]

作者: Asuka 时间: 2008-9-2 09:18
larrabee不需要H-Z，也不需要compression {mellow:]

作者: garou 时间: 2008-9-2 09:33
看来有了这显卡，就不用CPU了？

作者: gaiban 时间: 2008-9-2 10:00
P大是说单论shader如何如何，larrabee还要干其他活。
可能那是larrabee的向量单元奋斗目标，结果还要看。

作者: itany 时间: 2008-9-2 10:01

原帖由 Prescott 于 2008-9-2 01:55 发表

{lol:]
可惜啊，可惜，真料来了，却没人看得懂。
我来总结一下吧，反正这里的人只关心性能：
从Larrabee的设计来看，单论shader性能，理论上32核心@2GHz的Larrabee相当于512 SP@2Ghz的G80。

这个值与Intel论 ...

请问Prescott大，Larrabee每个核心每周期到底是发射1个512bit AVX还是发射两个啊？
如果是一个，貌似达不到单精度2Tflops

[ 本帖最后由 itany 于 2008-9-2 10:05 编辑 ]

作者: RacingPHT 时间: 2008-9-2 10:02
提示: 作者被禁止或删除内容自动屏蔽

作者: itany 时间: 2008-9-2 10:04

原帖由 我奏是马甲 于 2008-9-2 02:46 发表
这样换算的话就是：16核心的P54C等于256SP 2GHZ，灭掉GTX280，然后因为GTX280勇超扣肉QX9770 NN倍，所以16核心的P54C足够把QX9770轰渣……

又或者两年之后NV在出GF CTU380..成为世界上最强大地CPU。。。intel就出 ...

您这已经乱了
AMD的64个5D单元就相当于320个SP，为什么Intel的“16D”单元不能相当于512个SP呢？

作者: Edison 时间: 2008-9-2 10:04
似乎只有 "向量指令采用16比特预测寄存器控制向量指令的16路计算结果哪些应该写回到寄存器" 这句话是 larrabee-manycore.pdf 里没留意到的。

作者: RacingPHT 时间: 2008-9-2 10:12
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-9-2 10:13
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-9-2 10:15
那就其实是这段内容了：

"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."

作者: predaking 时间: 2008-9-2 10:16

原帖由 RacingPHT 于 2008-9-2 10:12 发表
预测寄存器其实很普通，可能他翻译的不大好，英文就是predicated register。我认为应该翻译为断言寄存器？

哥们，这可是CSarch的基本功……，是条件寄存器。

作者: RacingPHT 时间: 2008-9-2 10:23
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-9-2 10:41

原帖由 predaking 于 2008-9-2 09:57 发表

是么，呵呵：〉

记得N年前，我的小组还在的时候我主持过Inorder MPU和4-way Superscalar OOO MPU的Design，也相当长的时间研究过SMT OOO MPU，主要是以DEC Alpha 21464的思想为原型，呵呵。这都是我们之前 ...

  是硬件简介--以介绍几个关键硬件为主，软件仅仅是简单的形象的说一下而已，把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处理器--或许能降低误解出现的概率。

作者: RacingPHT 时间: 2008-9-2 10:49
提示: 作者被禁止或删除内容自动屏蔽

作者: daniel_k 时间: 2008-9-2 10:51
想请问一下：这个拉拉比是不是在intel发布的业界首款DX10显卡（G965）的基础上研发出来的呢？

作者: Prescott 时间: 2008-9-2 10:56

原帖由 itany 于 2008-9-2 10:01 发表

请问Prescott大，Larrabee每个核心每周期到底是发射1个512bit AVX还是发射两个啊？
如果是一个，貌似达不到单精度2Tflops

一个，FMA算两个

作者: RacingPHT 时间: 2008-9-2 10:58
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-9-2 11:07

原帖由 predaking 于 2008-9-2 10:45 发表

别的就不评价了就评价一点，LRB L2$相当于GPU fifo，不是RF。

你可以看成是可以OOO的fifo，其实也是RF。从向量指令的角度看，L1是RF,L2自然也可以是RF了，就是延迟有区别。

作者: gaiban 时间: 2008-9-2 11:15
其实可以是有register cache概念来看问题，有些限制罢了。

作者: gaiban 时间: 2008-9-2 11:20

原帖由 predaking 于 2008-9-2 11:15 发表

着结论厉害……应该ISCA上面给哥们20分钟发言

三流处理器国家的research，天天鄙视一流处理器国家的产品，概念是天天变化，没有变化的是长期落后。
既然人家intel提出来那些看法，那些角度来思考，自然是有它内在原因。缓存是全相联的哦。

作者: Prescott 时间: 2008-9-2 11:21
某位仁兄也实在是太自大了。
何止是三流，根本就是不入流。
这个架构放在这里，已经是现有成熟技术的集大成者，可以说颠覆传统GPU的设计，这一步已经跨的足够大，业界已经是一片哗然。

做产品不是做research，把一大堆概念性质的东西往上堆，最终只能造成产品失败。G80连CC都没有，在这里就要求LRB有transactional CC，否则就是落后，这不是扯淡吗？

[ 本帖最后由 Prescott 于 2008-9-2 11:28 编辑 ]

作者: RacingPHT 时间: 2008-9-2 11:30
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-9-2 11:38
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-9-2 11:46

原帖由 predaking 于 2008-9-2 11:41 发表
恩，非技术论坛果然不一样

受教受教：〉

有话好好说，何必冲头冲脑呢？
被河_蟹了吧

作者: RacingPHT 时间: 2008-9-2 11:51
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-9-2 12:37

原帖由 Edison 于 2008-9-2 10:04 发表
似乎只有 "向量指令采用16比特预测寄存器控制向量指令的16路计算结果哪些应该写回到寄存器" 这句话是 larrabee-manycore.pdf 里没留意到的。

  说明你没有好好看，而P大看的比较仔细。  有很多细节是 larrabee-manycore.pdf 里没有的，或者是没有直接说的。或者是没有被你们好好当成一回事来讨论的。
能看懂的人很少。

另外来的“predaking”哪是来讨论larrabee的？什么新的细节都没有提供，就来表个态偶是高手，nv与intel的设计都很差。

  应该说，讨论的是目的是利用larrabee的更多硬件规格细节的披露，来和nv/ati的产品比较优劣得失，设计理念上的差异，有可能的坑在哪里，等等。。。。。。

作者: Prescott 时间: 2008-9-2 14:00

原帖由 gaiban 于 2008-9-2 12:37 发表

说明你没有好好看，而P大看的比较仔细。有很多细节是 larrabee-manycore.pdf 里没有的，或者是没有直接说的。或者是没有被你们好好当成一回事来讨论的。
能看懂的人很少。

另外来的“predaking” ...

这个不是我看得仔细，而是我原先就都知道。:a)
写这个的人一定看了相当详细的内部资料。

作者: itany 时间: 2008-9-2 14:04

原帖由 Prescott 于 2008-9-2 10:56 发表

一个，FMA算两个

那我就知道了，谢谢

作者: RacingPHT 时间: 2008-9-2 14:36
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-9-2 14:40
larrabee-manycore.pdf 还有些"配套"的 slide，我在 Larrabee 专题中就都给出过连接：

http://s08.idav.ucdavis.edu/fors ... cs-architecture.pdf

我的看法是，楼主目前所说的的确并没有超越 Siggraph 08 上能看到的东西。

作者: RacingPHT 时间: 2008-9-2 15:13
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2008-9-2 15:16
提示: 作者被禁止或删除内容自动屏蔽

作者: predaking 时间: 2008-9-2 15:25
经常去砸，那边没有做Arch的，离Arch最近的只有Verification。

我就是路过玩玩：〉

作者: gaiban 时间: 2008-9-2 15:27

原帖由 Edison 于 2008-9-2 14:40 发表
larrabee-manycore.pdf 还有些"配套"的 slide，我在 Larrabee 专题中就都给出过连接：

http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf

我的看法是，楼主目前所说的的确并没有超越 S ...

但是超越了所有基于中文的介绍。  问题是，人家intel那里有正规的介绍，到了国内，就是变成了死的pdf，没人翻译没有说法了。

因为有了对后藤的翻译，后藤的一些废话到还继续流传。

而"predaking"所说偶是废话一千字，恰恰就是intel介绍larrabee硬件的正规幻灯片的中文翻译与细节，可能有些细节有点出入，但是该点的基本都点了一下，反正intel都是这么说larrabee硬件的。

  正规的材料没有人来翻译整理，就剩下乱说乱评流毒天下。

所以只有P大清楚没几个人弄清楚那是intel介绍的larrabee硬件。
  软件上的事情是另外一回事情，要分开说的话还有好几篇。

[ 本帖最后由 gaiban 于 2008-9-2 15:28 编辑 ]

作者: gaiban 时间: 2008-9-2 15:35
偶就是告诉你们， intel是怎么介绍larrabee的硬件的.

作者: gaiban 时间: 2008-9-2 15:52

原帖由 predaking 于 2008-9-2 15:32 发表
对本人的评价很好，受教受教：〉

偶用中文给了事实。
请问你对intel关于larrabee的硬件介绍有何感想？你认为intel的硬件idea是什么？先弄清楚，偶的介绍当前是针对硬件那一部分，还没有涉及programming/或软件问题上的idea，你别扯远了谈软件。看你就会酸。你说了你的idea吧。看看和intel的原意有多大的落差？

作者: aeondxf 时间: 2008-9-2 16:03
{biggrin:] 双核gesher集成4核的larrabee……我来了……

作者: gaiban 时间: 2008-9-2 16:07

原帖由 RacingPHT 于 2008-9-2 15:13 发表

说错了不要紧，我不是做硬件arch的，我做软件附带需要了解一下硬件。
基本上吧，这里装外行，还不说出了多少错漏，而又没有营养的的就是你了。
你看看你这个回贴，有哪怕一点点的信息量么？

他就没有信息，只有他的idea。  而且还是搞不清楚别人是说软件还是说硬件，他都分不清的。扁人是第一要务。
吵到现在，他到底说了什么啊。  既然他认为intel对larrabee硬件简介说的不好，那就请他说说看吧。

  小结一下他的开始一些说法，他说larrabee就是P54C的SMT版，P54C实现SMT好大的课题啊，怎么弄得啊，你们都不懂吧？
偶就觉得larrabee的核心应该是重新设计的，至于说它是P54C后代也就是intel的一句话而已。谈P54C如何实现SMT并没有太大意义。

作者: Prescott 时间: 2008-9-2 16:10

原帖由 Edison 于 2008-9-2 14:40 发表
larrabee-manycore.pdf 还有些"配套"的 slide，我在 Larrabee 专题中就都给出过连接：

http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf

我的看法是，楼主目前所说的的确并没有超越 S ...

也许确实是没有超越，但是又有几个人真正理解了呢？
ISA中非常重要的mask register以前都没有人注意到，Gather/Scatter也没有太多人提。
这千把字起码点出了几乎所有LRB体系架构中最重要的地方，其实这个VPU的设计像极了G80的SM

[ 本帖最后由 Prescott 于 2008-9-2 16:14 编辑 ]

作者: Edison 时间: 2008-9-2 16:17
Gather/Scatter 部分其实在大家看到 iL2-sub CACHE/L1 D-cache/Ring-Bus 的设计后都明白是怎么回事了吧。

作者: gaiban 时间: 2008-9-2 16:19

原帖由 Edison 于 2008-9-2 16:17 发表
Gather/Scatter 部分其实在大家看到 iL2-sub CACHE/L1 D-cache/Ring-Bus 的设计后都明白是怎么回事了吧。

是怎么一回事啊？

作者: Prescott 时间: 2008-9-2 16:28

原帖由 Edison 于 2008-9-2 16:17 发表
Gather/Scatter 部分其实在大家看到 iL2-sub CACHE/L1 D-cache/Ring-Bus 的设计后都明白是怎么回事了吧。

怎么一回事啊？
愿闻其详

作者: Edison 时间: 2008-9-2 17:03
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 内，只是这样会变得很复杂。

作者: lwmq 时间: 2008-9-2 17:09

原帖由 aeondxf 于 2008-9-2 16:03 发表
{biggrin:] 双核gesher集成4核的larrabee……我来了……

你你你你你.....
跪下!!!

作者: Prescott 时间: 2008-9-2 17:10

原帖由 Edison 于 2008-9-2 17:03 发表
Larrabee 在 G/S 的时候，只能做到单周期完成同一个 cache line 的 G/S，如果从不同的 cache-line G/S，就可能需要更多的时间，例如两条不同的 cache-line，可能就是两倍的时间，最糟糕的情况应该是16倍，这样的设计 ...

同一个cache line的G/S？
你有没有想过一个cache line多大？一个Vector register多大？

作者: Edison 时间: 2008-9-2 17:12
这个 06 年的 paper 已经说得很清楚了：cache line 是 512bit aka. 64B。

作者: 6119W 时间: 2008-9-2 17:13
怀念从前多家图形芯片厂商竞争的年代，希望能做成三家鼎立的状态，要不然老是两家没劲

作者: Prescott 时间: 2008-9-2 17:13

原帖由 Edison 于 2008-9-2 17:12 发表
这个 06 年的 paper 已经说得很清楚了：cache line 是 512bit aka. 64B。

vector register也是512bit，那存在从同一个cache line G/S的可能性吗？

作者: Edison 时间: 2008-9-2 17:17
那我准确一点说好了，从同一个 cache-line 里 G/S 。

作者: Prescott 时间: 2008-9-2 17:19

原帖由 Edison 于 2008-9-2 17:17 发表
那我准确一点说好了，从同一个 cache-line 里 G/S 。

那还叫G/S啊，就是一普通load嘛

作者: Edison 时间: 2008-9-2 17:24
难道同一条 cache-line 里 load 就一定是等于连续地址的 load ？

作者: Prescott 时间: 2008-9-2 17:28
寄存器大小=cache line大小，都是64Byte，你怎么从同一条cache line中load出不连续地址的64B数据来？

作者: zhangyi1984911 时间: 2008-9-2 17:37
游戏性能难说，用这东西跑3Dmark06 CPU分数肯定超过3万{lol:]

作者: Edison 时间: 2008-9-2 17:43

原帖由 Prescott 于 2008-9-2 17:28 发表
寄存器大小=cache line大小，都是64Byte，你怎么从同一条cache line中load出不连续地址的64B数据来？

Siggraph 的 paper 的确是这样说的。我上面说的是指不同 cache-line 需要多次 access，需要的时间就是 n 倍。

G/S 可以从不同的 cache-line 抓，也可以从同一条 cache 里抓。

你来说说 register size = cache line size 和从同一条 cache line 里能不能 G/S 不连续地址数据是有啥关系吧？

作者: RacingPHT 时间: 2008-9-2 17:50
提示: 作者被禁止或删除内容自动屏蔽

作者: Prescott 时间: 2008-9-2 18:06

原帖由 Edison 于 2008-9-2 17:43 发表

Siggraph 的 paper 的确是这样说的。我上面说的是指不同 cache-line 需要多次 access，需要的时间就是 n 倍。

G/S 可以从不同的 cache-line 抓，也可以从同一条 cache 里抓。

你来说说 register size = ...

很简单，如果G/S必然是从不同的cache line中取数据，那你就不要认为Intel工程师会笨到不会处理这种明显的性能问题

作者: gaiban 时间: 2008-9-2 18:13

原帖由 Edison 于 2008-9-2 17:03 发表
Larrabee 在 G/S 的时候，只能做到单周期完成同一个 cache line 的 G/S，如果从不同的 cache-line G/S，就可能需要更多的时间，例如两条不同的 cache-line，可能就是两倍的时间，最糟糕的情况应该是16倍，这样的设计 ...

话说游戏的时候，GPU主要应该是到显存去G/S吧？
由于tile/bin，而larrabee主要是到cache里面G/S吧？

为何说cuda呢？通用性能，larrabee天下无敌。

作者: Edison 时间: 2008-9-2 18:13

原帖由 Prescott 于 2008-9-2 18:06 发表
很简单，如果G/S必然是从不同的cache line中取数据，那你就不要认为Intel工程师会笨到不会处理这种明显的性能问题

The speed of gather/scatter is limited by the cache, which typically only accesses one cache line per cycle.

现在的问题是程序不会完全是由 Intel 的工程师来编写的吧，而且如果软件、编译器能解决这个问题，还需要 G/S 吗？

作者: Edison 时间: 2008-9-2 18:18

原帖由 gaiban 于 2008-9-2 18:13 发表
话说游戏的时候，GPU主要应该是到显存去G/S吧？
由于tile/bin，而larrabee主要是到cache里面G/S吧？
为何说cuda呢？通用性能，larrabee天下无敌。

谁说游戏的时候是不会动那个 "scratchpad" 的，只是图形运算的时候可能不触及，用 GPU 跑物理、AI 加速的时候不就是游戏运用上 scratchpad 的情况了吗？如果说是 deferred rendering，到了 DX11 世代我想大都会采用 compute shader 实现一些需要 data re-use 的状况，compute shader 支持 shared register。

Tile/binning 做图形运算的时候需要多少机会用到 G/S ？

作者: larrabee 时间: 2008-9-2 18:21
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-9-2 18:32

原帖由 Edison 于 2008-9-2 18:18 发表

谁说游戏的时候是不会动那个 "scratchpad" 的，只是图形运算的时候可能不触及，用 GPU 跑物理、AI 加速的时候不就是游戏运用上 scratchpad 的情况了吗？如果说是 deferred rendering，到了 DX11 世代我想大都会采 ...

你要是说，当前游戏里，驱动会自动使用scratchpad来参与渲染，还有点说服力。

要是你说的那些，那等到GPU 跑物理、AI、或compute shader的时候，那就基本就无关了。 larrabee跑那些会很强大，另外那些还用得到G/S？

作者: Edison 时间: 2008-9-2 18:39
目前跑 D3D/OGL 的时候，g8x/g9x/gt200 的 shared memory 应该根本就没启用，除非配合 CUDA ，但是这必须游戏开发人员来采用而不是驱动来做。

如果你用 compute shader 计算一些范围是 100x100 或者更大并且涉及到 data-reuse 的 filter，scratchpad + G/S 的设计就会非常有意义。

作者: insect2006 时间: 2008-9-2 19:03
好东西，慢慢研究一下

作者: RacingPHT 时间: 2008-9-2 19:15
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-9-2 19:46

原帖由 Edison 于 2008-9-2 18:39 发表
目前跑 D3D/OGL 的时候，g8x/g9x/gt200 的 shared memory 应该根本就没启用，除非配合 CUDA ，但是这必须游戏开发人员来采用而不是驱动来做。

如果你用 compute shader 计算一些范围是 100x100 或者更大并且涉及到 ...

若游戏没有用到的话，那GPU就是要去显存G/S了，需要好多好多个cycles了。

偶主要说物理、AI这些哪用得到G/S。 compute shader还比较远的事情。

作者: RacingPHT 时间: 2008-9-2 20:42
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2008-9-2 21:06
对于图形渲染来说，数据的读取大都是非常非常规则的，使用到 G/S 的机会并不大，如果需要使用的话，NVIDIA 这里有 CUDA，AMD 过两个星期也都有支持 RV770 scratchpad 的 SDK 推出，开发人员可以根据其游戏的渲染特别决定是否使用。

我的确不知道 Compute Shader 或者说 DX11 什么时候会正式出来，但是以目前资料的发布详细度看，明年应该就能出来了吧，谁能告诉我 Larrabee 什么时候出来呢？

如果是进行特征识别的话，我想 G/S 还是可以使用上的，特征识别在 AI 上是时常使用到的。

作者: gaiban 时间: 2008-9-2 21:10

原帖由 RacingPHT 于 2008-9-2 20:42 发表

计算的单元目前没有看到基于int8或者int16的MMX/SSE2 style的运算方式。看起来所有运算需要在fp32的精度下？
那么就不存在64strands/fiber。最多8/16。

应该存在64吧，16-64strands/fiber是intel的幻灯片里面写的。就都给它往大处算，才算到8万的。
可能是strands16/fiber比较常见吧？那就是2万多个strands。
所以偶一开始是说strands可以上万而已

[ 本帖最后由 gaiban 于 2008-9-2 21:17 编辑 ]

作者: gaiban 时间: 2008-9-2 21:16

原帖由 Edison 于 2008-9-2 21:06 发表
对于图形渲染来说，数据的读取大都是非常非常规则的，使用到 G/S 的机会并不大，如果需要使用的话，NVIDIA 这里有 CUDA，AMD 过两个星期也都有支持 RV770 scratchpad 的 SDK 推出，开发人员可以根据其游戏的渲染特别 ...

那么RV770 支持G/S吧？
  还有让GPU算AI，是遥远了一点，对于larrabee可能比较容易吧。
  偶觉得是谈现在与将来两年的游戏，绝大多数而言，那些还是遥远了一点。

  所以你说的很难有说服力--对于现在与将来两年的游戏而言。  GPU的G/S是要到显存去的，很多cycles了。

话说回来总的看来，compute shader可能更有利于larrabee。物理啊AI啊，也是。

作者: Edison 时间: 2008-9-2 21:30
RV770 从一开始就说是支持 scatter 的。

让 GPU 跑 AI 本来就不是什么不可想象的事情，例如在橄榄球类的运动游戏中，我们可以为 "运动员" 的眼睛设计两个视锥以及一个简单的模型（类似物理运算用到的非常简单的box）来做运动轨迹判断，这个视锥扫描哪个对手在扑向它以及附近有没有队员、可以移动的路径等，都是可以用 GPU 来高速处理的，甚至直接可以把视锥作为一个物理运算时候的 box，这样跑物理的时候也顺带作了 AI 。

你说现在和未来两年的游戏 GPU G/S 要到 local memory 里这个说法是没错，实际上这个观点这里没有人反对，但是我们这里必须指出你这样的说法实际上存在明显的问题，那就是对于图形渲染来说，目前的游戏极少机会去做一些不连续地址的存取动作，因此你说的 GPU 要 G/S 到显存中的说法对于大多数的图形渲染来说发生的机会是非常少的，而需要 G/S 的话，AMD/NVIDIA 都有相应的方案来实现片上执行。

有人认为 GPU 跑现在和未来两年的游戏需要整天 G/S 吗？

作者: gaiban 时间: 2008-9-2 21:36

原帖由 Edison 于 2008-9-2 21:30 发表
RV770 从一开始就说是支持 scatter 的。

让 GPU 跑 AI 本来就不是什么不可想象的事情，例如在橄榄球类的运动游戏中，我们可以为 "运动员" 的眼睛设计两个视锥以及一个简单的模型（类似物理运算用到的非常简单的bo ...

那支持Gather吧？

可以想象跑AI，问题主要是有多少游戏吧？其实应该没有必要争论吧，朝鲜还能制造核弹呢，但是能毁灭美国吧？不是有没有的问题，而是有多少游戏的问题，关键是百分比有多大的问题。其实如果说物理AI这些，总体优势在larrabee这边会更大点。

作者: Edison 时间: 2008-9-2 21:41
支持 scatter 当然支持 gather 了，gather 是 CTM 时代就有的了。

采用 GPGPU 实现一些图形运算的应用现在才只是刚刚起步，但是这个趋势大家都是非常看好的，你对这个趋势唱反调是没用的。

作者: gaiban 时间: 2008-9-2 21:48
关于G/S的讨论有了结果，游戏角度看，对于GPU而言可能需要很多cycles,而对于larrabee而言可能需要一些cycles。

向量单元--16个SP
上万strands--GPU线程
cache--GPU寄存器

  三项对抗的结果，intel应该是希望完成三大奋斗目标：
  向量单元的效率可以接近16个SP--可以讨论一下谁高谁低，能差多少。
  而HW thread/fiber/strands能否达到GPU线程的效率--也可以讨论一下larrabee掩藏延迟的能力是否充分。
  而新型向量指令/cache能否达到GPU寄存器的效率--还是可以讨论一下。
  哪里是坑，可能要掉去下去了。

作者: gaiban 时间: 2008-9-2 21:55

原帖由 Edison 于 2008-9-2 21:41 发表
支持 scatter 当然支持 gather 了，gather 是 CTM 时代就有的了。

采用 GPGPU 实现一些图形运算的应用现在才只是刚刚起步，但是这个趋势大家都是非常看好的，你对这个趋势唱反调是没用的。

好了，一切看现实比较好。等有了多数游戏用GPU搞物理搞AI的时候，所有人都会同意你的。现实是还比较遥远。
而compute shader，偶觉得总体说来还是对larrabee有利一些 -- 该话题就超越了G/S的讨论了。

作者: Eji 时间: 2008-9-2 22:58

原帖由 Prescott 于 2008-9-2 01:55 发表

{lol:]
可惜啊，可惜，真料来了，却没人看得懂。
我来总结一下吧，反正这里的人只关心性能：
从Larrabee的设计来看，单论shader性能，理论上32核心@2GHz的Larrabee相当于512 SP@2Ghz的G80。

別無視ROP的存在啊。 :p

作者: larrabee 时间: 2008-9-3 00:57
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-9-3 10:43

原帖由 larrabee 于 2008-9-3 00:57 发表
按precott的说法，gtx 的240个sp假设频率为1.3Ghz ，相当于larrabee的9.75个频率为2G的核心。

P大说的是shader性能。
Eji大大说了还有ROP。

若shader开销占总开销的80%，那就是说11-12个larrabee。
若shader开销占总开销的70%，那就是说13-14个larrabee。
若shader开销占总开销的50-60%，那就是说15到16个larrabee。

作者: Jason21 时间: 2008-9-3 10:46
到底什么时候上市，刚看新闻又说是2010，之前的报道是明年中，糊涂了。。。:wacko:

作者: gaiban 时间: 2008-9-3 11:01

原帖由 Jason21 于 2008-9-3 10:46 发表
到底什么时候上市，刚看新闻又说是2010，之前的报道是明年中，糊涂了。。。:wacko:

既然是行为艺术，有可能华丽掉到哪个坑里了，也有可能悄无声息的突然出现--晕啊

作者: 不喝孟婆汤 时间: 2008-9-3 11:09
太难了~~~ 看不懂啊~~！！ {cry:]

作者: shu0202 时间: 2008-9-3 11:21
以每核心16sp去和标量单元每TPC16sp等同对待根本就是脑袋被门夹了，这和用320 vs 128的数字比值判断性能高低是一路货色。现在的游戏连R600的5D向量单元都不能高效利用，怎么能充分配合larrabee的16D向量单元？

作者: RacingPHT 时间: 2008-9-3 11:35
提示: 作者被禁止或删除内容自动屏蔽

作者: gaiban 时间: 2008-9-3 11:39

原帖由 shu0202 于 2008-9-3 11:21 发表
以每核心16sp去和标量单元每TPC16sp等同对待根本就是脑袋被门夹了，这和用320 vs 128的数字比值判断性能高低是一路货色。现在的游戏连R600的5D向量单元都不能高效利用，怎么能充分配合larrabee的16D向量单元？

第一项论战开始了：16路向量单元与 SP的效率之争
向量单元 VS 16个SP
shu0202首先质疑：现在的游戏连R600的5D向量单元都不能高效利用，怎么能充分配合larrabee的向量单元？而如何可能赶上nv的8路SP的效率？
P大需要接招了。

作者: gaiban 时间: 2008-9-3 11:40
RacingPHT回应：组织方式和G80类似，即SIMD的每个unit对应不同的像素。对于像素来说，这个SIMD就是标量单元。

作者: gaiban 时间: 2008-9-3 11:43
偶听说，一个像素的RGB需要在同一个lane/strands里分成三次来计算。晕啊？？

作者: Prescott 时间: 2008-9-3 13:52

原帖由 gaiban 于 2008-9-3 11:39 发表

第一项论战开始了：16路向量单元与 SP的效率之争
向量单元 VS 16个SP
shu0202首先质疑：现在的游戏连R600的5D向量单元都不能高效利用，怎么能充分配合larrabee的向量单元？而如何可能赶上nv的8路SP的效率 ...

SIMD和G80的SM有两个最大的区别
1. SIMD操作的地址必须连续，G80的SM中不同的SP虽然执行的是相同的代码，但是可以从不同的地址中加载数据。
2. SIMD对一个向量中的不同元素所作的操作必须一样，不能对不同的标量执行不同的操作，比如对1356做A操作，而0247做B操作。这个在G80中是用分支实现的，先做1356的A，然后做0247的B。

这两个问题，前者通过G/S解决，后者通过Mask register解决了。这种情况下，如果一段代码可以在G80的16个SP组成的SM上获得不错的效率，那经过非常简单的变换，在LRB的VPU上也可以获得类似的效率。虽然LRB的VPU看起来和G80的SM完全不一样，但是本质上都是一样一样一样的啊。

所以，我原先说过，G80和LRB形不似而神似

对于我来说，不是很熟悉3D渲染的程序特性，只能拿G80这种已经被证明为有效的模式来做对比。至于Intel为什么这样实现，有可能是和NV英雄所见略同，也有可能像我一样的想法吧{lol:]

[ 本帖最后由 Prescott 于 2008-9-3 13:59 编辑 ]

作者: gaiban 时间: 2008-9-3 15:45

原帖由 Prescott 于 2008-9-3 13:52 发表

至于Intel为什么这样实现，有可能是和NV英雄所见略同，也有可能像我一样的想法吧{lol:]

P大，要是如此的话，larrabee的底层计算硬件实际上和nv的SP颇为神似，larrabee的VPU就是按照GPU的需要来设计的？

欢迎光临 POPPUR爱换 (https://we.poppur.com/)