POPPUR爱换

标题: 貌似计算性能完败 [打印本页]

---

作者: gtx5    时间: 2012-3-23 18:52
标题: 貌似计算性能完败
[attach]1813261[/attach]

---

作者: GTX999    时间: 2012-3-23 18:53
某个2盘菜曾经点评我说他测的通用计算680完爆7970
挖太多了 让他休息休息

---

作者: gtx5    时间: 2012-3-23 18:57
[attach]1813276[/attach]

---

作者: 餐具    时间: 2012-3-23 18:58
通用计算要有个生态圈的，性能有个蛋用

---

作者: GTX999    时间: 2012-3-23 18:59

餐具 发表于 2012-3-23 18:58
通用计算要有个生态圈的，性能有个蛋用

对我来说可以挖坟
   

---

作者: gtx5    时间: 2012-3-23 19:00

---

作者: eternal0    时间: 2012-3-23 19:08
双精度似乎悲剧了。

---

作者: CC9K    时间: 2012-3-23 19:09


ZOL测试通用计算性能680能秒了7970

---

作者: gtx5    时间: 2012-3-23 19:10

CC9K 发表于 2012-3-23 19:09
ZOL测试通用计算性能680能秒了7970

---

作者: GTX999    时间: 2012-3-23 19:10

CC9K 发表于 2012-3-23 19:09
ZOL测试通用计算性能680能秒了7970

大炮村的小编放评测前就说了

---

作者: gtx5    时间: 2012-3-23 19:11

---

作者: asd04122661    时间: 2012-3-23 19:16

CC9K 发表于 2012-3-23 19:09
ZOL测试通用计算性能680能秒了7970

游戏方面的通用计算性能当然秒了7970，否则1536sp怎么赢2048sp

---

作者: yihua伊华    时间: 2012-3-23 20:09
是不是这就是传说中的伪电，好，你GCN 7970大玩通用计算，我先不跟你玩，出个玩家叫好的游戏卡压死你，奈何680一出来，AMD大叫，你妹的，早知道用7870的执行效率堆出的7970秒你几条街啊，实在悲剧

---

作者: GTX999    时间: 2012-3-23 21:22

yihua伊华 发表于 2012-3-23 20:09
是不是这就是传说中的伪电，好，你GCN 7970大玩通用计算，我先不跟你玩，出个玩家叫好的游戏卡压死你，奈何 ...

伪电到领先4% 我是吐了

---

作者: xxxyyy    时间: 2012-3-23 22:13
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: csqaclp    时间: 2012-3-23 22:47


缓存很耗晶体管，而缓存对图形性能影响不大，对通用计算影响巨大。

---

作者: CC9K    时间: 2012-3-23 22:57

yihua伊华 发表于 2012-3-23 20:09
是不是这就是传说中的伪电，好，你GCN 7970大玩通用计算，我先不跟你玩，出个玩家叫好的游戏卡压死你，奈何 ...

显卡吧多欢乐
[attach]1813697[/attach]

---

作者: kevinkt    时间: 2012-3-23 23:01
這個時候某些人就會說通用計算重要了

---

作者: 东夷逍遥仙少    时间: 2012-3-23 23:07

CC9K 发表于 2012-3-23 22:57
显卡吧多欢乐

画图的僵尸玩多了吧。
地豆、僵尸脸的。。。

---

作者: SnakeLee    时间: 2012-3-23 23:08
暴走漫画

---

作者: Racca    时间: 2012-3-24 00:23
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: burntank    时间: 2012-3-24 00:43
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: disruptor    时间: 2012-3-24 02:14
就知道会有人拿双精度说事儿。建议楼主去等待tahiti被2t双精度的gk110爆菊

---

作者: VOODOO亚麻得    时间: 2012-3-24 02:21
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: mooncocoon    时间: 2012-3-24 02:24
刚看到这贴……然后开始后悔看到了……
纯吞吐测试=通用计算性能测试……你咋不去找找bitcoin的测试啊~那个更加欢乐而且赢得更多

穷举法果然对你们来说还是一切啊……

---

作者: rockyband    时间: 2012-3-24 02:28
bonic以及fah看到开心的对着lz的菊花笑了。

---

作者: VOODOO亚麻得    时间: 2012-3-24 02:30
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: mooncocoon    时间: 2012-3-24 02:30

GTX999 发表于 2012-3-23 18:53
某个2盘菜曾经点评我说他测的通用计算680完爆7970
挖太多了 让他休息休息

咦？~不是不跟我搅基了么？你能不能不要身体这么诚实啊

我所有的测试中成绩最稳定最没有波动的还就是SDK中关于DC的4个通用计算测试以及TS部分的测试，你这种“挖”法根本就是准备自抽嘛……SDK随便下载，几下就可以装好，你可以满大街随便抓个人或者男人点自己买块680来跑跑看SDK里的DC测试，然后再自己大力的扇自己两耳光也不迟嘛

哦，我忘了，你的世界里不存在SDK这种东西，通用计算什么的只要有人跟你说A卡很快你就会相信啦……sorry，我错了

---

作者: mooncocoon    时间: 2012-3-24 02:32

VOODOO亚麻得 发表于 2012-3-24 02:30
但你胡乱扯就是你的不对，又是菜又是谍战片的，洋相都被你出尽了，让人感觉680很牛逼，最后是托屎

我问过某人很多次了——我到底说错了什么？我所说的什么东西不是事实啊？
真的，你们哪一个都可以，马甲也无所谓~求求你们在被斩或者最终彻底疯掉之前告诉我吧

---

作者: VOODOO亚麻得    时间: 2012-3-24 02:33
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: mooncocoon    时间: 2012-3-24 02:34

VOODOO亚麻得 发表于 2012-3-24 02:33
你胡乱扯就是你的不对，让N饭失望，让AMD得意，你怎么能叫N饭？你让大家情何以堪

第一万六千次问你们——我到底胡扯什么了啊？

---

作者: VOODOO亚麻得    时间: 2012-3-24 02:34
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: mooncocoon    时间: 2012-3-24 02:35

VOODOO亚麻得 发表于 2012-3-24 02:34
你不去当神棍都吃亏了，肯定能骗很多人得，这次你在PCI让人很心寒，你已经失宠了，不多说了

马甲兄求你告诉我——我到底胡扯什么了啊

---

作者: VOODOO亚麻得    时间: 2012-3-24 02:36
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: mooncocoon    时间: 2012-3-24 02:36

VOODOO亚麻得 发表于 2012-3-24 02:34
你不去当神棍都吃亏了，肯定能骗很多人得，这次你在PCI让人很心寒，你已经失宠了，不多说了

动作快点马甲兄~在你再次被斩之前求你快告诉我我到底说错了什么啊~别老打那些没用的字浪费你为数不多的生命啊

---

作者: VOODOO亚麻得    时间: 2012-3-24 02:37
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: mooncocoon    时间: 2012-3-24 02:37

VOODOO亚麻得 发表于 2012-3-24 02:36
你继续吃你的两盘菜吧，主子给你的钱只够吃路边摊的也怪可怜的

我，到底，哪里，说错了~

马甲兄，我用了这么多逗号你总该能明白了吧~趁你还活着快告诉我啊~再晚可能就来不及了啊

---

作者: mooncocoon    时间: 2012-3-24 02:38

VOODOO亚麻得 发表于 2012-3-24 02:37
你现在在PCI都成过街老鼠了，你暗自得意吧，你自己心里清楚忽悠了多少人，说真的你的文章写出来也是奇迹， ...

求了这么多次，只求来这些模板式的自杀专用语句，一句有用的都没求来……
我尽力了，真的……

---

作者: VOODOO亚麻得    时间: 2012-3-24 02:41
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: 抱抱春日步    时间: 2012-3-24 02:43


   知识的欠缺程度往往和一个人的粗鄙是成正比的，这一点在某个群体上体现得尤为明显，知识性和技术性的东西说不上半点，满嘴的人参攻击和东拉西扯

我还清楚的记得某马甲在显存带宽上闹的笑话,还做梦7970 150MHZ显存性能不降，结果给人抽脸抽尿了，在驱动面板里动满手脚，好不容易跑个3400，却给人一眼识破Tessellation作弊.

  这群人常识如此不堪，但却乐于在任何帖子当中煽风点火人身攻击,我觉得这群人是把一辈子的财力和精力都押宝在一张7970上了，才有这么旺盛的战斗力

---

作者: mooncocoon    时间: 2012-3-24 02:52

VOODOO亚麻得 发表于 2012-3-24 02:41
我封不封没关系，但你没发现现在很多人在挖你坟么？你感觉是光荣的事？

求不来我哪里说错了不说，还冒出来一个“很多人在挖你坟”……
我这两天总在说“我尽力了”，我自己都说烦了，但不仅没求到我到底哪里说错了，反倒还冒出来一帮根本不知道从何说起的“挖坟”，连错都不知道在哪里你们怎么“挖”的啊……

我真的是尽了力了啊

---

作者: VOODOO亚麻得    时间: 2012-3-24 02:55
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: mooncocoon    时间: 2012-3-24 03:05

VOODOO亚麻得 发表于 2012-3-24 02:55
别的不说了，反正感觉你这次是两边都不讨好，不过680烧了那么多真的是680质量问题？

问了那么多次，一句“别的不说了，反正感觉……”就全完了。
恩，我也感觉我这次挺失败的，求人无解而且被感觉党以感觉完成了虚拟挖坟，最后还大声宣布了自己的胜利

至于烧了“那么多”680，我这次测5块680烧了1块，元旦测11块7970烧1黑1花1，以你这样的定义。哪个战损比更违和更像有质量问题呢……

---

作者: BDFMK2    时间: 2012-3-24 09:31
文明5不是纯吞吐测试吧？

纯吞吐的话，GK104应该有优势才对

---

作者: nom8393    时间: 2012-3-24 09:35
秀下限贴，界定完毕。

---

作者: hadeszhang    时间: 2012-3-24 09:39
680 本来就不是真正的680，这是AMD不给力造成的，但是无论怎样终归不是旗舰，只是以中端显卡，NV的中端显卡从来就没被用来做通用计算过，所以要比通用计算，那还只能等真正的680——110芯片上场

---

作者: aixiangsui2012    时间: 2012-3-24 09:40
我关心的是DX11.1

---

作者: hutigers    时间: 2012-3-24 12:00
=.=||讨论这个有意义吗？你们谁买显卡是干这个的？
干这个的人，买专业卡就好了。

一般人也就是视频转码+打游戏到头了。

---

作者: GTX999    时间: 2012-3-24 12:16
围观某楼被喷硬抗 哈哈哈

---

作者: potomac    时间: 2012-3-24 13:01
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: potomac    时间: 2012-3-24 13:01
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: yihua伊华    时间: 2012-3-24 14:11

CC9K 发表于 2012-3-23 22:57
显卡吧多欢乐

这个，那个。。其实我那段话是胡扯  除非点中了月神的所谓伪电

---

作者: hyj201    时间: 2012-3-24 14:25
通用计算这里没人用的，讨论来干嘛？

---

作者: mooncocoon    时间: 2012-3-24 22:47
darkstorm：单元复用率 I/Dcache分离...
厄……这问题不像你问的啊……
I/D分离，NV有画出来啊~SMX里那个大大的Instruction Cache很醒目啊……当然，GF100里好像也有画就是了……

至于单元复用率，我个人的标准是摸到矩阵操作、并行规约以及亮度直方等等单纯操作的效率之后在判断，虽然DC测试指向GK104的效率在压垮缓冲并开始利用显存当溢出缓冲之前非常的高，但我还是希望NV的驱动能够尽快稳定好让我开跑别的测试再说。

---

作者: mooncocoon    时间: 2012-3-24 22:49

BDFMK2 发表于 2012-3-24 09:31
文明5不是纯吞吐测试吧？

纯吞吐的话，GK104应该有优势才对

就目前的情况来看，GK104在很多场合的FP吞吐甚至只有Tahiti的一半……NV这次驱动过于仓促了。

---

作者: aixiangsui2012    时间: 2012-3-24 23:01

mooncocoon 发表于 2012-3-24 22:49
就目前的情况来看，GK104在很多场合的FP吞吐甚至只有Tahiti的一半……NV这次驱动过于仓促了。

DP更叫人揪心。。。三分之一到七分之一
PS：
这次NV以为AMD又会玩老招数，结果防范过头了。

---

作者: mooncocoon    时间: 2012-3-24 23:09

aixiangsui2012 发表于 2012-3-24 23:01
DP更叫人揪心。。。三分之一到七分之一
PS：
这次NV以为AMD又会玩老招数，结果防范过头了。

以我的测试，GK104的MAD DP吞吐是SP的1/4，很稳定……我不知道该不该相信，除了继续痛骂NV驱动仓促之外好像也没别的办法……

综合来看，能够进行的通用计算测试跟DC的测试完全对不上号，然后这两天抽风一样多的商业配合活动和断网把测试搞得断断续续的，下一周估计都没办法顺畅的测试了

---

作者: caoshichun    时间: 2012-3-24 23:18

darkstorm 发表于 2012-3-23 19:07
通用计算和游戏不同，相互之间区别很大，而且非常单纯，一般就是某种存储器上。
瓶颈出现在指令上是好的情 ...

就好比7970是大水管，但是进的水没能达到预期
女（NV）680水管小点但是众多“色狼”支持水阀也比按摩店开大了点

---

作者: CC9K    时间: 2012-3-24 23:51
原来并行计算可以无视吞吐量的？

其实GT430也只是吞吐量不如480而已，除开吞吐量性能和GTX480是一样的

---

作者: mooncocoon    时间: 2012-3-25 11:44

CC9K 发表于 2012-3-24 23:51
原来并行计算可以无视吞吐量的？

其实GT430也只是吞吐量不如480而已，除开吞吐量性能和GTX480是一样的

吞吐只有在“有效”的前提下才有意义啊，吞进去跑一圈无效出来在打一次包吞一次，这样造就出来的吞吐量对谁都是没有意义的。
从你第二句话来看，我前面这个回复可能就属于无效单元动作，但愿我想多了吧

---

作者: erodeox    时间: 2012-3-25 11:52
两个半斤八两，喜欢哪个入哪个。

---

作者: los_parrot    时间: 2012-3-25 12:23

mooncocoon 发表于 2012-3-24 23:09
以我的测试，GK104的MAD DP吞吐是SP的1/4，很稳定……我不知道该不该相信，除了继续痛骂NV驱动仓促之外好 ...

跟驱动没有多少关系,gk104本来运算能力就不如tahiti,有这种结果是正常的.



gk104的峰值FP吞吐达到tahiti的1半差不多是理论极限了,还想怎样?

---

作者: CC9K    时间: 2012-3-25 12:28

mooncocoon 发表于 2012-3-25 11:44
吞吐只有在“有效”的前提下才有意义啊，吞进去跑一圈无效出来在打一次包吞一次，这样造就出来的吞吐量对 ...

你说有效就有效，无效就无效喽，全世界680对7979的通用运算测试都是无效单元动作，跑了几圈得出个无效的测评结果，就你们ZOL是有效的，壮哉我大ZOL有效单元动作！

---

作者: coollab    时间: 2012-3-25 12:31

mooncocoon 发表于 2012-3-24 02:24
刚看到这贴……然后开始后悔看到了……
纯吞吐测试=通用计算性能测试……你咋不去找找bitcoin的测试啊~那个 ...

还有一群认为双精度等于一切的……

我怀疑他们在680的生命周期内是否能看到一个适合于桌面普通用户的双精度计算不……

---

作者: mooncocoon    时间: 2012-3-25 14:05

CC9K 发表于 2012-3-25 12:28
你说有效就有效，无效就无效喽，全世界680对7979的通用运算测试都是无效单元动作，跑了几圈得出个无效的测 ...

果然我又无效吞吐了

而且果然又疯了一只啊

---

作者: mooncocoon    时间: 2012-3-25 14:07

los_parrot 发表于 2012-3-25 12:23
跟驱动没有多少关系,gk104本来运算能力就不如tahiti,有这种结果是正常的.

这个表做的真绚丽……想从里面找对的数据还真是不容易……

---

作者: CC9K    时间: 2012-3-25 14:43

mooncocoon 发表于 2012-3-25 14:05
果然我又无效吞吐了

而且果然又疯了一只啊[sweatingbullets>

搞清楚自己的状况好么？

是你们的测试结论与全世界主流测媒体的结果相悖

这里别人贴成绩，质疑网友做什么？又不是他们测试的

想必你也清楚你的那套理论和吹的神乎其神的测评词藻，除了在这里和ZOL唬唬人，全世界也没有几家专业媒体会认同的，所以还是算了吧

---

作者: 樟树    时间: 2012-3-25 15:06


I/D cahce 自古以来就是分离的...
如果把I$做成和shared/L1 data一样的结构要慢死...

L1 I, L1 D, L1 Texture cache是这几种cache的第一级
不是L1 cache可以分为 I, D, T...

---

作者: 樟树    时间: 2012-3-25 15:09

los_parrot 发表于 2012-3-25 12:23
跟驱动没有多少关系,gk104本来运算能力就不如tahiti,有这种结果是正常的.

这张图不知道你怎么看出Gflops的
运算能力不是GK104的瓶颈

这张上面列出来了GK104在通用计算上的不足
以及为什么现有程序在它上面跑不高效率
但瓶颈不在单精度峰值

---

作者: aixiangsui2012    时间: 2012-3-25 16:31
单精度方面，NV已经有所落败，双精度方面，NV和A卡天差地别。
这种状况是怎么产生的呢，有帖子这么说的：

其实双精度运算和游戏运算用的是同样的单元
不同之处在于双精度对资源的要求较高，比如说缓存
GK104为节省晶体管，在这块省了，多数核心都不适合做双精度运算。
只有其中特殊的64个cuda核心，拥有做双精度运算的能力。
这才出现了其DP仅为1/24单精度这样惨绝人寰的结果。

话说我原本不怎么关注这一块，一方面我觉得普通显卡当前不需要太好的双精度能力，另一方面我觉得作为自身优势和路线图上的目标，老黄自然会做好这一块。但结果很令人意外。不需要太好，但也别做得这么极端啊！连上代都比不上了。

---

作者: 樟树    时间: 2012-3-25 16:51

aixiangsui2012 发表于 2012-3-25 16:31
单精度方面，NV已经有所落败，双精度方面，NV和A卡天差地别。
这种状况是怎么产生的呢，有帖子这么说的：
...

不对

主要原因很简单,就是双精度运算单元不够
看看浮点数标准很容易就能理解双精度单元在硬件上和单精度是不同的
虽然有些设计可以同时计算单精度和双精度，但是NV不是这种。或者说不全是这种

而你说的寄存器或者cache吞吐量反而很好处理。单精度32bit，双精度64bit，基本就是1:2的关系
在fermi那一代就已经解决了双精度的shared memory bank冲突问题
而如果光是说计算指令的吞吐量，如果运算单元没什么瓶颈，那更是只和寄存器位宽有关系。

归根结底，原因非常简单：可以执行双精度指令的单元数量很少
双精度差也没什么好纠结的。差就差，只影响一些数值计算，应用场合基本都是专业领域。

一些程序可能需要很多双精度或者超越函数等指令，Kepler对应硬件单元较少。在游戏中，削弱双精度和超越函数是十分合理的，因为游戏根本没有双精度，而超越函数数量不多，因此即使吞吐量较小也还好（指令中超越函数不多的话，大部分指令没有用特殊功能单元，因此增加特殊功能单元的吞吐量不会影响总的指令吞吐量）。而通用计算应用远远比游戏单纯，因此更容易碰到由于某一个指令或者某一种带宽造成的瓶颈。但我认为现在成绩相差较多的几个测试的瓶颈不是指令吞吐量。

我认为以下几个原因可能是目前测试成绩偏低的主要原因：
Kepler一个block中的线程数量必须比以前多得多才能获得较高效率。Tesla架构一般64-128，Fermi一般192-256就能获得比较高效率。而尺寸更大的block在这两个硬件上都会导致active block数量太少而降低效率。因此现有软件的block尺寸对kepler来说都太小，导致占用率不高。这还是在为NV写程序，只是改变block大小前提下的说法。比如说AES，在NV和AMD下基本是两个写法，那更不好说了。
与计算单元指令吞吐量相比，shared memroy 带宽较低，且容量较小。容量较小反过来又会导致active block数量较少。
寄存器文件数量不多，也就是每个线程的寄存器不多。这也会导致active block数量减少。

---

作者: mooncocoon    时间: 2012-3-25 17:04

CC9K 发表于 2012-3-25 14:43
搞清楚自己的状况好么？

是你们的测试结论与全世界主流测媒体的结果相悖

我从头到尾有质疑过那些测试的正确性么？我们所做的测试跟那些测试有一毛钱的冲突么？
贴了一车的sandra之类的吞吐测试，然后指着我们所做的DC的测试说“你的结果跟全世界主流媒体的结果相悖”，这合适么喂~
用吞吐来替代整个通用计算，质疑一下还要被扣“跟全世界相悖”这种高帽，我真的不知道我跟哪个次元的世界相悖了，我又唬到谁了。
好吧，退一万步讲，就算我真的唬人了，相比于连自己在说什么的你来说，我差的还真的是有点远呢

不明白我在说什么不要紧，不明白自己在说什么还要这些内容质疑别人说的内容，这是不是就有点不对了啊

---

作者: mooncocoon    时间: 2012-3-25 17:13

樟树 发表于 2012-3-25 15:06
I/D cahce 自古以来就是分离的...
如果把I$做成和shared/L1 data一样的结构要慢死...

MS要求shared这种东西存在，那最经济的做法其实就是这么干了，Fermi和Tahiti都是这么干的。

至于I/D分离，这里应该讨论的其实是I/D总线分离的问题，如果像Fermi那样I/D cache共用总线，那即便空间分离也没什么意义的，CHO曾经跟我说过Fermi的cache上的东西撞得相当“好看”，我没有手段去验证所以选择相信他。

---

作者: 樟树    时间: 2012-3-25 17:15

mooncocoon 发表于 2012-3-25 17:13
MS要求shared这种东西存在，那最经济的做法其实就是这么干了，Fermi和Tahiti都是这么干的。

至于I/D分 ...

I/D cache自远古以来就是分离的...
从来没有在一起过
更没有在Fermi上在一起过...

---

作者: mooncocoon    时间: 2012-3-25 17:24

樟树 发表于 2012-3-25 17:15
I/D cache自远古以来就是分离的...
从来没有在一起过
更没有在Fermi上在一起过...

有没有办法验证Fermi的I/D Cache总线同样分离。空间分离这种事构架图里就有，不用多聊的。而我手头目前没有现成的软件可以干这个，找人写找不到……
而且我去问NV的光头们关于GK104的I/D Cache总线分离的问题时，这帮家伙也承认并且说这是一个相对于过去的进步了

---

作者: 樟树    时间: 2012-3-25 17:31


这段话来自你的文章，其中除了L1 cache和shared共享空间以外，都是错的：
"在费米构架中，NVIDIA引入的第一代Unified Cache在结构上是相当简单的，L1 cache采用统一格式同时与shared分享空间，所有指令和数据均通过两者共同缓冲，这种做法会导致指令和数据在同一条缓冲总线上频繁相遇并彼此产生干扰。在开普勒构架中，L1 cache将会分为Instruction和Data两组独立的部分，分别对应ALU团簇的不同缓冲需求。在这一点上，AMD的Tahiti构架已经先期完成了cache的I/D分离，开普勒的cache改进将让双方再次处于同一起跑线上。"

---

作者: mooncocoon    时间: 2012-3-25 17:33
厄……先去修车了，晚上回来再说。
我确实非常有兴趣想深挖Fermi、Tahiti和Kepler的cache/shared结构和效率问题，光靠AMD和NV的人是完全不靠谱的

---

作者: mooncocoon    时间: 2012-3-25 17:38

樟树 发表于 2012-3-25 17:31
这段话来自你的文章，其中除了L1 cache和shared共享空间以外，都是错的：
"在费米构架中，NVIDIA引入的第一 ...

L1 cache采用统一格式同时与shared分享空间，所有指令和数据均通过两者共同缓冲
这句话依旧后面的描述的确有问题……本来脑子里是“L1 cache采用统一总线同时与shared分享空间，所有指令和数据均通过相同总线共同完成缓冲”，结果连战2月神经快断了，打出来扭曲了……
晚上回来把这一整段改掉

---

作者: Edison    时间: 2012-3-25 18:09

mooncocoon 发表于 2012-3-25 17:38
L1 cache采用统一格式同时与shared分享空间，所有指令和数据均通过两者共同缓冲
这句话依旧后面的描述的 ...

我建议你把这段全部删除。

---

作者: mooncocoon    时间: 2012-3-25 20:56

Edison 发表于 2012-3-25 18:09
我建议你把这段全部删除。

我要留着，而且还要加上“CHO某对我说”。

---

作者: aixiangsui2012    时间: 2012-3-25 21:23

樟树 发表于 2012-3-25 16:51
不对

主要原因很简单,就是双精度运算单元不够

你是对的。我再看了下相关资料，发现处理双精度的cuda core确实是独立存在。
这样说来的话，其实只要还没到用光线追踪，那么双精度和游戏就没有重复点？

我前面说的有点含蓄，其实如果仅仅是差的话我还不会说什么。毕竟我也不认为当前对双精度有多少需要。我只是着眼于未来，着眼于光线追踪，以及用GPU代替部分CPU功能的长远目标来看认为双精度即便不稳步增长的话，也不应倒退。不过现在看来似乎目前游戏与双精度并不能兼得？

有时间我再去找找GCN是怎么处理的。

---

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

Powered by Discuz! X3.4