News Samsung's GDDR6W Doubles Performance and Capacity

[Admin]

Samsung unveils 32Gb GDDR6W chips with 22 GT/s data transfer rate.

Samsung's GDDR6W Doubles Performance and Capacity : Read more

 

[-Fran-]

Reads cool, but this sounds power hungry and hot right off the bat. I mean, probably worth the trade off vs HBM's implementation, but I would not say HBM is not the better option for true high performance computing as things stand now. Trade offs, for sure.

Sounds interesting, but let's see how it is adopted. I think this will see better adoption on consumer than HPC.

Regards.

 

[InvalidError]

Reads cool, but this sounds power hungry and hot right off the bat. I mean, probably worth the trade off vs HBM's implementation, but I would not say HBM is not the better option for true high performance computing as things stand now. Trade offs, for sure.

If HBM was mass-manufactured on a scale comparable to GDDR6*, it would likely be cheaper than this fancy double-decked chip-and-PCB sandwich.

 

[thestryker]

Implementing HBM is pretty much always going to be more expensive due to the interposer. The advantage it has had is density which seems to be what Samsung is primarily aiming at with this technology.

 

[jp7189]

If HBM was mass-manufactured on a scale comparable to GDDR6*, it would likely be cheaper than this fancy double-decked chip-and-PCB sandwich.

Likely the production cost of HBM could be cheaper, but I doubt the implementation cost would be. HBM requires a lot of traces.

 

[-Fran-]

If HBM was mass-manufactured on a scale comparable to GDDR6*, it would likely be cheaper than this fancy double-decked chip-and-PCB sandwich.

As others have pointed out, it's not so much the cost of the HBM chip itself, but the whole "close to the CPU/SoC/GPU" restriction and interposer. I do believe you can do it outside of the interposer and use it as GDDR/DDR, but then the traces/routes on the PCB would still make the cost skyrocket compared to GDDR/DDR. The only comparable thing to HBM would be traditional eRAM in both performance and cost (as I understand it).

Regards.

 

[JamesSneed]

If HBM was mass-manufactured on a scale comparable to GDDR6*, it would likely be cheaper than this fancy double-decked chip-and-PCB sandwich.

The interesting thing with this new GDDR6W is it removes the interposer you normally need to do this kind of thing so it's going to be fairly cheap. HBM will never get that cheap unless we hit a point where its used-on package because the 1000's of motherboard traces would be insanely costly. On package it could get cheap enough to see on consumer stuff in a decade or so as it gets used more in HPC then in servers. I could see it making it down the stack in a decade. It would make an awesome APU down on TSMC's 1nm node for example.

 

[setx]

While this doubles the density it does pretty much nothing else. From the system point of view, to use 2x capacity and 2x transfer speed you need to have 2x data traces on the board and energy consumption also looks like 2x.
It's a progress but a very weak one. Not comparable to PAM4 on GDDR6X for example.

 

[tennis2]

But.....X comes after W and is therefore better. Big brain.

 

[InvalidError]

As others have pointed out, it's not so much the cost of the HBM chip itself, but the whole "close to the CPU/SoC/GPU" restriction and interposer.

The proximity isn't a limitation or restriction until you need more than 128GB and consumer GPUs aren't going to need that much VRAM within the next 20 years. We'll likely have 3D-stacked VRAM within the next 10 years.

 

[-Fran-]

The proximity isn't a limitation or restriction until you need more than 128GB and consumer GPUs aren't going to need that much VRAM within the next 20 years. We'll likely have 3D-stacked VRAM within the next 10 years.

I'm with you there. I rather GPUs stack HBM and charge me accordingly, but they won't, given the trade offs in cost.

In fact, I'll be surprised AMD goes back to HBM on consumer now that they're doubling down on stacked cache. I can absolutely see VCache+HBM on datacenter and HPC (in particular), but not in consumer space; sadge.

Regards.

 

[InvalidError]

I'm with you there. I rather GPUs stack HBM and charge me accordingly, but they won't, given the trade offs in cost.

There won't be a "tradeoff in cost" when HBM or some future replacement becomes mainstream, it'll be cheaper than GDDR-whateveriscurrent.

 

[-Fran-]

There won't be a "tradeoff in cost" when HBM or some future replacement becomes mainstream, it'll be cheaper than GDDR-whateveriscurrent.

Hm... That's an interesting prediction, but I don't see it like you do. What makes you say that is a potential future?

Regards.

 

[InvalidError]

Hm... That's an interesting prediction, but I don't see it like you do. What makes you say that is a potential future?

All memory, regardless of whether it is as stand-alone packages or integrated on SoC interposer will be TSV stacked die eventually, at which point there will be effectively no manufacturing cost difference between HBM and everything else, apart from HBM or equivalent on-package memories foregoing individual packaging, saving costs.

 

[-Fran-]

All memory, regardless of whether it is as stand-alone packages or integrated on SoC interposer will be TSV stacked die eventually, at which point there will be effectively no manufacturing cost difference between HBM and everything else, apart from HBM or equivalent on-package memories foregoing individual packaging, saving costs.

So, in other words to simplify your argument, you see HBM and other "super fast" memory go the way of the Cache?

I can see that, kind of.

Regards.

 

[InvalidError]

So, in other words to simplify your argument, you see HBM and other "super fast" memory go the way of the Cache?

I can see that, kind of.

AMD already uses chiplets for memory controllers and caches, they could easily integrate the HBM base die in those right now if they wanted to.

 

[-Fran-]

AMD already uses chiplets for memory controllers and caches, they could easily integrate the HBM base die in those right now if they wanted to.

But tipping your argument over (or taking it from another angle), just making CPUs and GPUs have bigger caches via chiplets or just bigger dies, wouldn't that just make having a slower secondary memory subsystem a non-issue? Or less of an issue at least.

I agree that's what AMD is trying to do with VCache putting it anywhere they can now, but I don't think it'll see the same capacities as HBM or (G)DDR can provide. And those require different pathways still and exclusive controllers. Looking at it from a cost perspective, I don't see them going away any time soon and as it stands now, HBM's implementation cost is still way higher. Alas, maybe they'll find a way thanks to VCache or, like you say, just accept the increased cost as "standard" at some point.

Regards.

 

[InvalidError]

But tipping your argument over (or taking it from another angle), just making CPUs and GPUs have bigger caches via chiplets or just bigger dies, wouldn't that just make having a slower secondary memory subsystem a non-issue? Or less of an issue at least.

In he case of GPUs, stacking memory directly on top of the memory controller / cache dies would enable AMD to cram all the bandwidth they need in less than half as many MC&CDs. Eliminating the HBM base die would also allow higher speeds at the same or lower power.