ssd's improves gaming graphics fidelity?

i have known for a while that ssd's load game levels faster (depending on game) but this thread and the idf link state that ssd's do improve gaming graphical experience by having no or less hitches/lags and having no or less low res graphical texture fillers.

How Games Really Benefit from SSD.

i have noticed my games 'seem' smoother now but i dont know if it was placebo. have you guys noticed increased graphical performance with your ssd?

 

I recently upgraded to a Crucial M4 msata from a good old 1TB platter drive. I do notice that games startup faster, and at times when the game loads data from disk it runs smoother (no stuttering due to waiting on platter drive), but that is it. No other benefits that I can see.

 

No, like the guy kind of arrives at in the thread.. What really happens is that it's become more and more common to use sloppy streaming schemes with dynamic sizes for maps, undeclared sizes, having suddenly very long synchronous loading in the middle of a level when the streaming isn't ready, or when you need to write back some table for node-generation, or geometry updates, etc.

And this can very easily end with random in-level hiccups becoming less obvious on an ssd compared to a slower hdd or usb flash-storage, and that kind of thing. Because you could suddenly have thousands of tiny writes that just.. disappear on an ssd, that would cause a 5 second pause on an hdd..

I can imagine that this is something you could see on Unreal Engine games, for example. Existing ones and new ones. That this is the new bus frequency on the graphics card problem. It's not a "oh, the shaders are too slow", or "the pipes need to be primed and *****" problem. It's just that you load modules with independent routines. And it's possible to create situations where you want to update information that isn't ready yet. And you don't know on beforehand (or you should know, but don't care) that you often or always get situations where the streaming engine croaks.

You see the same effect on games that were essentially written to run on the xbox or xb360, and then were ported to PC. The strategy to get the game to stream off a dvd was to lower the texture sizes, and always have an upper limit of some sort. So when you run the PC version, on "superior hardware", there's a possibility to stream faster and have larger amount of cache for random cache-hits loaded. And streaming pauses would go down and texture quality would noticeably go up. But - now the cache-misses that were planned to be loaded in a very short time suddenly took, say, 10 times as long, or cause buffers to flush so assumed present data would have to be reloaded.

But for a well-programmed game-engine, you could easily imagine (or just look at a few good examples, that exist all the way back to the gamecube and the n64 really..) a streaming engine that is scheduled properly, and working within well-designed limits for the rendering engine, and so on.

Still.. yeah, that's not going to happen very often. So you can be pretty much 100% certain that microstutter and loading pauses will practically disappear on an ssd, that would otherwise be pretty obvious when loading and streaming depends on slower storage media. The random cache-hits for "pre-loaded", or paged data in Windows is the one major culprit here, though. Honestly, the kind of laughable problems with performance and stability this particular ****ing idea of Microsoft's has caused over the last 15 years is just..

 

loading speed and stutter are more easily quantifiable but im most interested in their comments about texture loading- wherein low res filler textures are used when the storage is too slow to provide the hires texture itself. an ssd alleviates this situation but i personally havent noticed this in any game or maybe havent looked hard enough.

 

AFAIK, when games load a new area (like in Assassins Creed), or when you enter a building (like in the Fallout series), the game loads information about surroundings into system RAM. That is where the lag you speak of comes into play. System RAM is much much faster than a hard disk - conventional or otherwise. So once loading is done, you shouldn't see any slowdown. When you are playing NFS, for example, the game loads information about surroundings you will enter into RAM. Areas are usually separated by tunnels or something else that do not require as many textures. That way, you don't see any lag while the game loads textures for the upcoming areas into the memory. From there, the GPU is the major bottleneck. That is why it is difficult to see a big difference in frame rate.

 

yes this is what i also know. games basically use ram as a cache.
but if you take this together with what nipsen says (that the caching protocol has few hits) then i can see where the low res texturing filler can come in. the thread and the intel are old (2010) but they are interesting to me since this is the first time ive heard that ssd's or any fast storage can impact actual graphics quality.

 

I don't understand how you can have cache misses in system RAM.

 

Rage is the poster child for how an ssd can compensate for an engine that uses texture streaming that does not play nice with bandwidth available from slower storage devices.

Obviously many games stream in data since large sandboxed worlds are all the rage (no pun intended). Any of these will benefit from faster storage devices. An engine that does "pop-in" probably won't as that's typically draw distance related.

I like how tomb raider worked this in. It seems they used Lara squeezing herself through cracks in rocks or long claustrophobic tunnels to load assets for the next area. Somewhat elegant.

 

By the power of Microsoft, immaculate and all powerful, all is possible. B'sod.

 

RAM is not cache. So that term doesn't even apply. Cache is cache. To cache means to store for future use because it is a component that is frequently needed and (most likely) will be needed in the future. You have a cache miss when data the CPU tries to access data from its cache and it has been overwritten with something else. It then looks to the RAM. Data in RAM HAS TO BE PRESENT. A CPU will not look into the RAM for data it needs when said data does not exist in RAM. It will first load up that data to RAM. Required Data in RAM is not magically overwritten like cache. If that data is somehow lost, then it is because of either faulty memory or a poorly written program (in the case of programming or scripting).

Microsoft may be known for not making good, stable operating systems, but they cannot be responsible for something that is not possible. BSODs most commonly happen because drivers are missing and the system looks for them in spite of them being missing or memory is damaged. There are other, lesser frequent reasons. BSODs do not happen because there is a cache miss in RAM. That statement carries no meaning.

 

I know! But.. memory references that are stored in ram, that are prepared and declared but not actually loaded - can still be treated as if they were really stored in ram. Then the system will pull the data when explicitly told, or when the "resource is actually needed".

What this really amounts to is that before every single read-operation, there's unscheduled dma that halts program execution. Rinse and repeat. And then you actually do get cache-misses from references that you would expect to be stored in ram. In truth, this doesn't necessarily mean bad programming either. But just that you haven't pulled in data in the way your framework expected you to.

But it makes no sense, I completely agree with that.