POPPUR爱换

标题: 小月月，别和那些个喷子争论了，我来给他们上上课。。。。） [打印本页]

作者: asdfjkl 时间: 2012-9-21 11:17
标题: 小月月，别和那些个喷子争论了，我来给他们上上课。。。。）
本帖最后由 asdfjkl 于 2012-9-22 09:36 编辑

你们有啥吵的，大清朝就看到你们为这么无知的问题在喋喋不休，破坏心情。。。A粉和N饭的差距主要在于：学识 + 智力。

先说樟树：
看到的标题，然后看到这句话，我就明白了：
一堆术语忽悠一圈，回过头来一看显存配置
32bit  * 4 + 16 bit * 4
这里不是已经解释了为啥显存带宽没有损失么？
GK106显存192bit,对应着3个64bit的显存控制器，显存器控制器0和1管理着4块32bit的显存，显存控制2器管理着4块16bit的显存.
对于显存控制器0/1而言，它控制显存接口这边的粒度是32bit的，用交错的方式完成读写操作，保证显存读写操作的延迟不影响理论带宽。。。
对于显存控制器2而言，它控制显存接口这边的粒度是16bit的，用交错的方式完成读写操作，保证显存读写操作的延迟不影响理论带宽。。。
你这脑子怎么就明白不了呢？

说个最通俗的，按你这么说NV要是设计一块只有64bit的显卡，它支持GDDR5的显存的话，它的显存带宽就是无法达到理论值的，只有理论值的1/3是不是？  可笑呀。。。

这里就是在于NV设计的显存控制器的复杂度，这三块显存控制器是同一个设计，但在不同的配置下它可以支持不同的独显操作粒度：32bit,16bit.  这里不得不称赞Kepler的显存控制器的精妙之处；反观之AMD的显存控制器就简单多了，只支持32bit的管理粒度，所以AMD的产品无法以64bit作为尺度去屏蔽显卡带宽，只能是以128bit,如果按64就会碰到樟树说的问题。。。懂行就知道这里支持一个新的粒度，对于设计的影响，完全不是级别的。。。
屏蔽看起来很简单，一刀割下去，但实现起来绝对有很多细节技术需要解决的。

再说围观：
提啥你是什么工学硕士？  只要你不是读微电子的，毕业以后也没有做ASIC，就别拿出来显摆了。。。
我就问你一句：对于GDDR5的显存，你把地址和读写命令传输到它的接口上，你觉得数据会在多少个Clock Cycle就在数据接口上？  立马数据读出来了，一个Clock Cycle???

质疑的这几个A粉都不是做显存控制器，替别人显存控制的瓶颈操心。。。个个还霸气十足的。。。  还是怀着敬畏之心追赶吧。。。

作者: 樟树 时间: 2012-9-21 11:25
本帖最后由樟树于 2012-9-21 11:34 编辑

我看不懂你在说什么
所以你应该不懂我在说什么
我从来没说过峰值性能会因为显存采用clamshellmode降低

小月月原文是有一段作为靶子的，现在已经更正删掉了
他要否定最后0.5GB带宽为前1.5GB三分之一左右。

测试数据已经上了
求解读

另外一个64bit FB是两个32x MC
显存工作在clamshell mode时两片工作在16x组一个32x
此时一个FB 4片颗粒

作者: 50857817 时间: 2012-9-21 11:27
本帖最后由 50857817 于 2012-9-21 11:33 编辑

两个个人讨论问题，总被某些人上升到AN粉之战的高度，指出疑点的，不是“喷子”就是智力低，呵呵

作者: 小美哦 时间: 2012-9-21 11:31
高潮过后就是疲倦

作者: Episar 时间: 2012-9-21 11:36
估计有人要休息几天了

作者: sucKing 时间: 2012-9-21 11:40

50857817 发表于 2012-9-21 11:27
两个个人讨论问题，总被某些人上升到AN粉之战的高度，指出疑点的，不是“喷子”就是智力低，呵呵

+1 大家冷静冷静

作者: sucKing 时间: 2012-9-21 11:49
本帖最后由 sucKing 于 2012-9-21 11:54 编辑

其实这个问题，小弟也觉得：简单的说，显存位宽是192的话，容量就不能是"2G"，这两者不能同时成立，特别是在极端条件下。

作者: 樟树 时间: 2012-9-21 11:51

sucKing 发表于 2012-9-21 11:49
其实这个问题，小弟也觉得：简单的说，显存带宽是192的话，容量就不能是"2G"，这两者不能同时成立，特别是在 ...

当然可以

这是典型的非对称显存/内存系统。在CPU和GPU上都常见。

作者: asdfjkl 时间: 2012-9-21 11:51
本帖最后由 asdfjkl 于 2012-9-21 11:55 编辑

樟树发表于 2012-9-21 11:25
我看不懂你在说什么
所以你应该不懂我在说什么
我从来没说过峰值性能会因为显存采用clamshellmode降低

显存器控制器0和1管理着4块32bit的显存，显存控制2器管理着4块16bit的显存. 你看懂了么？按你这么说，我问你64bit的GPU支持GDDR5，显存带宽的是不是128bit的一半；还是想你说的这个64bit无法像128bit那样，所到底还是你脑袋一根筋抱定了只能最小粒度是32bit，所以这些个问题才出来了。。。

对比与完整256bit 2GB所用的显存颗粒，就能明确是不是我说的：显存控制2器管理着4块16bit的显存.还是你说的？

类推：如果GPU想32bit位宽支持GDDR5，那么FB控制器的内部读写粒度必须做到8bit才行。。。

你测试数据说明不了问题，因为现阶段无论是AMD，还是ＮＶ的ＦＢ读写效率都不超过理论计算带宽的７５％，所以你得到的读写速度和理论计算值的差别，你无法是效率所致，还真的是设计瓶颈。。。

作者: sucKing 时间: 2012-9-21 11:53

樟树发表于 2012-9-21 11:51
当然可以

这是典型的非对称显存/内存系统。在CPU和GPU上都常见。

您没明白我的意思…

作者: 樟树 时间: 2012-9-21 11:53
本帖最后由樟树于 2012-9-21 11:56 编辑

asdfjkl 发表于 2012-9-21 11:51
显存器控制器0和1管理着4块32bit的显存，显存控制2器管理着4块16bit的显存. 你看懂了么？按你这么说，我 ...

我在这里分开FB和MC。FB为64bit，下面两个MC。
MC为32x并且支持clamshell mode
正如小月月引用的GDDR5规范一样。
你对这一快认识有偏差。但这不是我说的问题。

新开一个贴讨论这个没什么意思。
我讨论的是非对称存储的性能，不是存储器控制器。

作者: asdfjkl 时间: 2012-9-21 11:58
本帖最后由 asdfjkl 于 2012-9-21 11:58 编辑

樟树发表于 2012-9-21 11:53
MC为32x并且支持clamshell mode
正如小月月引用的GDDR5规范一样。

性能这里是什么？　　不就是带宽么？　或者是读写Latency，这个你懂么？

　或者你还指容量了？
如果剩下的那个显存控制器2，用的2个32bit的颗粒，你说的读写带宽问题，这个512M显存的带宽比其他低，那是对的。。。
但现在却不是，他明明用的是4个16bit的显存颗粒，你还说有性能问题，那就是瞎扯了。。。

作者: sucKing 时间: 2012-9-21 11:58

樟树发表于 2012-9-21 11:53
我在这里分开FB和MC。FB为64bit，下面两个MC。
MC为32x并且支持clamshell mode
正如小月月引用的GDDR5规 ...

显存控制器和显存在下觉得最好不要分开讨论…

作者: asdfjkl 时间: 2012-9-21 12:01

樟树发表于 2012-9-21 11:53
我在这里分开FB和MC。FB为64bit，下面两个MC。
MC为32x并且支持clamshell mode
正如小月月引用的GDDR5规 ...

错就错在这里：
MC为32x并且支持clamshell mode
你抱定了自己设计的MC只能按照32X的粒度管理显存颗粒，所以荒唐的结论一而再，再而三。。。
实际上NV自行设计的ＭＣ实际上是可以配置的ＭＣ，支持GDDR5 32X,16X mode,也支持DDR3，SDDR3的诸多标准。。。

作者: 樟树 时间: 2012-9-21 12:03

asdfjkl 发表于 2012-9-21 11:58
性能这里是什么？　　不就是带宽么？　或者是读写Latency，这个你懂么？[sweat>[sweat>[sweat> 　或者你 ...

你在歪曲我的论点

我从没说过clamshell mode下GDDR5性能有任何降低，即单个64bitFB使用clamshell mode对性能有影响
我从没说过clamshell影响整体峰值性能。
我没讨论存储器控制器

我讨论的只有一点：非对称存储在使用一定容量后性能降低：

附件为代码，修改自CUDA SDK 4.0 例子sdk bandwidth test.
[attach]2030000[/attach]

测试环境为影驰四星黑将GTX550Ti, 192bit 1GB

测试方法：
预先分配一定显存，使被测速显存被分配在较靠后地址段上。
然后测试64MB显存device to device拷贝带宽
预先分配的显存大小通过以下方法修改：
修改参数为第187行int spacerSize = sizeof(unsigned char) * 1024 * 1024 * 640;
其中640为要修改的值测试中取值1-800

观察到现象：
取值0-400时，测得带宽稳定在71GB/s

400-480时，测得带宽不稳定，25GB/s-71GB/s之间
取值480-670，稳定在25GB/s

670以上开始out of memory不能分配

分析：
1. 显示缓冲区等已占用部分显存，大小变化，对测试有一定干扰。
2. 显存从低地址向高地址分配。
3. 预先分配大小为1-400MB时，被测速64MB内存全部被分配到低地址段。此时更接近理论带宽（98.4GB/s），可作为实测峰值
3. 400-480MB时，带宽开始降低，这是由于被测速64MB一部分获得了较高带宽，另一部分带宽较低
4. 480-670MB时，带宽降低并稳定到实测峰值三分之一左右。此时被测速64MB全部被分配到较高地址段。
5. 670MB以上时开始无足够连续区域供分配

结论：
GTX550Ti四星黑将存在一定区域带宽只有理论值三分之一左右，并且应该在较高地址段。
从尺寸上看可能为最高256MB（192bit 1GB）

展望：
GTX660Ti上可能有相同现象，待证实。
实验代码开源，可复现。欢迎提供GTX660Ti数据。

作者: asdfjkl 时间: 2012-9-21 12:03

樟树发表于 2012-9-21 11:53
我在这里分开FB和MC。FB为64bit，下面两个MC。
MC为32x并且支持clamshell mode
正如小月月引用的GDDR5规 ...

你懂GPU的基本框架么？在GPU设计里面，FB的设计肯定包括MC，还包括下面和显存颗粒直接打交道的物理协议层。。。
你去AMD，ＮＶ的ＧＰＵ找找，ＦＢ外面还有啥ＭＣ呢？？？

作者: 樟树 时间: 2012-9-21 12:06
本帖最后由樟树于 2012-9-21 12:09 编辑

asdfjkl 发表于 2012-9-21 12:01
错就错在这里：
MC为32x并且支持clamshell mode
你抱定了自己设计的MC只能按照32X的粒度管理显存颗粒， ...

你说的存储器控制器64bit，实际是FB，容易和MC混淆因此分开。

GDDR5颗粒有32x和16x clamshell mode

GDDR5 MC只有32x，并支持clamshell

再重复一次，这个和我要讨论的问题无关。

我只讨论非对称存储在使用一定容量后性能下降，并且证明GTX550 Ti上存在这个现象。
你可以推翻这个论点或者质疑我的实验。

作者: asdfjkl 时间: 2012-9-21 12:08

樟树发表于 2012-9-21 12:03
你在歪曲我的论点

我从没说过clamshell mode下GDDR5性能有任何降低，即单个64bitFB使用clamshell mode ...

你太搞笑了。。。 Fermi到Kepler的FB完全重新设计了，你还用用550Ti的成绩，去套给660Ti，我怎么说你呢？
还有想你这种对整个FB读写链路不大清楚的人，你看到瓶颈的差距，你就觉得把个塞给你知道的某个地方，其实不知道的地方出现瓶颈多的去了。。。。。
为了真的从实验上证明这一点，你要买两张Kepler显卡作对比，一个是256bit, 一个是192bit，都是2Ｇ的显存，这样你同样的程序一对比的成绩才能说明问题。。。

作者: asdfjkl 时间: 2012-9-21 12:14

樟树发表于 2012-9-21 12:06
你说的存储器控制器64bit，实际是FB，容易和MC混淆因此分开。

GDDR5颗粒有32x和16x clamshell mode

GDDR5 MC只有32x，并支持clamshell你是NV内部做的MC的么？否则，你为何如此去定这一点，既然GDDR5颗粒有32x和16x clamshell mode；为啥你抱着死脑筋觉得NV设计的MC一定不支持16x clamshell mode呢？？？

作者: Windyson 时间: 2012-9-21 12:44
192Bit/2GB比起192Bit/1.5GB是有过之而无不及

作者: bobcat 时间: 2012-9-21 12:48
本帖最后由 bobcat 于 2012-9-21 12:49 编辑

猫猫，樟树 fengpc hd4770 这几个是真干这行的工程师，他们说的基本就是对的。别争啦。辩一下也是为小月月好，毕竟小月月还是不如一线工程师清楚细节的。

作者: 围观 时间: 2012-9-21 12:53
我不屑于反驳猫神, 不过我得感谢猫神. 如果你喷我的话, 那大多数人可能就会认为我是站在真理那边的. 谢谢!

作者: 围观 时间: 2012-9-21 12:59

樟树发表于 2012-9-21 12:03
你在歪曲我的论点

我从没说过clamshell mode下GDDR5性能有任何降低，即单个64bitFB使用clamshell mode ...

你别跟他辩了. 摇尾猫神俩身份可能 1: 极端脑残N粉, 不分黑白. 2: AMD请来的高端N黑.

这货说话根本不讲道理的.
-----
倒是月神那边, mooncocoon最多其实也就算是个脑子不怎么灵光的骨灰N饭, 还有被改造的可能.
----
其实我tm不明白一个人 (还是学工科的) 怎能蠢到这种地步, 明摆着给他说说说是显存颗粒本身非对称设计会导致某些特定区块会对应有存取瓶颈, 结果blabla讲到死都在讲MC如何如何先进如何如何牛逼. 基本槽点都抓不住, 还吐什么吐呢.

作者: 50857817 时间: 2012-9-21 13:05

围观发表于 2012-9-21 12:59
你别跟他辩了. 摇尾猫神俩身份可能 1: 极端脑残N粉, 不分黑白. 2: AMD请来的高端N黑.

这货说话根本不 ...

淡定点吧，人家只是一个编辑而已，写出的“技术文”肯定有不少漏洞的，你就学着欣赏下别人的辞藻吧，那个才是绝活

作者: lttph 时间: 2012-9-21 13:09

作者: iamw2d 时间: 2012-9-21 13:36
我好像发现了一个喜闻乐见大快人心的帖子某人被打脸打的好爽
不过实验数据都出来了还能反咬几口不愧是收了钱的啊真敬业

作者: asdfjkl 时间: 2012-9-21 13:46

樟树发表于 2012-9-21 12:06
你说的存储器控制器64bit，实际是FB，容易和MC混淆因此分开。

GDDR5颗粒有32x和16x clamshell mode

你说的这个容量和性能的问题，太容易解决了。三个FB管理的容量： 768M + 768M + 512M 比例是：3:3:2
所以只要FB按照这个比例去分发读写的地址空间，就可以解决了；当FB0/1管理的768M 显存满的时候，也就是FB2管理的512M 显存满了。

作者: fengpc 时间: 2012-9-21 13:49

asdfjkl 发表于 2012-9-21 12:14
GDDR5 MC只有32x，并支持clamshell你是NV内部做的MC的么？否则，你为何如此去定这一点，既然GDDR5颗粒有 ...

clamshell mode只是GDDR5颗粒的x16工作模式，两个x16模式的颗粒并一起组成一个容量翻倍的x32通道，他们的地址线是接一起的，对MC来说可以当作一个颗粒。
GDDR5颗粒跟MC之间的点对点连接是为了降低信号线的负载改善信号质量提高工作频率，所以才有x16工作模式让两个内存颗粒的数据线跟MC始终保持一对一连接。对GDDR5来说，数据口的WCK和地址的CLK时钟是分开各自独立的，CLK只有WCK频率的一半，两个颗粒的地址引脚并联对信号质量影响相对较少，所以才会有这样的连接方式。

作者: 樟树 时间: 2012-9-21 13:53
本帖最后由樟树于 2012-9-21 13:55 编辑

asdfjkl 发表于 2012-9-21 13:46
你说的这个容量和性能的问题，太容易解决了。三个FB管理的容量： 768M + 768M + 512M 比例是：3:3:2
所以 ...

你说的这种方式类似hash了

即把性能的降低幅度均摊到更大容量上。
假定能够实现这样的组合，并且三个存储器控制器的性能相当。（如果其中一个更强，那么当然应该把其他两个性能提到一样强）

本来3:3:3时吞吐量是9
那么3:3:2时吞吐量则只有8，其中一个负载不满。

作者: fengpc 时间: 2012-9-21 13:55

樟树发表于 2012-9-21 12:06
你说的存储器控制器64bit，实际是FB，容易和MC混淆因此分开。

GDDR5颗粒有32x和16x clamshell mode

这跟固态硬盘数据快写满的时候速度降低的道理是一样的，MMU发现3个通道的颗粒都有剩余空间，就可以同时向三个通道写数据。当发现3个通道里面的2个通道的颗粒都写满了，就只能向一个通道写，带宽就下来了

作者: asdfjkl 时间: 2012-9-21 14:08

fengpc 发表于 2012-9-21 13:55
这跟固态硬盘数据快写满的时候速度降低的道理是一样的，MMU发现3个通道的颗粒都有剩余空间，就可以同时向 ...

这个问题的前提是，你按平均权重去分发的读写的空间（地址），这点赞成么？
只要用不同的权重分发读写的空间（地址），这么简单不就解决了么？？？想不通，你还是搞工程的人么？在地址的解码电路上做做优化就行，难不成还要我把代码贴出来，你才能理解么？

FB0:FB1:FB2 管理空间比例是：768:768:512= 3:3:2； 3+3+2 = 8；
所以FB接受到对于连续的地址的读写时，把低三位地址位解码，从第四位开始以后的地址位，传给显存的地址线例如：
000,001,010给FB0；
011,100,101给FB1；
110,111给FB2

这不解决了么？有何难的呀。。。

作者: 樟树 时间: 2012-9-21 14:10
本帖最后由樟树于 2012-9-21 14:12 编辑

asdfjkl 发表于 2012-9-21 14:08
这个问题的前提是，你按平均权重去分发的读写的空间（地址），这点赞成么？
只要用不同的权重分发读写的 ...

我说的就是按地址分。
你自己都已经列出表来了
三个的负载是3:3:2
第三个的负载只有前两个的2/3，在所有地址段上整体吞吐量从9降到8

而不这么做则是在四分之三区域吞吐量为9，最后四分之一吞吐量为3

作者: sucKing 时间: 2012-9-21 14:19

樟树发表于 2012-9-21 14:10
我说的就是按地址分。
你自己都已经列出表来了
三个的负载是3:3:2

这样说的比清楚了:P

作者: asdfjkl 时间: 2012-9-21 14:44

樟树发表于 2012-9-21 14:10
我说的就是按地址分。
你自己都已经列出表来了
三个的负载是3:3:2

真服了你，你搞清楚了没有，8是因为3为的地址解析为8。。。你什么逻辑？搞啥工程的，这个不明白么？扯啥吞吐量，完全是带宽的事。。。
在这里地址的调度算法是可以解决问题的。  地址位再多解析几位不纠结了。。。非得让我告诉你。
在我刚才说的地址位，选之前的再解析两位，记录状态，注意这里的每一种对应的8个地址：
新解析的两位： 00，       01，       10，          11
FB0：                   3，          2，          3，             3，             // 11 WCK cycle,  always full.
FB1：                   3，          3，          2，             3，             // 11 WCK cycle,  always full.
FB2：                   2，          3，          3，             2，             // 10 WCK cycle,  1 cycle is empty
地址数：             8，          8，          8，             8，

再来计算效率：  （11+11+10）/(11+11+11) = 32/33 = 97%. 还下降啥3/4完全是门外汉脑补的结果。。。

第三个的负载只有前两个的2/3，在所有地址段上整体吞吐量从9降到8

而不这么做则是在四分之三区域吞吐量为9，最后四分之一吞吐量为3

作者: 樟树 时间: 2012-9-21 14:51
本帖最后由樟树于 2012-9-21 15:14 编辑

asdfjkl 发表于 2012-9-21 14:44
真服了你，你搞清楚了没有，8是因为3为的地址解析为8。。。你什么逻辑？搞啥工程的，这个不明白么？ ...

此时每个FB对应的显存容量不是3:3:2了。

我不知道你是不是支持月月的每个FB可以访问任意一颗显存的

#如果不是，那么每个FB对应的显存容量不是3:3:2(假定能够这么连)，而是11:11:10。这与实际情况(1:1:2)和假设前提(3:3:2)不符。按照这个思路有解决问题的方法：每个FB控制的显存容量都是666MB（容量1:1:1），但是没有这种容量的显存颗粒。

#如果你认为FB和显存颗粒不是绑定的，能够使你和月月结论成立的必要条件是FB能够访问任意显存颗粒，并且认为显存颗粒在同时被多个MC访问时能够获得比一个MC访问时多几倍的带宽。实际情况是容量比例1：1：2，带宽比例1：1：1
显存颗粒能够提供的带宽是一定的，文档，理论和测试都支持这一点。并且clamshell mode上电时就确定，以后不能修改。FB是不是能访问任意显存我选择啥也不说，因为这个问题和FB没有关系。瓶颈总在显存颗粒容量与带宽的不均衡上，扯这么多FB MC一点帮助也没有。

作者: asdfjkl 时间: 2012-9-21 16:27

樟树发表于 2012-9-21 14:51
此时每个FB对应的显存容量不是3:3:2了。

我不知道你是不是支持月月的每个FB可以访问任意一颗显存的

看来你还是没有看懂我的分析，我已经明白你所认识的瓶颈在哪里了。。。我提出的对地址位的解析优化，可以减少的这种瓶颈，但这你却没有看懂。。。

在这里地址的调度算法是可以部分的解决问题的。  地址位再多解析几位不纠结了。。。非得让我告诉你。
在我刚才说的地址位，选之前的再解析两位，记录状态，注意这里的每一种对应的8个地址：
新解析的两位： 00，       01，       10，          11
FB0：                   3，          2，          3，             3，             // 11 WCK cycle,  always full.
FB1：                   3，          3，          2，             3，             // 11 WCK cycle,  always full.
FB2：                   2，          3，          3，             2，             // 10 WCK cycle,  1 cycle is empty
地址数：             8，          8，          8，             8，

再来计算效率：  （11+11+10）/(11+11+11) = 32/33 = 97%. 还下降啥3/4完全是门外汉脑补的结果。。。

你所认为的容量会对性能的影响；也就是说当FB2所管理的显存满了，FB0，FB1管理的显存还有空间这个时候，显存的带宽会下降，对不？因为FB2满了，实际的显存带宽只能是FB0 +FB1的，没有FB2的。
这个问题的发生，在于你认为FB0，FB1，FB2 同样的都是满速度写和读的。。。
加入按照我刚才： FB0=FB1=768M, FB2=512M分析。
看我上面的分析，FB0/1读写了11个cycle,FB1只有10个cycle. 所说带宽下降了 3%，但是FB2慢的时候，FB0，FB1的读写容量： 512 * （11/10） = 563.2M .这种配置下只有最后的：409M会有带宽下降的问题。。。
按照这个思路，我觉得还有其他的优化空间的。。。

例如解析更多的地址位，可以在位宽下降6%的情况下，FB0/1用到606M时，FB2才用到512M。这个时候只有最后的320M才有带宽下降的问题。。。

按此类推。。。

作者: 樟树 时间: 2012-9-21 16:44
本帖最后由樟树于 2012-9-21 16:48 编辑

asdfjkl 发表于 2012-9-21 16:27
看来你还是没有看懂我的分析，我已经明白你所认识的瓶颈在哪里了。。。我提出的对地址位的解析优化，可以 ...

这种方法在（FB0 768MB, FB1 768MB, FB2 512MB）设定下使1639MB获得了97%带宽，而409MB66%带宽
同条件下（FB0 768MB, FB1 768MB, FB2 512MB）不hash则为1536MB 100%带宽，512MB 66%带宽
而实际情况（FB0 512MB, FB1 512MB, FB2 1024MB,不hash）为1536MB 100%带宽，512MB 33%带宽

可见性能提升主要来自各FB上显存大小更加平均，至每FB 666MB时解决问题。
而编码方式则只是一种典型的hash，将性能降低平摊到更大地址段上。这是我早已指出的。
如果最后能想出一种解决方法那是最好了。

作者: Episar 时间: 2012-9-21 16:47

怎么不见顾编啊，估计也在学习呢..
Pia~

作者: asdfjkl 时间: 2012-9-21 16:56
本帖最后由 asdfjkl 于 2012-9-21 17:02 编辑

樟树发表于 2012-9-21 16:44
这种方法在（FB0 768MB, FB1 768MB, FB2 512MB）设定下使1639MB获得了97%带宽，而409MB66%带宽
同条件下 ...

你错了，我按你这个例子看：
而实际情况（FB0 512MB, FB1 512MB, FB2 1024MB）为1536MB 100%带宽，512MB 33%带宽

如果一开始你让三个FB是全速写入数据的话，也是在当整体显存超过1.5G以上才有带宽下降的问题，请你研究这个问题的时候引入时间轴，这个时候FB0，FB1都写入 512M，FB2才写入512M，还有512M的空白，这个时候才有带宽下降的问题，也就是你说的性能下降的问题。这里：
1）你的这种例子在GPU领域的显存操作上，基本上是不存在的；不是硬盘拷贝，一直写操作或一直读操作。。。
2）从时间轴上看，关键在于FB0，FB1满的时间，在这个时间之前，性能是毫无问题的。
3）FB的性能优化，可以改善这个时间的到来时整体所用的显存容量，FB0、FB1小的话，可以减少他们的写周期，最终写给他们的数据少于写给FB2的数据，带宽下降3%而已，发生性能变化的时候整体显存大小已经增大了10% 。如我上面所分析
3）为啥不是我分析的FB0=FB1= 768M， FB2 =512M，你有什么证据么？

作者: 樟树 时间: 2012-9-21 17:08

asdfjkl 发表于 2012-9-21 16:56
你错了，我按你这个例子看：
而实际情况（FB0 512MB, FB1 512MB, FB2 1024MB）为1536MB 100%带宽，512MB ...

1. 分配一定大小后一定出现，与操作是读写，是否连续无关。
2. 就是我的论点
3. 我的论点包括hash
4. 显存配置为8颗，每颗容量均为256MB，4颗被配置为16x, 4颗32x。Kepler一个FB为64bit。你说的768MB配置在16x * 2 + 32x时有可能实现，但是该FB在使用512MB显存以后，只有一个MC能够继续工作（另一个满了）。除非16x * 2能够提供两倍于32x的带宽。但是clamshell是上电时配置的，因此虽然可能有两个FB在工作，但是都为半速，除非颗粒容量为384MB。
并且测试结果表示是性能下降到峰值的1/3而不是2/3左右。如果有其他因素可以让性能降低三成，我会狠吃惊。

作者: flhssnake 时间: 2012-9-21 17:11
虽不明但觉厉直射膝啊

作者: 樟树 时间: 2012-9-21 17:20
我不明白为什么要专门提到时间轴

我早已说了地址从低到高分配，最高256MB(对550Ti, 对660为512MB)最高256MB有性能下降问题。

现在你的看法和小月月要驳倒的看法比一下，看看有什么区别：

“非对称的混搭设计巧妙地解决了显存容量问题，但其实也有隐忧。在对称设计中，每个控制器的显存容量都是相同的，很容易在所有控制器之间进行交错操作，达到子系统的性能最大化。而在非对称设计中，192-bit位宽、6GHz频率的总带宽为144.2GB/s，显存容量2GB的时候只有其中1.5GB可以享受到完全的交错操作，剩下的512MB只能与单个内存控制器通信，所以带宽也就是总量的1/3，仅仅为48GB/s。”

作者: asdfjkl 时间: 2012-9-21 17:23
本帖最后由 asdfjkl 于 2012-9-21 17:25 编辑

樟树发表于 2012-9-21 17:20
我不明白为什么要专门提到时间轴

我早已说了地址从低到高分配，最高256MB(对550Ti, 对660为512MB)最高25 ...

你如果没有明白时间轴，那你就是没有明白我的分析。假如按照你说的，FB0 = FB1 = 512M， FB2 =1024M的时候，
如果只需要768M的Frame Buffer,这个时候三个FB每个都是256M，这个状态下都是全速的读写，我实在不明白你说的这种状态下有啥瓶颈。。。时间轴只是一个状态，只有这个状态满足后才会对带宽有影响。。。

作者: 樟树 时间: 2012-9-21 17:26
本帖最后由樟树于 2012-9-21 17:28 编辑

asdfjkl 发表于 2012-9-21 17:23
你如果没有明白时间轴，那你就是没有明白我的分析。假如按照你说的，FB0 = FB1 = 512M， FB2 =1024M的时候 ...

这不是时间轴，因为时间与使用的容量大小无关。
我已经说得相当明白了，分配完一定容量（1536MB）后出现性能降低，你在重复我的话，同时说我是错的。

作者: fromiss 时间: 2012-9-21 17:29
是在说memory interleave么？FB是啥？

作者: asdfjkl 时间: 2012-9-21 17:47

fromiss 发表于 2012-9-21 17:29
是在说memory interleave么？FB是啥？

FB = Fram Buffer, 就是显存这一块的。

作者: caoshichun 时间: 2012-9-21 19:21

asdfjkl 发表于 2012-9-21 17:47
FB = Fram Buffer, 就是显存这一块的。

每次大动作的帖子后
甩尾猫总要发点东西出来

作者: BDFMK2 时间: 2012-9-21 20:49
小月月哭了，小月月啥时沦落到被甩尾猫救赎了

作者: chm128256_1 时间: 2012-9-21 22:52
二盘菜,单元复用率，求小月月解释。

作者: 参考消息 时间: 2012-9-22 00:18
围观2DOG互咬惨烈程度不输蛆家

作者: 蚯蚓 时间: 2012-9-22 00:38
神贴还在继续酱油路过......

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