POPPUR爱换

标题: 英特尔 Larrabee 体系架构讨论主题 [打印本页]

作者: Edison 时间: 2007-10-5 14:28
标题: 英特尔 Larrabee 体系架构讨论主题
本主题是专门为讨论Larrabee开设的，因此要求相关的讨论以技术为主。

Larrabee目前确定的信息：

1、Intel的Doug Carmean为Larrabee的首席架构师

2、目前唯一发布过Larrabee细节场合是在斯坦福大学的CS448教程上，由Doug Carmean主讲的"Intel Larrabee"，但是相关的演讲文件因为NDA的缘故并没有公开下载；

3、目前有两份和Larrabee相关的幻灯片文件，一份是TerPro-Aject首席架构师Ed Davis的"Tera Tera Tera"，另一份为惠普高性能计算部Richard Kaufmann的"HP & PetaFLOPS"；

4、按照"Tera Tera Tera"的介绍，Larrabee的架构将如下的：

频率：                                           1.7GHz~2.5GHz
内核数：                                        16~24内核 in-order x86 ISA，4线程/内核
每核单周期双精度运算能力：                      Non-SSE：2
                                                w/SSE：8-16
每核单周期整数运算：                            ???
每内核cache容量, 时延：                         L1 32KB, 1 clock
                                                L2 256KB, 10 clock
                                                L3 没有
                                                64-byte cache-line
内核互联总线：                                  256byte/cycle Ring环路
Ring环路时延：                                  ???
内存：                                           1~2GB 128GB/s GDDR/FastDRAM
设备总线带宽：                                  QPI, 17GB/s/link, 时延50ns
峰值：                                           14~40 GF/core, 0.2-1.0TF/processor

5、按照HP & PetaFLOPS的介绍，内核的细节基本上和"Tera Tera Tera"类似，但是在内核数量和内存带宽上有不少的提升：

频率：                                           4GHz
内核数：                                           32内核 in-order x86 ISA, 4线程/内核
每核单周期双精度运算能力：                         Non-SSE：2
                                                   w/SSE：8-16
每核单周期整数运算：                               ???
每内核cache容量,  时延：                         L1 32KB, 1 clock
                                                L2 256KB, 10 clock
                                                L3 没有
                                                64-byte cache-line
内核互联总线：                                     256byte/cycle Ring环路
Ring环路时延：                                     ???
内存：                                           1~2GB 192GB/s GDDR/FastDRAM
设备总线带宽：                                     QPI, 17GB/s/link, 时延50ns
峰值：                                           ~2TF/processor

5、将会在2008年提供演示，可能推出的时间在2009年或者2010年；

6、针对的市场主要是高端图形以及高性能计算机（HPC），适用于Jpeg纹理、物理加速、抗锯齿、AI强化、光线追踪等；

7、非游戏图形开发方面有可能采用Intel称之为Ct的API。[更新，现在基本确定Larrabee的SDK暂名为"Native SDK"]

~~~~~~
大家可以就以下话题展开讨论：
1、x86 ISA采用in-order流水线是否由于先天性的缺陷而导致性能受到严重抑制
2、Larrabee和Cell、G8X、R600在架构上的特点、差异以及由此可能引出的应用、性能差别
3、你对Larrabee的前景有何看法
4、你希望Larrabee能在哪些方面作适度的改进

~~~~~~
参与讨论的时候请注意：
1、请不要把其他网站的新闻照抄过来，如果你需要大家关注其内容，只需要把链接和部分关键的段落提供，照搬的内容我们会予以删除。
2、与上面或者其他网友提供的信息重复或者重叠的内容请不要再引用。
3、请注意网络礼节。

更新：
2008年6月3日，Siggraph 2008出现了名为"Larrabee: A Many-Core x86 Architecture for Visual Computing"的专题讲座，出席的人员包括了：
Larry Seiler, Doug Carmean, Eric Sprangle, Tom Forsyth (Intel Corporation), Michael Abrash (RAD Game Tools), Pradeep Dubey, Stephen Junkins, Adam Lake, Jeremy Sugerman, Robert Cavin, Roger Espasa, Ed Grochowski, Toni Juan (Intel Corporation), Pat Hanrahan (Stanford University)

内容概述：
This paper introduces the Larrabee many-core visual computing architecture (a new software rendering pipeline implementation), a many-core programming model, and performance analysis for several applications. Larrabee uses multiple in-order x86 CPU cores that are augmented by a wide vector processor unit, as well as fixed-function co-processors. This provides dramatically higher performance per watt and per unit of area than out-of-order CPUs on highly parallel workloads and greatly increases the flexibility and programmability of the architecture as compared to standard GPUs.

会议召开时间为 8 月 12 日。

文件释出：
http://softwarecommunity.intel.c ... rrabee_manycore.pdf

2009 年的 GDC 09 上 Intel 将公布 LRBni ISA 的细节：

https://www.cmpevents.com/GD09/a ... =11&SessID=9139

SIMD Programming with Larrabee: A Second Look at the Larrabee New Instructions (LRBni) in Action
Speaker: Tom Forsyth (Programmer, Intel)
Date/Time: TBD
Track: Programming
Format: 60-minute Lecture
Experience Level: All

Session Description
Larrabee is Intel's revolutionary approach to take the current evolving programmability of the GPGPU to its logical end. The Larrabee architecture features many cores and threads, as well as a new vector instruction-set extension, the Larrabee new instructions (LRBni).

This talk follows Michael Abrash's first glimpse into LRBni and examines the programming methods and hardware instructions that help programmers get the most out of LRBni's extremely wide vector units. Starting with simple math examples that are fairly simple to vectorize, it moves through loops, conditionals, and more complex flow control, showing how to implement these algorithms in LRBni.

Next, the numberous choices of data format are examined - when to use SOA or AOS (and what those terms mean!), and how to use gather/scatter most efficiently from the same data structures used in an existing engine.

Finally, there is a quick look at efficient code scheduling and how to use the multiple hardware threads to help absorb instruction latencies.

Takeaway
The attendees will learn about the latest processor architecture from Intel, and the instruction set used to program it. Understanding how this architecture and instruction set works will give the attendee information on how to design the next iteration of their game engine, and the possibilities available when programming Larrabee natively.

Intended Audience and Prerequisites
Programmers will get the most from this talk, although it will be of interest to anyone interested in the nature of Larrabee, and the reasons why processor architecture is evolving in Larrabee's direction.

Rasterization on Larrabee: A First Look at the Larrabee New Instructions (LRBni) in Action
Speaker: Michael Abrash (Programmer, Rad Game Tools)
Date/Time: TBD
Track: Programming
Format: 60-minute Lecture
Experience Level: All

Session Description
Larrabee is Intel's revolutionary approach to take the current evolving programmability of the GPGPU to its logical end. The Larrabee architecture features many cores and threads, as well as a new vector instruction-set extension, the Larrabee new instructions (LRBni).

This talk will provide an overview of LRBni and discusses the major instruction features - 16-wide SIMD, multiply-add, ternary instructions, predication, built-in data-format conversion, and gather/scatter.

The talk will then take a close look at a specific - and not obviously vectorizable - application of LRBni - rasterization. This is a crucial stage in the Larrabee rendering pipeline, and it demonstrates how developers can use the flexibility of the new instruction set to solve problems that are not obviously shader-like.

Takeaway
The attendees will learn about the latest processor architecture from Intel, and the instruction set used to program it. Understanding how this architecture and instruction set works will give the attendee information on how to design the next iteration of their game engine, and the possibilities available when programming Larrabee natively.

Intended Audience and Prerequisites
Programmers will get the most from this talk, although it will be of interest to anyone interested in the nature of Larrabee, and the reasons why processor architecture is evolving in Larrabee's direction.

作者: 三毛妮 时间: 2007-10-5 14:33
没有L3缓存有有什么影响？

作者: Edison 时间: 2007-10-5 14:58
人们引入cache主要是因为所谓的局部性原理，即"最近使用的数据可能会被再次使用"的时间局部性和"最近使用过的cache-line中的其他字节可能会在不久后使用"的空间局部性。

对于Larrabee的应用来说，虽然时间局部性的作用不大，但是空间局部性还是比较高的，所以人们倾向于作小而简单的cache。level越低的存储层次，容量必须越大才有意义，但是要知道，Larrabee的L2 cache已经是256KB*32=8mb了，L3岂不是要32MB以上？这么大容量cache不仅成本相当高，而且可能会造成cache一致性实现的复杂度暴跳。另外，Larrabee的GDDR内存带宽有192GB/s，某种程度上足以充当L3了。

作者: lemonninja 时间: 2007-10-5 15:43
其实我觉得这个东西就是INTEL版本的CELL

其用途和CELL非常相似

作者: justkick 时间: 2007-10-5 15:59
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2007-10-5 16:51
在DirectX中本来就有一个参考渲染器，能把shader转换x86指令。

作者: oakville 时间: 2007-10-5 17:55
不太懂:(
我只想知道什么价w00t)

作者: 晶晶守护神 时间: 2007-10-5 18:02
提示: 作者被禁止或删除内容自动屏蔽

作者: aeondxf 时间: 2007-10-5 18:35
为什么larrabee不用IA64呢？在CORE晶体管数目相当的情况下应该可以提供更高一点的性能，而频率也不需要那么高。EPIC+OPENML应该是一个很极品的组合啊……
记得04还是05年IDF上INTEL曾公布过一张概念图，一块IC上中间是几个大核心，周围环绕着十数个小核心，再外边就是CACHE，LARRABEE和这个有没有承上的关系？

作者: xiaolongzi 时间: 2007-10-5 21:11
我觉得Larrabee的架构很灵活。有着CPU的传统。又有GPU的功能。相信Larrabee能成功。

作者: shu0202 时间: 2007-10-5 21:20
个人以为高速L1足够用，对图形渲染来说，要么就搞个超大的缓存，L2看不出有什么必要。

作者: shu0202 时间: 2007-10-5 21:26
不知道Intel是不是有跳过D3D和OpenGL的野心。直接的完全编程结构恐怕现在会浪费大量的运算能力，D3D-X86效率恐怕是大问题，运算能力再强大也是扯。除非Intel打算软硬件一起抓另起炉灶。

作者: shu0202 时间: 2007-10-5 21:31
而且只靠这个运算机构无法完成图形渲染到结果输出的全部过程吧？

作者: slice 时间: 2007-10-5 21:51
:loveliness:
我是个外行，说错了大家不要笑我。
由于较强的通用性容易得到软件的良好支持支持，3DMAX或 maya等等最后渲染是不是也可以获益匪浅。目前这些还是靠CPU，啥专业显卡一点帮助也没有。
Larrabee针对的或许更本就不是我们认为的显卡或游戏卡领域。

作者: mm.pcinlife.com 时间: 2007-10-5 22:00
:funk: "Tera Tera Tera”看成“Tora Tora Tora"了

作者: Prescott 时间: 2007-10-5 22:02
这个是革命性的东东，至于会革了谁的命，谁又知道呢。

作者: cxj3000 时间: 2007-10-5 22:13
我认为其背后隐藏着Intel更大的狼子野心，企图用X86统一所有平台的运算！

作者: complexmind 时间: 2007-10-5 22:54

原帖由 slice 于 2007-10-5 09:51 PM 发表 <a href="http://we.pcinlife.com/redirect.php?goto=findpost&pid=15497221&ptid=828668" target="_blank"><img src="http://we.pcinlife.com/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new windownCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new windownCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://we.pcinlife.com/images/common/back.gif');}" onmousewheel="return imgzoom(this);" alt="" /></a> 
<img src="images/smilies/loveliness.gif" smilieid="60" border="0" alt="" /> 
我是个外行，说错了大家不要笑我。 
由于较强的通用性容易得到软件的良好支持支持，3DMAX或 maya等等最后渲染是不是也可以获益匪浅。目前这些还是靠CPU，啥专业显卡一点帮助也没有。 
Larrabee针 ...

同意啊，Cell其实对游戏没什么用的。。。。。。。。。

作者: Edison 时间: 2007-10-6 01:15

原帖由 slice 于 2007-10-5 21:51 发表
:loveliness:
我是个外行，说错了大家不要笑我。
由于较强的通用性容易得到软件的良好支持支持，3DMAX或 maya等等最后渲染是不是也可以获益匪浅。目前这些还是靠CPU，啥专业显卡一点帮助也没有。
Larrabee针 ...

这类软件应该是可以马上就能从Larrabee上获益的。

作者: nanshan 时间: 2007-10-6 01:53
我看，主要有几点问题，决定了这个构架的性能

1. 多内核下进程的调度和软件的支持，包括接口
2. 多内核下面对cache的使用，共享还是独立，怎么样的调度算法
3. intel是否打算用risc构架逐步取代现有的构架，如果intel始终要保留对原有构架的支持，那就看他如何分析专业和民用的市场
4. 价格，性价比的问题

作者: potomac 时间: 2007-10-6 10:21
提示: 作者被禁止或删除内容自动屏蔽

作者: Eji 时间: 2007-10-6 18:16
基本上我也覺得對Intel來說，用IA-64現有的結構來做Larrabee的話其實會比x86要來得好。Larrabee目前選擇x86應該只是因為公司內的輿論是x86抬頭IA-64低潮，但是如果拿IA-64的ISA來做shader ISA、或者說替IA-64加上GPU相關的ASIC，要當通用處理器以及GPU都相當有吸引力。

話說從我的觀點來看，G8x/G9x仍然算是SIMD+VLIW的結構。

作者: RacingPHT 时间: 2007-10-6 18:35
提示: 作者被禁止或删除内容自动屏蔽

作者: the_god_of_pig 时间: 2007-10-6 18:43
其实觉得太贪心了:loveliness:

作者: 来不及思考 时间: 2007-10-6 19:18
提示: 作者被禁止或删除内容自动屏蔽

作者: 来不及思考 时间: 2007-10-6 19:20
提示: 作者被禁止或删除内容自动屏蔽

作者: HeavenPR 时间: 2007-10-6 19:24

原帖由 RacingPHT 于 2007-10-6 18:35 发表
1: x86
SSE指令系统其实和X86没有什么关系, 所以不会出现x86拖累系统性能的问题。而x86的历史积累, 不是其他指令集可以替代的。
2: 512(1024)bit SIMD
这个可能有潜在的问题, 由于目前的系统都是基于SIMD128 ...

128-bit SIMD 的代码再来一个 4-SMT 不就成了 512-bit SIMD 了么？指令动态打包吧，Intel 肯定比 ATI 玩的好的多了

作者: 来不及思考 时间: 2007-10-6 19:26
提示: 作者被禁止或删除内容自动屏蔽

作者: potomac 时间: 2007-10-6 20:30
提示: 作者被禁止或删除内容自动屏蔽

作者: ayanamei 时间: 2007-10-6 21:12

原帖由 lemonninja 于 2007-10-5 15:43 发表
其实我觉得这个东西就是INTEL版本的CELL

其用途和CELL非常相似

在软件环境方面来说比CELL的优势强太多了

作者: RacingPHT 时间: 2007-10-6 22:25
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2007-10-6 22:32
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2007-10-6 22:37
提示: 作者被禁止或删除内容自动屏蔽

作者: Eji 时间: 2007-10-6 22:46

原帖由 RacingPHT 于 2007-10-6 22:32 发表
其实我觉得这东西和CELL的思想没什么相似性。
类比的话, 我觉得CELL是把一堆SPE打包在一起, 用一个PPE来协调, 而Intel就是把直接一堆加强版PPE包一块了。(和XBOX360的想法蛮像的)

真的很像：SPE是128register，所以Xenon主要就是把32register的VMX改成128個register。
於是Larrabee就是把這種方式擴展到P54c + SSE，頂多就是把SSE做到128 register....？

作者: RacingPHT 时间: 2007-10-6 22:53
提示: 作者被禁止或删除内容自动屏蔽

作者: fhnp 时间: 2007-10-6 23:01
http://www.pcpro.com.cn/pcpro//2007/0911/500970.shtml

虽然这种微内核/超多核设计是发展趋势，但短期内这种大跨度的设计改型，光从API层面还存在许多未知的问题。想通过光线追踪这种噱头型的技术，想在短期切入游戏市场还值得观望。

作者: feel囝 时间: 2007-10-6 23:32
我们都知道，现在所谓的X86处理器，内核已经有很大一部分是类似Risc架构(只处理微指令而非X86)，那么，我想知道，在搞D3d时，需要先编译成X86，然后又再解码，才处理，这不是需要太多的时间吗？！

[ 本帖最后由 feel囝于 2007-10-6 23:37 编辑 ]

作者: Prescott 时间: 2007-10-7 00:41

原帖由 Edison 于 2007-10-5 14:28 发表
本主题是专门为讨论Larrabee开设的，因此要求相关的讨论以技术为主。

1、Intel的Doug Carmean为Larrabee的首席架构师

这厮是Netburst的chief architect，喜欢走极端，我看出来了。

原帖由 HeavenPR 于 2007-10-6 19:24 发表

128-bit SIMD 的代码再来一个 4-SMT 不就成了 512-bit SIMD 了么？指令动态打包吧，Intel 肯定比 ATI 玩的好的多了

应该不是这个样子的。

原帖由 potomac 于 2007-10-6 20:30 发表

偶的问题就是这个SMT，
本来SMT就是消除损失的，现在又是主要跑图形。
当真需要4线程来填饱in-order？:huh:

恩，in-order就是有这么大的损失。

原帖由 RacingPHT 于 2007-10-6 22:37 发表
官方的Ct Pdf, 不过我觉得没几个人会认真看就是了
http://www.intel.com/research/pl ... cale_whitepaper.pdf

(看了一下pdf, 不少是华人在做的这个东东, 可惜不是primary author)

ICRC的有不少人在参与做这个东西，研究项目，所以。。。。。。

128 registers似乎不是x86的风格...我很怀疑...不过Intel在IA64也这么做过, 所以可以拭目以待.
总之几乎全是一样的
x86 vs PPC
512bit SIMD vs VMX128
2 threads vs 4 threads
双方的单线程通用指令性能都很烂(~1/3于该指令集的最高水准)
两边的基础指令集都不怎么样

所以根据这个惯性推论的是, 同样的Peak的前提下, Larrabee的实际性能不如SPE

SPE有SMT？我怎么不记得？
:huh:

作者: Prescott 时间: 2007-10-7 00:44
要说Larrabe的性能，先估算一下2G的P54C的性能怎么样？:unsure:

然后再加上4 Thread SMT？:unsure:

然后再加上512bit SIMD？:unsure:

然后再算上核心的个数？:unsure:

这样就差不多了。:p

作者: Eji 时间: 2007-10-7 01:06
原帖由 Prescott 于 2007-10-7 00:41 发表

[quote]128 registers似乎不是x86的风格...我很怀疑...不过Intel在IA64也这么做过, 所以可以拭目以待.
总之几乎全是一样的
x86 vs PPC
512bit SIMD vs VMX128
2 threads vs 4 threads
双方的单线程通用指令性能都很烂(~1/3于该指令集的最高水准)
两边的基础指令集都不怎么样

所以根据这个惯性推论的是, 同样的Peak的前提下, Larrabee的实际性能不如SPE

SPE有SMT？我怎么不记得？
:huh:[/quote]

那是在講Larrabee的x86 core vs PPE吧？所以用PPE的最佳狀況和同時脈SPE比。

不過我覺得問題不是性能的好壞而是泛用性和推廣上的可接受度....
x86畢竟不是因為性能而被推廣的。
Intel現在認為x86的包袱本身才是價值，所以推導至擴展x86的範圍才是把晶圓轉成經源的康莊大道。所以是為了x86而x86.....

[ 本帖最后由 Eji 于 2007-10-7 01:17 编辑 ]

作者: 紫色 时间: 2007-10-7 13:08
标题: netburst第二，走极端、等待流产的怪物。
在这种异构的处理器上进行编程很困难，编译器自动优化是不可能完成的任务，所以larrabee的“理论”能力只是个画饼。还不如增加核心数目，增加执行单元，减少指令吞吐量延迟来的实际。

[ 本帖最后由紫色于 2007-10-7 16:43 编辑 ]

作者: Eji 时间: 2007-10-7 16:23

原帖由紫色于 2007-10-7 13:08 发表
在这种异构的处理器上进行编程很困难，编译器自动优化是不可能完成的任务，所以larrabee的“理论”能力只是个画饼。还不如增加核心数目，增加执行单元，减少指令吞吐量延迟来的实际。

我反而覺得Larrabee用x86 ISA就是想解決compiler問題.... SPE麻煩多了。

編譯器自動優化是當初CELL在講的事情，PPE和SPE的結構真的差太多，還有LS的空間都讓compiler束手無策，所以上面的說法套到CELL上比較適當。
而且PPE的面積幾乎是SPE的兩倍，大部分benchmark的peak卻輸了接近1/3左右，Larrabee的32 core只怕可以放64個以上的SPE，peak的差距可能會更驚人。
但是PS3的title上用到SPE的比例也是少得可憐....

所以要論理論值的畫餅，還是CELL比較在行。

[ 本帖最后由 Eji 于 2007-10-7 16:38 编辑 ]

作者: RacingPHT 时间: 2007-10-7 16:38
提示: 作者被禁止或删除内容自动屏蔽

作者: 紫色 时间: 2007-10-7 16:56
[quote]原帖由 RacingPHT 于 2007-10-7 16:38 发表

拜托看懂我的意思。还来个“核心数目增加了”，“执行单元增加了”反驳我~~
这样写吧，也许你会容易理解：

netburst第二，走极端、等待流产的怪物。
在这种异构的处理器上进行编程很困难，编译器自动优化几乎是不可能完成的任务，所以larrabee的“理论”能力只是个画饼。还不如增强目前core2这种同构方案，（在同构的方案下）增加核心数目，增加执行单元，减少指令吞吐量延迟。

传统的并行编程模式是mpi,openmp。此类程序员们面对cell这种家伙都不知道该怎么把计算量向（8+1）平摊。

[ 本帖最后由紫色于 2007-10-7 17:22 编辑 ]

作者: Prescott 时间: 2007-10-7 17:00

原帖由紫色于 2007-10-7 16:56 发表
[quote]原帖由 RacingPHT 于 2007-10-7 16:38 发表

拜托看懂我的意思。我少写了几句，你就晕了？还来个“核心数目增加了”，“执行单元增加了”反驳我~~
这 ...

Larrabee就是同构的。OpenMP/MPI应该就可以跑得很欢。
BTW: Larrabee SDK已经粮草先行了。

作者: 紫色 时间: 2007-10-7 17:14
我晕，是的larrabee是同构的。。。

作者: RacingPHT 时间: 2007-10-7 17:24
提示: 作者被禁止或删除内容自动屏蔽

作者: 紫色 时间: 2007-10-7 17:38
to RacingPHT：
mpi的实现与程序员的编程模式是两码事。程序员的角度，其实也就是进程模型的角度，要么是mpi那样进程间通信，或者openmp的多线程。“多进程”或者“多线程”都是基于“多个相同的处理器”，也就是同构（多路、多核、smt之类）。所以说，openmp/mpi编程模式是基于同构系统。而cell就是站在openmp/mpi的对立面。
至于你说的在cell上实现mpi，请注意两点，首先在cell上编mpi程序，其实还是基于“同构”编程模型的进程间通信。其次，mpi库只是消息传递接口函数库，对程序性能没多少贡献，而且即使cell上有某库能够做到对性能贡献极大，这种通过库在底层实现并行的方式也不令人满意。
要想异构流行，就必须发展出相应理论，告诉程序员（8+1)这类异构模型的编程模型。在那之前，异构的“理论”能力只是画饼。说不定IBM的库也就只是“实现”了而已，它的库使用了几个spe谁知道呢。

[ 本帖最后由紫色于 2007-10-7 20:58 编辑 ]

作者: acqwer 时间: 2007-10-7 17:46

原帖由紫色于 2007-10-7 17:38 发表
是的，目前几乎所有的多路系统都支持mpi，但是他们都是同构的。

mpi的实现与程序员的编程模式是两码事。程序员的角度，其实也就是进程模型的角度，要么是mpi那样进程间通信，或者openmp的多线程，都是基于“ ...

Larrabee的规格已经很明显的表明是同构的了，你还扯什么异构。

作者: flykickbird 时间: 2007-10-7 17:46
提示: 作者被禁止或删除内容自动屏蔽

作者: 紫色 时间: 2007-10-7 18:43
原来larrabee的对手只是是ati和nv的显卡和通用计算卡，听说过intel要发展many core的处理器，我很激动~~~还以为larrabee就是呢。话说回来，一旦解决了在异构系统上怎样进行编程的问题，cell或者其他manycore处理器的威力还是很大的。我倒是很希望看到intel弄出4核心+N个浮点单元的many core商品出来，免得去购买clearspeed之类的天价卡。

[ 本帖最后由紫色于 2007-10-7 21:07 编辑 ]

作者: 1empress 时间: 2007-10-7 20:06
提示: 作者被禁止或删除内容自动屏蔽

作者: Eji 时间: 2007-10-7 22:37

原帖由 1empress 于 2007-10-7 20:06 发表
干掉arm 占领移动市场才是intel的目的

想太多_A_
占領移動市場與幹掉ARM是兩件事情...

作者: potomac 时间: 2007-10-7 23:04
提示: 作者被禁止或删除内容自动屏蔽

作者: Eji 时间: 2007-10-8 01:26

原帖由 potomac 于 2007-10-7 23:04 发表

偶还是不大相信。
Cell不过两线程，也能填饱8个SPE。:sweatingbullets:
弄4线程出来，岂不是执行效率比2005年的SPE都不如。:ermm:

PPE的線程是為了起始工作，延遲是靠MIC的DMA來對應的；
Larrabee的core線程則是為了填飽自己的work unit，所以作用不同....
PPE如果沒有自己的workload只為了分配工作的話，效能是的確夠用。

另外，就和PPE vs SPE一樣，效率應該是真的不如SPE。_A_

作者: itany 时间: 2007-10-8 01:33

原帖由 1empress 于 2007-10-7 20:06 发表
larrabee只是一颗实验性的东西，目的是验证x86做图形处理的可行性

larrabee的最终产品可以做大也可以做小

做小的话，可以与与网络处理器结合为强大的移动设备

干掉arm 占领移动市场才是intel的目的

个人觉得不管是这个创意还是上市的时间，都像是给XBOX 720（？）提供的……
感觉Larrabee通过即时把D3D的API编译到x86上执行来和GPU同场竞技有点玄，但是如果是游戏主机的话，完全可以直接编译成Larrabee直接执行的二进制代码，这样效率应该是很有保证的
单芯片在成本上也是有优势的吧，大不了在里边放一两个乱序的核心来专门跑AI和类似桌面应用的程序

作者: Prescott 时间: 2007-10-8 10:39

原帖由 Eji 于 2007-10-8 01:26 发表

另外，就和PPE vs SPE一樣，效率應該是真的不如SPE

不妨先定义一下什么叫效率？perf/watt? perf/mm2? perf/peak?
当然还要先定义什么叫perf，是linpack flops? 还是specint？还是specfp？还是自己的某个程序？

作者: potomac 时间: 2007-10-8 11:57
提示: 作者被禁止或删除内容自动屏蔽

作者: potomac 时间: 2007-10-8 12:09
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2007-10-8 15:00
提示: 作者被禁止或删除内容自动屏蔽

作者: Prescott 时间: 2007-10-8 15:53
标题: 回复 #61 RacingPHT 的帖子
1. en, reasonable.
2. 如果512bit SIMD为真，那Larrabee的单精度peak可以是51.2Gflops@1.6G，当然在找到512bit宽的数据并行度之前，这个数字只是浮云。如果拿这个当被除数peak，Larrabee也太吃亏了点。:p
3. 如果是同样的任务，PPE和SPE都充分优化，这种情况怎么会发生呢？SPE当然沾了LS的光，数据和指令带宽应该都不是问题，但是PPE的cache也不是摆设啊。
5. 这个有没有实际的指令序列或者源代码可以研究？

作者: FccR 时间: 2007-10-8 16:53
很是搞不懂为何要基于X86上做研发.:funk: :funk: :funk:

作者: Prescott 时间: 2007-10-8 18:09
无聊，看了看RacingPHT的http://we.pcinlife.com/viewthrea ... 26amp%3Btypeid%3D62

貌似Larrabee比较适合Kyro或者PowerVR模式啊，各位有什么意见啊？

作者: RacingPHT 时间: 2007-10-8 23:57
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2007-10-9 11:44
虽然Intel和PowerVR有授权，但是Intel的整合图形并没有使用上PowerVR的Tile Based Deferred Rendering，而是Zone Rendering和deferred texturing，Larrabee的内存带宽相当充沛而且未来会有3d stack的可能，Tile Based Deferred Rendering不太可能应用上去。

作者: Prescott 时间: 2007-10-9 11:54
标题: 回复 #65 Edison 的帖子
未必哦，内存带宽永远没有充沛一说，永远是不够的，能不用stack就不用，没必要增加不必要的成本而且降低灵活性。
而且，Larrabee那样的结构，貌似Tile based很合适。

BTW: 怎么设签名档啊？

[ 本帖最后由 Prescott 于 2007-10-9 11:56 编辑 ]

作者: 287381906 时间: 2007-10-9 17:34
为了看懂努力……:wacko:

作者: itany 时间: 2007-10-12 17:47
居然沉了，唉……
上浮，上浮

作者: Prescott 时间: 2007-11-4 11:28

原帖由 Prescott 于 2007-10-8 18:09 发表
无聊，看了看RacingPHT的http://we.pcinlife.com/viewthread.php?tid=606808&extra=page%3D1%26amp%3Bfilter%3Dtype%26amp%3Btypeid%3D62

貌似Larrabee比较适合Kyro或者PowerVR模式啊，各位有什么意见啊？

B) B)
:a)

作者: Edison 时间: 2007-11-4 13:19
没有Deferred Rendering这个关键字眼的话，tiled-based也就与Power VR的渲染方式没必然关系了。

作者: cxasuka 时间: 2007-11-23 17:39
=。=~~~弄不懂larrabee到底怎麽用~~~無聊的時候想~~~larrabee既然在可編程性上已經比較好的話~~~直接作爲一塊非定義的加速卡來賣至於在上面實現的功能由使用其的os或者應用程序來定義~~~來實現協助功能的多樣化？

作者: RacingPHT 时间: 2007-11-24 17:50
提示: 作者被禁止或删除内容自动屏蔽

作者: Prescott 时间: 2007-11-24 23:49
以Larrabee完美的可编程性：完整的X86_64指令集和扩展的512bitSIMD，Larrabee干什么，怎么干都是可以的。总之呢，别看NV现在风光，但是如果NV死在AMD前头，我一点都不会吃惊。

我唯一担心的是软件的问题。

[ 本帖最后由 Prescott 于 2007-11-24 23:53 编辑 ]

作者: Eji 时间: 2007-11-25 07:51
我是覺得TBR在IMR都已經具備Hi-Z等HSR之類技術的時代，已經沒有什麼存在的必要了。當然我們可以說OpenGL和DirectX等IMR專用的API扼殺了TBR沒錯....

TBR當年是的確有複雜度高的問題，Dreamcast的PowerVR2DC只有1條100M pixel/s 的pipeline、但是規模卻與TNT2平起平坐是個可怕的問題，不過不可忽視的是PVR2DC有DOT3 bump、這個NVIDIA系要到GeForce256才有。

此外，Dreamcast的3M triangle/s我認為主要的問題是SH-4的FPU沒有良好的pipelining造成的問題，在AC用的NAOMI配了專門的T&L chip之後，NAOMI就有大約10M pilygon/s穩定的能力；而且PVR2DC應該是100MHz、800MB/s的single channel SDRAM而已，沒有1.6GB/s那麼豪華的記憶體系統。

CPU當然幹什麼都是可以的，但是GPU會希望"有效率地幹"某件事情，否則架構意義就不大；而這不是真的一堆SIMD accerator就可以搞定的。CPU是有on-chip cache沒錯，但是光這樣就能夠把TBR的on-tile Z-reject做好嗎？總之，我想大概會是完全不同方向的實作會更有效率吧；雖然Larrabee有很大的可能是打算在multi-core上以software來模擬GPU咦鳎?贿^短期之內我相當懷疑這種作法的實效。

不論ATI or NVIDIA，GPU廠商的命脈還是在OEM廠訂單上，相對於過去的ATI，現在的AMD理論上能燒的錢比以前多，因為有CPU市場的獲利；遇到的狀況也都比以前嚴苛，因為CPU+GPU的實作可能會在推出後很快地席捲低階市場。

[ 本帖最后由 Eji 于 2007-11-25 07:53 编辑 ]

作者: RacingPHT 时间: 2007-11-25 15:12
提示: 作者被禁止或删除内容自动屏蔽

作者: Prescott 时间: 2007-11-25 20:23
理论确实是一大堆一大堆的，等着明年看Larrabee的3DMark06成绩吧。:lol:

所谓X86的浮点效率就不需要讨论了，讨论x87的效率还差不多。其实定制单元的优势是可以很容易作出非常高的理论FLOPS，但是只能在特定的应用中发挥出来，可编程单元的优势是可以在绝大部分应用中发挥出非常高的效率，但是同样多晶体管获得的理论FLOPS值却非常低。如果可编程单元的理论值可以和定制单元相提并论，性能上前者绝对不会输于后者，对灵活性要求越高的场合，两者之间的差距也就越来越大。

各位图形高手给我科普一下，跑3DMark06 10000分需要多高的FLOPS？这个都是固定的吧。号称FLOPS 1T的G100打算3DMark06跑多少分啊？

[ 本帖最后由 Prescott 于 2007-11-25 21:29 编辑 ]

作者: Edison 时间: 2008-4-9 01:08
我这里收到最新的消息，Larrabee的45nm版发热相当高，根据第三方厂商的测试，其通用性能也比对手的下一代65nm GPU产品低不少。

作者: littlebird 时间: 2008-4-9 01:45
通用性不如gpu？不可能吧。

作者: yyloveyou 时间: 2008-4-9 01:52
这就是电信重组后的新三国演义，毫无疑问INTEL就是移动，而AMD就是新的联通-网通，也非常相像，AMD收购了ATI=联通合并网通，而NV比较尴尬，它就是电信了，当然了潜力是巨大的。

作者: samsung 时间: 2008-4-9 01:54
是否規格類似?

其實Intel應該用Power VR技術與自己的半導體製程

作者: Edison 时间: 2008-4-9 02:22
Larrabee的一个主要优势是具备程序代码无关的cache coherence protocol，这可以让程序员在编写代码的时候不用像GPU、Cell SP那样需要考虑scratch pad内数据的一致性和连贯性，但是Larrabee的cache coherence protocol代价相当大，吃掉大量的晶体管，这是一把双刃剑。

作者: agentjones 时间: 2008-4-9 08:28
http://www.pcper.com/article.php?aid=532

JC似乎对larrabee很不屑，他认为intel这种企图用暴力加速传统的低效raytracing算法这条道路是错误的，他已经发明了一种新的数据结构sparse voxel octree能够高效率raytracing,将被用到下一代id tech6中

(PS:intel也够无聊的，在IDF上为了突出它的raytracing，拿来做对比的竟然是一个ps1时代水准的3D demo，靠，它怎么不拿crysis,GOW来做对比:whistling: )

作者: Eji 时间: 2008-4-9 10:15
sparse voxel octree有個好處是，他可以用來把"需要ray tracer的區域分出來，也就是利用區域性。
實際上沒有複雜光源反射的話，ray tracer和Rasterizer相比並沒有優勢....
另外一點是，為了滿足大規模的亂數行為所做的cache model(Larrabee)的實用性也會受到質疑。

Relief Mapping算是pixel level 的 ray trace，加上sparse voxel octree的話，基本上可以說把ray tracer相對於rasterizer有利的部分都包下來了....
所以sparse voxel octree(ID Tech06)可以順利完成的話，應該不會再有人單獨使用Ray Tracer才是。

作者: agentjones 时间: 2008-4-9 10:38

原帖由 Eji 于 2008-4-9 10:15 发表
sparse voxel octree有個好處是，他可以用來把"需要ray tracer的區域分出來，也就是利用區域性。
實際上沒有複雜光源反射的話，ray tracer和Rasterizer相比並沒有優勢....
另外一點是，為了滿足大規模的亂數行為所 ...

E大能不能把那篇采访翻译出来，英文版的看的太累，JC的话又很饶舌~~~

作者: Prescott 时间: 2008-4-9 11:23

原帖由 Edison 于 2008-4-9 01:08 发表
我这里收到最新的消息，Larrabee的45nm版发热相当高，根据第三方厂商的测试，其通用性能也比对手的下一代65nm GPU产品低不少。

连silicon都没有，第三方厂商就可以测试了啊？:huh:

作者: Edison 时间: 2008-4-9 11:45

原帖由 Prescott 于 2008-4-9 11:23 发表
连silicon都没有，第三方厂商就可以测试了啊？:huh:

当然有了。

作者: Prescott 时间: 2008-4-9 12:56

原帖由 Edison 于 2008-4-9 11:45 发表

当然有了。

:funk:
好吧，就算有吧

作者: 来不及思考 时间: 2008-4-9 13:26
提示: 作者被禁止或删除内容自动屏蔽

作者: droganmaster 时间: 2008-4-9 13:28
管它三七二十一反正登出来了看具体测试
我个人感觉这卡跑专业测试跑一些纯浮点运算可能会很强游戏如何还要看与厂商的合作
架构这东西确实不好说从公布的来看估计通用计算可能会就此真正的进入民用领域 N和A的通用计算目前还是浮云 Intel的优势在于能得到更加多的通用计算软件的支持物理计算由于I有Havok估计这卡应该很强但是纯粹的3D图形渲染很难预测性能和以往的GPU差别太大

作者: 蒙大拿 时间: 2008-4-9 13:36
太复杂的东东性能会大打折扣. 这个里内部混乱是难免的. 就象大城的十字路口没有交警没有红绿灯, 乱得一团麻.

作者: 287381906 时间: 2008-4-9 13:56
看了INTEL“全球首款DX10显卡G965”的结局，我不敢对这东西抱有什么幻想:wacko:

作者: complexmind 时间: 2008-4-19 11:29
:w00t): :w00t): WEPC上的高手齐聚一堂啊！！
好久不见P大了，小弟这厢有礼了:lol:
  一下是小弟个人见解，说错了各大高手别笑啊:a)
  感觉Intel希望把高性能计算（典型代表：科学计算）和工业计算（典型代表：流计算）结合起来，而鼓捣出了Larrabee，所以用很多的含通用计算成分的核心做出了Larrabee，由于P大所说的通用核心和定制核心的特点，所以显得累赘了些，不过我有一些不明白：
  1.既然强调通用性，为什么用顺序结构？超标量和乱序执行为什么不加入？如果是为了控制晶体管的规模，那么这么做是不是暗示着其实现在大一统通用计算结构完全占领机箱还需要材料学，物理学的理论突破来支撑，而现在的制程技术无法支撑真正的万能通用核心进入工业计算领域而实现统一？
  2.观察GPU，一些DSP，是不是一般的定制核心都优先考虑顺序结构，如果是，那么可不可以理解为顺序计算是非通用计算的特征之一呢？
  3.多线程技术能在多大程度上取代乱序执行和超标量的作用？
  4.最后，是不是顺序计算结构在某种程度上相对乱序结构有天生缺陷？
谢谢各位大侠指惑，小弟先谢谢了:a)

[ 本帖最后由 complexmind 于 2008-4-19 11:34 编辑 ]

作者: complexmind 时间: 2008-4-19 12:40
这个板块怎么又变冷清了？:a)

作者: catalufa1984 时间: 2008-4-19 13:22
为什么没有l3？对性能没有影响吗？

作者: 花泥 时间: 2008-4-19 14:00
早点出来解开疑团嘛～～～

作者: Edison 时间: 2008-4-19 15:51
1、通用性与微架构上的in-order、OoOE无关，是否具备通用性是看ISA。
2、同上。在Cyrix 6x86/pentium Pro之前的x86处理器都是顺序执行微架构，在IBM/Motorola Power1之前的通用处理器都是顺序执行的微架构，在CDC 6600之前的计算机硬件系统都是顺序执行架构。
3、取决于程序。
4、in-order和OoOE各有优势和缺点，人们引入OoOE的主要原因是为了改善superscalar的性能，代价是消耗更多的晶体管。

作者: Prescott 时间: 2008-4-19 18:05

原帖由 complexmind 于 2008-4-19 11:29 发表
  感觉Intel希望把高性能计算（典型代表：科学计算）和工业计算（典型代表：流计算）结合起来，而鼓捣出了Larrabee，所以用很多的含通用计算成分的核心做出了Larrabee，由于P大所说的通用核心和定制核心的特点，所以显得累赘了些，不过我有一些不明白：
  1.既然强调通用性，为什么用顺序结构？超标量和乱序执行为什么不加入？如果是为了控制晶体管的规模，那么这么做是不是暗示着其实现在大一统通用计算结构完全占领机箱还需要材料学，物理学的理论突破来支撑，而现在的制程技术无法支撑真正的万能通用核心进入工业计算领域而实现统一？
  2.观察GPU，一些DSP，是不是一般的定制核心都优先考虑顺序结构，如果是，那么可不可以理解为顺序计算是非通用计算的特征之一呢？
  3.多线程技术能在多大程度上取代乱序执行和超标量的作用？
  4.最后，是不是顺序计算结构在某种程度上相对乱序结构有天生缺陷？

Intel显然是希望处理器具有异常强大的浮点运算能力，未来Larrabee肯定是要作为处理器的一部分集成的

你的问题参见Edison老大的回答

作者: efficient3d 时间: 2008-4-19 19:32

原帖由 RacingPHT 于 2007-11-24 17:50 发表
Kyro或者PowerVR的模式?
那么首先看看这个模式的特点是什么
1: 在fill-rate上的bandwith需求很低, 因为很多东西做到on-chip
2: pixel throuphput很低, 主要用高效率来补偿
3: geometry的处理能力很低, 因为每个t ...

PS2那个填充率多了一个“零”吧，应该是4800M每秒，不过带纹理的时候会降到2400M每秒。总的说来，PS2游戏画面不比DC好太多。
粗看了一下Larrabee的介绍，咱也不懂太多更加深层次的东西，感觉这个和他们自己的CPU有一定关系，搞不好就是一个暴力运算器来的，相比CPU运行图形程序，性能更好；但是比专用的又差了一些，就是一个中间产物。但是不管怎样我还是看好Intel，不为其他，就是因为他是Intel。Intel手中掌握的图形技术应该不少－－Real3D、3Dlabs与PowerVR这些公司的图形核心技术他都有，但是一没有用出来，现在看看Intel怎么搞了。不过先前看过一些新闻，Larrabee最初的产品定位是专业绘图工作站，不知道这个架构运行OpenGL程序相比其他公司的有无优势。

作者: complexmind 时间: 2008-4-22 16:55
:lol: :lol: 谢谢P大和Edison大的解答！！

作者: complexmind 时间: 2008-4-22 17:32
:)
小弟看了回答又想到两个问题：
1。现在GPU的ISA和CPU的ISA在通用性上还有没有决定性的差异？
2。为什么CPU的内核里集成像GPU那么多的乘法器除法器和大量的寄存器来提升浮点运算效能呢？除了在制程和发热量及良品率上的考虑外，是不是在CPU定位于控制管理而不是计算这方面的考虑？也就是说在3D及物理运算上CPU劳心而GPU劳力，，而在GPU的ISA能力以外的工作CPU即劳心又劳力？这种理解对么？

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