融聚的未来在哪里 APU构架方向发展分析.docx
《融聚的未来在哪里 APU构架方向发展分析.docx》由会员分享，可在线阅读，更多相关《融聚的未来在哪里 APU构架方向发展分析.docx（27页珍藏版）》请在冰豆网上搜索。
融聚的未来在哪里APU构架方向发展分析
融聚的未来在哪里APU构架方向发展分析
CBSi中国·ZOL作者：
中关村在线顾杰责任编辑：
林光楠【原创】2011年03月24日评论（51）
本文导航
∙第1页：
APU构架方向发展分析
∙第2页：
2加2等于1？
∙第3页：
2加2到底等于几
∙第4页：
Fusion构架解析
∙第5页：
直连是真正的天堂
∙第6页：
缘起：
扩展指令集的前世今生
∙第7页：
矛盾：
兼容指令集的应用
∙第8页：
阿喀琉斯的脚踝
∙第9页：
我要咬破那无边的黑暗
∙第10页：
死胡同？
∙第11页：
上帝拯救那些自救的人
∙第12页：
雪中送炭的ComputeShader
∙第13页：
融合的谜底，AMD的最终武器
∙第14页：
融合的未来，融聚未来
返回分页阅读文章
产品：
OntarioC-30APUAMDCPU
APU构架方向发展分析
前言：
天下之事，分久必合，合久必分。
大到国家和社会，小到热力学统治下的一小群微观粒子，我们周围的一切都在佐证着这个真理。
这当中自然也包括了我们所使用的电脑。
从硬件T&L第一次正式开始将显示相关计算和操作从CPU中剥离出去之后，GPU和CPU已经在各自独立的路线上分别发展了十二年。
在此期间，无论CPU还是GPU，他们的结构和性能有了突飞猛进的提升。
现在，伴随着INTEL和AMD再次将GPU集成回CPU内部，一场统一融合的行动就此拉开了序幕。
分有分的道理，合有合的规矩，当初GPU从CPU内部剥离的时候可以说是顺应需求，现在两者再次合并总要有个说法。
INTEL和AMD已经分别推出了自己融合CPU和GPU的产品，他们真的只是为了简单的降低成本同时将产品线延伸到显示领域去么？
秉承CBS之眼的精神，我们将在CBS探索与发现节目中以三期的篇幅，从根本上介绍AMD,NVIDIA以及INTEL三家的不同思路以及产品，为读者逐步展示CPU与GPU的统一之路的真实面目，以及隐藏在背后的三方的“小算盘”。
顾杰所写过的技术分析类文章索引（持续更新）
1、谁是微软忠实随从A/N统一构架历史回顾
2、忠实微软是否有用A/N统一构架细节分析
3、揪出幕后罪魁祸首是谁拖累了统一架构
4、曝你不知道的DX11解析GPU通用计算妙用
产品：
OntarioC-30APUAMDCPU
2加2等于1？
●2加2等于1？
关于AMD和APU的故事，我觉得应该从5年前讲起。
因为AMD今天的一切，甚至在过去5年间贯穿AMD公司上下的唯一一根发展主线，都是从5年前的那场收购开始的。
AMD收购ATI
美国东部时间2006年7月24日4:
30，世界第二大CPU供应商AMD突然在其官方网页上宣布收购世界第二大桌面独立图形芯片供应商ATI，消息一出举世震惊。
在这次收购之前，如果不计入过于弱小的VIA的话，世界上能够同时供应CPU，显示芯片以及主板芯片组的厂商仅有INTEL而已。
通过对ATI的收购，AMD不仅再次获得了高性能主板芯片组的系统研发和制造能力，更成为了世界上唯一一家能够同时供应桌面独立显示芯片的CPU制造商。
惨淡的AMD股价
为了这次收购行动，AMD付出了沉重的代价。
54亿美元的交易额带来的沉重债务负担，收购如此巨大的企业对自身企业体系和文化产生的冲击，混乱的管理，忽然增加的对等部门之间的磨合和协调……收购ATI之后的AMD在一段时间内简直就像是靠近台风眼的海面上飘摇的轮船一样。
再加上后来金融危机导致的消费紧缩，AMD的处境一时间险象环生。
化腐朽为神奇的HD4850
好在在经历了诸多变故，甚至卖掉FAB之后，AMD终于在风雨中恢复了稳定。
与此同时，逐渐消化了ATI的AMD开始在CPU和独立显卡两个方向上同时发力。
我们看到了让R600构架起死回生的RV770，看到了几乎达到换代级性能提升的上海核心的Phenom，看到了fusion计划，这一系列锐意进取的动作是如此的干脆利落又大快人心，以至于很多人都联想到了那个斗士桑德斯领导下的AMD。
AMD仿佛要用实际行动告诉世人，2+2有的时候是可能等于1的。
产品：
OntarioC-30APUAMDCPU
2加2到底等于几
●2加2到底等于几
人们常说世事难料，在经历了RV770和上海Phenom的崛起之后，人们期待中的上升和闪耀并没有出现。
AMD在随后所推出的一系列硬件，无论是GPU还是CPU，都给人一种极为明显的停滞和堆砌感。
RV870和RV970在构架层面上与对手的相比竟然达到了代差级的差距，对DirectX11的支持充满了迎合和堆砌感。
伊斯坦布尔核心的Phenom则干脆只是改了改内核广播模式就直接登场了。
即便连最忠实的拥趸也不得不承认，在构架前进以及设计更高效电路的方向上，AMD在过去两年多的时间里几乎是停滞不前的。
堆砌而成的伊斯坦布尔核心
对于一个科技创新型企业来说，停滞不前是危险的信号，他可能意味着某个重大革新或构架来临之前短暂的积蓄力量和酝酿释放，也可能意味着企业陷入了发展方向上的迷茫和困惑。
对于前者，在有足够资金实力和外界支持的前提下可以予以应对，在革新出现之后企业会走上正轨并获得比以前更大的飞跃。
对于后者，方向和思路的丧失对企业来说只意味着致命的危险和灾难的降临。
构架毫无创新的RV870
这种停滞如果持续更长时间的话，AMD最终将在CPU领域被INTEL彻底甩开，而显卡领域则会将上帝赐予的领地全数吐还给NVIDIA。
如果等一切都发生了再去寻找突破口，一切就都晚了。
到时候天知道2+2会等于几了……
还好，上帝是眷顾喜爱AMD的人们的。
当APU出现的时候，所有人都长出了一口气。
事实证明，AMD并没有迷失在一片迷雾之中，坚强的他勇敢地站了起来并找到了自己前进的方向——融合。
产品：
OntarioC-30APUAMDCPU
Fusion构架解析
●Fusion构架解析
Fusion构架由一颗标准CPU和一颗标准的支持DX11的GPU组成，这种构架表面上看起来平淡无奇，甚至INTEL早先发布的Sandybridge构架也一样是由类似的基本组合构成的。
但是如果我们观察细部，就会发现fusion构架与Sandybridge构架之间本质性的不同，那就是对CPU和GPU的连接。
APU构架特点
其实硬件内部的互联问题一直是AMD和INTEL争论以及口水的焦点。
自K8将MC直接引入到内核中开始，“谁是胶水谁是真”这种争执就一直萦绕在双方各代构架的周围。
公允来讲，AMD的硬件设计确实比竞争对手更早的进入到更深层次的互联水平上。
不论是MC的引入还是通用共享式cache，甚至是内核任务广播机制方面，Nehalem出现之前的INTEL一直都维持着于AMD相差一代的互联层次。
AMD在构架直连方面一直处在领先位置
正是这种长期以来形成的互联层次上的优势以及经验，造就了今天Fusion的与众不同。
区别于竞争对手通过北桥进行连接的方式，AMD在Fusion中通过crossbar直接将GPU和CPU连接在了MC上。
GPU本身无须具备独立的内存控制单元，它只需通过crossbar直接使用CPU的MC即可，这不仅节约了在GPU体系中即为占用晶体管资源的内存管理机制，而且还大幅改变了GPU对本地显存的操作方式。
产品：
OntarioC-30APUAMDCPU
直连是真正的天堂
●直连是真正的天堂
随着GPU对MC的直连，GPU对本地显存的使用不再需要传统的集成，或者通过带宽有限而且本来就拥挤不堪的PCIE总线/北桥绕路访问主存。
Fusion内部的GPU只需要在需要的时候直接使用CPU的MC单元，即可直接访问本地主存并完成对应的操作。
自AGP-DIME以来人们一直梦寐以求的显卡直接内存操作，终于在Fusion上得到了应用。
AGP-DIME操作模式
不论AMD公布的信息、竞争对手对他的评价还是舆论和媒体的报道，人们对Fusion的认知和理解依旧停留在低功耗、快速直连以及高集成度的CPU/显示一体化解决方案。
诚然，在去除了相当大一部分高发热的MC单元所占用的晶体管之后，Fusion的GPU在保持一定性能的同时的确实现了极低的功耗指标，这使得Fusion的整体功耗性能比颇为出色。
但一切真的仅止于此么？
APU构架特色
接下来，我们将面对一段恩怨，一段跨越几十年的恩怨，一段纠结在INTEL和AMD灵魂最深处的恩怨。
产品：
OntarioC-30APUAMDCPU
缘起：
扩展指令集的前世今生
●缘起：
扩展指令集的前世今生
指令集是做什么的？
他跟处理单元又有什么区别呢？
我举个简单的例子——要处理“a+b=？
”这个方程问题，使用到的是运算器，也就是ALU和FPU。
而如果要处理的是“寄存器a的结果+寄存器b的结果=？
”，这种情况下所要使用到的，就是扩展指令集了。
SIMD指令集操作方式
运算器所执行的，是从指令中拆解出来的数据，执行这些数据的过程即为操作，由于传统的X86指令集是典型的SISD结构，单周期只能处理一组操作以及使用一组寄存器，这造成了处理效率的极端低下，寄存器资源方面也存在极大的浪费。
后来出现的一些并行指令集如MMX虽然改善了状况，但其本身又无法处理浮点数据。
针对这种情况，INTEL从Katmai核心也就是PIII开始引进了一系列的SIMD指令集，用来完成并行多指令数据的吞吐工作，这就是我们今天看到的SSE。
SSE指令集结构
SSE的出现代表了浮点指令集正式进入历史舞台，并行吞吐浮点指令的引入极大地提升了CPU的单位周期执行能力，也提高了寄存器资源的利用效率。
随着技术的进步，SSE开始有了自己的专用高速寄存器，通过对寄存器的高速操作，很多过去使用X87缓慢进行的浮点运算和处理过程现在可以成倍甚至几十倍的提速。
一时间指令集成了提升浮点性能的不二法门。
产品：
OntarioC-30APUAMDCPU
矛盾：
兼容指令集的应用
●矛盾：
兼容指令集的应用
SSE出现的时代，AMD拥有自己的浮点指令集3DNOW!
，这个指令集出现在MMX之后，它极大地弥补了MMX本身只具备整数处理能力的不足。
3DNOW!
曾一度成为AMD引以为傲的特色技术，但随着时间的推移，SSE无论是功能还是性能方面逐渐超越了3DNOW!
，这使得AMD不得不在自己的CPU中兼容了SSE指令集。
支持3DNOW!
指令集的K6-2
兼容SSE这件事本身做起来并不难，SSE是针对IA-32的X86扩展指令集，将SSE纳入自家CPU，这对使用标准X86结构的AMD来说没有任何技术上的困难。
AMD和INTEL以及其他厂商之间存在广泛的交叉授权协议，对SSE的兼容和使用在法律层面上也没有太多值得顾忌的地方。
INTEL辛辛苦苦搞出来的指令集，就这么被AMD不费吹灰之力的吸收了。
兼容SSE2的Athlon64
不费吹灰之力？
你以为INTEL是大头么？
指令集作为一组扩展IC，想要使用就必须有针对性的软件优化，同时还要在编译器和开发工具中添加对新指令集操作的支持。
只有借助编译器的翻译，常规程序才可以从代码转变成指令并被指令集所吞吐。
如果没有编译器和整合型开发工具，程序员们要想利用指令集就必须引用外源目的码或者自己编写inline-assembly，这极大地增加了编程复杂度和难度。
SSE刚刚发布时，没有任何一款编译器对其进行了支持，直到INTEL自己发布了VisualC++ProcessorPack，才算是在编译器和开发工具端实现了对SSE系列指令集的支持，各种针对SSE优化的软件也雨后春笋版得涌现出来了。
SSE优化示例
很奇怪吧，为什么是INTEL发布了编译器之后SSE指令集才得到了业界的支持呢？
这就是一切恩怨的起点——因为AMD在windows环境下没有业界广泛认可并应用的编译器。
产品：
OntarioC-30APUAMDCPU
阿喀琉斯的脚踝
●阿喀琉斯的脚踝
诚然，无论是技术上还是法律上，AMD希望将SSE引入到自己的CPU中都没有任何问题。
这就好像刀枪不入的阿喀琉斯，只要他愿意前进，想要阻止他几乎是不可能的。
但是这世界上并不存在绝对的事情，阿喀琉斯和AMD都不例外，他们都有自己的弱点。
阿喀琉斯也是有弱点的
在硬件上兼容了SSE并不意味着一切事情都结束了，前面我们提到过，要让程序使用新的指令集，编译器和开发工具的支持，尤其是编译器的支持是必不可少的。
AMD的脚踝，就在于它没有在windows环境下被广泛接受和采用的编译器。
没有自己的编译器，要想让硬件动起来就必须使用别人的开发的东西，在硬件对软件的最底层接口上使用了自己竞争对手的方案，谁都会想到会有什么后果的。
INTEL显然不是冤大头，会眼睁睁的看着AMD一分钱都不花就拿走自己的劳动成果，于是很自然的，INTEL将眼光投向了编译器。
为了能够得到最好的硬件兼容性和执行效率，INTEL的编译器会针对不同的SSE版本产生不同的代码片段，具体的SSE版本与硬件也就是CPUID直接挂钩，通过对CPUID的识别，编译器可以准确的判断出当前执行环境下的CPU可以执行怎样的代码。
编译器对硬件的逐层识别
对CPUID的识别可以通过CPUSpecified和General两组开关进行实施，前者会精确判断CPU型号并采取不同的生成对策，后者则仅关注甚至不关注当前硬件的SSE版本。
从精确优化的角度出发，使用CPUSpecified似乎是合理的。
他可以依据不同的CPU型号精确地控制编译器生成适应性最强的指令供硬件执行，这在最大限度上杜绝了错误版本的SSE代码流入无法执行的硬件中。
恩，没错，非常合理，简直天衣无缝了。
因为这种判断，本身还能筛选出所有的非INTELCPU。
被限制的SSE性能（图片来自网络）
截止到2009年底双方达成反托拉斯和解之前，INTEL一直在CPUSpecified中使用“W开关”，“N开关”和“P开关”3种不同的判断模式，分别对应SSE，SSE2以及SSE3。
在相当长的一段时间内，ClawHammer至Winchester核心的所有K8处理器虽然均支持SSE2，但在编译器环境下会被识别出来并应用W开关，Venice核心之后的K8处理器也得到了相同的待遇，虽然都支持SSE3但仅能在编译器环境中使用N开关。
这极大的影响了AMDCPU在不少场合的应用效率，使得ClawHammer和Venice在与NorthWood和Prescott的竞争中，起码在编译器优化领域处于了下风。
产品：
OntarioC-30APUAMDCPU
我要咬破那无边的黑暗
●我要咬破那无边的黑暗
尽管在2009年12月，AMD和INTEL就编译器方面的问题达成了反托拉斯和解，之后的INTELC++编译器组件将不再通过CPUSpecified对AMD产品进行限制，但是之前数年的遭遇如同梦魇一般萦绕在AMD的心头。
编译器带来的性能损失不仅损伤了AMD的市场形象，甚至曾经让AMD背负起了“兼容设计不利”以及“提供有BUG的不完整指令集”这样莫须有的罪名。
备受影响的AMDCPU性能
要寻求突破，就要在底层彻底摆脱对竞争对手的依赖。
方式无非有两个——推出业界广泛接受并足以撼动INTEL统治地位的编译器，尤其是windows环境下的编译器；或者推出强过SSE，起码不再仅仅是完全兼容SSE的指令集。
推出整个业界都认可的windows环境下的编译器是一件极其困难的事情，事实上由于第一款X86构架就是INTEL设计的，其他公司长期以来所生产的全部体系都是对X86构架的兼容产品，所以从X86诞生的第一天起，适应构架的编译器的游戏规则就是由INTEL制定的。
X86的鼻祖——8086
在长达30余年的历史中，INTEL已经通过11代编译器牢牢地抓紧了整个业界。
想要打破这种近乎绝对的统治地位，AMD肯定要付出艰巨而漫长的努力，与PortlandGroup合作开发新的编译器的动作就是这漫长努力中的一小步。
这种努力所需要的时间跨度是如此之大，以至于眼下还完全看不到哪怕一丝一毫的成功的希望和苗头。
于是，改变现状的重担落在了相对来说更加现实而且更加偏重于硬件设计的方向，也就是指令集结构的改变上。
死胡同？
●死胡同？
AMD曾经以3DNOW!
震惊了整个业界，甚至获得了大商人微软在DirectX7当中的全面支持。
其强劲的性能和当时极为先进的理念不仅使得K6处理器大幅提升了本来非常羸弱的浮点处理能力，更直接惊醒了INTEL并促成了SSE指令集的诞生。
3DNOW!
是如此的成功，成功到让INTEL在指令集领域倾注了大量的心血和研究资源，这直接导致了历代SSE的发展都非常严谨系统。
从SSE2的64bitSIMD吞吐到SSE3的thread-handling多线程管理，再到SSE4的向量数据运算以及引入更多先进的操作方式，SSE的发展甚至到了密不透风的地步。
SSE指令集发展历程
这种不留余地的发展模式加上INTEL的大力推广所带来的直接结果，就是SSE指令集本身的大行其道以及其他指令集发展的举步维艰。
为应对SSE指令集，AMD曾经在3DNOW!
的基础上通过新指令的扩展形成了Extended3DNOW!
。
但由于双方的资金规模和所能够耐受的最大投入量相差实在过于悬殊，最终AMD选择将相对有限的资源投注到X86-64指令集的研究领域，在SIMD指令集方面则直接兼容INTEL的后代SSE。
应该说AMD在SIMD指令集领域的遭遇都是这个决策所导致的。
取得成功的X86-64
这个世界是平衡的，当你得到很多东西的时候，所付出的代价一定也是不菲的。
X86-64指令集最终取得了完全的成功，但它也直接使得AMD丢掉了几乎整个SIMD指令集领域。
意识到问题所在的AMD开始寻求突破，着手改进SSE显然是一条不错的出路。
但严防死守的INTEL显然没有给AMD留下多少可供改进的余地，截止到SSE4.0为止，AMD推出的SSE4A仅仅是删除了SSE4中与IA64相关的内容，所谓的“改进”几乎完全没有出现。
AMD毕竟离开SIMD指令集领域太久了，想要完全上手并通过投注更多的资源开创一番新的天地，对目前这种经营状态下的AMD来说显然是力不从心的。
只能选择继续支持SSE的AMDCPU
编译器层面不能尽快突围，指令集设计层面又找不到突破口，甚至因为经营环境等其他外界因素，连可用的研究资源都变得不再充裕。
难道困境中的AMD要掷子投降了么？
产品：
OntarioC-30APUAMDCPU
上帝拯救那些自救的人
●Godhelpsthosewhohelpthemselves
我们前面提到过，对于一个科技企业来说，方向的迷失是最为可怕的问题。
任何的外部压力和阻碍都可以解决，但来自内部自身的迷茫却没有任何人可以帮忙。
好在AMD并没有迷失自我，即便在最黑暗的时刻，桑德斯留下的斗士精神依旧激励着他们不断地寻找突破口。
硅谷斗士：
杰里桑德斯
上帝是仁慈的，他创造了分久必合合久必分的真理，他还会主动拯救那些自救的人们。
在经历了缓慢艰难的消化过程之后，AMD终于开始系统的整理和审视源自收购ATI得来的各种资源和科研成果。
于是，一个巨大的闪着金光的机遇被上帝摆在了AMD面前。
自从彻底独立出CPU之后，经历了十余年发展的GPU的结构早已经今非昔比。
海量的ALU和高速低延迟直连总线造就的庞大带宽使得GPU变成了一台恐怖的吞吐机器。
尤其是ATI的R600构架，其本身的US结构就是天然的SIMD设计，US内部的ALU具备完整的指令和操作的执行能力，而且扩展极为方便，在单纯的吞吐领域，这种GPU足以产生令CPU望而生畏的暴力浮点运算能力。
R600的SIMDCORE
SIMD，暴力吞吐，暴力浮点运算能力，看着眼熟么？
SIMD指令集的初衷，就是通过并行吞吐和执行来提升CPU的浮点处理能力。
SIMD指令集的使用，只需要得到编译器的支持和优化即可。
从结局来看，它跟GPU中的ALU所做的事情其实是一样的，GPU的ALU团簇可以通过自己的暴力吞吐能力和运算和执行能力轻松地处理掉CPU无法应付或者需要靠SIMD来面对的海量数据。
更加令人振奋的还在后头呢——对ALU团簇的使用所需要的编译器来自微软，也就是说对GPU在运算中的使用在目前看来几乎不会受到来自INTEL的直接干扰。
伴随着AMD对ATI的收购，漂泊在外多年之后的GPU，带着上帝的宽仁和慈爱，在AMD最需要的时候带着它最需要的东西回来了。
产品：
OntarioC-30APUAMDCPU
雪中送炭的ComputeShader
●雪中送炭的ComputeShader
尽管海量的ALU以及解决指令集问题的曙光同时出现在了AMD面前，但想要真正等来黎明，前面还有一段不得不面对的黑暗。
R600是符合DirectX10设计的GPU，其ALU所能够执行的数据类型也深深的带上了DirectX10的图形烙印。
R600所能够执行的代码必须具备完整的几何关联性。
这种繁冗的几何关联性问题导致了符合DirectX10要求的ALU并不能随心所欲的被使用，代码格式的限制以及寄存器资源的特定要求成了横亘在AMD面前的一座大山。
传统结构的shader指令
人们都说锦上添花并不能体现价值，雪中送炭才是最重要的。
商人微软是重要的，因为它对API的更新成了雪中送炭。
我们在《曝你不知道的DX11解析GPU通用计算妙用》中已经进行了相关的描述，在DirectX11中，微软进行的最具革命性的创新就是引入ComputeShader。
ComputeShader是一种纯数学形式的代码，它不仅可以结合延迟操作模式和树状结构方便的进行线程间的大并行度管理，实现跨指令的数据共享，快速的实现各种通用计算应用，而且取消了代码形式上对几何过程的强制关联。
CS应用实例——hiz
直接数学代码的引入，意味着程序员们可以以平时面对CPU时所惯用的自然编程方式和手段，直接利用符合DirectX11要求的ALU进行常规的浮点数据吞吐、运算和操作。
使用ComputeShader格式的代码可以同时被CPU和GPU处理，只要CPU和GPU之间存在某种直接的快速联系，ComputeShader代码便可以被微软的编译器拆解成适用于CPU和GPU的指令格式分别输送到各自的流水线中进行处理。
这使得很多过去在CPU上即便借助指令集仍然执行缓慢的应用，比如AI控制、超大并行吞吐以及逆向运动学分析等得以实践。
简单地说，透过ComputeShader，CPU和GPU被紧密的联系在了一起，在ComputeShader代码面前，他们将一视同仁的成为平等的执行单元。
产品：
OntarioC-30APUAMDCPU
融合的谜底，AMD的最终武器
●融合的谜底，AMD的最终武器
现在，我为什么会说AMD的APU绝不仅仅至于低功耗高集成度的廉价解决方案这么简单，为什么AMD会如此急迫的迅速推出一个仅仅是迎合和堆砌，完全看不到任何图形构架创新的RV870，为什么融合一定要等到DirectX11GPU出现，屏幕前的你应该都明白了吧。
落后
升级会员 