自从传闻390X用4G显存后，对显存大小的认识就有些变化了。。。

iamw2d

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

hmc可以这么连

iamw2d

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

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.

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