POPPUR爱换

 找回密码
 注册

QQ登录

只需一步,快速开始

手机号码,快捷登录

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

NVIDIA 下一代架构"Fermi" 猜测、讨论专题

 关闭 [复制链接]
201#
发表于 2009-5-23 02:59 | 只看该作者
就是因为SM 4.0所以才导致了现代GPU设计就是一个怪胎。所谓的GPU上有大规模并行计算单元,其实是一种很不好的体系结构。 SM3.0 以后厂商基本上就被微软牵着鼻子走了。
ic.expert 发表于 2009-5-18 19:28


我可以理解成"unified shader是個不好的設計"嗎。
回复 支持 反对

使用道具 举报

202#
发表于 2009-5-23 03:24 | 只看该作者
:〉US是一个好的设计思想,也绝对是未来的趋势。但是如何US,这个还需要进一步商榷。反正SM4的方式我不那么苟同~~
回复 支持 反对

使用道具 举报

203#
发表于 2009-5-23 11:36 | 只看该作者
本帖最后由 Eji 于 2009-5-23 11:37 编辑
:〉US是一个好的设计思想,也绝对是未来的趋势。但是如何US,这个还需要进一步商榷。反正SM4的方式我不那么苟同~~
ic.expert 发表于 2009-5-23 03:24


因為我正在思考NV50和NV40比起來沒什麼好處這件事情,最後就變成要用NV40為基礎做US....
這時候要避開哪些NV50作的事情,才能夠保留NV40的好處....不過想一想還真搞不清楚。

可能要請學界大老來解釋一下了吧,想想我也是個對stream computing理解得很差的人。_A_
希望那些大老來別每個都送去植牙了。
回复 支持 反对

使用道具 举报

204#
发表于 2009-5-23 23:55 | 只看该作者
本帖最后由 ic.expert 于 2009-5-24 02:06 编辑

这个说起来恐怕不是一个帖子能解决的,这几个月我正写一篇一万多字的文章来解释这个事情。写出以后来希望楼上等大牛来指正。简单说以下,对于Pixel Processing大致分三个发展阶段。

第一个阶段是Fixed Function时期,这些传统的Graphics Pipeline都是利用Attribute Interpolation出来的Texture Address来Prefetch Texture然后来计算Fragment颜色的。这个过程可以简写为“Texel Addr Generation-〉 Texel Fetch -〉 Fragment Processing “

第二个阶段是SM1/2时期,随着Shader的出现,用户可以在Shader Program内部计算Texel Address并且多次Texel Fetch,由于有限的指令数量,所以甚至Shader Program可以利用静态跳转。这种Pixel Processing Programming Model出现以后,就意味着需要多次LOOP  “Texel Addr Generation-〉 Texel Fetch -〉 Fragment Processing”这个过程。这就对硬件复杂度提出了新的要求。

第三个阶段是SM3时期,由于PS内部允许Branch这种Dynamic Control Flow的特性,所以这就需要上述那个Loop的过程是一个动态过程。SM3有个好处在于Subroutine和branch的数量都是有限的。并且Shader Program总的指令数量也是有限(不是Shade动态执行的指令数量阿,是Shader静态包含的指令数量)。所以这种prefetch -based Architecture还可以有效的给与支持!

但是在SM4时代,可以说除了少量的Fixed Function,整个Graphics Pipeline都沦陷了~ 由于MS过于强调灵活性,使得我们很难使用Prefetch -based Architecture来支持SM4。而基于TLP的Shader Unit势在必行,这也就是NV50上那些复杂度和功耗都处于怪兽级别的计算单元的由来……。而Prefetch-based Arch就是Stream Processing思想在Graphics Architecture中的最好的体现之一。

人们就是这样,很多人被一种统制压抑了很久之后,总是迫不及待的投向另一个统制,而不会过多的关心和反思这种改旗易帜合理与否,这一点在Fixed Function向Programmable转变的过程中体现的尤为明显。其实改朝换代的只是一个机会,是机会就会有风险和代价,不加思索的全盘否定过去其实是一种盲动,所以随着SM4这种无限强调灵活性的规范出现,并逐渐统制了GPU Architecture。GPU在功耗和复杂度方面的矛盾以及代价逐渐显露了出来。并且未来最终会到达一个无法调和的程度。但是现在木已成舟,所有的应用都会照着SM4来写,要想改朝换代江山易主也不是那么容易的事情。当然,这也不是说NV40就比NV50要好,NV40在灵活性上的确有很大问题,改进是必须的!所以未来如何反攻Graphics并且光复这片沃土,还需要硬件和软件厂商做很多事情。
回复 支持 反对

使用道具 举报

RacingPHT 该用户已被删除
205#
发表于 2009-5-25 09:44 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

RacingPHT 该用户已被删除
206#
发表于 2009-5-25 10:11 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

207#
 楼主| 发表于 2009-5-25 12:12 | 只看该作者
DX10 规格放在那里,但是如何实现就是另一回事情了,同代的 gt200 vs rv770,大家都认为 RV770 在成本、性能、功耗上的平衡很不错,所以关键还是芯片设计师的考量。
回复 支持 反对

使用道具 举报

208#
发表于 2009-5-25 18:45 | 只看该作者
本帖最后由 ic.expert 于 2009-5-25 19:39 编辑

楼上说的很对。权衡就是体系结构工程师的事情,其实R6/7XX很大程度上参考了Imagine的设计,当然,由于Imagine从底层并不匹配SM4的编程模型,所以AMD做了很大的改进,效果是明显的,性能/(瓦特*面积)有效的降低了。如果不是SM4碍事,还可以有更显著的提高(当然,AMD也被迫放弃了Prefetch-based Arch,这从开放的文档就可以看出来,而且放弃的比NV更彻底。不过AMD又用了其他的几乎来弥补这方面的损失)。但是NV则沿着SM4的思路在设计,一切都是靠TLP外加强大的Texture Cache,这种靠电路动态调度的机制在性能上的确不错,但是在效率上很有待商榷。我并没有说SM4弱化了Graphics Pipeline,即便是在DX11里面Graphics Pipeline也是很健壮的存在的,我只是想说功耗的主要贡献在于Hierarchical Storage Structure和Shader机制。虽然低功耗多核心的体系结构比比皆是,但是SM4让我们几乎没有选择……


We have no Choice but to do so……


所以从这个角度来说,还是OGL的Shader Language这种规范的风格稍微好一些,不规定Shader虚拟机的ISA,只要满足了高级语言特性底层可以任意设计。当然,我也不是说OGL好,我只是想说这种行为级规范的风格比较好:〉
回复 支持 反对

使用道具 举报

RacingPHT 该用户已被删除
209#
发表于 2009-5-26 10:57 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

210#
发表于 2009-5-27 14:55 | 只看该作者
感觉GT200还是想暴力撑过这一代,真正的进步在GT300。
基本上,以双倍摩尔速度来运行,只能这样。

2代革命一次,中间加一次暴力。
D65 发表于 2008-7-21 21:36

顶这个,见解独到
回复 支持 反对

使用道具 举报

211#
发表于 2009-5-27 16:28 | 只看该作者
从GT300现在暴出的规格来看也只是GT200的翻倍而已~~
回复 支持 反对

使用道具 举报

212#
发表于 2009-5-30 03:46 | 只看该作者
本帖最后由 Eji 于 2009-5-30 14:26 编辑
不是在抬杠,我这个软件工程师真的不大明白DX10的"Hierarchical Storage Structure"是说哪一部分。还望指教。另外"当然,AMD也被迫放弃了Prefetch-based Arch,这从开放的文档就可以看出来"是那一块文档?我也很有兴 ...
RacingPHT 发表于 2009-5-26 10:57


如何放棄Prefetch based arch老實說我也看不太出來。XD
prefetch是真的變得比較低重心,這兩邊都往TLP走了沒錯,
不過我以為視task,prefetch還是會頗有效率,要說"放棄prefetch-based"有點言過不是?
還是說這是在講"嚴格的stream-processing"?
追記:去補了一點Imagine的架構,稍微理解了一些部分。

----
programming上的Hierarchical Storage Structure是指Cubic Texture Array?
回复 支持 反对

使用道具 举报

213#
发表于 2009-5-30 18:18 | 只看该作者
本帖最后由 ic.expert 于 2009-5-30 18:25 编辑

解释一下,Prefetch Arch主要是从Fixed Function时代继承过来的。指,通过一些缓存技术来隐藏访问Vetex和Texture的延迟。这方面论文很多,最有名的是下面这个Arch。当然,这里仅仅是Tex部分,而Vertex部分也是同样的。



可以看出这就是一个Stream Processing的过程。的确,只要是Stream的东西当然也可以TLP,不过TLP的硬件代价往往比Stream的硬件代价要大不少。不然,像Imagine那种东西为什么能够简化设计降低功耗,原因从何而来?

关于,Hierarchical Storage Structure具体可以查阅《计算机体系结构:量化方法》的第五章。大陆方面的翻译是“层次化存储机制”,从Register files到System Memory都属于层次化存储得范围。Stream相比TLP,应用领域要小很多,但是相对于TLP,Stream更好的优化了存储访问的结构,从而给降低功耗和复杂度提供了很大的帮助。而以往的Graphics应用就是一个Stream的过程,可以很好的匹配,但是SM4上,这些特性大的被弱化了。有人说,我们这样做是为了Post-processing等特性。其实如果对数字图像处理以及模式匹配稍有了解的人都知道,这两个领域广泛了使用了DSP,而DSP的编程模型是什么?赫赫~其实为了达到同样的效果,DX大可以不必以这种方式体现“灵活”。


顺便说一句,微软在DX上的开放与民主是属于“人民民主”,而不是“资产民主”~~赫赫

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?注册

x
回复 支持 反对

使用道具 举报

214#
发表于 2009-5-31 13:23 | 只看该作者
看不太懂
回复 支持 反对

使用道具 举报

215#
发表于 2009-5-31 16:38 | 只看该作者
本帖最后由 Eji 于 2009-5-31 16:39 编辑
解释一下,Prefetch Arch主要是从Fixed Function时代继承过来的。指,通过一些缓存技术来隐藏访问Vetex和Texture的延迟。这方面论文很多,最有名的是下面这个Arch。当然,这里仅仅是Tex部分,而Vertex部分也是同样的 ...
ic.expert 发表于 2009-5-30 18:18


喔,也就是指過去那種pipeline stage來隱藏延遲的方法。
這好處是半導體cost低廉,壞處就是無法對應kernel swap,因為flush out代價非常大....
也就是說,ic.expert兄的意思是,其實DX9/10開始引入dynamic branch這個特性,
本身是一個影響stream processing性質的,一個大幅增加成本的不好的決策?
因為NV40其實除卻一些靈活度上的小折衷(而且願意的話可以輕易補上),
本身最大的影響就是dynamic branch的對應能力,因為還屬於pipeline stage式的隱藏法,所以這方面的性能並不好。

而G80就變得一口氣往TLP走了,規模也一口氣大了許多....
而後頭又提到DSP的example,也就是說維持前面stream processing的model,照樣可以實現這些靈活性。
於是就變成"DirectX導入這些做法加上政策,結果大家只能朝TLP的方向走,半導體成本和發熱量就開始一路攀升",這是ic.expert兄的意見對吧?
回复 支持 反对

使用道具 举报

216#
发表于 2009-5-31 23:42 | 只看该作者
本帖最后由 ic.expert 于 2009-5-31 23:53 编辑

“於是就變成"DirectX導入這些做法加上政策,結果大家只能朝TLP的方向走,半導體成本和發熱量就開始一路攀升”
------------------------------------------------------


差不多这意思把,不过Branch在Imagine上面也可以使用阿,这不是特别关键的地方。最关键是“访存”和“计算”的粒度,TLP的访存粒度太小,但是Stream都是大尺寸的访存粒度。并且计算上Stream也强调,一次取更多的数据,然后进行长时间计算,再和内存器交换数据。而不是TLP那种一小口一小口的在计算并且吞吐数据到存储器上。不过TLP的确更加灵活,但是代价就是硬件成本的飙升。

这方面和CPU上OOO比In-order Pipeline要在硬件开销方面大的原因类似。OOO+Superscacler的在乱序执行的同时主要解决了WAW和WAR Dependency,从而提高了IPC(即,开发了ILP),但是却增加了硬件代价。但是如果硬件本身寄存器数量足够多,一条指令操作数以及操作码足够多,比如VLIW那样,就能有效减少OOO+Superscacler所带来的硬件代价和功耗。(这里就不深入展开VLIW的RF Write/read Port等问题了)。但是灵活性受到制约。所以一般VLIW更多用在高性能的DSP领域,而不是针对跑OS的通用计算。(当然,也有Transmeta等X86实现,这里我就不展开了)。

不同的应用领域要求不同的硬件和编程模型,DX如此Tradeoff图形编程接口,我还是持有保留意见。
回复 支持 反对

使用道具 举报

217#
发表于 2009-6-1 08:58 | 只看该作者
可以读读下面这个论文,附件太小,我传送不上来。

其实都是拉姆达表达式在图灵机上的变种,赫赫。

Compilation for Explicitly Managed Memory Hierarchies
回复 支持 反对

使用道具 举报

RacingPHT 该用户已被删除
218#
发表于 2009-6-1 11:36 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

RacingPHT 该用户已被删除
219#
发表于 2009-6-1 11:44 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

RacingPHT 该用户已被删除
220#
发表于 2009-6-1 11:47 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

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

本版积分规则

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

GMT+8, 2025-8-29 06:56

Powered by Discuz! X3.4

© 2001-2017 POPPUR.

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