POPPUR爱换

标题: 非对称显存性能带宽讨论 [打印本页]

作者: 樟树 时间: 2012-9-20 11:19
标题: 非对称显存性能带宽讨论
本帖最后由樟树于 2012-9-21 13:40 编辑

http://vga.zol.com.cn/322/3220624.html

GTX660Ti 192bit 2GB配置:

32bit * 4 + 16 bit * 4

工作在clamshell的显存容量和普通模式下的显存容量各占一半
但是位宽只有一半。

归根结底，和他要打的靶子是一样的：

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

而且测试方法也错了。人家说的是在已分配1.5GB显存以后测试，zol上来直接来了个峰值。

非对称多通道内存原理就这样了，玩文字游戏变魔术也变不了。只有使用hash之类的方法使带宽的降低被分配到更大容量上去。但是测试结果上没有覆盖到。

作者: BDFMK2 时间: 2012-9-20 11:38
你要明白测试人是顾杰

召唤小月现身说法

作者: westlee 时间: 2012-9-20 11:58
提示: 作者被禁止或删除内容自动屏蔽

作者: flhssnake 时间: 2012-9-20 11:59
保持围观态势

作者: mooncocoon 时间: 2012-9-20 12:18
本帖最后由 mooncocoon 于 2012-9-20 12:27 编辑

我用最白话的方式解释一下
clamshell mode可以让4颗16bit 2048Mb的颗粒“变成”2颗32bit 4096Mb的颗粒。因为clamshell mode允许2颗对称分布在PCB两侧的颗粒使用一组address/command进行并行操作。
老黄干的事，其实就是用低得多的成本达到了跟4*32*2048+2*32*4096这种你理解的了的布局同样的效果，实现的手段我理解了，而你却完完全全没明白。你以为4*32*2048+2*32*4096没问题，4*32*2048+4*16*2048就会因为连线少而出问题，这是因为你不知道根据clamshell mode的特性，4*16*2048跟2*32*4096在clamshell mode下是一样的，只要将16bit的颗粒对称布置在PCB后面对应的位置，以通孔并启动镜像模式即可。如果不满足布位要求，clamshell mode无法启动，这就是660/660Ti显存颗粒位置都很怪异，有4颗不对称另外4颗两两对称的原因。

最后，再被无数次莫名其妙的戴有色眼镜之后，我不得不说一句特没品的话——带着有色眼镜的话，你也就只能知道走进科学是蒙小白的，至于哪里蒙了，走进科学又是谁拍的，你是不能理解的。

脾气好不代表我每次都有义务跟你们这种家伙讲道理。脾气好更不意味着我可以随便被你们欺负。

作者: sucKing 时间: 2012-9-20 12:28
打脸？还是？

作者: BDFMK2 时间: 2012-9-20 12:34

mooncocoon 发表于 2012-9-20 12:18
我用最白话的方式解释一下
clamshell mode可以让4颗16bit 2048Mb的颗粒“变成”2颗32bit 4096Mb的颗粒。因 ...

clamshell mode是NV的资料，还是你推测的？

作者: fengpc 时间: 2012-9-20 12:37

mooncocoon 发表于 2012-9-20 12:18
我用最白话的方式解释一下
clamshell mode可以让4颗16bit 2048Mb的颗粒“变成”2颗32bit 4096Mb的颗粒。因 ...

一知半解就忽悠成文了~~每颗显存有对应的MC，这是不能交错的~~最后还扯到Unmatched Trace Length Routing上，你看现在哪个卡用上这个特性了？待机时候显存低频运行时的DLL都被关掉，IO也从CML模式切换到CMOS模式，布线不等长的话数据就出错了；或者这样做了，待机显存频率就不能降下来

clamshell mode就是x32 GDDR5颗粒的x16工作模式而已，没什么特别的~~另外670的空焊是因为用了x16/x32混合布线，以前的卡是空焊放在同一面的，这一代因为MC出线改变了才变成间隔的

作者: 买个棒槌 时间: 2012-9-20 12:48
讲得很高深，新手学习学习~~~~

作者: 樟树 时间: 2012-9-20 13:14

westlee 发表于 2012-9-20 11:58
这测试和显存占用大小有啥关系?

非对称显存可以按照非对称组双通道来类比。

比如一条1GB和一条2GB内存组双通道,一共3GB，能够双通道访问的数据是只有2GB的。剩下的1GB还是只能单通道。

这里也是一样，2GB内存, 192bit。你可以想成三通道，其中两通道每通道512MB，另一通道有1G。这里都不用考虑MC，直接在显存的位宽上就限死了。所以一定是有一部分显存不能以三通道访问的，无非是512MB以单通道访问，还是hash而已。

作者: 樟树 时间: 2012-9-20 13:33

mooncocoon 发表于 2012-9-20 12:18
我用最白话的方式解释一下
clamshell mode可以让4颗16bit 2048Mb的颗粒“变成”2颗32bit 4096Mb的颗粒。因 ...

你这楼里说这么组非对称多通道，这没有任何问题。

但是

用峰值测试结果来说最后那512MB没有性能损失是占不住脚的。最后说了一圈和你要驳倒的东西一模一样

作者: qdamao 时间: 2012-9-20 13:33
本帖最后由 qdamao 于 2012-9-20 13:34 编辑

技术白看不懂，对于我来说只要知道非对称结构会不会影响最终效果就行了。不过在技术讨论时把争论往正义VS邪恶方向引，感觉更不可信或别有用心。

作者: mooncocoon 时间: 2012-9-20 13:35

BDFMK2 发表于 2012-9-20 12:34
clamshell mode是NV的资料，还是你推测的？

clamshell mode是GDDR5显存体系最基本的特性，任何一个GDDR5显存的Introduction或者USER’S MANUAL上都会有介绍，不需要NV去提供。

[attach]2029066[/attach]

作者: mooncocoon 时间: 2012-9-20 13:41
本帖最后由 mooncocoon 于 2012-9-20 13:43 编辑

fengpc 发表于 2012-9-20 12:37
一知半解就忽悠成文了~~每颗显存有对应的MC，这是不能交错的~~最后还扯到Unmatched Trace Length Routing ...

对于所谓每颗显存都有对应的MC，请参见memory controller top level的介绍。点对点的显存连接在字面意思上是没有问题的，但只理解到字面意思就去望文生义才是忽悠……

关于所谓clamshell mode就是让颗粒运行在16X而已，我觉得官方描述应该可以消除这种望文生义的结果：
The benefit of clamshell mode is that users are able to quickly react on changing market conditions by easily creating new product
variations. E.g., by taking the same component from the inventory, utilizing the same controller, PCB layout and memory channel
width, the user can decide on the actual framebuffer size at a very late stage of the manufacturing process by
• either populating only one side of the PCB and configuring the GDDR5 to x32 mode, which results e.g. in a 1GB framebuffer
by using 8 pieces of 1Gbit with a 256-bit wide memory interface at the controller;
• or populating both sides of the PCB and configuring the GDDR5 to x16 mode, which results e.g. in a 2GB framebuffer by using
16 pieces of 1Gbit with a 256-bit wide memory interface at the controller.
Clamshell mode has no performance penalty because it preserves the point-to-point connection on the high-speed data bus. The
shared address and command interface can easily be connected by vias in the PCB and the use of mirror function mode which lets
these pins appear at the exact opposite locations.

这篇文章的特性介绍全部来自xilinx和elpida的官方PDF，之所以会写这么长，就是防止以前经常出现的那种有地方没说清楚结果被自己也不清楚的人拿出来喷的事发生。

可惜现在看来，我还是失败了。想喷的人，无论你做什么他都会去喷的……

作者: coollab 时间: 2012-9-20 13:42

mooncocoon 发表于 2012-9-20 13:41
对于所谓每颗显存都有对应的MC，请参见memory controller top level的介绍。点对点的显存连接在字面意思上 ...

没看到你已经成为靶子了吗？
部分人士喜欢的就是，吃喝免费东西，玩盗版游戏，上论坛喷人。

素质就这样了。

作者: solidusmic 时间: 2012-9-20 13:42
说白了,

老黄,造得板卡上省下了一大笔钱

然后再从这一大笔钱中拿出一小笔钱出来开销

最后得到了一样的效果.

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

mooncocoon 发表于 2012-9-20 13:41
对于所谓每颗显存都有对应的MC，请参见memory controller top level的介绍。点对点的显存连接在字面意思上 ...

这一段英文里精确的描述了clamshell mode的功能
显存控制器位宽不变时(这里是讨论一个kepler的64bit显存控制器)，使用单面贴两片颗粒(每片配置为32x)，或者clamshell mode镜像双面贴4片颗粒(每片配置为16x)。我不明白为什么用这么一大段说明clamshell就是两片16x组32x的定义，来反驳"clameshell就是单片颗粒16x"

关于fengpc 说的GDDR5实际方面的东西，我只想稍微更正一点是PLL不是DLL。另外不是显存控制器和一片显存颗粒绑定，而是一个显存控制器对固定的几片。应该是打字太快了。

作者: 樟树 时间: 2012-9-20 14:17
非对称多通道这么用问题并不大。
对于绝大多数应用来说，用不到那么打容量根本不会有性能损失。正如测试中显示的结果一样
而即使是在最后的带宽较小的一部分容量，访问时也远比爆显存开销小一个数量级。这个没测出来。

小月月写文章还是做了很多功课，这个要值得表扬。
问题是始终在原地绕，立了个靶子没打中。非对称多通道一定有在一部分容量性能损失。我就抓这个问题。
然后MC和显存的关系错了。这个看显存厂的文档是不知道显存控制器怎么做的。这个我没喷
最后GDDR5布线这个是个feature，板卡上不一定用了。这个我也没喷。

作者: sucKing 时间: 2012-9-20 14:25

樟树发表于 2012-9-20 14:17
非对称多通道这么用问题并不大。
对于绝大多数应用来说，用不到那么打容量根本不会有性能损失。正如测试中 ...

貌似楼主第一句话就是“一堆术语忽悠一圈”

作者: 樟树 时间: 2012-9-20 14:26
本帖最后由樟树于 2012-9-20 14:34 编辑

sucKing 发表于 2012-9-20 14:25
貌似楼主第一句话就是“一堆术语忽悠一圈”

始终原地绕当然是一圈。

文章的主题是非对称显存没有带宽问题。
但是测试方案不能测出有没有问题
一堆术语解释说明了显存的组织方式，反过头来指向是很有可能有问题的。

考虑这个问题其实可以只看显存，不用过多关注显存控制器和显存布线。

作者: mooncocoon 时间: 2012-9-20 14:44
本帖最后由 mooncocoon 于 2012-9-20 14:49 编辑

我在5楼说的没办法再简单了吧。
你们觉得2+2+2没问题，2+2+4的时候4会因为过多显存颗粒用过少连线连载了过少的MC上于是带宽会有问题。
于是我给你们解释了，MC不是跟显存颗粒物理绑定，因为有MC TOP LEVEL，任意MC单元是可以访问任意显存颗粒的，你们所谓的点对点只是针脚对阵脚和MC单元整体对MEM连接的点对点而已，所谓的超过1.5G的部分会变单通的事不存在；然后2+2+4也因为clamshell mode变成了2+2+2，所以这里没有任何值得担心的所谓带宽问题。

结果呢？

“一堆术语忽悠一圈”
“始终原地绕当然是一圈”
你们肯去理解么？你们肯看我说的是什么么？为了让你们明白自己对点对点连接理解的错误，我还专门先写了top level，以便争取让你们能够明白自己对多通道以及mem和MC通讯的形式理解出了问题，然后再去解释它跟clamshell mode结合在一起让问题消失了。
可结局呢？

你们除了喷之外，有别的哪怕是一星一点多余的企图么？

文在这里，图在这里，关键性的官方描述也在这里，这些描述解决了什么问题同样在这里。不是每一个人都像你们这样要么没明白装明白，要么明白了也要强迫自己变得不明白然后装明白。

你们想闹，那就继续闹吧，向歪曲那就继续歪曲吧。我做什么都躲不掉你们的话，做那么多事说那么多话又有什么意义呢？

你们继续，我尽力了，同时也无能为力了。

作者: 扫帚 时间: 2012-9-20 14:58
顾肥我看出来了, 你就是个傲娇受

作者: mooncocoon 时间: 2012-9-20 15:01
本帖最后由 mooncocoon 于 2012-9-20 15:02 编辑

扫帚发表于 2012-9-20 14:58
顾肥我看出来了, 你就是个傲娇受

我是挺受的，明知道会有人无脑喷，却还要一遍又一遍的给自己弄一些会导致无脑喷现身的自主选题出来，自己立个靶子找事，还拿所谓公众有权知道真相这种假大空的念头蒙自己。
我就是特么的贱！艹！

作者: 扫帚 时间: 2012-9-20 15:07

mooncocoon 发表于 2012-9-20 15:01
我是挺受的，明知道会有人无脑喷，却还要一遍又一遍的给自己弄一些会导致无脑喷现身的自主选题出来，自 ...

easy~easy~ 你要明白, 你想让所有人都满意是不可能的

作者: Windyson 时间: 2012-9-20 15:10
用不到1.5GB的时候,没什么影响,
用超过1.5GB的时候,比起只有1.5GB的卡,2GB要好.

作者: 围观 时间: 2012-9-20 18:56

mooncocoon 发表于 2012-9-20 14:44
我在5楼说的没办法再简单了吧。
你们觉得2+2+2没问题，2+2+4的时候4会因为过多显存颗粒用过少连线连载了过 ...

别人喷你一般都是有想法才喷的, 你别总那么主观.
就拿你这个说法来说吧. 你好好缕缕自己的逻辑.

即便假设所有MC单元都可以访问任意显存颗粒, 但是显存颗粒本身是有传输瓶颈限制的. 一个32bit的显存颗粒难道给予10个MC来访问它的权利, 难道10个MC就可以同时访问了? 难道位宽会变到320bit吗? 说白了还是32bit. 所以2+2+4 最后那个多出来的 "2", 是有点问题的. 你那top level 解决不了问题. top level如果能加强MC访问颗粒的随意性, 那只是将实际带宽和理论带宽拉近, 而不是解决理论上的瑕疵, 2+2+4这种搭配方法有不可避免的理论缺陷. 你的测试相当片面, 解决不了问题, 因为在那种测试中, 软件很可能只是调用其中一部分数据来做反复尝试取结果, 而不是覆盖所有的可能被操作到的数据 (这种覆盖所有可能的测试是相当麻烦的). 一般来说这种测试模式也能反映普通使用情况, 因为大部分情况下显存 (或者内存) 都是对称设计的, 不会奇葩的搞什么非对称.

换句话说, 洞的大小有限, 你拿10个jb来艹, 插得进去吗? 这时候只能轮着插, 不能同时插, 也就是说抽插总频率还是不会有实质的提升 (对不起我觉得给你打比方只能用这么粗俗的方法, 否则文明讨论你总是觉得别人对你是阴谋论).

-------
我觉得你的数学和逻辑能力实在太差了, 很多问题分析来分析去都是一桶浆糊戳不到G点上, 包括楼主一楼对你的质疑, 你都没看懂人家啥意思, 结果5楼答非所问. 我本人很讨厌权威论, 但是我这次不得不自抬一下身价, 我是国内某著名大学的某响当当的数学系的某优秀学生, 我说你数学逻辑方面有问题, 真的不是我主观带有色眼镜抨击你的, 你写的东西让任何一个稍微懂些数学的人看了都会无语的.

作者: chulei104 时间: 2012-9-20 19:03
额，我看了文章，感觉就是说那重叠的两组4颗芯片，等于2组512m，加上剩下的4颗等于4组256m，这不就类同于550ti的2组256+4组128？

作者: mooncocoon 时间: 2012-9-20 19:53
本帖最后由 mooncocoon 于 2012-9-20 21:44 编辑

围观发表于 2012-9-20 18:56
别人喷你一般都是有想法才喷的, 你别总那么主观.
就拿你这个说法来说吧. 你好好缕缕自己的逻辑.

作为一个工学硕士，我觉得既然是数学系的学生，在评判别人逻辑性之前，你是不是起码应该先检讨一下自己看待内存时令人沮丧的非连续性呢？只看一个时间断面上特定颗粒的读取形式，却不去考虑什么才是“带宽”和“并行读取”，如果要我这个非专家再来给你讲一遍内存连续操作过程的宏观意义，会不会有更多莫名其妙的靶子被立起来？
对于mem和MC来说，只要bank满足条件，剩下的事就是提供与位宽相对应的address/command，只要address/command可以支持延迟要求，mem的读取在宏观时间分段上，或者说讨论带宽时就不存在任何问题。你们在这里出现的纠结，起点不就是怀疑NV没有提供足够的与位宽相对应的地址线，所以这些颗粒被MC操作的时候会有等待产生的多余的延迟，进而让有效带宽变少么？这么简单的逻辑，如果看不出来却硬要说别人不明白的话，究竟糟糕的是谁呢？
内存的存取不可能停留在一个周期上，单周期单个颗粒与单个MC的动作也没有任何决定性的意义。如果整个内存体系都建立在一个单元卡壳性能就要坍缩的基础上的话，整个随机存储大厦根本就没必要存在而且早就该轰然倒塌了。一个数学系的学生，潜意识里最基本的连续的概念都没有建立起来，满脑子只有割裂的独立的甚至是互不关联的片段事件，你做积分的时候难道就会套公式从来不管它们背后的含义么？学数学的人感到无语的究竟应该是我的文字，还是你用错误概念作出发点来强J了我的逻辑性呢？

最后，如果无法迁就各种花样百出的错误认识就是欠缺逻辑性的表现，那我究竟要怎么做才能不太费力地让你觉得我的逻辑性还算过的去呢？针对你们提的每一个花样百出的错误概念去一一的纠正？你的逻辑性难道没有把“纠正了一个后面还会有10个等着，纠正了10个后面还会有100个等着”这么简单的结果展现给你么？你难道还不知道究竟为什么会有这么多稀奇古怪的问题冒出来么？戳到G点？我怎么可能做到去戳你们建立在错误概念基础上的G点啊？

作者: Episar 时间: 2012-9-20 20:01

而在非对称设计中，192-bit位宽、6GHz频率的总带宽为144.2GB/s，显存容量2GB的时候只有其中1.5GB可以享受到完全的交错操作，剩下的512MB只能与单个内存控制器通信，所以带宽也就是总量的1/3，仅仅为48GB/s。

前几天，一堆6那位不是还否定这个呢

作者: 围观 时间: 2012-9-20 22:20

mooncocoon 发表于 2012-9-20 19:53
作为一个工学硕士，我觉得既然是数学系的学生，在评判别人逻辑性之前，你是不是起码应该先检讨一下自己看 ...

你除了会用华丽的辞藻还会干什么? 基本逻辑都搞不清楚.

楼主和我的意思说通俗一点就是 "颗粒的最大耐艹程度在那摆着, 你拿一百个MC来艹它也没用",
搁到你这居然就理解成了 "颗粒被好多个MC一起艹也艹不够".

槽点太多, 你敢仔细想想自己的逻辑么?

显存颗粒里存储的数据, 一个32bit的显存颗粒, 一周期内最多交换32bit的数据, 难道你让2个64bit的控制器同时控制它, 一个周期内就可以交换128bit的数据吗? 真是奇葩.
你还说什么 "难道要解释一下时间连续性" 一类的玩意. 别避开话题, 废那么多话, 你就把上面那个 "32bit的颗粒让2个64bit的控制器控制, 一个周期最多交换多少数据" 的事情说清楚就行了.

作者: 围观 时间: 2012-9-20 22:25

mooncocoon 发表于 2012-9-20 19:53
作为一个工学硕士，我觉得既然是数学系的学生，在评判别人逻辑性之前，你是不是起码应该先检讨一下自己看 ...

还说什么 adress, command支持延迟要求如何如何.
你这是废话, 要是等效5ghz的32bit gddr5颗粒的延迟能支持你10个MC同时来读取, 那这货根本就不是5ghz, 至少是50ghz.

你这逻辑就好比是: 如果一个一秒打10拳的人可以和10个一秒踢10脚的人做出一个拳-脚的一一对应, 那这个一秒能打10拳的人就能打100拳. 荒诞.

作者: mooncocoon 时间: 2012-9-20 22:26
本帖最后由 mooncocoon 于 2012-9-20 22:38 编辑

围观发表于 2012-9-20 22:20
你除了会用华丽的辞藻还会干什么? 基本逻辑都搞不清楚.

楼主和我的意思说通俗一点就是 "颗粒的最大耐 ...

"颗粒的最大耐艹程度在那摆着, 你拿一百个MC来艹它也没用”
“显存颗粒里存储的数据, 一个32bit的显存颗粒, 一周期内最多交换32bit的数据, 难道你让2个64bit的控制器同时控制它, 一个周期内就可以交换128bit的数据吗? 真是奇葩. ”
最奇葩的是你不仅割裂了片段，还忘记了其他存在——这么多显存控制器凭什么非要死盯着这一刻的这一颗显存不放？！为什么！凭什么！特么的这个世界在这一刻就只有这一颗显存么！！！特么的带宽只能靠这一颗显存被所有MC操作才能带来么！！！

够了！我真的受够了！！！你每次除了那句“你除了华丽辞藻还有什么？”之外，还有些什么？！你难道就只有这样或者那样错误的概念么！

连续存储到底是什么！并行连续存储到底是什么！随机并行连续存储到底是什么！！！干！用如此低级的错误累死我或者逼疯我就是你们的目的么？！
我是没什么东西，但我起码知道一些最最基础的问题的概念，而且我不会用错误的出发点去强暴别人的逻辑！

作者: bull 时间: 2012-9-20 22:46

樟树发表于 2012-9-20 14:26
始终原地绕当然是一圈。

文章的主题是非对称显存没有带宽问题。

现在显卡上的显存频率这么高，数据线又都是单端（时钟线是差分）。所以所有的数据I/O口都是点对点。这是为了保证阻抗匹配良好。
但是内部逻辑是不是点对点。这和I/O是什么结构毫无关系。

作者: 围观 时间: 2012-9-20 22:48

mooncocoon 发表于 2012-9-20 22:26
"颗粒的最大耐艹程度在那摆着, 你拿一百个MC来艹它也没用”
“显存颗粒里存储的数据, 一个32bit的显存颗 ...

废话, 本来数据可以均匀地放到各个颗粒里面来供数据交换, 但是2G显存里面有512MB是不能做这种交换的.

等你需要用到这奇葩的512MB的芯片的时候, 总共只有64bit的位宽让你耍, 你还说什么 "这么多显存控制器凭什么非要死盯着这一刻的这一颗显存不放？！为什么！凭什么！这世界在这一刻只有这一颗显存么！"

事实就是这时刻你想要的数据都在那64bit位宽的显存里.
你逻辑上过来没?

作者: 围观 时间: 2012-9-20 22:53

mooncocoon 发表于 2012-9-20 22:26
"颗粒的最大耐艹程度在那摆着, 你拿一百个MC来艹它也没用”
“显存颗粒里存储的数据, 一个32bit的显存颗 ...

比如我问你,
我有2G的数据需要存到这2G显存里.

然后我开始读取, 最理想的情况就是有512MB *3同时读完, 这时候是1.5G, 那请问剩下的512MB在哪里? 他们只在最后那64bit对应的颗粒里面.

当然实际上更不会有这么理想, 反正你存取数据的时候总有颗粒会先被占满而无法使用. 如果算法足够好, 在同位宽对应同容量的前提下, 你可以让你的数据存取尽量均匀. 但是如果同位宽能保存的数据量都不同, 那即使你一直满负荷工作, 当容量小的芯片先被写满之后, 你就只能往剩余的那些芯片里写, 还是那句话, 这时候你只有64bit位宽对应的颗粒可以艹, 是不?

作者: mooncocoon 时间: 2012-9-20 22:53
本帖最后由 mooncocoon 于 2012-9-20 22:55 编辑

围观发表于 2012-9-20 22:48
废话, 本来数据可以均匀地放到各个颗粒里面来供数据交换, 但是2G显存里面有512MB是不能做这种交换的.

...

物理上的链接没有问题，逻辑上的管理也没有问题，2G显存里面有512MB为什么不可以做这种交换！凭什么不可以做这种交换！有充足的地址线，有所有MC可以访问，没有多余的延迟，凭什么你就要让512M各种不能用！就因为你“觉得”它不能用么！

我写这文的目的，不就是告诉你们“没有什么4*16bit显存这一块会工作不正常”这个最基本的问题的答案么！！！

你到底有没有看过并且尝试理解过哪怕一个我写的字啊！随机并行连续存储以及多通道内存管理模式在你的脑海里究竟是一个怎样畸形的存在啊！

竟然被这么低级到令人发指的问题纠缠住，我特么真的疯了啊啊啊啊啊啊啊啊啊啊啊啊啊啊！

作者: PowerfulMe 时间: 2012-9-20 23:01

围观发表于 2012-9-20 22:48
废话, 本来数据可以均匀地放到各个颗粒里面来供数据交换, 但是2G显存里面有512MB是不能做这种交换的.

...

额……

这个问题就和Intel 的双通道技术一样，它支持“混合双通道”，即：不要求两条内存具有相同的容量，但是频率需要一致……

作者: mooncocoon 时间: 2012-9-20 23:01
本帖最后由 mooncocoon 于 2012-9-20 23:04 编辑

围观发表于 2012-9-20 22:53
比如我问你,
我有2G的数据需要存到这2G显存里.

为什么是X3！为什么是2G的数据莫名其妙的成了不可再分的整体！为什么不考虑MC交替并行动作对延迟的掩盖！为什么一定要一口气同时读完！为什么还必须在你规定的一个周期里一口气同时读完！！！！

随机并行连续存储，随机！！！并行！！！连续！！！

我不行了……我没精力跟你在这些最基本的概念上耗下去了，我没本事写一本教材出来，我无能，你自己乐意去了解最基本的随机并行连续存储以及多通道内存并行管理的基本概念的话就去吧，那样善莫大焉。如果不乐意，那你继续纠结在你脑海中错到离谱的基本图景里继续发不沾边的问吧。就当我没来过或者我已经承认错误并决定痛改前非了吧。

作者: fengpc 时间: 2012-9-20 23:03

mooncocoon 发表于 2012-9-20 13:41
对于所谓每颗显存都有对应的MC，请参见memory controller top level的介绍。点对点的显存连接在字面意思上 ...

clamshell mode和mirror function是两个独立的功能，mirror function是用过显存的一个引脚的上拉和下拉来配置的，clamshell mode是MC给显存发送初始化命令配置的，你有机会可以找个电路图求证一下。mirror 之后的显存也可以工作在x32模式。因为受工艺制约容量翻倍的颗粒价格有时候比两个小容量可以价格加和还贵，所以才需要用到clamshell mode在成本最低情况下实现容量翻倍，像670这样的x16/x32兼容模式布线实际会影响显存最高工作频率的。

你的文章一个很严重的问题是借用了xilinx的文档去套用在GPU上，FPGA/CPLD跟ASIC一个很大的区别是FPGA内部的单元是连在芯片内部一个庞大的交叉连线网络上的，所以FPGA的功能可以任意配置，你所说的“因此任意一个连接在TOP LEVEL上的memory controller也可以透过TOP LEVEL来实现对任意显存颗粒的直接操作 ”只是你根据不正确的资料的推测而已。不是反对你的人都是喷的，只是交流而已。

作者: mooncocoon 时间: 2012-9-20 23:09
本帖最后由 mooncocoon 于 2012-9-20 23:37 编辑

首先，我们测试过的670/660/660Ti的显存频率都可以超过7000甚至超过7500，更少的以及更简单的布线显然可以提升频率的上限。670公版中的所有颗粒全部都是刻意回避clamshell mode的，它们并不要求颗粒一一对应来创造镜像模式和clamshell mode的先决条件，所以所有颗粒全部工作在32X模式下。部分非公版出于自身的考虑采用了量大到不得不对称分布的显存颗粒，进而进入到这样的状态并不是NV的要求，也不在我们本文讨论的范围。

top level作为交换层的存在与交叉连线网络以及FPGA的功能任意配置并不在同一个问题方向上，交换层不是bus，不是xbar，不是你所描述的任何东西，它不是导致可以将区域任意配置的存在，它是MC的一部分，是连接逻辑层和物理层的交换场所，这跟你要进行的关于公用通讯互联等等纯逻辑层的讨论没有任何关系。FPGA就是ASIC，“FPGA跟ASIC的区别”又是笔误么？你把若干个不相干的问题拉在了一起，却说我根据不正确的资料进行了推测，我不知道这算不算交流的一种形式……

作者: sucKing 时间: 2012-9-20 23:18

fengpc 发表于 2012-9-20 23:03 clamshell mode和mirror function是两个独立的功能，mirror function是用过显存的一个引脚的上拉和下拉来 ...

各位大婶继续，不过小弟觉得这标题就不像是要交流来的…

作者: inSeek 时间: 2012-9-20 23:44
楼主一直没明白月虫要说明的...
在两个空间里...........

作者: inSeek 时间: 2012-9-21 00:05
楼主可能进了一个牛角尖。
这组成192bit的3个64bit MC是可以独立操作的...而数据也不会是一整块不可分割的2GB..
这就为一段时间内的各种存取并行化提供了条件...

作者: soloparadise 时间: 2012-9-21 00:19
不是一个层面的对话，有些时候让人觉得好笑。

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

我专门借了一块GTX550Ti, 花了45分钟改代码做了我在一楼提到的测试
另外还花了十几分钟发帖，以示我对这个问题的重视。

附件为代码，修改自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
[attach]2030002[/attach]
400-480时，测得带宽不稳定，25GB/s-71GB/s之间
取值480-670，稳定在25GB/s
[attach]2030003[/attach]
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数据。

作者: caoshichun 时间: 2012-9-21 02:39
这数据提供出来了，都哑口无言不说话了

作者: 围观 时间: 2012-9-21 06:10

hd4770 how about use the last 512M before using the first 1.5G to avoid your case? 发表于 2012-9-20 23:15

无用, 请你仔细理解里面的逻辑, 无论如何, 你至少有512M的数据是存在了64bit位宽对应的显存颗粒里面, 不管早取晚取, 只要取这些数据, 带宽就上不去.

作者: 围观 时间: 2012-9-21 06:23
我真是给你跪了, 别动不动上纲上线的, 我再把例子解释一遍, 你真想讨论就好好讨论, 带点攻击性话语无所谓, 但是你别满篇都是悲天悯人的玩意. 你倒是给解释解释啥叫你所谓的随机并行连续存储? 然后再说说你这种所谓的存储模式是怎么让那些不处于对等地位的数据诡异的飘来飘去还可以不固定在同一个物理地址上的?
------
例子解释, 形象版, 再给你配个图:
假设我有两口井, 一口井(A)口径大, 可以让两个人同时往里倒水或者打水, 另一口(B)口径小, 只能让一个人同时往里倒水或者打水 (这里口径相当于显存颗粒本身的位宽)
但是两口井的最大容量都是100桶水.
这时候你开始往井A和井B里倒水, 无论你如何操作倒水方式 (比如你可以找100个人来排队倒水, 以尽量最大化倒水的速度), 你也只能在最开始的50次 (相当于50个周期) 做到3个人同时倒水, 但是剩下50次你只能往(B)里倒, 这时候无论你倒水水平多高, 你也做不到你所谓的3人同时倒水的最大能力. 难懂?[attach]2030057[/attach]

作者: 围观 时间: 2012-9-21 06:29
在主楼中是32bit*4 (总量1G) 的颗粒搭配 16bit*4 (总量1g)的颗粒.
所以为什么楼主说你这个和你打的靶子是一样的 (没有本质区别) 呢? 不好好理解别人的话, 自己扯来扯去说不到地方上. 不知道你在想什么.

非对称搭配的问题在于显存颗粒本身, 根本就不是控制器的事 (就像48#中那样, 控制器的能力相当于 "派人打水的能力", 再强也没用), 你就算是让那64bit对应的颗粒可以让一百个MC来艹, 当显存容量被占满时, 里面照样是有512MB的数据不能很快的存取.

作者: westlee 时间: 2012-9-21 07:06
提示: 作者被禁止或删除内容自动屏蔽

作者: xiaxin222a 时间: 2012-9-21 08:47
本帖最后由 xiaxin222a 于 2012-9-21 08:51 编辑

westlee 发表于 2012-9-21 07:06
是71mb还是71g？

为啥从实际游戏测试来看，这个特点对550ti的游戏性能没有明显影响呢？

按照数据后面6位小数来看，应该是71G...
单就那256M区域带宽确有瓶颈，但实际应用中极难出现前面3/4内存空间锁死不更新只使用后256M的情况,宏观来看影响被淡化了吧..

作者: sucKing 时间: 2012-9-21 09:08

xiaxin222a 发表于 2012-9-21 08:47 按照数据后面6位小数来看，应该是71G... 单就那256M区域带宽确有瓶颈，但实际应用中极难出现前面3/4内存 ...

同意 …

作者: flhssnake 时间: 2012-9-21 10:13
楼主我的公版660ti可能到到时候我提供数据吧不过现在我的卡还在路上

作者: 50857817 时间: 2012-9-21 10:14

樟树发表于 2012-9-21 00:45
我专门借了一块GTX550Ti, 花了45分钟改代码做了我在一楼提到的测试
另外还花了十几分钟发帖，以示我对这个 ...

你太认真了，人家既然不肯接受错误虚心学习，你笑笑就好了，以后不准再“喷”大神了哦

作者: flhssnake 时间: 2012-9-21 10:21

xiaxin222a 发表于 2012-9-21 08:47
按照数据后面6位小数来看，应该是71G...
单就那256M区域带宽确有瓶颈，但实际应用中极难出现前面3/4内存 ...

+1 主要是楼主提供的代码强制写入并锁死前面高位宽空间，排除高位宽的干扰来测试在极端情况下的本质情况
游戏中会实时刷新的，并且释放的所以目前这个本质没有暴露出来

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

xiaxin222a 发表于 2012-9-21 08:47
按照数据后面6位小数来看，应该是71G...
单就那256M区域带宽确有瓶颈，但实际应用中极难出现前面3/4内存 ...

对...

在1024M都被使用的情况下，按照测试出来的值，全部访问一次需要的时间是（786/71 + 256/25, 而如果全部都能达到满带宽，需要时间为（1024/71）,最差情况下大概仍然有70%的性能。而考虑到计算与访存间的并行，以及显存只有前面用完后才会分配到这一段，一般不会用满，实际情况应该好一些。

而在爆显存的情况下，得到的结果是(768/71+256/4)，按照PCI-E一般单向实测带宽（4GB/s-5GB/s左右）,此时最差性能是19%左右。

仅考虑显存因素，而且取理论值，实际情况具体数字应该有一定差别。

作者: xiaxin222a 时间: 2012-9-21 10:57
本帖最后由 xiaxin222a 于 2012-9-21 10:58 编辑

樟树发表于 2012-9-21 10:46
对...

在1024M都被使用的情况下，按照测试出来的值，全部访问一次需要的时间是（786/71 + 256/25, 而如 ...

爆显存的情况下，不是0.768/71+ 0.256/25+NG/6么？

作者: westlee 时间: 2012-9-21 11:00
提示: 作者被禁止或删除内容自动屏蔽

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

xiaxin222a 发表于 2012-9-21 10:57
爆显存的情况下，不是0.768/71+ 0.256/25+NG/6么？

考虑只有768MB显存，其他需要过PCI-E

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

westlee 发表于 2012-9-21 11:00
实际游戏，4aa下显存占有提升200m是很正常的情况，性能是99%，和你的理论数据差距极大，我不得不怀疑你 ...

提升200MB，但是仍然未爆显存时，说明使用的显存仍然在1024MB以下。
但是具体值是未知的，是不是在768MB以下，或者是否有其他因素成为瓶颈，都是未知的。

作者: Episar 时间: 2012-9-21 11:14
果然是“科学”啊~~学习了~~
某猫某六加油

作者: xiaxin222a 时间: 2012-9-21 11:31

westlee 发表于 2012-9-21 11:00
实际游戏，4aa下显存占有提升200m是很正常的情况，性能是99%，和你的理论数据差距极大，我不得不怀疑你 ...

你查看到的显存占用，其实并不是一定是实际占用量。

作者: westlee 时间: 2012-9-21 11:48
提示: 作者被禁止或删除内容自动屏蔽

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

westlee 发表于 2012-9-21 11:48
也就是说你的理论对于显卡选购毫无意义，相信你的理论还不如相信nv对于产品硬件配置的合理性的把握。

NV作出这样的设计应该就是基于相同的理论。

作者: 围观 时间: 2012-9-21 12:55
月神又不说话了?
怎么每次捅到你Ｇ点的时候你就息声了？　每次讨论都是 "xxx我难道要从xx给你解释一遍?" 或者 "你难道不知道xxxx?", 而且回复经常牛头不对马嘴, 但是当别人举出实实在在的例子的时候, 你就只会沉默?

作者: inSeek 时间: 2012-9-21 13:06
极端情况下是这个样子的。但是这情况只会出现在从0MB占用到涨到768M占用这个过程中，全程都是连续的192bit写入整片数据，然后锁定这768M的数据，再接着尝试写入数据才会出现的吧

但其实这3个64bit的MC可以分开独立操作的，要存取的数据也不会是整片连续的，且很多的时候存取的数据块都是小于192bit的，所以这类极端情况基本不会有，且存在了大量优化/规避的可能...

作者: 围观 时间: 2012-9-21 13:17

inSeek 发表于 2012-9-21 13:06
极端情况下是这个样子的。但是这情况只会出现在从0MB占用到涨到768M占用这个过程中，全程都是连续的192bit写 ...

你说的情况在某种程度上可以规避这种缺陷,
不过我觉得吧, 与其认为 "非对称设计多出来的部分单独被用到的可能性很低", 不如直接去掉这多出来的部分好了.
你可以仔细考虑一下那多出来的256MB的 "价值", 其实往往是很低的, 当你用到它的时候, 速度会下降 (虽然没有爆显存那么明显), 而且大多数情况下你用不到它.

对于你说到的优化和规避问题, 我觉得大致来说, 就是在空闲时间去调整数据的存储位置. 这个吧我感觉对于cpu-内存来说, 还有可能, 但是对于显存来说的话, 显卡工作的吞吐量是很大的, 数据也都是成批成批的存取, 很难说有时间调出来干这种技术活, gpu还是比较粗暴的玩意. 不过这只是我的看法, 可能这种优化-调整的方式在某些情况下会有效.

------
最后我想说的是, 楼主其实目的就是指出这种显存不对等搭配带来的理论上的不可避免的问题, 他是为了反驳 "某编辑在某文中大肆歌功颂德某显卡厂商, 号称某显卡厂商解决了这个问题" 的这种低能行为. 如果大家把这当做一场辩论, 而且承认这个不可避免的缺陷的话, 那我是不是可以认为你们是站在楼主这边的?

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

围观发表于 2012-9-21 13:17
你说的情况在某种程度上可以规避这种缺陷,
不过我觉得吧, 与其认为 "非对称设计多出来的部分单独被用到 ...

没，我只是看了一圈MC没看懂，最后又回到原点数显存而已。

首先自我检讨文章题目太伤人，一会编辑掉
然后小月月这次做了很多对GDDR5显存颗粒研究，
只是立论时使用非对称显存的缺陷作为靶子，而反驳理由是clamshell对峰值性能没有影响而已。
坦率而言整篇文章现在去掉非对称显存的部分以后，还是有内容可以看看的。

非对称显存虽然存在性能上的不足，但是实际使用中遇到几率不大，并且即使出现比爆显存时性能也高一个数量级
显卡采用非对称显存应该作为一个加分项，而不是缺陷来看。

散了散了

作者: 围观 时间: 2012-9-21 13:48

樟树发表于 2012-9-21 13:38
没，我只是看了一圈MC没看懂，最后又回到原点数显存而已。

首先自我检讨文章题目太伤人，一会编辑掉

你别这么自谦, 自谦某种程度上就是对另一方的鄙视.

建议题目改回.

既然一篇文章立论和论述方式没有任何关系, 那这文章有什么价值?
换句话说, 路人甲说A的数学不好, 结果A反驳来反驳去都在说自己作文写得如何如何优秀, 那算是什么玩意?

还某站编辑呢, 无节操.
-----
另外一个建议是没事干不要编辑自己写过的东西, 尤其是这种有争议的帖子, 以备自查, 还有我觉得先编辑帖子的一方, 往往都是理由站不住脚的一方.

作者: ilovejulia 时间: 2012-9-21 13:51
本帖最后由 ilovejulia 于 2012-9-21 14:01 编辑

我讲一下我的理解

MC<==>32bit/256MB  (带宽为32bit)
MC<==>32bit/256MB  (带宽为32bit)
MC<==>32bit/256MB  (带宽为32bit)
MC<==>32bit/256MB  (带宽为32bit)
MC<==>16bit/256MB+16bit/256MB  (两颗显存通过clamshell mode连接MC带宽为32bit)
MC<==>16bit/256MB+16bit/256MB  (两颗显存通过clamshell mode连接MC带宽为32bit)

因为后两个连接为两个16bit/256MB通过clamshell mode连接到一个MC上，提供类似双通道的存储模式，所以对于MC而言成为了一个32bit/512MB的显存颗粒。
[attach]2030546[/attach]

这2组就对应了正反两面对应的4颗显存。组成了192bit/2GB的显存规格。

作者: inSeek 时间: 2012-9-21 14:22
其实我只关注实际使用中的效能，至于是不是在某些特别情况下有问题但是没啥想法，毕竟现在的所有硬件的构架设计之初就是针对现有或者可预见的未来的绝大部分应用的特点的。所以我关心的也只是测试环境的搭建是不是足够贴近绝大部分实际应用的特点。脱离实际的测试都没啥参考意义...
就像真的需要，完全可以构架出一个对称多通道下最后500M速度剩下为1/n的测试环境。问题是这个情形也脱离实际...

貌似你也木有理解俺上贴说的：
GPU 存/取数据并不是时时刻刻次次都需要来个192bit或者128bit的，3个MC完全可以是3个不同的任务，且任何MC可以存取任何颗粒，所以那只能“单通道”带宽访问的500MB部分不就存在这类情况下（比如就64bit的存取）的使用价值且不因带宽拖GPU后腿么？。而同样的，因有这类小数据操作的需求，所以在被用满3/4显存之前，完全可以一路优化着使用显存...而不必必须一路一直均量的用所说的3个通道下的显存。这点我发现可能是LZ的一个错误理解，实际上不存在 3个通道存900MB数据，然后每个通道之下必须各存300MB这个限制...

最后...月虫文中要表述的东西和这个贴说的问题感觉完全不是一个事情啊... ... ...

作者: inSeek 时间: 2012-9-21 14:33
本帖最后由 inSeek 于 2012-9-21 14:34 编辑

另外 LZ有个误区。MC和具体的颗粒没有恒久远的绑定关系。MC0 MC1 MC2和颗粒0 颗粒1 ... 颗粒7 没有一直固定的绑定，即可以在时刻a MC0存取颗粒0，时刻b可以存取颗粒7 等等等等...

作者: 围观 时间: 2012-9-21 14:35

inSeek 发表于 2012-9-21 14:22
其实我只关注实际使用中的效能，至于是不是在某些特别情况下有问题但是没啥想法，毕竟现在的所有硬件的构架 ...

某编辑的文中完全就是在讲MC对显存可以交叉操控的方式如何如何好, 丝毫没有论述是如何解决不对等搭配造成的某些情况下的带宽瓶颈问题的.
-------
你说的东西我认可. 你的意思就是这种搭配对于某些数据处理是比较有益的.

不过我还是感觉, 对于GPU来说, 这种 "异化" 的显存搭配方式没有太大意义, 如果是cpu-内存可能还有点意思. 毕竟cpu-内存处理数据的特点和gpu-显存有很大不同. 显存里好像没有什么 "特殊" 的数据需要一般数据1/3这么大的量来存放, 你说的 "小数据" 即便和其他数据不加区别, 在gpu处理中也不见得会有什么影响.

我个人还是感觉, gtx660ti这种搭配吧, 估计是NV根据上代580做出的调整, 可能他们认为580的显存大小使得对手在某种程度上抓住了一些 "噱头", 所以销量受到了影响. 单论目前的实用价值来看, 1.5g显存和2g本身就没啥大差别 (尤其是针对660ti的应用环境而言), 更何况是和这种混搭风格的2g相比较呢?

我一直觉得580 的1.5g就挺好, 660 ti的2g在某种程度上, 还是受到了某种脑残的 "显存容量为上" 的观念的影响, 毕竟销量很重要, 而且加几个16bit的渣芯片, 成本也不大.

作者: inSeek 时间: 2012-9-21 14:54

围观发表于 2012-9-21 14:35
某编辑的文中完全就是在讲MC对显存可以交叉操控的方式如何如何好, 丝毫没有论述是如何解决不对等搭配造成 ...

问题就在于你说的某种情况在实际使用中几乎不存在... ...这类几乎不存在的情况拿来当普适的就不大科学了

作者: iamw2d 时间: 2012-9-21 15:01

inSeek 发表于 2012-9-21 14:54
问题就在于你说的某种情况在实际使用中几乎不存在... ...这类几乎不存在的情况拿来当普适的就不大科学了 ...

如果这样理解岂不是那512m就成了大部分时候都无用的东西了？

作者: 围观 时间: 2012-9-21 15:17

inSeek 发表于 2012-9-21 14:54
问题就在于你说的某种情况在实际使用中几乎不存在... ...这类几乎不存在的情况拿来当普适的就不大科学了 ...

其实仔细来说是这样, 我拿数字打个比方 (不一定准确)

正常情况下, 位宽和容量是对等的, 这种情况下对应的工作时间可能是99,
显存被占满被迫使用系统内存的情况, 可能只相当于1 (相对于上面的99来说)

而添加这非对称显存的设计后, 只是把这个 "1" 里面的0.8 转化成了1/3带宽的降速情形, 里面的0.2的情形还是爆显存.

总的来看没啥意思.

-------
简单来说就是, 如果要承认这种1/3的缺陷模式工作状态很少出现的话, 那可以做一个合理的推断, 就是本身这种非对称的搭配方式的意义就不大, 因为需要用到那多出来的无法让MC全力工作的显存的情况也会很少.

作者: 围观 时间: 2012-9-21 15:19

inSeek 发表于 2012-9-21 14:54
问题就在于你说的某种情况在实际使用中几乎不存在... ...这类几乎不存在的情况拿来当普适的就不大科学了 ...

不过这些我也没有什么靠谱的数据来说明. 只是纯个人感觉.

我还是想针对这贴子本身说说. 就这贴子本身所讨论的问题而言, 某编辑的说法真是牛头不对马嘴.

作者: yellowfly 时间: 2012-9-21 15:41
说穿了就是其实1.5GB就完全足够660ti耍了···多出来那512M聊胜于无，好看的目的占绝大多数

作者: divx001 时间: 2012-9-21 16:14

yellowfly 发表于 2012-9-21 15:41
说穿了就是其实1.5GB就完全足够660ti耍了···多出来那512M聊胜于无，好看的目的占绝大多数

等暴显存就知道是不是聊胜于无，即使是带宽减半也远比从PCIE读要好N倍。

作者: taizer 时间: 2012-9-21 16:41
随即连续存储的事情，非要划分开来看，越想就越糊涂。
顾胖子要崩溃了··········

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

iamw2d 发表于 2012-9-21 15:01
如果这样理解岂不是那512m就成了大部分时候都无用的东西了？

真服了你的理解力，人家明明是说：围观说出现瓶颈的这种应用，完完全全是在实际中不存在的情况。。。
所以只剩下512M显存了，从而带宽下降只是头脑中的例子。。。

你的理解和别人的意思完全相反。。。

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

围观发表于 2012-9-21 06:23
我真是给你跪了, 别动不动上纲上线的, 我再把例子解释一遍, 你真想讨论就好好讨论, 带点攻击性话语无所谓, ...

这种不同FB管理如此差别的容量的情况，完全可以在ＭＣ的调度上去trade off.

在这里地址的调度算法是可以部分的解决问题的。  地址位再多解析几位不纠结了。。。非得让我告诉你。
在我刚才说的地址位，选之前的再解析两位，记录状态，注意这里的每一种对应的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:56

asdfjkl 发表于 2012-9-21 16:45
这种不同FB管理如此差别的容量的情况，完全可以在ＭＣ的调度上去trade off.

768 768 512配置时，不做编码的结果是1536MB 100%, 512MB 66%
而编码后结果为1639MB 97%, 409MB 66%，对于某些应用可能是改进吧。

可见，改进主要来自条件设定中，三个FB容量比以前更平均。反过来又说明了我的观点：
非对称一定有性能损失，hash只能让更大容量平摊性能降低。

作者: 围观 时间: 2012-9-21 17:14

asdfjkl 发表于 2012-9-21 16:45
这种不同FB管理如此差别的容量的情况，完全可以在ＭＣ的调度上去trade off.

你这回来回去是逼我辩呢?

你是真不懂还是装不懂?
两种颗粒, 容量相同, 位宽不同. 你一块用的时候, 其 "容量/存储速率" 是不对等的, 无论如何你不可能让他们总是满负荷运作的, 位宽高的 (更快的) 肯定要迁就位宽低的, 你的任何做法都只能让这种 "迁就" 看上去更均匀, 而不是突破这一理论瓶颈.

仔细做自己的推算, 我不明白为什么一个如此简单的道理, 让你理解起来就跟登天一样难.

作者: 围观 时间: 2012-9-21 17:19
月神看样子是已经低头沉默了, 摇尾猫神还是不死心啊.

作者: 围观 时间: 2012-9-21 17:19
以后没事这贴我就顶一顶.

作者: percyxl 时间: 2012-9-21 17:20
提示: 作者被禁止或删除内容自动屏蔽

作者: westlee 时间: 2012-9-21 17:34
提示: 作者被禁止或删除内容自动屏蔽

作者: asdfjkl 时间: 2012-9-21 18:15

westlee 发表于 2012-9-21 17:34
我50楼的测试算是白贴了。460 768m的从1680 0aa->4aa->8aa的性能下降幅度远大于550ti 1g，很显然显存容量 ...

你是实测的数据，的确表明了这一点！

作者: sucKing 时间: 2012-9-21 18:20
本帖最后由 sucKing 于 2012-9-21 18:38 编辑

1g的460应该没有可比性，编辑掉…

作者: flhssnake 时间: 2012-9-21 19:09
楼主麻烦编下660ti的那个测试我配合你
[attach]2030963[/attach]

作者: westlee 时间: 2012-9-21 19:13
提示: 作者被禁止或删除内容自动屏蔽

作者: 樟树 时间: 2012-9-21 19:27
本帖最后由樟树于 2012-9-21 19:41 编辑

原文下很多人和我提出了一样的质疑，原因就是mooncoon后面说的和非对称显存完全没有关系，一圈以后并没有解决非对称显存的配置是否有一定地址段存在性能降低这个问题。
而我认为正确的测试手段我也发出来了。这个代码只要改187行那个参数，在660Ti上应该同样可以运行。现在回过头来看原文：

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

　　这就是我们的媒体同行在文章中所提到的问题。如果GeForce GTX 660 Ti以及GeForce GTX 660采用的非对称显存体系以及PCB布局真的导致了这样的问题，那可是一件非同小可的事，它代表NVIDIA向市场投放了带有设计问题，甚至可以说是不成熟的产品，这不仅会严重影响GeForce GTX 660 Ti以及GeForce GTX 660的可购买性，还会影响到由Kepler其他产品积累起来的认同度。更为严重的是，NVIDIA竟然并未对此做出任何回应，也没有对新的非对称显存体系进行任何有效地更深入的说明。

这就是小月月的靶子。而小月月通过测试和论证说明的是峰值性能没有受到影响。
讨论到现在以后，我们经过一圈以后回到了原点。被引用这一段没有提到最后512MB是被最后分配的，没有提到有hash的方法用来做trade off，但不提也没问题，重点已经有了。

目前看来这个靶子是正确的，正确的论点和论据应该是本楼中westlee放出的图：实际情况中影响不大，并且相对爆显存好得多。

作者: sucKing 时间: 2012-9-21 20:23
这个问题要老黄派人来回答吗！？

作者: mooncocoon 时间: 2012-9-21 20:33

樟树发表于 2012-9-21 19:27
原文下很多人和我提出了一样的质疑，原因就是mooncoon后面说的和非对称显存完全没有关系，一圈以后并没有解 ...

如果一开始就这么和谐的话，我觉得我们之间进行沟通不会有任何的问题，最关键的是不会招来那么多的苍蝇。
幸亏这两天个头更大的几只苍蝇没来上班，要不我们之间的沟通和交流将无从谈起………………

今天白天写了一整天的AMD配合，目的是作一篇HD7750大胜650的文，别管我怎么写的，反正我写完了而且正常情况下你们也看不到……这个就当时我拖到现在才来回复的解释吧。刚刚我大概看了代码，也明白了你我之间的问题以及你这个设计实验要验证目的的错误，或者说考虑不周之处了。

好吧，冷静下来，我们来看看你设计的这个实验吧。
int spacerSize = sizeof(unsigned char) * 1024 * 1024 * 670;
int memSize = sizeof(unsigned char) * 1024 * 1024 * 64;
//allocate host memory
unsigned char *h_idata = (unsigned char *)malloc( memSize );

//initialize the host memory
for(unsigned int i = 0; i < memSize/sizeof(unsigned char); i++)
{
h_idata = (unsigned char) (i & 0xff);
}

你通过指针让显存线性写入，然后通过锁死阻止了被写入显存的刷新，这样就可以做到让显存在考虑帧缓存影响的前提下被固定的填满。接下来，你通过指针把内存地址和物理地址“绑定”，让后写入的数据永远被指向高位地址，借以达到让整个显存体系在被你塞满一部分之后“仅剩下”看上去有问题的那组不对称位上的显存颗粒，这很棒。

但是，你塞满的到底是“谁”……
你考虑过帧缓存的存在会导致指针整体后移么？你考虑过写入显存以及锁死对帧缓存所在缓冲区域的影响么？表面上看你塞满了显存颗粒并组织了它们的刷新，但实际上，你锁死和阻止刷新了480MB显存之后剩下的，确定就是那2颗非对称端的颗粒么？

你填满，或者说等效填满了的其实并不是特定的一部分显存颗粒，而是与这些显存颗粒对应的地址线~~~

我们来看看你的测试结果吧。

0~400MB填充并阻止刷新，实际带宽是理论带宽的80%（粗略）并大体不变
400~480MB填充并阻止刷新，性能出现随机波动，波动没有小样本收集可以总结的规律，同时波动范围刚好是1/3性能~略低于0~400的情况（还是粗略）之间
480~670MB填充并阻止刷新，性能下降至0~400的1/3。

为什么刚好是3段？为什么最后的性能刚好是初始性能的1/3？

因为你实际上将地址线以接近3段的形式堵死了
在第一阶段的试验中，你将一部分显存（不包括帧缓存以及其他杂七杂八所占用的部分）填满并锁死，因为指针指向固定物理地址的关系，这部分显存颗粒就无法再被MC访问到了，于是，这部分颗粒相连的地址线，也就因为点对点的物理链接而在整个存储过程中变得没有意义了。他们没有消失，他们依旧可以被访问到，但是他们所连接的mem已经无法被MC操作，他们也无法跟其他mem产生任何物理联系，所以他们失去了存在的意义。

换句话说，塞满显存等于实际上将这块显卡从192BIT一步一步的拖到了128/64bit……
不管你有多少颗显存被连上了地址线，不管你有多少根地址线，不管你有多少个显存控制器，最终如果只剩下1组2根32bit地址线，你认为这样的测试是在干什么？难道测试场景不是已经变成了测试一块64bit显存位宽的550Ti的实际显存带宽了么？现在我们面前有3组64bit显存控制器，但可以使用的访问通道却只有一组，你认为会产生什么结果呢？
我的测试平台没安装VS，所以也没有一个合适的配置环境去吧你写的CU添加到CUDA SDK里进行测试。但我可以做一个预言——如果正确的修改了你的代码，将填充显存尺寸继续扩大或者缩小，所有可以进行测试的N卡，不管他是不是非对称显存的显卡，都应该会出现类似的问题：小尺寸~中等尺寸填充，比如说（并不是确定值，因为帧缓存神马的很讨厌，会导致指针实际指向发生些许变化）还是0~400MB填充时性能不会有多少变化，接下来随着尺寸的放大，性能会开始出现波动，波动范围因MC个数不同而不同，具体情况会因为随机存储过程的随机性以及显存操作优化程度的不同而各异，但最终，带宽测试一定会在占用并锁死的显存达到一定数量之后衰减到峰值数值的MC个数分之一。256bit的最终测试结果将会是峰值的1/4，384则应该是1/6.
我讨厌分页……话还没说完呢就打不下了……

作者: 樟树 时间: 2012-9-21 20:40
本帖最后由樟树于 2012-9-21 20:41 编辑

mooncocoon 发表于 2012-9-21 20:33
如果一开始就这么和谐的话，我觉得我们之间进行沟通不会有任何的问题，最关键的是不会招来那么多的苍蝇。 ...
显存自刷新和我代码差了N层。我只不过连续分配了一段显存，然后测另一段显存读写速度罢了。

如果对称存储器上分配显存就能造成峰值性能突降2/3，那还真是可怕。

如果我用GT640可能你又说Kepler架构不一样了。
这样吧，我换个GTX480。

作者: mooncocoon 时间: 2012-9-21 21:12

樟树发表于 2012-9-21 19:27
原文下很多人和我提出了一样的质疑，原因就是mooncoon后面说的和非对称显存完全没有关系，一圈以后并没有解 ...

接着我们刚才的事进行讨论。

正常显存的刷新可以尽快释放显存空间，同时被释放的还有地址线，这种占据/释放的过程会在随机存储过程中充当模糊数据的作用，同一时刻总会有无法被使用的地址线，而及时的释放又会让大多数地址线变得可以被访问，于是实际操作带宽和理论带宽的差值就出现了。一般意义上的显存存储体系优化甚至包括cache的加入以及优化都会影响到这一差值，让这种因为统计学概率导致的地址线不足而出现（当然，他并不是唯一导致带宽差距的原因）带宽差异发生变化。但无论如何，即便你在某一个时刻充塞了所有的地址线，只要下一个时刻能够释放它，它就依旧可以在整体宏观操作中发挥作用。

而现在，你完全充塞了它们，所以也就让它们在接下来的存储动作中失去了存在的意义。而你充塞它们的动作本身又导致了整个测试的结果形态。不管它们到下面怎么去连接，550Ti的显存体系都是3组MC对应3组地址线。当你的填充逐渐让1/3的显存被塞满并且无法被释放时，1/3左右的地址线也就没用了。在这之前，性能不会有明显衰减，或者说出现衰减的机会非常非常小。接下来，你的填充会导致超过1/3的地址线被占用并且无法释放。当被充塞地址线的数量在一个连续时间内都跨过临界点1/3时，显存体系实际上就变成了3组MC VS 2组地址线，这就让测试进入了波动的区间。接下来，你继续填充显存，更多的地址线被长时间的充塞而失去了意义，当被充塞地址线的数量在一个连续时间内都跨过临界点2/3时，整个体系就变成了3组MC VS 1组地址线。
于是，某只逻辑性很好的苍蝇描述的10个男人1个洞的场景，就被创造出来了。任你MC再多，颗粒规格再诡异还是再正常，3个MC都不可能在一个周期内同时使用1组地址线。于是测试的结果，也就很明确的出现了……

最简洁的说法——不管你怎么测试，你实际上都是在测试削减显存位宽对显卡带宽的影响，而不是特定颗粒是否可以被正确的或者说“正常”的读写操作以及它们能不能表现出正确的带宽。

你设计的实验，与你要表达的意思，我所要表达的意思以及你理解的我文章的意思其实全都不相干，截止到上一贴之前你跟我的争执，苍蝇们看到的争执以及我们要争执的事，其实根本就完全没对上。另外，你制作了一个精妙但不能达到目的的实验……

其实我在争论开始没多久的时候就已经表达了我的想法，MC与显存的关系，其实就是MC+地址线的关系。bank不超过上线的话，MC对MEM的访问只跟地址线有关，跟地址线背后的显存容量和分布形态是没有关系的。如果把随机存储中所有底层细节全部看做是一个黑箱，把地址线后面的显存看做是一个显存池，你应该就能找到这种感觉了。在带宽的世界里，实测带宽基本上只与地址线被释放的及时度有关，地址线被长时间占用，这种占用超过了宏观随机并行过程对延迟的掩盖能力，那么带宽就会掉。而地址线被释放的及时度，又由显存刷新的及时程度相关，如果显存像现在这个实验中那样在写入后被人为锁死，那么它所在的内存颗粒或者内存池所占用的地址线也就失去了存在的意义。

还有一个小要素影响着性能和结果，但我无法度量这一要素产生影响的程度——无论你用什么方式，帧缓存所在的区域是不能被锁死的，他们会被程序自动的保护起来并剔除到整个操作之外。你定义的顺序写入显存并不能保证将数据随心所欲的写入到你希望被塞满的那部分颗粒中，起码在我看到并且看懂了的代码部分并不包含这样的动作，实际上你也不可能在正常完成测试的前提下坐到这一点。因为你定义的指针指向起点，不可能是严格意义上的物理地址起点，即便我们运气好刚刚好塞住了那部分显存，我们也不能保证刷新帧缓存之后在进行测试，被同样动作塞满的依旧还是那部分显存。

如果有条件的话，其实你应该可以轻松的进行延展实验，在接下来的实验中，660Ti肯定会出现类似550Ti的衰减，但其余的N卡，甚至可以说所有能进行该测试的N卡，都将会出现分段式的带宽变化以及最终稳定的带宽缩减。因为所有N卡的MC都会经历面前的地址线从N变成N-X并最终变成1的过程，N以及N-X但X不大时，带宽衰减不明显或者不衰减，N-X达到一定数量时带宽开始衰减，N-X=1时，带宽停止衰减并重归稳定。如果你没有取得这样的结果，希望你继续把代码贴上来，我好可以进一步与你保持交流和沟通。

我下了一个热乎的VS2008，周一我回去办公室配置你的CU，进行适当修改并用它来测试其他对称显存模式的N卡。因为以前其实没干过这个，我不知道其他不同容量的N卡的物理地址以及帧缓存分布情况是否会有什么不同，不知道会被保护起来不被锁死的显存到底有多少以及到底分布在哪里，所以不敢保证指针是不是还会工作正常。如果代码修改遇到问题，我会向你求助和沟通的。如果测试成功并且跟我所预言的一样，那我就不再回复这个帖子了。如果测试失败并导致了新的结果，我会将结果更新上来。我们到时候再一起讨论。

我不知道测试结果，我也不知道我的预言以及分析过程是否100%正确，但既然是讨论，即便我的想法是错误的，把它们说出来也不是什么值得羞耻的事情。但是你也看到了，要描述一件事，尤其是尽可能清楚的描述一件事，透过敲击键盘的方式究竟会有多么的费劲。坐下来谈的话，其实这事情20分钟就可能说清楚了，甚至最多一顿饭的工夫就足够了，但在论坛里说，需要耗费的时间却会成倍甚至十数倍的增加。我每天都要工作，工作之余还要思考我不知道的同时渴望知道的事情，我没有时间和精力静下心来去跟每一个论坛上的人恳谈。文章是我写的，但论坛上的靶子真不是我立起来的。我是一个在乎别人看法，尤其是值得尊重的人对我的看法的人，所以这种靶子立起来之后我肯定会管不住自己的进行回应。但时间和精力，让我不可能把一个问题掰开揉碎的再细讲一次。留下的空档就给了苍蝇们围上来的机会，而苍蝇们对我情绪的破坏又会进一步加剧沟通手法的失误……周而复始，恶性循环，我的精力被消耗，问题没有得到解决，我对了没人理解，我错了也无法获得正确答案并更正。对苍蝇们的驱赶又没有显著的效果，SO……

在看过代码之后，你的实验设计过程让我感觉到了你思考问题的耐心和能力，这种遇到问题之后会自己考虑一个试验模式去加以验证的方法让我感动和欣赏，所以我尊重你并挤出时间来跟你进行进一步的交流。如果你愿意的话，我可以PM联系方式，我们以电联等更加畅快的形式去沟通也许会更加有效。

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

我说我在GTX480上测了spacer size对带宽没影响也没什么意思

大家一起来玩好了，这次下载应该能运行，不需要SDK。如果说少了cudart.dll我再想办法。

1. 下载后改名为spacertest.7z,论坛不能上传.7z文件
2. CMD命令行到解压后目录
3. 运行命令
bandwidthTest.exe -spacer=400

其中400为spacer大小，可以自己修改，不要写非数字的东西，不要写小数。
太大的值没法分配，不过也不会有事。
单位MB。直接运行bandwidthTest.exe时大小为1MB

作者: mooncocoon 时间: 2012-9-21 21:15

樟树发表于 2012-9-21 20:40
显存自刷新和我代码差了N层。我只不过连续分配了一段显存，然后测另一段显存读写速度罢了。

如果对称存储 ...

我所要表达的可不是显存自刷新，你不是通过指针把数据指向了特定的地址位，然后将它门锁死了么。
如果我看错了代码，其实你并没有进行这一步的话，那大幅衰减的结果无论出现在什么时候都将是恐怖并且不可解释的了……

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

mooncocoon 发表于 2012-9-21 21:15
我所要表达的可不是显存自刷新，你不是通过指针把数据指向了特定的地址位，然后将它门锁死了么。
如果我 ...

我可没指向特定地址位，只不过分配了一定显存后，再分配一块看看带宽是不是符合非对称显存特征罢了。

非对称显存在分配一定容量后，再往后地址段的性能都要降低
而对称的从1 到out of memory，带宽都会稳定。

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