Well, if they are using 4GB of RAM doesn't using much faster RAM sort of alleviate any problems that might occur due to the lower RAM amount (compared to their competitors anyway)? I assume that would be the only reason they'd want to go with HBM, and I still agree that they very likely won't.
But wouldn't, say, 4GB of 256GB/s RAM pretty consistently perform better than say, 6GB of 60GB/s RAM? Or is that just going to be a case by case basis?
Additional bandwidth, to my knowledge at least, shouldn't "counteract" low capacity in any way. Bandwidth usage in a console is predominantly composed of buffer accesses, which increase both with resolution (as the buffers become larger) and by using more bandwidth-intensive rendering techniques like deferred rendering (which has extra intermediate buffers). Techniques like buffer compression and tile-based rendering can help, by making buffers smaller and keeping them in cache respectively, but this is all largely independent of the actual memory capacity.
Larger memory capacity would generally be taken up by higher-quality assets (i.e. textures, typically). This will actually increase the required bandwidth a bit, as the larger textures take more bandwidth to read, although it's relatively small in comparison to buffer accesses, and texture caches tend to do a pretty good job of minimising the effect.
Sufficiently fast data storage (i.e. HDD, flash, game card, etc.) could reduce memory requirements for games which make heavy use of data streaming (open-world games, obviously, but also many linear games). These games typically have to load quite a bit more data into memory than is strictly needed, in order to account for mechanical hard drives' low read speeds and high latency. So, for example, the game might keep high quality textures in memory further away than the player can actually see them, because if the player runs in that direction he would get to the point that they're needed before they can be pulled from the hard-drive. On a system with high speed, low latency storage, the game could be a lot more conservative about only keeping assets that are strictly necessary in memory, as it could pull up new assets quickly enough to keep up with the players movements.
In a more extreme example, in theory it would be possible for a game to simply drop any assets which are behind the player from memory, and re-load them if and when he turns around. Of course this would require far higher speed storage than could be expected from Switch, but it illustrates the extent to which improved storage speed and latency can reduce memory requirements in games like this.
A huge L3 cache shared by both the CPU & GPU like Apple's ARMv8-A based SoC architectures is also a possibility.
Edit: I'm wrong, only the CPU uses the 4MB of L3 cache in Apple's SoCs.
Yeah, as I've mentioned previously I think that a combo of LPDDR4 and a large L3 victim cache (or perhaps simply an increased GPU L2 cache) is most likely. I'm curious to hear that Apple's L3 caches are only used for the CPU, though, do you have a source for that? (Not that I don't believe you, I'd just be interested to read the reasoning behind it)
I think HBM is pretty much wishful thinking TBH. It isnt that prevalent now in the GPU market. The Fury line of video cards that take advantage of it were priced so high it was absurd and Vega is approaching release sometime next year. This would literally be the first time an Nvidia device would be using HBM (outside of gp100 their research compute product).. I find it extremely unlikely for them to demonstrate HBM in a mobile device like this.
They're using HBM in
some kind of mobile device, as a single 4GB HBM stack doesn't make any sense for a desktop GPU. It only makes sense in a scenario where LPDDR4 memory doesn't provide enough bandwidth and GDDR5 consumes too much power and/or takes up too much motherboard space. The only two chips Nvidia has in development that could match those criteria are Switch's SoC and Xavier. Xavier would seem the most likely candidate, but we can't completely rule out Switch.
Edit: Also, aside from this being almost two years since AMD's Fury cards, and using HBM2 rather than HBM1 (plus just one stack and InFO packaging), I don't think the pricing of Fury was "absurd", given the enormous die size. AMD released two cards in mid-2016 based on the ~600mm² Fiji die, with the full card costing $649 and the cut-down card costing $549. Nvidia, at about the same time, launched two cards based on the ~600mm² GM200 die, with the full card costing $999 and the cut-down card costing $649. Both chips were made on TSMC's 28nm process, so would have cost about the same, and yet AMD, even with HBM, managed to significantly undercut Nvidia for both binned and non-binned cards. Granted, Nvidia would have been taking higher margins (particularly on the Titan X), but there's no evidence to suggest that HBM forced AMD's pricing up.