Have they really said so explicitly?
AMD: Pirate Islands (R* 3** series) Speculation/Rumor Thread
- Thread starter iMacmatician
- Start date
-
- Tags
- amd
Have they really said so explicitly?
One AMD's slides touted a new low-latency cache hierarchy.
Current APUs and the consoles particularly don't set a very high bar, so I'm cautiously optimistic.
Right, found it:
If I wanted to be mean, I would say that the memory controller could still screw things up and lead to a very high memory latency, but let's give AMD the benefit of the doubt on this one. After all, Zen will first see the light of day on a pure CPU, so that should simplify things somewhat.
If AMD fixes the on-chip latency in Zen, there will be much bigger perveived difference between DDR/GDDR/HBM. With Jaguar, the difference between GDDR and DDR in latency is minimal. I would hope that HBM is slightly lower latency than the others, because it is so close to the die (same interposer), even if the technology itself adds some cycles. Is there anything pointing to the other direction? Is HBM designed solely for GPUs (to replace GDDR) or has there been mentions about using it on CPUs (to replace DDR4)?
Last edited:
I did some googling to confirm my recollection, and with the speed of light giving ~.3 meters per nanosecond and even with copper signaling being at least a third slower, the distance between the chips itself is not a major contributor. Other factors like needing less to drive the signals might save some time, but that is coupled with a bus that is clocked slower.
I am trying to find a citation for a rather informal characterization that HBM takes a little longer to deliver the initial part of a burst than GDDR5, but can finish the burst faster.
The raw number of channels can help with loaded latency and increase the CPU's ability to spread accesses over more channels, potentially reducing the number of turnaround penalties incurred.
What doesn't necessarily change is the time it takes to fall through the cache hierarchy and traverse the uncore, which AMD hopefully improves.
On the other side, there is the internal logic, routing, and latency of the DRAM arrays.
The arrays have not scaled in latency for years, and DRAM devices have a number of latencies that are measured in wall-clock time, not device speed.
Hynix has marketed HBM for other device types, like networking, but I don't recall a strong push to replace main memory. Perhaps some classes of consumer device can, although WideIO is liked by mobile, and DDR4 will be hard to beat in terms of capacity and pricing.
tFAW is generally not what is discussed when the topic is access latency.
That is a device restriction, measured in wall clock time, that is a time window within which at most 4 banks can be activated.
Depending on the access pattern, a CPU could rarely encounter it.
It's not that it can't come up, but it's more of a constraint on sustained bandwidth across banks. Some extra sleight of hand may be needed to map memory locations to take advantage of the pseudo channel mode, so it may not show up the way you'd expect in a memory latency benchmark.
That is a device restriction, measured in wall clock time, that is a time window within which at most 4 banks can be activated.
Depending on the access pattern, a CPU could rarely encounter it.
It's not that it can't come up, but it's more of a constraint on sustained bandwidth across banks. Some extra sleight of hand may be needed to map memory locations to take advantage of the pseudo channel mode, so it may not show up the way you'd expect in a memory latency benchmark.
Does HBM 256 byte access granularity mean that four adjacent 64 byte cache lines need to be loaded to serve a single cache miss? This would be quite inefficient for random memory accesses (such as hash maps and pointer indirections) that do not even fully use the data of a single 64 byte cache line.
I don't think this makes much sense. I suppose there's a reason there's no option for less than 1024 bits (not cost effective, I assume), and with just a single HBM2 stack, even if they'd stay at the HBM1 frequency/bandwidth the bandwidth would be quite overkill. A Quad-core Zen, with just 8 CUs, would probably be best served with 128bit lpddr4 or something like that if you don't want memory modules (there should be faster lpddr4 out by that time, which would give you about the same bandwidth as the HD 7750 gddr5 had, which should be plenty considering APU gpu clock is typically lower AND it should have framebuffer compression). I suspect that would be cheaper and be very similar in performance overall. Double the amount of CUs (which is quite reasonable for a 14nm chip) and it might make some more sense...
Plus more than 8GB would be plain impossible in that timeframe I believe (unless you want two stacks???) with HBM2.
That'll make some more sense though the amount of memory is imho a bit limiting for a high end gaming laptop for that timeframe. Unless you'd opt for two HBM2 stacks (or just use ordinary ddr4 memory alongside it)...
Last edited:
As a layman I guess you are right.
Timothy Lottes on this subject:
http://timothylottes.blogspot.de/2015/06/amd-fury-x-aka-fiji-is-beast-of-gpu.html
Infinisearch
Veteran
I was told each 1024 bit stack is divided into 8 channels and the burst length to be 2 or 4. So isn't the access granularity 32 or 64 bytes?
I don't think that figure is correct.
The standard indicates that all channels should be independent, and the granularity for that is 128 bits with a burst length of 2 or 4.
The larger number seems to be adding together the bursts for all the channels in a stack. If there is something going on the the other side of the interface, that is one thing, but HBM's granularity is smaller than 256 bytes.
Infinisearch and 3dilettante are right. HBM stacks each consists of 8 independent channels, that are logically completely separate. Each channel is 128-bit wide, and can require burst length of 2 or 4, so it transfers 32 bytes or 64 bytes per access.
This design seems optimized to match well with the existing AMD GDDR5 memory controllers -- lots of independent links leading to different devices get converted into lots of independent links leading to different channels on a HBM stack.
The primary latency contributions, reading from the DRAM arrays and precharge, are exactly the same as all other modern DRAM. There are some differences, but they are relatively minor compared to the time cost of actually reading from capacitors. So expect just a few percent here and there.
Negative points would be that lower clock rate means that first arrival of signal takes longer, and that the standard lacks "most important word first" feature. Not that it's very important.
Positive would be that having so much more banks spread across so many channels means that in a latency-limited scenario (pointer chasing) with little other load on the system, the odds of hitting a precharged bank with each new load is much higher. Also, wider bus should mean that transfers complete faster than on DDR4.
D
Deleted member 13524
Guest
Fixed that for you!
Ah.. one could only dream..
But it's Nintendo, so I'm going to cry over that corner now
This sounds like "ganged" vs. "unganged" in DDR MCs.
It's incredibly nice that a GTX 970 consumes so little power. It's a major item to put on your marketing material, and it resonates very well with consumers.
But is it something that limits performance? Except for that small sliver of ultra-high-end gaming laptops, not really.
The question is really how much more efficient can be gained beyond Maxwell (adjusted for process, of course.) For gaming workloads, I doubt there's going to be a huge additional jump, though I've been proven wrong about these kinds of claims in the past. So, for now, I'm assuming just process scaling in terms of perf/mm2. Say a 50 to 60% increase per mm2. That gives a 400mm2 chip roughly the same performance as a 600mm2. We already know that a 600mm2 doesn't strictly need HBM to be competitive...
Of course. Nobody has made such claim.
AMD targeted only the enthusiast segment for HBM (q2 2015 financial conference call) so I think HBM 2 will only be for the next gen high end and HBM gen 1 for mid range and lower end GPU's. It really doesn't make sense with the extra cost and bandwidth of HBM 2 to go to lower than the enthusiast SKU's.
They didn't answer the HBM vs older model's margins based for ram I think we can take that its much more expensive.......
Oh they stated they have a lead time for HBM already, but they didn't answer how long and how they are taking advantage of that, so how we look at that.......
They didn't answer the HBM vs older model's margins based for ram I think we can take that its much more expensive.......
Oh they stated they have a lead time for HBM already, but they didn't answer how long and how they are taking advantage of that, so how we look at that.......
Last edited: