Next-Generation NVMe SSD and I/O Technology [PC, PS5, XBSX|S]

Are people still arguing over ratchet and clank...

What the SSD is allowing the game to do is quite clear. Just because background streaming of assets via loading in ram has been a thing for decades doesn't mean insomniac are somehow being untruthful.

Isn't it the point that the SSD means that such a method isn't neccesary anymore?
Clearly a ratchet and clank game on ps4 trying the same thing wouldent be possible in the same way.

The advantage of ssds in the new consoles means you can use that ram for other things besides having to keep the next assets in memory to anywhere near the same degree as the past few console generations
 
Are people still arguing over ratchet and clank...
Honestly, are people still arguing over high performance flash storage connected vie PCIe using the NVMe protocol being something useful?

I get that we all want to swallow the fat pile of marketing about ALL ZEE JIGGABITZ, yet at the end of the day it turns out high performance storage allows you to (gasp) spend your resources in different and more inteersting ways. I see now that we have to argue about why this was NEVER BEFORE POSSIBLE because, uh, things get faster as technology improves. I guess it turns out that portals have been done a lot, especially static portals (remember Prey on the PC? No, not the one on a space station...) and quite a long time ago at that. How many of you remember Duke Nukem 3D? Yeah, turns out, zero -latency loading portals. Duke Nukem 3D: Build Engine Internals (fabiensanglard.net)

So anyway, while we can all swing some of our genetalia around how our elected GodKingConsole is neater because it has moAR Solid State Disk girthiness, I think it's more of just welcoming y'all to the years-ongoing storage I/O party. Congrats for catching up! Don't forget to argue more about compression now, as well as special Marvell controllers making them imminitely better than everyone and everything else now.
 
it's a different thing to have a portal where what's in both sides of the portal are already in ram (prey, duke nukem, and whatever other old games) and dump everything from one level of the one side of the portal and loading everything from the other side in a second.
Insomniac (and sony) never claimed that mechanic was never done before, they just said how they did it was never done in preivous generations of consoles, and that's true.
oh and they never claimed it could not be done differently, like having more ram instead of fast storage, people on the internets did this.
 
it's a different thing to have a portal where what's in both sides of the portal are already in ram (prey, duke nukem, and whatever other old games) and dump everything from one level of the one side of the portal and loading everything from the other side in a second.
Insomniac (and sony) never claimed that mechanic was never done before, they just said how they did it was never done in preivous generations of consoles, and that's true.
oh and they never claimed it could not be done differently, like having more ram instead of fast storage, people on the internets did this.
Sort of. The exact quote is "Ratchet and Clank: Rift Apart uses dimensions... and dimensional rifts. And that would not have been possible without the solid state drive of the Playstation 5". That was Marcus Smith from Insomniac. I would agree that what Insomniac did is different than what was done before from a technique standpoint. And it most certainly helped them maintain a level of fidelity that wouldn't have been possible without fast storage. But the quote in question does imply that the gameplay wouldn't have been possible.

Rift Apart also uses techniques not unlike older games, where they teleport you to other areas already in ram. They use the full level swap from storage technique only for some portals, not all.

I feel dirty typing this stuff. Ratchet and Clank Rift Apart is a great looking game and a technical achievement. But like many games, it's pre-launch marketing was hyperbolic. They made broad claims before launch, just like any other game. It's just marketing hyping up the new capabilities of the system and showcasing some examples in a game. That's better than filling a tub full of ducks in my book.
 
Last edited:
it's a different thing to have a portal where what's in both sides of the portal are already in ram (prey, duke nukem, and whatever other old games)
Apparently you don't remember what memory looked like back when the Build engine was around. In fact, portals were a way to get a lot more assets into view than you actually had memory to directly support in a BSP way. You also have to consider that assets do share between levels and worlds; every single blade of grass and rock aren't unique. Just because the base level geometry needs to change doesn't mean the entire texturing system is upended at the same time. A complete evict and reload of all static memory in an entire system (GPU included) does take a tiny bit of time, despite how fast an SSD might be. And when I say tiny, what we're talking about is more than the 16.7msec between frames in a 60fps game.

I think, again, a few folks in this thread seem to be gulping down a heavy dose of wonderful marketing speak with absolutely zero critical thinking about what is being said. Maybe having some better background on, not just the physical, but the logical technology stack makes it easier to pick apart what the nuance might be in how SSD's are truly helping.
 
Honestly, are people still arguing over high performance flash storage connected vie PCIe using the NVMe protocol being something useful?

I get that we all want to swallow the fat pile of marketing about ALL ZEE JIGGABITZ, yet at the end of the day it turns out high performance storage allows you to (gasp) spend your resources in different and more inteersting ways. I see now that we have to argue about why this was NEVER BEFORE POSSIBLE because, uh, things get faster as technology improves. I guess it turns out that portals have been done a lot, especially static portals (remember Prey on the PC? No, not the one on a space station...) and quite a long time ago at that. How many of you remember Duke Nukem 3D? Yeah, turns out, zero -latency loading portals. Duke Nukem 3D: Build Engine Internals (fabiensanglard.net)

So anyway, while we can all swing some of our genetalia around how our elected GodKingConsole is neater because it has moAR Solid State Disk girthiness, I think it's more of just welcoming y'all to the years-ongoing storage I/O party. Congrats for catching up! Don't forget to argue more about compression now, as well as special Marvell controllers making them imminitely better than everyone and everything else now.

This is what I was largely talking about...this isn't neccesary.

The consoles gaining technology is good as devs will prioritize it and Sony focused more on that aspect with the ps5 and their games are taking advantage of it. Good for them.

Trying to dismiss that or use it for PS5 fanboy wars on either side of the spectrum is silly. It's just toxic
 
Isn't it the point that the SSD means that such a method isn't neccesary anymore?

There's a lot of nuance in all this. PS5 SSD is super, no doubt, but it doesn't naturally make all the techniques that the TT guy was talking about obsolete.

For example, creating little special stages using a minimum of memory helps the Megadrive because of cart sizes. It helps PS1 because of RAM and loading times. And it'll help the PS5 for the same reasons - even if the impact in seconds is smaller than it would be for a HDD or DVD.

Likewise, if you're in an on rails section, why wouldn't you use the predictability in what you can discard and what you'll need to inform your data transfers? I'll bet a tenner that Insomniac aren't throwing out all their battle tested data transfer techniques just because the PS5 SSD is great. These technologies aren't mutually exclusive, they stack.

I would be astounded if some of the techniques Jon Burton is talking about aren't used in, and any other technically competent game on any platform, or perhaps even R&C itself. Old timers that know about banging on registers know the basics of how this stuff all more or less works even now.

Oh, and setting up the stage that you're about to enter can take a little while too - lots of variables to initialise and ... pointers to set and ... things.

TL : DR - a good technique applicable to fundamentals that still influence the industry is never truly obsolete! :D
 
There's a lot of nuance in all this. PS5 SSD is super, no doubt, but it doesn't naturally make all the techniques that the TT guy was talking about obsolete.

For example, creating little special stages using a minimum of memory helps the Megadrive because of cart sizes. It helps PS1 because of RAM and loading times. And it'll help the PS5 for the same reasons - even if the impact in seconds is smaller than it would be for a HDD or DVD.

Likewise, if you're in an on rails section, why wouldn't you use the predictability in what you can discard and what you'll need to inform your data transfers? I'll bet a tenner that Insomniac aren't throwing out all their battle tested data transfer techniques just because the PS5 SSD is great. These technologies aren't mutually exclusive, they stack.

I would be astounded if some of the techniques Jon Burton is talking about aren't used in, and any other technically competent game on any platform, or perhaps even R&C itself. Old timers that know about banging on registers know the basics of how this stuff all more or less works even now.

Oh, and setting up the stage that you're about to enter can take a little while too - lots of variables to initialise and ... pointers to set and ... things.

TL : DR - a good technique applicable to fundamentals that still influence the industry is never truly obsolete! :D
Well I think that’s the point that’s being missed, SSD isn’t reinventing the wheel rather streamlining it.

It’s removing a lot of shackles that slow loading big assets introduced and allowing devs to either not have to worry about the structure of a game (be it how do I hide this load or how do I design this level due to slow loading) to allow for more concentration on producing the full vision of the end product.

There will be games that will uniquely be able to utilise the SSD I’m sure but for now we’re enjoying games which are either loading substantially faster or just looking significantly better thanks to the SSD.
 
There's a lot of nuance in all this. PS5 SSD is super, no doubt, but it doesn't naturally make all the techniques that the TT guy was talking about obsolete.

For example, creating little special stages using a minimum of memory helps the Megadrive because of cart sizes. It helps PS1 because of RAM and loading times. And it'll help the PS5 for the same reasons - even if the impact in seconds is smaller than it would be for a HDD or DVD.

Likewise, if you're in an on rails section, why wouldn't you use the predictability in what you can discard and what you'll need to inform your data transfers? I'll bet a tenner that Insomniac aren't throwing out all their battle tested data transfer techniques just because the PS5 SSD is great. These technologies aren't mutually exclusive, they stack.

I would be astounded if some of the techniques Jon Burton is talking about aren't used in, and any other technically competent game on any platform, or perhaps even R&C itself. Old timers that know about banging on registers know the basics of how this stuff all more or less works even now.

Oh, and setting up the stage that you're about to enter can take a little while too - lots of variables to initialise and ... pointers to set and ... things.

TL : DR - a good technique applicable to fundamentals that still influence the industry is never truly obsolete! :D

Again in the road to PS5, Cerny talked about it. The goal was to finish with streaming as a constraint meaning than design sublevel is not useful. Basically load your level and this is done. Some devs were saying the work of level designer will change totally. Before SSD in consoles it was very technical and linked to the streaming and RAM constraint. And it means limiting assets quality. Here you don't need to design around it and you don't need to limit the asset quality comared to what your GPU is able to render.

https://gamingbolt.com/ps5s-ssd-com...to-big-changes-in-level-design-developer-says

“There’s a dual approach we can take advantage of as developers not only with the faster SSD’s but also in combination with Unreal Engine 5,” Bottomley said. “When you’re creating the larger 3D games that we tend to design at White Paper, streaming the content for the player and knowing how to approach the design of the levels to get them to the most optimal performance takes a lot of time. With quicker loading times, you have less need to design features into loading screens along with the streaming of the content at runtime. Unreal Engine 5 removes the need for this side of development and instead ‘chunks’ the content under the hood. I think you’ll see some big changes to level design with these two upgrades in the development pipeline.”

Here someone do some portals without direct Storage and NVME SSD and it needs level designer to think about sublevel. The goal of PS5 SSD and Xbox Series SSD with DirectStorage is to be able to not think about it.

https://thegabmeister.com/blog/portals-level-streaming/

Level streaming allows asynchronous loading and unloading of levels during play to decrease memory usage and create seamless worlds. You can find references in the Level Streaming documentation, particularly this guide which uses blueprints instead of level streaming volumes. Furthermore, Alan Willard talked about the different techniques that you can use to handle loading levels seamlessly in this video.

The process of loading/unloading huge levels can cause obvious stuttering. To minimize impact on performance, you should consider creating multiple sublevels for your 3D models
 
Again in the road to PS5, Cerny talked about it. The goal was to finish with streaming as a constraint meaning than design sublevel is not useful. Basically load your level and this is done. Some devs were saying the work of level designer will change totally. Before SSD in consoles it was very technical and linked to the streaming and RAM constraint. And it means limiting assets quality. Here you don't need to design around it and you don't need to limit the asset quality comared to what your GPU is able to render.

Yes, level design constraints are going to change significantly for the better when mechanical drives are gone, and get even better when PS5 and Direct Storage are the baselines. But streaming is not going to be entirely eliminated as a constraint across gaming, and sublevels (or chunks, or something like that) will still have uses. Not needing to think about GPU limitations on asset quality is more about game engine tech than raw SSD / IO performance though.

So, next gen storage vastly shrinks constraints in terms of "plan ahead" (visibility and traversal time), and potentially removes some altogether for artists in practical terms (for example camera pans during gameplay). But it really doesn't remove them entirely across gaming - if you're counting ms instead of seconds, you're still counting.

As a simple thought experiment, image an on rails section where you're about to initiate transfer of a 3 GB boss composed of hundreds of characters with particle systems. You're not going to be able to do that in a single frame, and you're still going to need some kind of mechanism to trigger streaming before the data for that boss before the first time you try and use the data.

There will still be uses for the kind of techniques Jon Burton was talking about. And all the usual stuff - instancing, chunks, deliberately loading ahead, manual tweaking of LoDs, loading screens (like the portal in R&C).

Here someone do some portals without direct Storage and NVME SSD and it needs level designer to think about sublevel. The goal of PS5 SSD and Xbox Series SSD with DirectStorage is to be able to not think about it.

https://thegabmeister.com/blog/portals-level-streaming/

There's quite a bit more to it than that, and there are more potential causes of stuttering than simply data transfer rate. Often stuttering is caused by CPU bottlenecks, and dumping a whole level onto the CPU to add to memory, potentially decompress, setup within the game world ... all kinds of stuff ... can be pretty demanding on the system in ways other than transfer. There's a lot more to jumping between levels than just transferring raw data from SSD to ram.

The move to SSD is the best thing to happen this gen, but it doesn't eliminate the basics. You're moving data or you're processing data. You're loading on some level of granularity. You're thinking x frames ahead, or your reacting to a miss.

Some responsibility might move from an artist to a programmer or engine developer (e.g. Jon Burton), but it remains something for the developer to think about.

Not wanting to be a Debbie Downer, as this gen is the best gen from a hardware POV and both Sony and MS have great systems and there are no losers amongst buyer. I'm just not into the "magic hardware" that the gaming press want people to fight over.
 
Yes, level design constraints are going to change significantly for the better when mechanical drives are gone, and get even better when PS5 and Direct Storage are the baselines. But streaming is not going to be entirely eliminated as a constraint across gaming, and sublevels (or chunks, or something like that) will still have uses. Not needing to think about GPU limitations on asset quality is more about game engine tech than raw SSD / IO performance though.

So, next gen storage vastly shrinks constraints in terms of "plan ahead" (visibility and traversal time), and potentially removes some altogether for artists in practical terms (for example camera pans during gameplay). But it really doesn't remove them entirely across gaming - if you're counting ms instead of seconds, you're still counting.

As a simple thought experiment, image an on rails section where you're about to initiate transfer of a 3 GB boss composed of hundreds of characters with particle systems. You're not going to be able to do that in a single frame, and you're still going to need some kind of mechanism to trigger streaming before the data for that boss before the first time you try and use the data.

There will still be uses for the kind of techniques Jon Burton was talking about. And all the usual stuff - instancing, chunks, deliberately loading ahead, manual tweaking of LoDs, loading screens (like the portal in R&C).



There's quite a bit more to it than that, and there are more potential causes of stuttering than simply data transfer rate. Often stuttering is caused by CPU bottlenecks, and dumping a whole level onto the CPU to add to memory, potentially decompress, setup within the game world ... all kinds of stuff ... can be pretty demanding on the system in ways other than transfer. There's a lot more to jumping between levels than just transferring raw data from SSD to ram.

The move to SSD is the best thing to happen this gen, but it doesn't eliminate the basics. You're moving data or you're processing data. You're loading on some level of granularity. You're thinking x frames ahead, or your reacting to a miss.

Some responsibility might move from an artist to a programmer or engine developer (e.g. Jon Burton), but it remains something for the developer to think about.

Not wanting to be a Debbie Downer, as this gen is the best gen from a hardware POV and both Sony and MS have great systems and there are no losers amongst buyer. I'm just not into the "magic hardware" that the gaming press want people to fight over.

On PS5 all the bold are done on I/O side and decompression is done too on hardware decompressor block on Xbox Series. And setup the level is part of the loading*(portal screen) but using a devkit devs showed everything was setup into the level when you arrive in the level even during on rail sequence.

And other thing Ratchet and clank will not be the only game using portal. You will have games where it will be possible to use portals and transfer at any time in another place. And we can say fast travel is the same thing ;)

*loading time contains I/O operation and CPU setup of level. In some of the first R&C trailer a little stutter was very visible between the moment the new level was visible and the moment entities in the level were setup. Because the setup was done too late when new world was visible.

I never said that it would be instantaneous in ms. This just make loading screen so fast, this is not a problem anymore basically loading screen on R&C takes 1 to 2 seconds and it contains I/O operations and CPU operation like setup the level. This is just what we are seeing in game. In R&C loading screen are existing they are the portal between two worlds.

With good compression system is able to treat between 8 to 11 GB/s. It goes faster than 1 second to load but after CPU needs to do the job. ;) And it is what the CPU is doing.

I never said it means no work for engine developer but they need to reengineer all the game engine and data around the I/O but when it is done this is ok.

For Spiderman 2 or Wolverine, Insomniac games developer won't need to redo all the job to adapt the engine to the new I/O system.


All the animation here is a loading screen and it takes around a second.
 
Last edited:
On PS5 all the bold are done on I/O side and decompression is done too on hardware decompressor block on Xbox Series. And setup the level is part of the loading*(portal screen) but using a devkit devs showed everything was setup into the level when you arrive in the level even during on rail sequence.

And other thing Ratchet and clank will not be the only game using portal. You will have games where it will be possible to use portals and transfer at any time in another place. And we can say fast travel is the same thing ;)

*loading time contains I/O operation and CPU setup of level. In some of the first R&C trailer a little stutter was very visible between the moment the new level was visible and the moment entities in the level were setup. Because the setup was done too late when new world was visible.

I never said that it would be instantaneous in ms. This just make loading screen so fast, this is not a problem anymore basically loading screen on R&C takes 1 to 2 seconds and it contains I/O operations and CPU operation like setup the level. This is just what we are seeing in game. In R&C loading screen are existing they are the portal between two worlds.

With good compression system is able to treat between 8 to 11 GB/s. It goes faster than 1 second to load but after CPU needs to do the job. ;) And it is what the CPU is doing.

I never said it means no work for engine developer but they need to reengineer all the game engine and data around the I/O but when it is done this is ok.

For Spiderman 2 or Wolverine, Insomniac games developer won't need to redo all the job to adapt the engine to the new I/O system.


All the animation here is a loading screen and it takes around a second.

I love that you're so enthusiastic about this new tech, and I am too. But there are many things here that you are almost treating as absolutes and certainties for development that aren't.

I know this from people working on [games]. Bitch mode comment, I know, and I suck.

Next / new gen is amazing and artists are psyched but how you organise your data by area and visibility is still something they keep in mind. Nanite is supposed to be a partial solution but it's in its infancy and it doesn't cover everything. And some of the most impressive games in the next few years probably aren't even using Unreal 5.

There's more than one engine to skin a cat....
 
I love that you're so enthusiastic about this new tech, and I am too. But there are many things here that you are almost treating as absolutes and certainties for development that aren't.

I know this from people working on [games]. Bitch mode comment, I know, and I suck.

Next / new gen is amazing and artists are psyched but how you organise your data by area and visibility is still something they keep in mind. Nanite is supposed to be a partial solution but it's in its infancy and it doesn't cover everything. And some of the most impressive games in the next few years probably aren't even using Unreal 5.

There's more than one engine to skin a cat....

Again a level or a part of a map are always exising even with an SSD they separate data by biome in an open world but they don't need to micromanage data inside the biome or part of the map. They load it and it is done. After streaming of data is fast enough to not micromanage the data and design every part of the map around it. No alley, elevator and other trick to do the level design.

cyjmc897hgn41.png


When you do a fast travel on a game on PS4 you load the part you need in memory it tooks between 40 seconds and a minute, on PS5/XSX you do the same thing but it takes a few seconds and they need probably less non useful data and can improve the quality because streaming is not a problem. I don't think if we are now able to load 8k texture and pixel size geometry quality than size of data is a problem anymore for the I/O system.;) Storage size problem will exist for sure.

I prefer listen what devs with devkit and doing games on the machine are saying than an ex dev without devkit.

Loading screen doesn't dissapear with SSD they are just much faster and streaming doesn't dissapear but latency is lower and with a much bigger volume of data available.

EDIT:

And a good video about streaming problem with slow HDD.
 
Last edited:
Devs are interested in selling games on the platforms they support, and they are absolutely incentivised to make sales pitches.

The basic logic of how a computing ecosystem functions (storage, memory, CPU and the interactions therein) do not change because of the SONY PS5 moniker on the outside of the box. All the things Function has pointed out are foundational to the current x86 architecture, and nothing in your last few posts invalidates or refutes literally anything he's said.

Maybe some self reflection is due here: how much actual training do YOU have in x86 architecture at this level? Are you simply consuming marketing and regurgitating it because of an Appeal to Authority fallacy, or are you actually capable of describing, in the necessary intricate level of detail, how the things you're describing actually work?

Have you EVER created a production game devkit? Have you EVER been a developer for a game or an enterprise-class piece of I/O intensive software? Have you EVER had to hand-tune one of these storage and compute platforms for an intended performance target?

If the answers are no, then you aren't the authority here. Maybe you should pay some modicum of attention to people who actually have done this, and aren't RIGHT NOW trying to sell you something.
 
Devs are interested in selling games on the platforms they support, and they are absolutely incentivised to make sales pitches.

The basic logic of how a computing ecosystem functions (storage, memory, CPU and the interactions therein) do not change because of the SONY PS5 moniker on the outside of the box. All the things Function has pointed out are foundational to the current x86 architecture, and nothing in your last few posts invalidates or refutes literally anything he's said.

Maybe some self reflection is due here: how much actual training do YOU have in x86 architecture at this level? Are you simply consuming marketing and regurgitating it because of an Appeal to Authority fallacy, or are you actually capable of describing, in the necessary intricate level of detail, how the things you're describing actually work?

Have you EVER created a production game devkit? Have you EVER been a developer for a game or an enterprise-class piece of I/O intensive software? Have you EVER had to hand-tune one of these storage and compute platforms for an intended performance target?

If the answers are no, then you aren't the authority here. Maybe you should pay some modicum of attention to people who actually have done this, and aren't RIGHT NOW trying to sell you something.

Again no one of you have any experience with the devkits and this is not onlt Sony devs who said this but third party dev too and for the two platform and soon three platforms when DirectStorage will be available onPC . Basically third party devs said this too and SSD is not an exclusivity of Sony and The Xbox SSD is able to do the same thing loading screen will be a few seconds longer maybe 2 seconds but nothing very important. Even Fabian Giesen from RAD tools game the creator of oodle Kraken said basically the difference between PS5 I/O and Xbox I/O is not large. I don't talk about Sony and Microsoft I speak SSD and the right software stack. This is the same for NVME SSD on PC when Direct Storage will be available and this will be much better than PS5 and Xbox very fast maybe next year or in 2023 with 10GB/s and faster PCIE 5 SSD.

And again devs agree with Insomniac about problem of slow streaming SSD when they talk with their peers at GDC


https://devblogs.microsoft.com/directx/directstorage-is-coming-to-pc/

We’re excited to bring DirectStorage, an API in the DirectX family originally designed for the Velocity Architecture to Windows PCs! DirectStorage will bring best-in-class IO tech to both PC and console just as DirectX 12 Ultimate does with rendering tech. With a DirectStorage capable PC and a DirectStorage enabled game, you can look forward to vastly reduced load times and virtual worlds that are more expansive and detailed than ever.

Microsoft DirectStorage engineer said exactly the same things than Mark Cerny or Xbox team when they presented the experience to have an NVME SSD into the PS5/Xbox Series console.

And I prefer believe all Sony, Microsoft engineer and dev first or third party about the benefit of having a NVME SSD and a great I/O stack on any platform PS, Xbox or PC. They have much more crediblity than anyone. Even an ex dev doing youtube clickbait video.
 
Last edited:
Again no one of you have any experience with the devkits and this is not onlt Sony devs who said this but third party dev too and for the two platform and soon three platforms when DirectStorage will be available onPC .
Neither do you, and further more, neither have you ever apparently done heavy I/O stack management or application development. Some of us have done this work, for our paying day jobs, for literally decades.

The people creating the marketing are incentivized to make it sound as if it's the God(s) coming down to touch it directly. This is because their statements directly drive sales, both of the console and of their software. The true, objective reality is: this technology is well understood whether you think it true or not. At the end of the day, SSD's are faster -- yes, nobody disagrees. Faster anything allows you to make new decisions on where to allocate and spend against a limited pool resources. That's not actually anything new, even with your YouTube video deep-dives.

So please, recognize that you are basing your commentary on sales pitches. Others in this thread are basing their commentary on doing this as their paying, enterprise job for years upon years -- with equal amounts of education along the way.
 
Last edited:
Neither do you, and further more, neither have you ever apparently done heavy I/O stack management or application development. Some of us have done this work, for our paying day jobs, for literally decades.

The people creating the marketing are incentivized to make it sound as if it's the God(s) coming down to touch it directly. This is because their statements directly drive sales, both of the console and of their software. The true, objective reality is: this technology is well understood whether you think it true or not. At the end of the day, SSD's are faster -- yes, nobody disagrees. Faster anything allows you to make new decisions on where to allocate and spend against a limited pool resources. That's not actually anything new, even with your YouTube video deep-dives.

So please, recognize that you are basing your commentary on sales pitches. Others in this thread are basing theri commentary on doing this as their paying, enterprise job for years upon years -- with equal amounts of education along the way.

I am developer, not in games but I worked with C, C++, Java, C#. You don't know me and you don't know much more what you are talking about than me or other people not working with current devkit. You think console sales are there because of SSD. And if you think dev team will do GDC presentation about new streaming system for sales, I don't know what to do for you. Because presentation will probably arrive in 2022/2023.:D

Consoles sold because of games and services.

I am mostly seeing a fanboy here. Basically console are heavily cost constrained and if NVME SSD were not useful like you seems to say, they would have let SATA SSD in consoles this is much cheaper.

And another fact I am french and I have two friends working in game development. One in France at Quantic Dreams and two other peoples in Barcelona. The first one is the reasonI was knowing some of specs of PS5 and Xbox before Road to PS5. And all this guy told me SSD on consoles are the biggest thing this generation and soon on PC where they only need to change the software. PC have NVME SSD for years. The second biggest progress is the CPU.

Same I was on game forum since a long time. Sometimes we even had some dev speaking french explaining the work they are doing like Didier Malenfant.
 
Last edited:
Where did I say NVME SSD were not useful? I'd like you to quote where I said anything of the sort. Stop putting words into my mouth.

I'm glad you're a developer -- how much work do you do at the low level I/O stack management? I'm glad that you have friends working on games -- are they doing I/O stack management?

You keep saying things that, while technically true, aren't insightful or even useful to the conversation. There are things being said from software devs that you're taking at 100% face value, where the actual people who work on this tech know it isn't quite what you're being told. And any attempt at educating you why those statements are marketing versus reality gets pushed back by you with YouTube videos and more marketing.
 
Where did I say NVME SSD were not useful? I'd like you to quote where I said anything of the sort. Stop putting words into my mouth.

I'm glad you're a developer -- how much work do you do at the low level I/O stack management? I'm glad that you have friends working on games -- are they doing I/O stack management?

You keep saying things that, while technically true, aren't insightful or even useful to the conversation. There are things being said from software devs that you're taking at 100% face value, where the actual people who work on this tech know it isn't quite what you're being told. And any attempt at educating you why those statements are marketing versus reality gets pushed back by you with YouTube videos and more marketing.

Since you don't know about what you are talking GDC is acronym of Game developement conference.

https://gdconf.com/


This video is not about SSD but about Spiderman technical postmortem on PS4 and it is a recording of the conference done to devs and one of the biggest constraint comes from the low speed streaming system. You can go on the site and find tons of paper or video about streaming constraint on consoles with HDD or before optical disk.

I never said it is impossible to do the same things using for example SATA SSD but it means use old tricks and add contraint to game developpement. Here they load the data it is treated by the CPU setting uo everything and it is finished. There is a video somewhere I need to search where they use a portal on an on rail section and stop the game and make the camera travel into the full level loaded.

They don't need the full level because after it will be another on rail session and another portal but they do this because it is simple to do and ask less data management. And it will help them the day they need to do a portal system with more freedom.

Again the youtube video is a GDC presentation by devs to their peers and it is not because you work on I/O stack management than you don't know what your colleague are doing and how much NVME SSD impacts game dev. They don't do I/O stack management but they know people who do it. ;)

I don't do I/O stack management and the most important for games.
 
Last edited:
Oh look, another commentary from a dev who is hocking a platform.

You're now on the ignore list, because all you're apparently capable of (re)posting is marketing drivel. Fanboy indeed.
 
Back
Top