POPPUR爱换

标题: Fermi部分纸面规格(和游戏有关)与RV870对比 [打印本页]

作者: shu0202    时间: 2009-12-2 12:27
标题: Fermi部分纸面规格(和游戏有关)与RV870对比
Fermi                                 Cypress

4200MHz@384bit               4800MHz@256bit
48ROP                                32ROP
31.2G/sROP速率           27.2G/sROP速率
83.2G/s像素填充           68G/s像素填充

综合判断相同频率下G300的纹理性能是G200的1.6倍,相比RV870有微弱优势。
作者: 0阿诺0    时间: 2009-12-2 12:30
本帖最后由 0阿诺0 于 2009-12-3 12:50 编辑

没出来呢 不保准啊。。等出来了在看看
现实里的40nm卡只有240
各网站测试
秒杀一切4670的存在
作者: 大草原赶羚羊    时间: 2009-12-2 12:52
一切...等出来在说..
作者: iamspy    时间: 2009-12-2 13:01
Fermi完整版绝对不会4200的显存的.按NV的习惯,肯定是5200-5600
作者: 绿色世界    时间: 2009-12-2 13:03
提示: 作者被禁止或删除 内容自动屏蔽
作者: zxjike    时间: 2009-12-2 13:03
提示: 作者被禁止或删除 内容自动屏蔽
作者: sagecao    时间: 2009-12-2 13:07
凭借无敌的物理加速引擎,完秒A卡5系了.......
作者: banner    时间: 2009-12-2 13:08
LZ头像是谁啊………………
作者: sonicgoboy    时间: 2009-12-2 13:40
12颗显存估计整卡成本和g200差不多
作者: Asuka    时间: 2009-12-2 13:43
Fermi                                 Cypress

4200MHz@384bit               4800MHz@256bit
48ROP  ...
shu0202 发表于 2009-12-2 12:27


这就可以看出纹理性能?
作者: gz_easy    时间: 2009-12-2 13:58
TMU个数呢?
作者: westlee    时间: 2009-12-2 14:04
提示: 作者被禁止或删除 内容自动屏蔽
作者: Buffer    时间: 2009-12-2 14:07
楼主头像大图呢?
作者: tomsmith123    时间: 2009-12-2 14:21
回复 1# shu0202
SP 相同频率?那肯定会差一些,如果是GPU 主频,那会强很多。
作者: airforce18    时间: 2009-12-2 14:27
TMU数量没哦~~~~
作者: 苯苯小哥    时间: 2009-12-2 14:30
看不懂呀 什么频率相同啊 显存?  核心? 着色器?
作者: nukualofa    时间: 2009-12-2 14:44
貌似现在唯一能确定的就是384bit GDDR5 512SP 吧
核心/显存/流处理器频率都是最后确定的,根据当时的工艺改进和发热/能耗情况来调整的
作者: aibo    时间: 2009-12-2 17:10
在某处看到的,也许只是YY

[attach]1170784[/attach]
作者: knightmaster    时间: 2009-12-2 17:26
楼主科普一下你的纹理数据在那里
作者: 绿色世界    时间: 2009-12-2 17:28
提示: 作者被禁止或删除 内容自动屏蔽
作者: goldman948    时间: 2009-12-2 19:41
性能是可以用想像的
作者: 1101    时间: 2009-12-2 21:51
用下半身造数据来扮油料。。。
作者: terracai    时间: 2009-12-2 22:39
费米再差也比5870好,NV出道以来唯一失败的核心是NV30!
qf1919 发表于 2009-12-2 20:00


论据呢?论据是什么东西,能吃么?

                                                     --Asuka
作者: shu0202    时间: 2009-12-3 09:57
频率方面A2版本就基本能确定下来,我列出的数据基于比较理想的状态,实际上没这么高,甚至某些数值比不上RV870。A3版本目标就是提升良率。
Fermi的双精度计算追求从管线利用到内存带宽利用对游戏运算都是有负面影响的。G80那样的单位运算效能不会再出现了。
作者: Asuka    时间: 2009-12-3 09:58
频率方面A2版本就基本能确定下来,我列出的数据基于比较理想的状态,实际上没这么高,甚至某些数值比不上RV870。A3版本目标就是提升良率。
Fermi的双精度计算追求从管线利用到内存带宽利用对游戏运算都是有负面影响的。G80那样的单位运算效能不会再出现了。
shu0202 发表于 2009-12-3 09:57

比如?
作者: philonb    时间: 2009-12-3 10:02
我觉得性能不会差
就是时间不等人
作者: shu0202    时间: 2009-12-3 10:08
Fermi管线中有专门负责双精度运算的DP向量单元,运行目前的游戏它不能被充分利用;未来光线追踪游戏也许会采用双精度算法,全速运转的DP单元会占用几乎所有数据资源,管线中另外的普通运算单元又会闲置。
ECC机制遍布于缓存和内存控制当中,当然要占用带宽而导致实际带宽降低……
作者: gz_easy    时间: 2009-12-3 10:12
ECC启用时占用相当一部分的显存容量。
作者: jhg1159    时间: 2009-12-3 10:50
本帖最后由 jhg1159 于 2009-12-3 11:07 编辑

按G200B频率512SP 128TMU 48ROP得出来的?
作者: shu0202    时间: 2009-12-3 11:21
按G200B频率512SP 128TMU 48ROP得出来的?
jhg1159 发表于 2009-12-3 10:50

比这个频率要高不少……感觉G300在频率上还是可以设得比G200高一些……
作者: jhg1159    时间: 2009-12-3 11:37
650 1700  4200(?)
作者: Edison    时间: 2009-12-3 11:42
Fermi管线中有专门负责双精度运算的DP向量单元,运行目前的游戏它不能被充分利用;未来光线追踪游戏也许会采用双精度算法,全速运转的DP单元会占用几乎所有数据资源,管线中另外的普通运算单元又会闲置。
ECC机制遍布于缓存和内存控制当中,当然要占用带宽而导致实际带宽降低……


Fermi 的双精度单元和单精度单元是共享式的设计,GT200 和 Cell SPE 的双精度单元才是独立式的设计。

Fermi 跑游戏的时候,不会对内存使用上 ECC,此时也就不存在带宽、容量占用问题。
作者: zxjike    时间: 2009-12-3 11:43
提示: 作者被禁止或删除 内容自动屏蔽
作者: jhg1159    时间: 2009-12-3 12:02
本帖最后由 jhg1159 于 2009-12-3 12:05 编辑

着色器频率对功耗影响较小
着色器与核心频率比值还得看设计因素
性能估计还是拿GTX 295 OR GTX285 SLI  做对比
作者: anolen01    时间: 2009-12-3 12:25
Fermi 的双精度单元和单精度单元是共享式的设计,GT200 和 Cell SPE 的双精度单元才是独立式的设计。
...
Edison 发表于 2009-12-3 11:42


共享设计的双/单精度单元效率能维持独立的双精度or单精度单元的效率嘛?

缓存和寄存器的ECC/nonECC切换是否需要额外的控制单元消耗?
作者: shu0202    时间: 2009-12-3 12:33
Fermi的管线应该是分成两部分,一部分用于单精度运算,另一部分则是二者兼顾,而在双精度运算时,前者应该事闲置的。并且双精度运算单元进行单精度运算时速度并不能加倍……
作者: Edison    时间: 2009-12-3 12:55
Fermi的管线应该是分成两部分,一部分用于单精度运算,另一部分则是二者兼顾,而在双精度运算时,前者应该事 ...
shu0202 发表于 2009-12-3 12:33


它们是一体的,只是单元本身的芯片面积增加大约 10%。

AMD 的 RV670、RV770、RV740、RV870 也是类似的设计,但是它们的双精度浮点单元功能不如 Fermi,只能执行 add/mul,而 Fermi 是 FMA。
作者: shu0202    时间: 2009-12-3 13:04
它们是一体的,只是单元本身的芯片面积增加大约 10%。

AMD 的 RV670、RV770、RV740、RV870 也是类似 ...
Edison 发表于 2009-12-3 12:55

受教了……我感觉Fermi大力提升双精度运算能力的重点是资源配置上更加充分,特别是一体化的L2,只是对游戏来说很浪费……
作者: Edison    时间: 2009-12-3 13:31
L2 cache 对于寄存器溢出、游戏物理计算上会有非常大的助益。
作者: zxjike    时间: 2009-12-3 13:37
提示: 作者被禁止或删除 内容自动屏蔽
作者: 1101    时间: 2009-12-3 13:41
Fermi管线中有专门负责双精度运算的DP向量单元,运行目前的游戏它不能被充分利用;未来光线追踪游戏也许会采 ...
shu0202 发表于 2009-12-3 10:08
Fermi的管线应该是分成两部分,一部分用于单精度运算,另一部分则是二者兼顾,而在双精度运算时,前者应该事 ...
shu0202 发表于 2009-12-3 12:33



是凭幻觉产生的规格进行对比的么?
作者: Edison    时间: 2009-12-3 13:46
30亿+的晶体管默认SP频率跑到1700,老大你相信吗?
这样单双精度和NV官方数据差距太大了不说,以现在的良 ...
zxjike 发表于 2009-12-3 13:37


NVIDIA 没有公布游戏卡版本的规格,但是应该和 Tesla 20 差不多。
作者: zxjike    时间: 2009-12-3 13:52
提示: 作者被禁止或删除 内容自动屏蔽
作者: jhj9    时间: 2009-12-3 13:55
嗯,我也觉得不可能差距太大,理论说Tesla 版本应该是最优秀的核心吧?差不多Tesla 能达到的频率也就是游 ...
zxjike 发表于 2009-12-3 13:52



Tesla版本有ECC支持的问题,而Geforce版本没有
别忘了这一点
作者: westlee    时间: 2009-12-3 13:55
提示: 作者被禁止或删除 内容自动屏蔽
作者: zxjike    时间: 2009-12-3 13:58
提示: 作者被禁止或删除 内容自动屏蔽
作者: jhj9    时间: 2009-12-3 14:00
现在看来,这个ECC对SP频率会不会有影响还是未知数,个人估计只是对显存的速度和延迟影响更大一些吧。
zxjike 发表于 2009-12-3 13:58



Cache都存在ECC问题,这个不可能不影响核心吧?
作者: gz_easy    时间: 2009-12-3 14:03
L2 cache 对于寄存器溢出、游戏物理计算上会有非常大的助益。
Edison 发表于 2009-12-3 13:31

我觉得L2 cache对于加速shader指令的处理/装载速度会有帮助,但对图形性能不一定有大的帮助,图形性能基本都在像素处理上;处理所有像素之前,shader指令只装载一次就好了,接下来就是等待像素处理。请E大指教。
作者: zxjike    时间: 2009-12-3 14:08
提示: 作者被禁止或删除 内容自动屏蔽
作者: jhj9    时间: 2009-12-3 14:16
GPU内存Cache的ECC如果关闭的话如何实现我倒是很感兴趣,不大可能设计2款大芯片出来吧?我更倾向于这部分 ...
zxjike 发表于 2009-12-3 14:08



既然显存可以轻易设定甚至很可能自动的判断是否支持ECC,Cache会是难事吗?
做硬件设计的人要这点都考虑不到,还不如别做ECC支持了
作者: zxjike    时间: 2009-12-3 14:24
提示: 作者被禁止或删除 内容自动屏蔽
作者: luckissy    时间: 2009-12-3 14:39
显存可以通过显存控制器轻松实现,现在来看费米的显存不是通过增加显存颗粒来实现的硬ECC,而是通过牺牲显 ...
zxjike 发表于 2009-12-3 14:24


是牺牲显存容量来的 官方已经有说明了开启ECC可使用显存的容量
作者: zxjike    时间: 2009-12-3 14:47
提示: 作者被禁止或删除 内容自动屏蔽
作者: Asuka    时间: 2009-12-3 15:00
Fermi管线中有专门负责双精度运算的DP向量单元,运行目前的游戏它不能被充分利用;未来光线追踪游戏也许会采用双精度算法,全速运转的DP单元会占用几乎所有数据资源,管线中另外的普通运算单元又会闲置。
ECC机制遍布于缓存和内存控制当中,当然要占用带宽而导致实际带宽降低……

shu0202 发表于 2009-12-3 10:08



0202兄还是老样子啊

连自己在说什么都没搞清就急急忙忙下结论
作者: Asuka    时间: 2009-12-3 15:10
我觉得L2 cache对于加速shader指令的处理/装载速度会有帮助,但对图形性能不一定有大的帮助,图形性能基本都在像素处理上;处理所有像素之前,shader指令只装载一次就好了,接下来就是等待像素处理。请E大指教。
gz_easy 发表于 2009-12-3 14:03


GPU multi-threading结构的本质是计算和访存的解耦,on-chip cache是非常重要的一个载体
作者: gz_easy    时间: 2009-12-3 15:37
GPU multi-threading结构的本质是计算和访存的解耦,on-chip cache是非常重要的一个载体
Asuka 发表于 2009-12-3 15:10

解耦关键靠并行计算的程序设计,如果代码里存在高度耦合,再好的构件也没用, 必须为多线程的硬件程序改写代码。
作者: slr    时间: 2009-12-3 15:39
费米再差也比5870好,NV出道以来唯一失败的核心是NV30!
qf1919 发表于 2009-12-2 20:00

都晚了几个月了,再不比5870好还造个费米干什么?
作者: jhj9    时间: 2009-12-3 15:40
解耦关键靠并行计算的程序设计,如果代码里存在高度耦合,再好的构件也没用, 必须为多线程的硬件程序改写 ...
gz_easy 发表于 2009-12-3 15:37



图形渲染天生就是高度并行的
根本不用考虑什么耦合度,Shader指令远远没有x86指令那么复杂,还需要考虑分支预测什么的。
作者: jhj9    时间: 2009-12-3 15:45
显存可以通过显存控制器轻松实现,现在来看费米的显存不是通过增加显存颗粒来实现的硬ECC,而是通过牺牲显 ...
zxjike 发表于 2009-12-3 14:24



如果晶体管不能关掉,2D模式比3D满负载低那么多功耗是如何实现的?
ECC无非是运作方式和部分逻辑电路的开关而已,对于数据传输方式处理不同。
每7个数据包增加1个校验数据包,还是不增加校验包,没那么复杂吧?
作者: zxjike    时间: 2009-12-3 15:55
提示: 作者被禁止或删除 内容自动屏蔽
作者: jhj9    时间: 2009-12-3 16:01
这是最基本的Basic ECC(说实话连Basic ECC都算不上),自然很简单。
标准的ECC是8+1,最后那一位硬件固 ...
zxjike 发表于 2009-12-3 15:55



硬件固化和可以通过硬件来控制关闭,有冲突吗?
SP里面的那些ALU用你的说法也是硬件固化,但2D模式下照样可以关闭省电
作者: zxjike    时间: 2009-12-3 16:08
提示: 作者被禁止或删除 内容自动屏蔽
作者: Asuka    时间: 2009-12-3 16:08
本帖最后由 Asuka 于 2009-12-3 16:10 编辑
解耦关键靠并行计算的程序设计,如果代码里存在高度耦合,再好的构件也没用, 必须为多线程的硬件程序改写 ...
gz_easy 发表于 2009-12-3 15:37



.......你没看懂我说的意思

我是指计算访存两种行为的解耦,这属于硬件级别,和代码没有任何关系

这是如今mulit-threading GPU的基本结构
作者: gz_easy    时间: 2009-12-3 16:28
.......你没看懂我说的意思

我是指计算和访存两种行为的解耦,这属于硬件级别,和代码没有任何关系 ...
Asuka 发表于 2009-12-3 16:08

那么on-chip cache究竟对于提高图形性能方面有哪些贡献?
我理解on-chip cache对于指令cache可以减少分支预测失败的次数,而对于数据cache可以提高数据依赖性的代码的执行效率,变几次内存访问为一次的缓存flush。
作者: 2266889    时间: 2009-12-3 16:38
提示: 作者被禁止或删除 内容自动屏蔽
作者: gz_easy    时间: 2009-12-3 16:40
图形渲染天生就是高度并行的
根本不用考虑什么耦合度,Shader指令远远没有x86指令那么复杂,还需要考 ...
jhj9 发表于 2009-12-3 15:40

但是对于一般的3D game之类的app都不是为multi-threading优化或开发的,数据代码里仍然存在相当高的耦合度,即使专门为多线程GPU写的app, DX可能在里面要做很多支持,multi-threading主要用于计算应用的比较多吧, 但对于3D game之类的app,由于本身的耦合性,用途可能不太大。
作者: 只爱美女    时间: 2009-12-3 16:59
等了这么久,就等到一个强点有限的卡?!!NV想干嘛?!!!
作者: duansindo    时间: 2009-12-3 17:03
呵呵。。。。。。不错。。
作者: Edison    时间: 2009-12-3 17:09
我觉得L2 cache对于加速shader指令的处理/装载速度会有帮助,但对图形性能不一定有大的帮助,图形性能基本 ...
gz_easy 发表于 2009-12-3 14:03


在 GT200 中,每个 SM 有 16K 寄存器,和 8K 寄存器的配置相比,在 3dmark vantage extreme 测试中,提高了大约 12% 的性能。
作者: jhj9    时间: 2009-12-3 17:20
但是对于一般的3D game之类的app都不是为multi-threading优化或开发的,数据代码里仍然存在相当高的耦合度 ...
gz_easy 发表于 2009-12-3 16:40



你连这里说的Multi-Threading是啥意思都没搞清楚,拜托
显卡和CPU是不同的
随便一个渲染对象,比如一个256*256的渲染表面,总共65536个像素都可以同时并行渲染(如果有65536个SP的话),代码耦合度再高,再复杂,只要SP数量够多,只要运行一遍代码的时钟周期就可以把这65536个像素全部渲染出来
显卡的Shader开发天生就是并行度极高的,根本不用什么特别编写,又不是CPU,你还是搞清楚显卡基本的渲染过程,搞清楚基本概念吧
作者: aibo    时间: 2009-12-3 17:22
等了这么久,就等到一个强点有限的卡?!!NV想干嘛?!!!
只爱美女 发表于 2009-12-3 16:59


R600内牛满面
作者: gz_easy    时间: 2009-12-3 17:46
你连这里说的Multi-Threading是啥意思都没搞清楚,拜托
显卡和CPU是不同的
随便一个渲染对象,比如 ...
jhj9 发表于 2009-12-3 17:20

请教Multi-Threading是什么意思?
此外,你说的随便一个渲染对象属于简单化,实际操作不是这么简单,有些需要参考别的图像,像素之间还要做运算。
作者: jhj9    时间: 2009-12-3 17:52
请教Multi-Threading是什么意思?
此外,你说的随便一个渲染对象属于简单化,实际操作不是这么简单,有 ...
gz_easy 发表于 2009-12-3 17:46



不同情况下的意思不一样
要看语境,版主说的是啥意思你可以去请教他
我的理解是不同SP跑Shader时候代码和数据的并行调度
而不是你理解成的CPU那样需要专门改写代码的并行计算
你所谓的“参考别的图像”无非是为了一个渲染流程所需要准备的正常资源而已
对于正在计算中还没算完的RenderTarget自身之间的像素运算正常情况是绝对不会的
这种情况只会做成多个Pass来处理,你有DX9、DX10的开发经验吗?
没有的话,最好不要把CPU那套东西生搬硬套到GPU上,那是不对的
作者: Asuka    时间: 2009-12-3 18:02
但是对于一般的3D game之类的app都不是为multi-threading优化或开发的,数据代码里仍然存在相当高的耦合度,即使专门为多线程GPU写的app, DX可能在里面要做很多支持,multi-threading主要用于计算应用的比较多吧, 但对于3D game之类的app,由于本身的耦合性,用途可能不太大。

gz_easy 发表于 2009-12-3 16:40


GPU的multi-threading不是你理解的那样,也不存在优化问题,它是硬件级别的,不是程序级别的
作者: gz_easy    时间: 2009-12-3 18:08
.......你没看懂我说的意思

我是指计算和访存两种行为的解耦,这属于硬件级别,和代码没有任何关系 ...
Asuka 发表于 2009-12-3 16:08

请问A版,jhj9对Multi-Threading的理解是不同SP跑Shader时候代码和数据的并行调度,这个说法是否正确?或者是否合乎你所指的Multi-Threading?
此外A版所说的Multi-Threading具体含义为何?
作者: 黑仔木木    时间: 2009-12-3 18:18
没出来呢 不保准啊。。等出来了在看看
现实里的40nm卡只有240
各网站测试
秒杀一切4670的存在
0阿诺0 发表于 2009-12-2 12:30



    650以上的价格我都能买4850了
作者: westlee    时间: 2009-12-3 19:11
提示: 作者被禁止或删除 内容自动屏蔽
作者: angeldiy    时间: 2009-12-4 00:42
650以上的价格我都能买4850了
黑仔木木 发表于 2009-12-3 18:18


“新品”上市 都那样啦~~

最终定价应该和9600gt绿色版接近吧~~




欢迎光临 POPPUR爱换 (https://we.poppur.com/) Powered by Discuz! X3.4