POPPUR爱换

标题: 自从传闻390X用4G显存后，对显存大小的认识就有些变化了。。。 [打印本页]

作者: asdfjkl 时间: 2015-3-18 17:16
标题: 自从传闻390X用4G显存后，对显存大小的认识就有些变化了。。。
本帖最后由 asdfjkl 于 2015-3-22 11:20 编辑

今天看到这么一个说法：
1）
爆显存！= 卡顿，大家无须担心
“,,,,,,,,,,,,,,,,,，但是，爆显存也不见得卡顿，不用太care”

第二种说法：
2）
290X 4G在1080p和4K的差距可以忽略不计“

”
潜台词就是4G显存对于4K分辨率绝对够用， 390X用4G完全合理；可怜的970，主打1080p的却被喷出翔了。。。

第三种说法：（来自同一个人）：

390x 只要性能强。那怕是4G还是有人去买的。毕竟目前超过4G 显存的游戏还是不多

4K显示器普及起码3--5年后~~~~ 现在21.5--23 显示器 1080P才刚刚开始呢

现在的电脑基本上99% 是1080P的而且大多是是低端显卡或者集成显卡 4K普及从何说起·~

哥笑了，请问99%的PC玩家都是1080P，所以Fiji就应该是4GB吗？ 99%的PC用户买的都是高端旗舰699美金+的Fiji吗？在这人口中PC玩家中1080P比例完全是自适应，倘若Fiji标配是8G，为了强调和980/970的差异，我相信这货口中1080P的比例肯定不是99%。

懂得自然懂！~

作者: archangelzry 时间: 2015-3-18 18:43
不是已经开始造势了吗?HBM显存速度特别快,完全没问题,还可以双卡交火共享,等于8G显存,我当时就傻了

作者: jhg1159 时间: 2015-3-18 18:45
Titan X

真的有必要12G么.

作者: G70 时间: 2015-3-18 18:47
提示: 作者被禁止或删除内容自动屏蔽

作者: yfren01 时间: 2015-3-18 21:02

jhg1159 发表于 2015-3-18 18:45
Titan X[dry>真的有必要12G么.

旗舰显卡，当然有必要。

作者: asdfjkl 时间: 2015-3-18 22:07

archangelzry 发表于 2015-3-18 18:43
不是已经开始造势了吗?HBM显存速度特别快,完全没问题,还可以双卡交火共享,等于8G显存,我当时就傻了

交火可以共享显存在现有的GPU架构下完全是扯淡，一张卡的GPU要通过PCIE 接口才能访问另一张卡的显存。
PCIE的带宽和显存的带宽，有着绝大的差距，怎么共享？怎么叠加？

除非像NVLINK这种接口普及了才有机会（注意，也只是有可能），GPU与GPU之间直连；数据通路带宽够大，延迟够低。

作者: G70 时间: 2015-3-18 22:42
提示: 作者被禁止或删除内容自动屏蔽

作者: chrislue 时间: 2015-3-19 04:54
12G没有必要，8G有必要

作者: eraser666 时间: 2015-3-19 08:43
Pro-A嘴中的显存需求等于AMD的显存大小

作者: G70 时间: 2015-3-19 12:38
提示: 作者被禁止或删除内容自动屏蔽

作者: Xenomorph 时间: 2015-3-19 13:15
不管怎么说，12G确实大了点。快点换新制程高容量的颗粒吧。

多卡共享显存目前不行，而NVLINK短时间也很难被广泛接受吧，不然怎么搞双接口了。

关于单卡双芯，我在想能否通过一个总线，让2枚GPU的显存控制器管理和调用这双倍的容量。

作者: G70 时间: 2015-3-19 13:28
提示: 作者被禁止或删除内容自动屏蔽

作者: eraser666 时间: 2015-3-19 17:36

Xenomorph 发表于 2015-3-19 13:15
不管怎么说，12G确实大了点。快点换新制程高容量的颗粒吧。

多卡共享显存目前不行，而NVLINK短时间也很难 ...

有单颗1G的8Gbps的显存，不知道为什么不用

估计是产能问题

毕竟GM204很走量

作者: 伪娘死光光！！ 时间: 2015-3-19 18:17

eraser666 发表于 2015-3-19 17:36
有单颗1G的8Gbps的显存，不知道为什么不用

估计是产能问题

估计目前很贵

作者: Xenomorph 时间: 2015-3-19 23:00

G70 发表于 2015-3-19 13:28
物理层面上如何实现？

额外弄一个“巨大”的外置MC接驳所有memory，再让这个外置MC同时对接2枚GPU的原接驳各自memory的线。

瞎扯幻想出来的，欢迎各种吐槽……

作者: Xenomorph 时间: 2015-3-19 23:01

eraser666 发表于 2015-3-19 17:36
有单颗1G的8Gbps的显存，不知道为什么不用

估计是产能问题

应该是时间点不对。Samsung跑出来说的时候GM200已经搞完，注定悲剧了。

这些显存估计留Pascal用。

作者: 路西法大大 时间: 2015-3-21 13:54

Xenomorph 发表于 2015-3-19 23:00
额外弄一个“巨大”的外置MC接驳所有memory，再让这个外置MC同时对接2枚GPU的原接驳各自memory的线。

...

有这功夫跟成本还不如把显存容量翻倍算了....

作者: Xenomorph 时间: 2015-3-22 22:04

路西法大大发表于 2015-3-21 13:54
有这功夫跟成本还不如把显存容量翻倍算了....

其实我这个幻想的意义不在于容量翻倍，主要为了能让单卡双芯能读取PCB上每一部份显存，不然还是只能各读各的。

作者: asdfjkl 时间: 2015-3-22 22:43

Xenomorph 发表于 2015-3-19 23:00
额外弄一个“巨大”的外置MC接驳所有memory，再让这个外置MC同时对接2枚GPU的原接驳各自memory的线。

...

你这个idea还是不错的，但实施起来有好几块芯片要做。
GPU不带MC或者带MC的，之前的那种；（芯片1）
专门的芯片一边连接数块上面GPU，另外一边连接常见的GDDR5.（芯片2）

这样的问题在于，访问显存的延迟大了，另外专门的芯片连接的GPU这边的数据率极高，可能需要多芯片封装，而不能通过PCB上的连线连接。
对于不需要多块GPU的情形，还需要芯片1 + 芯片2. 成本高了。
如果芯片1本来带MC的，那么这个芯片1相比现有方案，多了一组接口。可能会导致芯片面积过大（pad limited area）。

总之，有可取之处，但真正实施需要克服/解决诸多问题。

作者: iamw2d 时间: 2015-3-22 23:07

Xenomorph 发表于 2015-3-22 22:04
其实我这个幻想的意义不在于容量翻倍，主要为了能让单卡双芯能读取PCB上每一部份显存，不然还是只能各读各 ...

hmc可以这么连

作者: Xenomorph 时间: 2015-3-23 13:11

asdfjkl 发表于 2015-3-22 22:43
你这个idea还是不错的，但实施起来有好几块芯片要做。
GPU不带MC或者带MC的，之前的那种；（芯片1）
专 ...

我这个思路完全是方便双芯而已，专门新弄个“不带MC的GPU”就免了；所以如果是单芯卡，不必出现“芯片2”的。

这个方案仅限于单卡双芯，物理上看让“数块GPU”在PCB上好像不太现实？延迟问题，我相信你可以用12GHz的GDDR5弥补~

这个普通GPU怎么会多1组接口呢？原MC接出的连线通往芯片2，但GPU和芯片2是分开的呀，要算面积也是分开的吧；好比Tesla时期G200核心和NVIO2芯片那样分开，对良率的影响就没这么大了。

作者: Xenomorph 时间: 2015-3-23 13:15

iamw2d 发表于 2015-3-22 23:07
hmc可以这么连

同一显存颗粒能同时被不止1颗GPU读写信息吗？

作者: iamw2d 时间: 2015-3-23 17:32

Xenomorph 发表于 2015-3-23 13:15
同一显存颗粒能同时被不止1颗GPU读写信息吗？

[attach]2784306[/attach][attach]2784307[/attach][attach]2784308[/attach][attach]2784309[/attach]Multiple HMC devices may be chained together to increase the total memory capacity available to a host. A network of up to eight HMC devices and 4 host source links is supported. Each HMC in the network is identified through the value in its CUB field, located within the request packet header. The host processor must load routing configuration information into each HMC. This routing information enables each HMC to use the CUB field to route request packets to their destination. Each HMC link in the cube network is configured as either a host link or a pass-through link, depending upon its position within the topology. See Figure 5 and Figure 6 for illustration. A host link uses its link slave to receive request packets and its link master to transmit response packets. After receiving a request packet, the host link will either propagate the packet to its own internal vault destination (if the value in the CUB field matches its programmed cube ID) or forward it towards its destination in another HMC via a link configured as a pass-through link. In the case of a malformed request packet whereby the CUB field of the packet does not indicate an existing CUBE ID number in the chain, the request will not be executed, and a response will be returned (if not posted) indicating an error. A pass-through link uses its link master to transmit the request packet towards its destination cube, and its link slave to receive response packets destined for the host processor.
An HMC link connected directly to the host processor must be configured as a host link in source mode. The link slave of the host link in source mode has the responsibility to generate and insert a unique value into the source link identifier (SLID) field within the tail of each request packet. The unique SLID value is used to identify the source link for response routing. The SLID value does not serve any function within the request packet other than to traverse the cube network to its destination vault where it is then inserted into the header of the corresponding response packet. The host processor must load routing configuration information into each HMC. This routing information enables each HMC to use the SLID value to route response packets to their destination. Only a host link in source mode will generate a SLID for each request packet. On the opposite side of a pass-through link is a host link that is NOT in source mode. This host link operates with the same characteristics as the host link in source mode except that it does not generate and insert a new value into the SLID field within a request packet. All link slaves in pass-through mode use the SLID value generated by the host link in source mode for response routing purposes only. The SLID fields within the request packet tail and the response packet header are considered "Don’t Care" by the host processor. See Figure 5 for supported multi-cube topologies. Contact Micron for guidance regarding feasibility of all other topologies. In the following figures, the link arrows show the direction of requests from the host(s). Responses will travel in the opposite direction on the same link.

没看出来到底可不可以读写同一块我猜是可以的

作者: Xenomorph 时间: 2015-3-24 21:50

iamw2d 发表于 2015-3-23 17:32
Multiple HMC devices may be chained together to increase the total memory capacity available to a ...

刚看了下，应该能被2个MC读写；但好像没提及能否“同时”被读写，而不能的话顶多充当1个容量自适应的显存~

作者: fengpc 时间: 2015-3-25 17:58

Xenomorph 发表于 2015-3-24 21:50
刚看了下，应该能被2个MC读写；但好像没提及能否“同时”被读写，而不能的话顶多充当1个容量自适应的显存 ...

外置MC能同时被两个GPU读写，那就需要增加一个FSB，类似core2时代的多核方式一样。问题是这个FSB的带宽需要跟memory一样大的话，IO的布线数量和功耗也要直追GDDR5了

作者: Xenomorph 时间: 2015-3-26 21:58

fengpc 发表于 2015-3-25 17:58
外置MC能同时被两个GPU读写，那就需要增加一个FSB，类似core2时代的多核方式一样。问题是这个FSB的带宽需 ...

原来如此呀……

那GDDR5采用外置MC统一管理的方法行不？

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