• Hey everyone, staff have documented a list of banned content and subject matter that we feel are not consistent with site values, and don't make sense to host discussion of on Famiboards. This list (and the relevant reasoning per item) is viewable here.
  • Do you have audio editing experience and want to help out with the Famiboards Discussion Club Podcast? If so, we're looking for help and would love to have you on the team! Just let us know in the Podcast Thread if you are interested!

StarTopic Future Nintendo Hardware & Technology Speculation & Discussion |ST| (Read the staff posts before commenting!)

The question being, how exactly feasible is the nearly 2000mAh upgrade.
I mean, the switch's battery compartment seems to be a bit small but I believe at the very least, 5000~5500 should be possible (judging from some cheap android phones).
They could maybe even do it like smartphone companies and make the battery taller, but thinner and re-arrange the other internals.
If you had a battery the same size and density as Switch and you apply the average 5% per-year battery density improvements to it, you end up with a battery capable of at least ~5775mAh, so yeah, should definitely be possible.

And the good news is, now that scientists have solved the polysulfide shuttle issue for lithium-sulphur batteries, this might all be a bit moot for the hardware after Drake, as we might see cheaper and far more energy-dense batteries by then.
 
So, it looks like Drake has a File Decompression Engine, a new piece of hardware which isn't on Orin.

A while ago after it was found out that Drake is using an 8 core CPU from a Linux commit message, I had a browse around myself and found some differences in some of the hardware blocks between Orin and Drake. Most of these are pretty understandable (removing automotive-focussed hardware), but one of them has stuck in my brain for a while, which is that there's a new block on Drake that's not on Orin, labelled FDE. I find this interesting because if it's on Drake but not on Orin, it would likely be something requested by Nintendo, or at least something that's of particular usefulness for a games console.

I just found a commit which solves the conundrum. The commit message simply reads:



I've also found a LinkedIn profile of a Nvidia employee which mentions FDE being "File Decompression Engine for games". I won't share it here, as I don't really feel comfortable posting links to random people's social media on public forums, but you can find it easily enough if you search. In any case, if the block is on Drake but not Orin, then it's not a huge leap to say it's for games.

A File Decompression Engine makes a lot of sense for a games console. Decompressing files as they're read from disk has a significant CPU overhead, something Nintendo are clearly well aware of, as Switch features a CPU boost mode specifically for improving loading times. It's a clear win for a fixed-function block like this, as modern game engines are constantly loading (and decompressing) assets from disk, and doing so on dedicated hardware will be more efficient in terms of transistors and power than throwing more CPU cores at it. Sony have gone this route with the PS5, where they've licensed both an algorithm and the hardware IP from an external source, whereas Nvidia seem to have done this in-house.

I think this is a pretty good sign for the next Switch. I've been saying for quite a while that dedicated decompression hardware would be a sensible thing to add to the new console, so it's good to see Nintendo and Nvidia thinking along the same lines. Of course it doesn't mean anything like PS5 load speeds, and we're still going to be limited by the read speeds of game cards, internal storage and removable storage, but it suggests Nintendo are serious about improving load speeds and decreasing CPU overhead of asset streaming. Which bodes well for them also using faster storage media too.
Good catch. It's interesting that the define there is related to cryptography -- perhaps the hardware can do both decryption and decompression? I can't really think of a strong link between the two, though. "FDE" appears elsewhere in the codebase with reference to AES, but I'm assuming in those cases it means full-disk encryption.
 
So, it looks like Drake has a File Decompression Engine, a new piece of hardware which isn't on Orin.

A while ago after it was found out that Drake is using an 8 core CPU from a Linux commit message, I had a browse around myself and found some differences in some of the hardware blocks between Orin and Drake. Most of these are pretty understandable (removing automotive-focussed hardware), but one of them has stuck in my brain for a while, which is that there's a new block on Drake that's not on Orin, labelled FDE. I find this interesting because if it's on Drake but not on Orin, it would likely be something requested by Nintendo, or at least something that's of particular usefulness for a games console.

I just found a commit which solves the conundrum. The commit message simply reads:



I've also found a LinkedIn profile of a Nvidia employee which mentions FDE being "File Decompression Engine for games". I won't share it here, as I don't really feel comfortable posting links to random people's social media on public forums, but you can find it easily enough if you search. In any case, if the block is on Drake but not Orin, then it's not a huge leap to say it's for games.

A File Decompression Engine makes a lot of sense for a games console. Decompressing files as they're read from disk has a significant CPU overhead, something Nintendo are clearly well aware of, as Switch features a CPU boost mode specifically for improving loading times. It's a clear win for a fixed-function block like this, as modern game engines are constantly loading (and decompressing) assets from disk, and doing so on dedicated hardware will be more efficient in terms of transistors and power than throwing more CPU cores at it. Sony have gone this route with the PS5, where they've licensed both an algorithm and the hardware IP from an external source, whereas Nvidia seem to have done this in-house.

I think this is a pretty good sign for the next Switch. I've been saying for quite a while that dedicated decompression hardware would be a sensible thing to add to the new console, so it's good to see Nintendo and Nvidia thinking along the same lines. Of course it doesn't mean anything like PS5 load speeds, and we're still going to be limited by the read speeds of game cards, internal storage and removable storage, but it suggests Nintendo are serious about improving load speeds and decreasing CPU overhead of asset streaming. Which bodes well for them also using faster storage media too.

This is very good news for Drake as Switch really needed a DFE to speed loading times up (and having better compression methods available).

It should help a bit with devs choosing the absolute cheapest cards available with limited read speeds. Even better the faster the card is
 
Good catch. It's interesting that the define there is related to cryptography -- perhaps the hardware can do both decryption and decompression? I can't really think of a strong link between the two, though. "FDE" appears elsewhere in the codebase with reference to AES, but I'm assuming in those cases it means full-disk encryption.
Basically all game data of note is stored encrypted on disk, so being able to decrypt before decompressing would certainly be a useful capability to have, at least for Nintendo's use case.
 
and then it's revealed that the soc really is made on samsung 8nm
While it is possible that it is Samsung 8nm, the size of the chip points to a more advanced process node, because according to the Nvidia power estimation tools for Jetson, a chip with 1/3rd less hardware would have nearly identical performance as Drake thanks to limited power draw and form factor limiting clocks. You can check it out yourself but 1024 Cuda cores at 624MHz offers 1.28tflops under 6w, while Drake's 1536 Cuda cores at 420mhz offers 1.29tflops at 5.7w. CPU has the same problem, which is to say, Drake is so big on 8nm that they are wasting a third of the transistors, thanks to power efficiency on 8nm. Burning money is not something we should expect, thus a die shrink is likely Imo.
 
Is it true that the T239 is a T234 but with a downgrade in its performance or power?
Yes in a sense Drake has

-8 A78 CPU cores (A78Cs are not confirmed, but reasonable)instead of 12 A78Es... And likely clocked lower than max 2.2 GHz

-less GPU cores (2048 vs 1536?) and not likely not clocked as high as 1.3 GHz

-128 bit bus width instead of 256.. so twice as less bandwidth from it's LPDDR5 RAM (102 GB/s vs 204 GB/s

-T234 AGX Orion doesn't have to worry to worry about power constraints due to not being run on battery

-Likely less cache than AGX Orion, but if T239 somehow gets A78C CPU, we might get more and match Agx Orion. Who knows.

Orion AGX isn't optimized for gaming and all the automotive machine stuff not relevant won't be on T239/Drake.

IRRC, the highest AGX model can go up to 5.2 TFLOPs for the GPU, and Drake could theoretically go up to 4 TFLOPs, but I believe nobody here is expecting the latter and hoping for closer to 3 TFLOPs in docked mode to be somewhat more reasonable.
 
Last edited:

 
Yes in a sense Drake has

-8 A78 CPU cores (A78Cs are not confirmed, but reasonable)instead of 12 A78Es... And likely clocked lower than max 2.2 GHz

-less GPU cores (2048 vs 1536?) and no1t likely not clocked as high as 1.3 GHz

-128 bit bus width instead of 256.. so twice as less bandwidth from it's LPDDR5 RAM (102 GB/s vs 204 GB/s

-T234 AGX Orion doesn't have to worry to worry about power constraints due to not being run on battery

-Likely less cache than AGX Orion, but if T239 somehow gets A78C CPU, we might get more and match Agx Orion. Who knows.

Orion AGX isn't optimized for gaming and all the automotive machine stuff not relevant won't be on T239/Drake.

IRRC, the highest AGX model can go up to 5.2 TFLOPs for the GPU, and Drake could theoretically go up to 4 TFLOPs, but I believe nobody here is expecting the latter and hoping for closer to 3 TFLOPs in docked mode to be somewhat more reasonable.
A78C is the lowest grade/oldest ARM chip that could be used in Drake given the 8 cores / 1 cluster configuration of Drake, all seemingly use the same frequency as well, meaning they are all one style of chip (Big ARM chip)

4TFLOPs is certainly possible if they are using 4N for the process node, I think 4N and 5nm Samsung are both more likely than 8nm at this point, but I'd suggest 2.3TFLOPs docked with 8nm, 5nm Samsung would likely offer 3.2TFLOPs and 4N would offer 4TFLOPs when docked... portable it's ~1.3TFLOPs for 8nm, 1.8TFLOPs for 5nm Samsung and up to ~2.5TFLOPs for 4N. Obviously this isn't including DLSS, and Nintendo might choose to keep a ~2TFLOPs performance with 4N in portable to give an extra 30 minutes+ to battery life, I think 5nm Samsung sort of fits with the performance that seems to have been offered up by people in the know, that the device is a PS4 with DLSS on top when portable, as 5nm Samsung could offer 1.843TFLOPs very easily, as it would only require 600MHz in portable, considering Erista hits 460MHz on 20nm 2D transistors for the original Switch, 600MHz is a pretty reasonable portable clock for Nintendo to hit this time around, but it would be closer to 400MHz on 8nm, with 420MHz requiring 5.7w on 8nm with Drake's configuration, 5nm Samsung should hit 624MHz under 5.5w, and 600MHz would probably cost right about 5w, probably less as these numbers are high load numbers and most games likely won't push the GPU to the limits the whole time.
 
Last edited:
Stupid question but what’s stopping Nintendo from changing memory controller from LPDDR5 to LPDDR5X? I know that Drake is “based” on Odin but is it mainly cost or do they need to redesign the chip to support it?

Setting as Drake is a more custom made SoC than Tegra X1 ever was
 
Stupid question but what’s stopping Nintendo from changing memory controller from LPDDR5 to LPDDR5X? I know that Drake is “based” on Odin but is it mainly cost or do they need to redesign the chip to support it?

Setting as Drake is a more custom made SoC than Tegra X1 ever was
I think we are just limiting expectations here, technically LPDDR5X support is completely possible for Drake and the upgrade in memory bandwidth would benefit the higher clock speeds I've mentioned above, so we will have to wait and see what the final specs are, all we know about the memory is that it has 128bit memory bus.
 
The dock only handles the DisplayPort (coming from the console) to HDMI signal conversion. The USB signal to DisplayPort signal switching is handled by the console.

So if VRR is an important enough feature that necessitates Nintendo to use HDMI 2.1, especially since HDMI 2.0b doesn't natively support VRR, unless FreeSync is used, then Nintendo only needs to replace the crossbar switch chip on the console (e.g. PI3USB30532 [USB 3.0/DisplayPort 1.2] to PI3USB31532 [USB 3.2 Gen 2/DisplayPort 1.4]) and the DisplayPort to HDMI converter chip on the dock (e.g. RTD2172N [DisplayPort 1.4 to HDMI 2.0b] to RTD2173 [DisplayPort 1.4 to HDMI 2.1]).

The OLED model still uses the PI3USB30532 chip, which has been used on the Nintendo Switch. However, the HDMI 2.0 cable provided by Nintendo for the OLED model's dock is apparently causing blackouts, which seems to have been fixed by switching to a HDMI 1.4 cable, which makes me wonder if the PI3USB30532 chip is the culprit for the blackouts. If so, then Nintendo has to change the crossbar switch chip on Nintendo's new console regardless.

And VRR doesn't necessarily require 120 Hz support. The only reason 120 Hz is mentioned is that all the mobile OLED displays with VRR support happen to support 120 Hz (e.g. iPhone 13 Pro and iPhone 13 Pro Max).
I never even mentioned VRR... My point was that I don't think Nintendo will drive ahead with HDMI 2.1 exclusive features at all! I think they'll stick to 2.0b in part because they wouldn't want to break compatibility with existing docks, and in part because it appears that the Dock with LAN Port was DESIGNED with some newer console in mind given its HDMI 2.0b capable hardware and massively increased ventilation, as well as its hugely increased power budget.
 
0
The Yen has exceeded 150 yen to the dollar for the first time in 32 years. Every Switch sold in Japan could result in a loss.
Nintendo promised in August that it would not raise the price of the Switch. Therefore, raising the price of existing the Switch would create a huge backlash.
Will Nintendo move forward launch of the new Switch in light of this exchange rate? 🤔
 
The Yen has exceeded 150 yen to the dollar for the first time in 32 years. Every Switch sold in Japan could result in a loss.
Nintendo promised in August that it would not raise the price of the Switch. Therefore, raising the price of existing the Switch would create a huge backlash.
Will Nintendo move forward launch of the new Switch in light of this exchange rate? 🤔
Day to day exchange rates of currencies do not tend to considerably affect launch windows for hardware where production, advertising and planning would have been in motion for years with little margin for change outside of moving a quarter or so.
 
The Yen has exceeded 150 yen to the dollar for the first time in 32 years. Every Switch sold in Japan could result in a loss.
Nintendo promised in August that it would not raise the price of the Switch. Therefore, raising the price of existing the Switch would create a huge backlash.
Will Nintendo move forward launch of the new Switch in light of this exchange rate? 🤔
I doubt it, for large corporations like Nintendo, it would be rare to see one not engaging in foreign exchange (FX) derivatives to reduce potential losses. Besides I believe their main reporting currency is JPY and Switch sales in JP is large but not the majority versus other regions. So if anything, a weak JPY would actually work in their favor.
 
The external source you’re referring to with PS5 is Oodle, yeah? The data decompression on that was impressive, but the real big win there was the texture compression tech, hope Nvidia offers something like that.

Yeah, that's the one. Microsoft also have their own hardware decompression on the Series consoles, along with a proprietary texture compression algorithm called BCPack. I can't find any details on BCPack, though. No evidence here if Nvidia are doing something similar with texture decompression, but I would imagine that the choice of compression algorithms to support would be heavily influenced by how it handles game data, and textures would be a big part of that.

Good catch. It's interesting that the define there is related to cryptography -- perhaps the hardware can do both decryption and decompression? I can't really think of a strong link between the two, though. "FDE" appears elsewhere in the codebase with reference to AES, but I'm assuming in those cases it means full-disk encryption.

As @Pokemaniac said, all content will have to be decrypted before being decompressed, so there is a relationship there. It's a separate block from any other crypto hardware like TSEC (although I'm not sure if TSEC actually performs any decryption, or just manages keys). It's possible that the FDE block also performs decryption, or it works in tandem with other hardware to decrypt then decompress.

This is very good news for Drake as Switch really needed a DFE to speed loading times up (and having better compression methods available).

It should help a bit with devs choosing the absolute cheapest cards available with limited read speeds. Even better the faster the card is

It's important to note that this doesn't actually make read speeds any faster, a 100MB/s microSD card is going to be just as slow whether the FDE block is there or not. The difference is that without the FDE block you'd have to use up a bunch of CPU cycles to decompress the data coming from the microSD card, whereas now the CPU is free to do other stuff. Drake's CPU is already much more capable than the current Switch, so it would have been able to perform faster decompression and therefore improve loading times relative to the current model, but the FDE means that the CPU doesn't have to do that job.

This is particularly important when we're talking about asset streaming in games, not just statically loading data at the start of a level. If you've built a game engine around being able to continuously stream data from a storage device (see basically every modern game engine), then having to perform decompression on the CPU is a pain, because it eats into all the other things you're trying to run on the CPU. This gets even worse as storage media gets faster, as more and more of your CPU time is just spent on getting data into memory. This is why MS and Sony and Nintendo have all gone with hardware decompression blocks in their new hardware.

The reason it makes me hopeful for faster storage solutions is that is shows Nintendo are actively targeting data loading as something they're trying to improve, so they might also be looking at improving the underlying read speeds as well. Relatively fast internal memory shouldn't be a problem, as eUFS 2.1 is cheap and hits around 800MB/s, but I'm still concerned about removable storage, as there's no clear, widely used successor to the old and slow UHS-I microSD standard.
 
Stupid question but what’s stopping Nintendo from changing memory controller from LPDDR5 to LPDDR5X? I know that Drake is “based” on Odin but is it mainly cost or do they need to redesign the chip to support it?

Setting as Drake is a more custom made SoC than Tegra X1 ever was
I think we are just limiting expectations here, technically LPDDR5X support is completely possible for Drake and the upgrade in memory bandwidth would benefit the higher clock speeds I've mentioned above, so we will have to wait and see what the final specs are, all we know about the memory is that it has 128bit memory bus.
Lpddr 5X prices, if anything.
What’s stopping it is straight up lack of physically supporting it inside the silicon where the memory controllers are. You need a MC for LPDDR5X. If something has LPDDR5 MC, it can only take LPDDR5. If it has the MC of DDR5 and LPDDR5, it can support both but not at once.

It’s why you see something like the 6800U with LPDDR5 and DDR5 support.

If Drake were to have it, a modification to the silicon is required, which can be netted during a die shrink process and offer a more efficient system a la Lite 2 for instance.


So yes, there’s something that does stop them. It could be that it already supports 5X memory, but we are assuming 5 because ORIN supports 5. We will have to see when we get the thing.


Example:
lyhmdzo6c3w71.jpg

You see that Memory Control? You also see the Physical layer? That’s inside the SoC. It’s not a simple cold swap like an HDMI cable, has to directly support it.
 
Last edited:
The reason it makes me hopeful for faster storage solutions is that is shows Nintendo are actively targeting data loading as something they're trying to improve, so they might also be looking at improving the underlying read speeds as well. Relatively fast internal memory shouldn't be a problem, as eUFS 2.1 is cheap and hits around 800MB/s, but I'm still concerned about removable storage, as there's no clear, widely used successor to the old and slow UHS-I microSD standard.
I remember @fwd-bwd posted a while back about UFS and microSD card dual support, and it makes me wonder if Nintendo had that in mind to adopt here….

I wonder if they’ll go with something newer for the internal, and have it run slower for any potential energy savings.
 
0
Stupid question but what’s stopping Nintendo from changing memory controller from LPDDR5 to LPDDR5X? I know that Drake is “based” on Orin but is it mainly cost or do they need to redesign the chip to support it?

Setting as Drake is a more custom made SoC than Tegra X1 ever was
I think we are just limiting expectations here, technically LPDDR5X support is completely possible for Drake and the upgrade in memory bandwidth would benefit the higher clock speeds I've mentioned above, so we will have to wait and see what the final specs are, all we know about the memory is that it has 128bit memory bus.
Lpddr 5X prices, if anything.
There's a possibility that the LPDDR5 memory controller isn't forwards compatible with LPDDR5X, similar to how the LPDDR4 memory controller isn't forward compatible with LPDDR4X.

So in that case, Nintendo and Nvidia need to replace the LPDDR5 memory controller with the LPDDR5X memory controller in Drake for LPDDR5X to be used.
 
There's a possibility that the LPDDR5 memory controller isn't forwards compatible with LPDDR5X, similar to how the LPDDR4 memory controller isn't forward compatible with LPDDR4X.

So in that case, Nintendo and Nvidia need to replace the LPDDR5 memory controller with the LPDDR5X memory controller in Drake for LPDDR5X to be used.
The question that was asked was “Stupid question but what’s stopping Nintendo from changing memory controller from LPDDR5 to LPDDR5X?”

What’s stopping them from changing memory controller? Lpddr5x prices if anything.

There is nothing stopping them from changing memory controller, but why bother if lpddr5x is to expensive anyway, is what I meant.
 
The question that was asked was “Stupid question but what’s stopping Nintendo from changing memory controller from LPDDR5 to LPDDR5X?”

What’s stopping them from changing memory controller? Lpddr5x prices if anything.

There is nothing stopping them from changing memory controller, but why bother if lpddr5x is to expensive anyway, is what I meant.
There's also a non-trivial amount of time required to change the memory controller in the SoC and to do memory controller validation, especially if Nintendo wants to take full advantage of the max I/O rate of LPDDR5X for TV mode (e.g. 8500 MT/s for Samsung's LPDDR5X).

So I suppose "time is money" is applicable here.
 
As an aside, A) I feel dumb as hell that it took me right up until the 6 seconds before the season 1 finale where Mr. Wednesday screamed his real identity (especially given the allusions to absolutely everything), and B) fuck the showrunners/Amazon Prime who screwed over Orlando Jones and axed literally THE BEST character of Anansi, and cancelled the show after three seasons on such a ridiculous cliffhanger
 
Without knowing what I’m talking about, I somehow doubt this would make a significant contribution to the total budget for customizing Drake.
I think timing rather than cost is the issue, considering Samsung only announced having Samsung's 8.5 Gbps (8500 MT/s) LPDDR5X modules validated by Qualcomm a couple of days ago.

 
I forgot to comment myself on this: the SoC is perfect and has checked every personal checklist, I can die peacefully now. I have zero real qualms now.

CPU? Perfect upgrade. GPU? perfect upgrade. Decompression block? Perfect upgrade. Memory? Perfect upgrade. OLED display? Perfect upgrade. HDMI 2 or later? Perfect upgrade.

I have no qualms and it’s a perfect upgrade in every facet over the switch. This will last me until 2030 or whatever, I don’t care.

The SoC is a perfect upgrade…..


Actually there’s one thing I want to know, will this have an SLC? That’s still a mystery to me, this wouldn’t really be that apparent or visible, but it would be a Bandwidth requirement reduction, and efficiency increase.

4-6MB SLC would be pretty sweet. Orin has a 4MB SLC, so maybe this remained?

That’s how I feel. It’s everything you would want in a 2023 hybrid console. Nothing really stand out as major bottleneck unlike the original Switch cpu needing a die shrink and faster/more ram. All I need is to hear about ufs 3.1 expansion support and I can put this thread on ignore.
 
I think timing rather than cost is the issue, considering Samsung only announced having Samsung's 8.5 Gbps (8500 MT/s) LPDDR5X modules validated by Qualcomm a couple of days ago.

MS will never do this, as that would kill the entire appeal of the console.
 
Without knowing what I’m talking about, I somehow doubt this would make a significant contribution to the total budget for customizing Drake.
If you’re going to go for 5X, you make the SoC with 5X in mind. If not, then no. The process of shrinking is more of actually remaking it on a later node while still keeping foundry IP and compatibility provided by the foundry. For Erista, during the shrink they “swapped” the 4 memory controller for a 4X memory controller and also changed to have the 4X physical layer from the 4 physical layer (an IP). For Drake, it would be the same thing if they decide to go with 5X later. Though this might be less of an issue since 5 and 5X are in the same family, I’m not so sure with the physical layer.

They could have chosen 5X from the start, and that being their plan, they would have made the SoC with the 5X in mind. If not, they went with 5 because that’s what Orin uses.

You make a soc with every factor and facet in mind, not one or the other. In this case, you’d have to go through the whole process even if it’s a change of memory controllers, but it’s a quicker process than making a whole different SoC. That said, time here and money spent with designing it isn’t trivial at all, you still have to do the whole
Validation, testing, verification, sampling, etc.

And that’s just for altering to have faster memory.
 
In terms of storage, how much real world difference would it make loading from micro sdxc vs a faster medium for this kind of platform?

From what I have seen the difference on the steam deck between the NVME model and loading from sdxc isn't that huge, I will admit I haven't looked for a while, OS improvements may have increased the gap.

Ultimately the device will be power constrained so it won't be able to max something like UFS 2.1.

That being said, Nintendo has a relationship with SanDisk at the very least with its branded micro sd cards, so I could see them looking to launch the new system with a new medium like SD Express or UFS card using one of their memory partners to do so, might drive adoption in other markets.

They could go with their own storage solution but I don't think that's likely given how much it hurt the vita.

NVME? It's doable, they could just limit the speeds massively like in the steam deck. The reason I don't think it's likely is because of how much fluctuation there is between NVME Drives in terms of both active and idle power draw, my gaming laptops battery life has been abysmal since I fitted a second NVME in the form of a WD Blue so I looked it up and yup, power draw is all over the place. I feel this would take some control away from Nintendo for their battery life claims and no doubt they won't really want that.

So the only real option they have is stick to micro sdxc or push a new standard via either SanDisk or Samsung. This would be a gamble so there needs to be a great benefit to doing so in a device like the switch.

Edit: Actually nvm, I just found some new figures and it's twice as slow loading from sd card vs a good NVME, wow.
 
Last edited:
In terms of storage, how much real world difference would it make loading from micro sdxc vs a faster medium for this kind of platform?

From what I have seen the difference on the steam deck between the NVME model and loading from sdxc isn't that huge, I will admit I haven't looked for a while, OS improvements may have increased the gap.

Ultimately the device will be power constrained so it won't be able to max something like UFS 2.1.

That being said, Nintendo has a relationship with SanDisk at the very least with its branded micro sd cards, so I could see them looking to launch the new system with a new medium like SD Express using one of their memory partners to do so, might drive adoption in other markets.

They could go with their own storage solution but I don't think that's likely given how much it hurt the vita.

NVME? It's doable, they could just limit the speeds massively like in the steam deck. The reason I don't think it's likely is because of how much fluctuation there is between NVME Drives in terms of both active and idle power draw, my gaming laptops battery life has been abysmal since I fitted a second NVME in the form of a WD Blue so I looked it up and yup, power draw is all over the place. I feel this would take some control away from Nintendo for their battery life claims and no doubt they won't really want that.

So the only real option they have is stick to micro sdxc or push a new standard via either SanDisk or Samsung. This would be a gamble so there needs to be a great benefit to doing so in a device like the switch.

Edit: Actually nvm, I just found some new figures and it's twice as slow loading from sd card vs a good NVME, wow.
The metric that is important, is the real world minimum speed that devs can rely on for their games. The industry is about to embrace fast asset streaming for their engines, the obvious example of this is Nanite. According to a dev here, Nanite requires a minimum of 500 mb to work decently, preferably 1gb,

edit: 300 mb minimum.
 
Last edited:
0

Hmm, so referencing the chart from this page, to recap, the three foundries are all attempting backside power delivery in different years. Presumably, Intel's trying first in 2024 (in combination with their first attempt with GAAFET, I think?), Samsung in 2025 with their second generation of GAAFET, and TSMC in 2026? with the refinement/variant of their first GAAFET generation.
I think timing rather than cost is the issue, considering Samsung only announced having Samsung's 8.5 Gbps (8500 MT/s) LPDDR5X modules validated by Qualcomm a couple of days ago.

Full speed LPDDR5X should be getting into products first half of next year, going by Nvidia's Grace superchip. Of course, if Drake was originally targeting the end of this year, 7500 MT/s was probably the one that theoretically could've been planned for years ago.
 
In terms of storage, how much real world difference would it make loading from micro sdxc vs a faster medium for this kind of platform?

From what I have seen the difference on the steam deck between the NVME model and loading from sdxc isn't that huge, I will admit I haven't looked for a while, OS improvements may have increased the gap.

Ultimately the device will be power constrained so it won't be able to max something like UFS 2.1.

That being said, Nintendo has a relationship with SanDisk at the very least with its branded micro sd cards, so I could see them looking to launch the new system with a new medium like SD Express or UFS card using one of their memory partners to do so, might drive adoption in other markets.

They could go with their own storage solution but I don't think that's likely given how much it hurt the vita.

NVME? It's doable, they could just limit the speeds massively like in the steam deck. The reason I don't think it's likely is because of how much fluctuation there is between NVME Drives in terms of both active and idle power draw, my gaming laptops battery life has been abysmal since I fitted a second NVME in the form of a WD Blue so I looked it up and yup, power draw is all over the place. I feel this would take some control away from Nintendo for their battery life claims and no doubt they won't really want that.

So the only real option they have is stick to micro sdxc or push a new standard via either SanDisk or Samsung. This would be a gamble so there needs to be a great benefit to doing so in a device like the switch.

Edit: Actually nvm, I just found some new figures and it's twice as slow loading from sd card vs a good NVME, wow.
I think a possible reason for why the steam deck does not exhibit much of a difference between eMMC and NVMe in terms of storage speeds for actual real world practice is that it’s CPU limited. The eMMC might be tapping out to its max speed and CPU limited, but the CPU limit may be preventing the NVMe drive from actually performing as best as I could. So you get a similar speed in practice. On top of that, it doesn’t seem like things are made to even properly use one anyway so the Steam deck sees no gain here.

It’s only a theory though.
 
Hmm, so referencing the chart from this page, to recap, the three foundries are all attempting backside power delivery in different years. Presumably, Intel's trying first in 2024 (in combination with their first attempt with GAAFET, I think?), Samsung in 2025 with their second generation of GAAFET, and TSMC in 2026? with the refinement/variant of their first GAAFET generation.

Full speed LPDDR5X should be getting into products first half of next year, going by Nvidia's Grace superchip. Of course, if Drake was originally targeting the end of this year, 7500 MT/s was probably the one that theoretically could've been planned for years ago.
Yeah, seems to be that way.

I imagine if Nintendo's planning on releasing new hardware in early 2023*, which is still a very real possibility, especially with the release of Tears of the Kingdom, then Nintendo and Nvidia need to tape out Drake by September 2022 at the absolute latest, which I don't think is enough time to implement support for 8500 MT/s LPDDR5X modules. But perhaps implementing 7500 MT/s LPDDR5X modules could be possible, although not necessarily ideal.

* → I define early 2023 as January - May 2023, mid 2023 as June and July 2023, and late 2023 as August - December 2023
 
0
I think a possible reason for why the steam deck does not exhibit much of a difference between eMMC and NVMe in terms of storage speeds for actual real world practice is that it’s CPU limited. The eMMC might be tapping out to its max speed and CPU limited, but the CPU limit may be preventing the NVMe drive from actually performing as best as I could. So you get a similar speed in practice. On top of that, it doesn’t seem like things are made to even properly use one anyway so the Steam deck sees no gain here.

It’s only a theory though.
I think that it's more likely due to us still being in the pre-DirectStorage era and/or power throttling, than it is due to CPU limitations.
Consider that eMMC isn't exactly worlds apart from SATA, and that in PC space right now, there isn't significant tangible difference between SATA and NVMe for most mainstream usecases. Certainly not gaming. It goes back to sequential vs random access; the former's improving at a much faster pace than the latter. Reading individual giant files (like in video editing) vs jumping around all over the place reading a smaller file here and there (like...most things happening on a PC, really; also the reason that going from spinning hard disks to SATA SSD feels like one of the top revolutionary upgrades for consumer PC usage in the past ~15? years).
 
If there is this requirement for 500mbps for asset streaming, what combination of cartridge, internal and external storage medium could realistically achieve that and be mass adopted by the consumer?

This is where I struggle to see Nintendo moving away from simple micro sdxc. If asset streaming is such a big deal then they need to be able to achieve it on internal storage, carts and removable storage.

UFS 2.1 is fine for internal but what about removable? Only options I can see that are cost effective is NVME and UFS Card but as far as I can see UFS Card is a dead format.

Carts, there really is nothing that can be cost effective and read at that speed.

I simply think they won't prioritise it. Cost effectiveness of storage options and simple user experience are more important to Nintendo I feel.
 
If there is this requirement for 500mbps for asset streaming, what combination of cartridge, internal and external storage medium could realistically achieve that and be mass adopted by the consumer?

This is where I struggle to see Nintendo moving away from simple micro sdxc. If asset streaming is such a big deal then they need to be able to achieve it on internal storage, carts and removable storage.

UFS 2.1 is fine for internal but what about removable? Only options I can see that are cost effective is NVME and UFS Card but as far as I can see UFS Card is a dead format.

Carts, there really is nothing that can be cost effective and read at that speed.

I simply think they won't prioritise it. Cost effectiveness of storage options and simple user experience are more important to Nintendo I feel.
I dug up the actual quote, what I wrote earlier was somewhat badly remembered. He is referencing the game he is working on, using Nanite.

300 MB/s would be barely enough. 500 MB/s would be fine but I'd have to be more thoughtful about staying within those boundaries. 1000 MB/s would be enough to where I wouldn't have to worry about it.
 
In terms of storage, how much real world difference would it make loading from micro sdxc vs a faster medium for this kind of platform?

From what I have seen the difference on the steam deck between the NVME model and loading from sdxc isn't that huge, I will admit I haven't looked for a while, OS improvements may have increased the gap.

Ultimately the device will be power constrained so it won't be able to max something like UFS 2.1.

That being said, Nintendo has a relationship with SanDisk at the very least with its branded micro sd cards, so I could see them looking to launch the new system with a new medium like SD Express or UFS card using one of their memory partners to do so, might drive adoption in other markets.

They could go with their own storage solution but I don't think that's likely given how much it hurt the vita.

NVME? It's doable, they could just limit the speeds massively like in the steam deck. The reason I don't think it's likely is because of how much fluctuation there is between NVME Drives in terms of both active and idle power draw, my gaming laptops battery life has been abysmal since I fitted a second NVME in the form of a WD Blue so I looked it up and yup, power draw is all over the place. I feel this would take some control away from Nintendo for their battery life claims and no doubt they won't really want that.

So the only real option they have is stick to micro sdxc or push a new standard via either SanDisk or Samsung. This would be a gamble so there needs to be a great benefit to doing so in a device like the switch.

Edit: Actually nvm, I just found some new figures and it's twice as slow loading from sd card vs a good NVME, wow.

SD Express and CFexpress are both basically NVMe SSDs in plastic casing, as they both use the NVMe spec. The issue with them is much like the issue with M.2 NVMe SSDs, in that they draw too much power for a device like the Switch. SD Express also has the problem that it requires a custom interface to support both the old SD and new NVMe modes, unlike CFexpress where you could basically just wire a PCIe lane directly from Drake to the card reader and almost be done. SD Express is currently supported by a grand total of zero devices whereas CFexpress exists in the expensive niche world of high-end cameras.

I personally like UFS cards, as being based on the embedded UFS standard they're power efficient, and should be reasonably cheap to manufacture (as they can leverage the economies of scale of eUFS production). Current cards only go to 550MB/s, but the UFS Card 3.0 spec supports 1200MB/s, and as it's based on a single-lane version of the existing embedded UFS 3 interface, it should be achievable to scale up manufacturing relatively quickly.

Anything other than plain old UHS-I microSD would require Nintendo to basically drive adoption of the standard themselves, working with manufacturers to make sure a range of capacities are available at a reasonable price at launch. They're likely big enough to do so (Nintendo ship far more Switch units a year than the entire camera industry ship dedicated cameras), but I'm not sure if there'll be a willingness to do that.
 
Last edited:
Anything other than plain old UHS-I microSD would require Nintendo to basically drive adoption of the standard themselves, working with manufacturers to make sure a range of capacities are available at a reasonable price at launch. They're likely big enough to do so (Nintendo ship far more Switch units a year than the entire camera industry ship dedicated cameras), but I'm not sure if there'll be a willingness to do that.
Qhile that is true, external storage cards is basically a requirement for a dedicated camera. I reckon a large percentage of switch users get by with the onboard storage. I don't know the percentage, but I bet Nintendo does.
 
I dug up the actual quote, what I wrote earlier was somewhat badly remembered. He is referencing the game he is working on, using Nanite.
Although BC said it, he isn’t the only person that said 1GB/s throughput minimum is preferred. Mark Cerny spoke about how devs wanted at least 1GB/s in the Wired interview, and they just went above that because reasons.

It seems like all around, 1GB/s at least is a safe spot for devs.
 
Qhile that is true, external storage cards is basically a requirement for a dedicated camera. I reckon a large percentage of switch users get by with the onboard storage. I don't know the percentage, but I bet Nintendo does.
The attach ratio of the Nintendo switch is nearing 8 games per console sold, and that is not including digital only titles. Judging by the best selling titles on the system, and the fact of the switch only carrying 32 GB of onboard storage, it’s pretty safe to assume that they are not getting by with just onboard storage. Even looking at the eshop and looking at the Evergreen titles and amount of storage they require, you can determine pretty safely what the actual average spending is, and the amount of storage required for that.


Currently, the most downloaded item on the system is Overwatch 2 at 13.4GB. Next title is Fall Guys at 2.4GB. Next YT at 163MB. Next is Fortnite, who has actually stayed in the top ranking for quite a while, is 17.8GB. And finally there’s Rocket League, at 17.7GB. How much does this add to? 51.463GB of internal storage required. Keep in mind that these are ahead of the best sellers list.


If we move over to the Paid items, aka the best sellers list, I’m going to narrow it to the titles that have remained in the top best sellers for a while and not for a fleeting moment. So I’m excluding titles like Nier Automata or No Man’s Sky.

Ok, so the titles that consistently remain in the best sellers is Mario Kart, Minecraft, Super Smash Bros (which is a whole can of worms) and previously it was Breath of the Wild.

7.9GB-MK
1.2GB-MC
17.3GB-SSB
14.4GB-BOTW

That’s 40.8GB is storage required there.


I think you can see where I headed here.


Actually the 51GB above is perfect for an OLED with 64GB of storage, and really, having more storage encourages more spending.


And even with the Wii U, the people went for the higher storage model even if more expensive.


The idea that it’s a large percentage… quite frankly to me is not supported, it’s likely a minority at best. You’ll need a 64GB or a 128GB card to get by, but it’ll be harder if we went for an average of 8 games added.


Even if I did add the numbers above, it’s about 92GB for the games people reach for the most on the system.
 
Last edited:
not 100% relevant, but it does get the "imagine" juices flowing

Tower of Fantasy is getting ray tracing support. I knew it was getting DLSS3, but I wasn't expecting RT. and this game is animu-as-fuck-boi, so it's an interesting case of how RT can work with such styles (even though we know there was never a problem)

 
Please read this staff post before posting.

Furthermore, according to this follow-up post, all off-topic chat will be moderated.
Last edited:


Back
Top Bottom