And here we go again ...
Allocated VRAM will be used at some point. All of you seem to think that applications just allocate buffers randomly for no reason at all to fill up the VRAM and then when it gets close to the maximum amount of memory available it all just works out magically such that the memory in use is always less than the one being allocated.
A buffer isn't allocated now and used an hour later, if an application is allocating a certain quantity of memory then it's going to be used pretty soon. And if the amount that gets allocated comes close to the maximum amount of VRAM available then it's totally realistic to expect problems.
What? No. That is not true whatsoever. Games allocate data for many possible future game states, of which only a handful can come true. If a player in a game is in a specific position, looking in a specific direction, then the game streams in data to account for the possible future movements of that player within the relevant pre-loading time window, which is determined by expected transfer speed. They could, for example, turn around rapidly while not moving otherwise, or run forwards, backwards, strafe, or turn around and run in any direction for whatever distance is allowed by movement speed in the game, but they wouldn't suddenly warp to the opposite end of the map or inside of a building far away. If the player is standing next to a building or large object that takes several seconds to move around, what is behind said object doesn't need to be loaded until the possibility of it being seen arises. Depending on level design etc., this can produce wildly varying levels of pre-caching (an open world requires a lot more than a game with small spaces), but the rule of thumb is to tune the engine to pre-load anything that might reasonably happen. I.e. if you're next to a wall, texture data for the room on the other side isn't pre-loaded, but they will be if you are right next to a door.
As time passes and events happen (player movement, etc.), unused data is ejected from memory to allow for pre-caching of the new possibilities afforded by the new situation. If not, then pretty much the entire game would need to live in VRAM. Which of course repeats for as long as the game is running. Some data might be kept and not cleared out as it might still be relevant for a possible future use, but most of it is ejected. The more possible scenarios that are pre-loaded, the less of this data is actually used for anything. Which means that the slower the expected read rate of the storage medium used, the lower the degree of utilization becomes as slower read rates necessitate earlier pre-caching, expanding the range of possible events that need to be accounted for.
Some of this data will of course be needed later, but at that point it will long since have been ejected from memory and pre-loaded once again. Going by Microsoft's data (which is to be very accurate, they do after all make DirectX, so they should have the means to accurately monitor this), DirectStorage improves the degree of utilization of data in VRAM by 2.5x. Assuming they achieved a 100% utilization rate (which they obviously didn't, as that would require their caching/streaming algorithms to be effectively prescient), that means
at the very best their data showed a 40% rate of utilization before DirectStorage - i.e. current DirectX games are
at most making use of 40% of the data they are pre-loading before clearing it out. If MS achieved a more realistic rate of utilization - say 80% - that means the games they started from utilized just 32% of pre-loaded data before clearing it out. There will always be
some overhead, so going by this data alone it's entirely safe to say based on this information that current games cache
a lot more data than they use.
And no, this obviously isn't happening on timescales anywhere near an hour - we're talking millisecond time spans here. Pre-caching is done for perhaps the next few seconds, with data ejection rolling continuously as the game state changes - likely frame-by-frame. That's why moving to SSD storage as the default for games is an important step in improving this - the slow seek times and data rates of HDDs necessitate multi-second pre-caching, while adopting even a SATA SSD as the baseline would dramatically reduce the need for pre-caching.
And that is the point here: DS and SSD storage as a baseline will allow for less pre-caching, shortening the future time span for which the game needs possibly necessary data in VRAM, thus significantly reducing VRAM usage. You obviously can't tell
which of the pre-loaded data is unnecessary until some other data has been used (if you could, there would be no need to pre-load it!). The needed data might thus just as well live in that ~1GB exceeding a theoretical 8GB VRAM pool for that Skyrim screenshot as in the 8GB that are actually there. But this is exactly why faster transfer rates help alleviate this, as you would then need less time to stream in the necessary data. If a player is in an in-game room moving towards a door four seconds away, with a three-second pre-caching window, data for what is beyond the door will need to start streaming in in one second. If faster storage and DirectStorage (though the latter isn't strictly necessary for this) allows the developers to expect the same amount of data to be streamed in in, say, 1/6th of the time - which is reasonable even for a SATA SSD given HDD seek times and transfer speeds - that would mean data streaming doesn't start until 2.5s later. For that time span, VRAM usage is thus reduced by as much as whatever amount of data was needed for the scene beyond the door. And ejection can also be done more aggressively for the same reason, as once the player has gone through the door the time needed to re-load that area is similarly reduced. Thus, the faster data can be loaded, the less VRAM is needed at the same level of graphical quality.
No, that comparison is perfectly valid in the context of the effect of VRAM size differences on a single GPU spec. A similar comparison could be made for the GTS8800 320MB VS 640MB, GTX9800 512MB VS 1GB, GTX560 1GB VS 2GB or the RX580 4GB vs 8GB. The extra ram is very helpful for the then current gen of software and for future software. As the card life-cycle matures the extra RAM becomes critical to the card's continued viability and usefulness. More VRAM generally means a GPU stays useful for longer period of time. This is a well known fact.
That is only true if the base amount of VRAM becomes an insurmountable obstacle which cannot be circumvented by lowering settings. Which is why this is applicable to something like a 2GB GPU, but won't be in the next decade for a 10GB one. The RX 580 is an excellent example, as the scenarios in which the 4GB cards are limited are nearly all scenarios in which the 8GB one also fails to deliver sufficient performance, necessitating lower settings no matter what. This is of course exacerbated by reviewers always testing at Ultra settings, which typically increase VRAM usage noticeably without necessarily producing a matching increase in visual quality. If the 4GB one produces 20 stuttery/spiky frames per second due to a VRAM limitation but the 8GB one produces 40, the best thing to do (in any game where frame rate is really important) would be to lower settings on both - in which case they are likely to perform near identically, as VRAM use drops as you lower IQ settings.
Except Skyrim
stutters when stuff is loaded into VRAM, I even specifically pointed that out earlier. So when you have less than you need maxed out, the experience immediately suffers. This goes for quite a few games using mods. Its not a streamlined as you might think. And yes, I posed it as a
dilemma. My crystal ball says something else than yours, and I set the bar a little bit higher when it comes to 'what needs to be done' in due time to keep games playable on GPU XYZ. If current day content can already hit its limits... not a good sign.
Any time games need to resort to swapping and they cannot do that within the space of a single frame update, you will suffer stutter or frametime variance. I've gamed too much to ignore this and I will
never get subpar VRAM GPUs again. The 1080 was perfectly balanced that way, always has an odd GB to spare no matter what you throw at it. This 3080, most certainly is not balanced the same way. That is all, and everyone can do with that experience based info whatever they want
I'll happily lose 5 FPS average for a stutter free experience.
Do the stutters kick in immediately once you exceed the size of the framebuffer? Or are you comparing something like an 8GB GPU to an 11GB GPU at settings allocating 9-10GB for those results? If the latter, then that might just as well be indicative of a poor pre-caching system (which is definitely not unlikely in an old and heavily modded game).
Node has everything to do with VRAM setups because it also determines power/performance metrics and those relate directly to the amount of VRAM possible and what power it draws. In addition, the node directly weighs in on the yield/cost/risk/margin balance, as do VRAM chips. Everything is related.
Yes, everything is
related, but you presented that as a
causal relation, which it largely isn't, as there are multiple steps in between the two which can change the outcome of the relation.
Resorting to alternative technologies like DirectStorage and whatever Nvidia is cooking up itself is all well and good, but that reeks a lot like DirectX12's mGPU to me. We will see it in big budget games when devs have the financials to support it. We won't see it in the not as big games and... well... those actually happen to be the better games these days - hiding behind the mainstream cesspool of instant gratification console/MTX crap. Not as beautifully optimized, but ready to push a high fidelity experience in your face. The likes of Kingdom Come Deliverance, etc.
From what's been presented, DS is not going to be a complicated API to implement - after all, it's just a system for accelerating streaming and decompression of data compressed with certain algorithms. It will always take time for new tech to trickle down to developers with less resources, but the possible gains from this makes it a far more likely candidate for adoption than somethinglike DX12 mGPU - after all, reducing VRAM utilization can directly lead to less performance tuning of the game, lowering the workload on developers.
This tech sounds like a classic example of "work smart, not hard", where the classic approach has been a wildly inefficient brute-force scheme but this tech finally seeks to actually load data into VRAM in a
smart way that minimizes overhead.
In the same vein, I don't want to get forced to rely on DLSS for playable FPS. Its all proprietary and per-game basis and when it works, cool, but when it doesn't, I still want to have a fully capable GPU that will destroy everything.
I entirely agree on that, but it's hardly comparable. DLSS is proprietary and only works on hardware from one vendor on one platform, and needs significant effort for implementation. DS is cross-platform and vendor-agnostic (and is likely similar enough in how it works to the PS5's system that learning both won't be too much work). Of course a system not supporting it will perform worse and need to fall back to "dumb" pre-caching, but that's where the baseline established by consoles will serve to raise the baseline featureset over the next few years.
.
