• 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.

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

giphy.gif

How some here probably view Nintendo engineers.
Nintendo engineers in actuality:

1474a556848411f587f0becc179954fc
 
Hello Fami Fam, lets HOPE this the be the last full week we go without OFFICIAL information about the successor to the Nintendo Switch, by Wednesday of next week by all that is holy we be put out of misery next week discussing a device we know for sure is real and coming.
Next week I‘ll find out if this thread is real or only existed in my head
 
Mario Kart is also pretty miserable. Sure, you can always say it’s all legacy code but I really think there's no excuse for that, whether its 3D World or Splatoon.
Rollback isn't possible in Mario Kart, or Smash, and likely not in those other two games. At least not on Switch. The hardware can't do it.

There is something called big O notation which is a way of talking about how complicated an algorithm is. Algorithms aren't programs, right, like you can optimize a program to make it more efficient, but a program can never be faster than the algorithm. It's like baking a cake - you can optimize the number of dishes, you can rearrange your kitchen so all the ingredients are at hand, but you can't make the cake itself bake faster in the oven without changing the recipe.

Big O lets you describe how algorithms scale - which isn't how "fast" or "slow" they are, but how their speed changes as you increase the number of things. It's written like this, O(math problem with the letter n in it). N, in this case is the number of things.

O(n )means "each time you add a thing, this algorithm slows down by the same amount". Like going down a line of people to tell them that the restaurant is out of french fries. Each person adds the same amount of time to the process. Contrast with O(1) "this algorithm takes the same amount of time no matter how many things there are to deal with." So standing at the front of the line and just yelling "yo, we're outta french fries!"

Rollback netcode is O(n^2), where n is the number of game states that need to be reconciled. That's basically just the number of players, minus 1. You're playing Street Fighter, you just need to reconcile your game with your opponents game, and adjust player positions if they are out of sync. (2-1)^2 = 1^2 = 1. Simple

Smash has four players, twice the number as Street Fighter. (4-1)^2 = 3^2 = 9. Rollback netcode for Smash is nine times as complex as Street Fighter. Mario Kart 8 supports 12 online players simultaneously - (12-1)^2 = 11^2 = 121. Mario Kart's rollback load is 121 times as complex as Street Fighter.

If you really wanna get in the weeds, there are actually two algorithms at work. The one were counting says "how many reconciliations do we need to run to sync this frame of gameplay." But there is a second that says "how complex is the reconciliation itself".

This process of reconciling all these potentially diverging players is probably O(n ), but in this case, n is the number of states the game can be in. That's basically "number of pixels in the game field x the number of things the players can be doing". That's what I mean by big O describing how algorithms scale, not how slow or fast they are. In this case, the reconcilliation process gets slower the larger the level, and the more moves players have. Smash obviously has lots of moves, but in Mario Kart, basically each item is gonna be a "move" - or, in some cases, like the blue shell, it's effectively a new player with it's own moves!

What does this have to do with the Switch hardware? All these simulations have to be run on the CPU. The Switch has a truly remarkable GPU for a 2017 mobile device, but CPU wise, it's hamstrung. It's got a decent mobile CPU for 2017, but that was right before the mobile CPU boom. Switch underclocks those things for power reasons down to a mere 1GHz, and it only has 4 of them, where rollback code is actually pretty multi-core friendly, when done right.

In the case of Smash specifically, we know that the team implemented rollback netcode, but removed it because the cost of it took multiple frames to reconcile, increasing latency, not reducing it. So at least one Nintendo product wasn't saddled with legacy code, it was purely that the Switch's CPU hardware wasn't up to the task for the huge complexity that multiplayer Nintendo games offer.
 
Nah, I've tested it plenty on a modded Switch. I've yet to run into a game that's supposed to support the touch screen that doesn't when forced into docked performance.
Just to be sure, when you say forcing docked performance, I assume that also involved forcing docked mode? Since the "operating mode" (docked/handheld) and performance configurations (CpuXxxMhz, GpuXxxMhz) are technically independent settings, they're just normally changed together and have system validations constraining them. If a game did stop registering input in docked mode, it would be because of the operating mode, not the performance profile.
 
Exactly.

giphy.gif

How some here probably view Nintendo engineers.

Nintendo's engineers are like anyone else really. Just regular people who are hired to do a job. But said job can only be accomplished effectively, and efficiently provided they have the required time, and resources. They are no more special than anyone in any other field.

Why did TOTK turn out so good from a technical perspective? Time. That's all it was. Nothing groundbreaking. Just time. They weren't rushed by some arbitrary deadline in order to meet some bean counter's demands. The team took their time, and Nintendo was more than willing to let that happen.
 
And here... we... go. Again.

Pretty much just repeating rumours, since Switch 2 is the most talked about system, despite it not being revealed.

But the only interesting tidbit would be this from the article

,,The shift from “focus” to “support” for the Switch implies that a new console will launch in Nintendo’s next fiscal year — so, between April 2024 and March 2025’’.

Other than that it’s the usual click bait article.
 
Nintendo's engineers are like anyone else really. Just regular people who are hired to do a job. But said job can only be accomplished effectively, and efficiently provided they have the required time, and resources. They are no more special than anyone in any other field.

Why did TOTK turn out so good from a technical perspective? Time. That's all it was. Nothing groundbreaking. Just time. They weren't rushed by some arbitrary deadline in order to meet some bean counter's demands. The team took their time, and Nintendo was more than willing to let that happen.
If only a certain dystopian game took note… funnily enough its saving grace was a good anime.
 
0
Just to be sure, when you say forcing docked performance, I assume that also involved forcing docked mode? Since the "operating mode" (docked/handheld) and performance configurations (CpuXxxMhz, GpuXxxMhz) are technically independent settings, they're just normally changed together and have system validations constraining them. If a game did stop registering input in docked mode, it would be because of the operating mode, not the performance profile.
Yes, operating mode, via ReverseNX. It's quite clear that it works with games like Bowser's Fury, which switches framerate targets depending on operating mode. I've played around pretty extensively with both operating mode and performance profiles in different games for the fun of experimentation (forcing games that are normally sub-native into docked operating mode while handheld in particular is a treat).
 
Nintendo's engineers are like anyone else really. Just regular people who are hired to do a job. But said job can only be accomplished effectively, and efficiently provided they have the required time, and resources. They are no more special than anyone in any other field.

Why did TOTK turn out so good from a technical perspective? Time. That's all it was. Nothing groundbreaking. Just time. They weren't rushed by some arbitrary deadline in order to meet some bean counter's demands. The team took their time, and Nintendo was more than willing to let that happen.
I think this is a tad reductive tbh. I think there are variables other than just “development time” that have lead to Nintendo’s various successes: high employee retention rate, highly selective/competitive hiring, focused vision from senior staff/management, company culture of innovation, etc.
 
Nintendo's engineers are like anyone else really. Just regular people who are hired to do a job. But said job can only be accomplished effectively, and efficiently provided they have the required time, and resources. They are no more special than anyone in any other field.

Why did TOTK turn out so good from a technical perspective? Time. That's all it was. Nothing groundbreaking. Just time. They weren't rushed by some arbitrary deadline in order to meet some bean counter's demands. The team took their time, and Nintendo was more than willing to let that happen.
I'm afraid Nintendo has its own unique approach to project management, and some of the game industry practitioners I know (including those in Japan) are amazed that it took Nintendo five years to make totk with such amazing technical effects and physical interactions.
 
I'm down for it only if we can apply one of the following personalities to it:

Navi
Midna
Captain Toad
Olimar
Rusty
Isabelle, she is litterally THE assistant in the Animal Crossing series :p
Assistant for what exactly..
Good question, tho. But I can see it in a way that an AI assistant can tell you about the environment in a certain level.

''This forest level gives me the creeps. It's something about those Boo's and poisoned water, so watch out where you step.''
''This level is more vertical than horizontal, good thing Kirby can float and hover through the air. If only there was a certain ability that allows you to attack more carefully in the air.''
''Rainbow Road is so colorful and beautiful! But it can be dangerous aswell! Just don't fall off the track, or you'll end up last!''

Things like that, kinda like the Palutena's guidance easter egg in Smash, but about the levels/world map.
That's what I can think of actually. But I think that'll be difficult to implement in third party games like a CoD or Red Dead Redemption II.

Hello Fami Fam, lets HOPE this the be the last full week we go without OFFICIAL information about the successor to the Nintendo Switch, by Wednesday of next week by all that is holy we be put out of misery next week discussing a device we know for sure is real and coming.

I don't know, everytime there is a investors meeting, we think they might say something. I'll just be careful with my hopes this time. It would be something if they said it, but the last 2 investors meeting I followed here on Fami, our hopes crushed. So yeah..
 
I don't know, everytime there is an investors meeting, we think they might say something. I'll just be careful with my hopes this time. It would be something if they said it, but the last 2 investors meeting I followed here on Fami, our hopes crushed. So yeah..

TBH the odds of Nintendo mentioning anything in the last 2 Investor meetings was incredibly low, nobody should be banking on it.

The odds are still low here for upcoming investors meeting as well. The only thing making odds slightly higher is the fact that March 2025 falls into the current (new) FY.

But even that’s not a guarantee either.

If nintendo doesn’t say anything (and let’s be honest if they did, it will be only a single sentence probably), boy, we probably are in for a LONG wait (potentially October 2024 in the worst timeline)
 
Rollback isn't possible in Mario Kart, or Smash, and likely not in those other two games. At least not on Switch. The hardware can't do it.

There is something called big O notation which is a way of talking about how complicated an algorithm is. Algorithms aren't programs, right, like you can optimize a program to make it more efficient, but a program can never be faster than the algorithm. It's like baking a cake - you can optimize the number of dishes, you can rearrange your kitchen so all the ingredients are at hand, but you can't make the cake itself bake faster in the oven without changing the recipe.

Big O lets you describe how algorithms scale - which isn't how "fast" or "slow" they are, but how their speed changes as you increase the number of things. It's written like this, O(math problem with the letter n in it). N, in this case is the number of things.

O(n )means "each time you add a thing, this algorithm slows down by the same amount". Like going down a line of people to tell them that the restaurant is out of french fries. Each person adds the same amount of time to the process. Contrast with O(1) "this algorithm takes the same amount of time no matter how many things there are to deal with." So standing at the front of the line and just yelling "yo, we're outta french fries!"

Rollback netcode is O(n^2), where n is the number of game states that need to be reconciled. That's basically just the number of players, minus 1. You're playing Street Fighter, you just need to reconcile your game with your opponents game, and adjust player positions if they are out of sync. (2-1)^2 = 1^2 = 1. Simple

Smash has four players, twice the number as Street Fighter. (4-1)^2 = 3^2 = 9. Rollback netcode for Smash is nine times as complex as Street Fighter. Mario Kart 8 supports 12 online players simultaneously - (12-1)^2 = 11^2 = 121. Mario Kart's rollback load is 121 times as complex as Street Fighter.

If you really wanna get in the weeds, there are actually two algorithms at work. The one were counting says "how many reconciliations do we need to run to sync this frame of gameplay." But there is a second that says "how complex is the reconciliation itself".

This process of reconciling all these potentially diverging players is probably O(n ), but in this case, n is the number of states the game can be in. That's basically "number of pixels in the game field x the number of things the players can be doing". That's what I mean by big O describing how algorithms scale, not how slow or fast they are. In this case, the reconcilliation process gets slower the larger the level, and the more moves players have. Smash obviously has lots of moves, but in Mario Kart, basically each item is gonna be a "move" - or, in some cases, like the blue shell, it's effectively a new player with it's own moves!

What does this have to do with the Switch hardware? All these simulations have to be run on the CPU. The Switch has a truly remarkable GPU for a 2017 mobile device, but CPU wise, it's hamstrung. It's got a decent mobile CPU for 2017, but that was right before the mobile CPU boom. Switch underclocks those things for power reasons down to a mere 1GHz, and it only has 4 of them, where rollback code is actually pretty multi-core friendly, when done right.

In the case of Smash specifically, we know that the team implemented rollback netcode, but removed it because the cost of it took multiple frames to reconcile, increasing latency, not reducing it. So at least one Nintendo product wasn't saddled with legacy code, it was purely that the Switch's CPU hardware wasn't up to the task for the huge complexity that multiplayer Nintendo games offer.
thanks for the explanation!
 
TBH the odds of Nintendo mentioning anything in the last 2 Investor meetings was incredibly low, nobody should be banking on it.

The odds are still low here for upcoming investors meeting as well. The only thing making odds slightly higher is the fact that March 2025 falls into the current (new) FY.

But even that’s not a guarantee either.

If nintendo doesn’t say anything (and let’s be honest if they did, it will be only a single sentence probably), boy, we probably are in for a LONG wait (potentially October 2024 in the worst timeline)
It's best to be patient I guess, ever since the leak of it being released in 2025, I try to be more careful, and less excited about when to expect the reveal.
However, when we're gonna see the reveal trailer, I might get more hyped again. The new stuff that was mentioned the last couple of days were cool tho, although the whole magnet discussion went over my head, and was more focusing on the tidbits of the extra front button and extra side buttons.
 
0
Rollback isn't possible in Mario Kart, or Smash, and likely not in those other two games. At least not on Switch. The hardware can't do it.

There is something called big O notation which is a way of talking about how complicated an algorithm is. Algorithms aren't programs, right, like you can optimize a program to make it more efficient, but a program can never be faster than the algorithm. It's like baking a cake - you can optimize the number of dishes, you can rearrange your kitchen so all the ingredients are at hand, but you can't make the cake itself bake faster in the oven without changing the recipe.

Big O lets you describe how algorithms scale - which isn't how "fast" or "slow" they are, but how their speed changes as you increase the number of things. It's written like this, O(math problem with the letter n in it). N, in this case is the number of things.

O(n )means "each time you add a thing, this algorithm slows down by the same amount". Like going down a line of people to tell them that the restaurant is out of french fries. Each person adds the same amount of time to the process. Contrast with O(1) "this algorithm takes the same amount of time no matter how many things there are to deal with." So standing at the front of the line and just yelling "yo, we're outta french fries!"

Rollback netcode is O(n^2), where n is the number of game states that need to be reconciled. That's basically just the number of players, minus 1. You're playing Street Fighter, you just need to reconcile your game with your opponents game, and adjust player positions if they are out of sync. (2-1)^2 = 1^2 = 1. Simple

Smash has four players, twice the number as Street Fighter. (4-1)^2 = 3^2 = 9. Rollback netcode for Smash is nine times as complex as Street Fighter. Mario Kart 8 supports 12 online players simultaneously - (12-1)^2 = 11^2 = 121. Mario Kart's rollback load is 121 times as complex as Street Fighter.

If you really wanna get in the weeds, there are actually two algorithms at work. The one were counting says "how many reconciliations do we need to run to sync this frame of gameplay." But there is a second that says "how complex is the reconciliation itself".

This process of reconciling all these potentially diverging players is probably O(n ), but in this case, n is the number of states the game can be in. That's basically "number of pixels in the game field x the number of things the players can be doing". That's what I mean by big O describing how algorithms scale, not how slow or fast they are. In this case, the reconcilliation process gets slower the larger the level, and the more moves players have. Smash obviously has lots of moves, but in Mario Kart, basically each item is gonna be a "move" - or, in some cases, like the blue shell, it's effectively a new player with it's own moves!

What does this have to do with the Switch hardware? All these simulations have to be run on the CPU. The Switch has a truly remarkable GPU for a 2017 mobile device, but CPU wise, it's hamstrung. It's got a decent mobile CPU for 2017, but that was right before the mobile CPU boom. Switch underclocks those things for power reasons down to a mere 1GHz, and it only has 4 of them, where rollback code is actually pretty multi-core friendly, when done right.

In the case of Smash specifically, we know that the team implemented rollback netcode, but removed it because the cost of it took multiple frames to reconcile, increasing latency, not reducing it. So at least one Nintendo product wasn't saddled with legacy code, it was purely that the Switch's CPU hardware wasn't up to the task for the huge complexity that multiplayer Nintendo games offer.
This really needs to be blasted at full volume on repeat to all the people who continuously blame Nintendo/Sakurai/Bandai Namco for Super Smash Bros. Ultimate’s “trash netcode” and their “refusal to implement rollback”.

This also explains why the N64 NSO app doesn’t support rollback while the NES and SNES apps did, since the latter only support 2 players online while the former supports 4 players (and takes more resources to emulate on top of that).
 
WiiU: Literally every aspect of the hardware
3DS: Betting on 3D... It was a reasonable bet, but it turns out no one cares about 3D.
Switch: Stick drift (didn't affect them much, but was a very annoying product failure that they seemingly didn't foresee)
To be honest, it felt like they was phoning it in with the 3D..Maybe the tablet as well, but definitely 3D. Like how much can you do with stereoscopic 3D? Not much. Even the same with the tablet and asymmetrical gameplay. It is good for a dungeon master type of game play and inventory management but.... not a lot. This is why I say that the innovation is what happens on screen and not some gimmick device. Like I said the Switch has some cool gimmick such as the camera but they can only carry you so far.
We may not like it, but their consoles are powered by the biggest player in AI hardware AND Nintendo is likely to be the console vendor with the most AI juice on tap (at least in the base model, PS5 Pro likely won't be allowed exclusive AI powered features.).

I certainly wouldn't put it past them to work with Nvidia on a few client side AI features.
If this is like a non gaming app, Sure. System integrated... I mean the only thing I can see voice command but that's really it.
Rollback netcode is O(n^2), where n is the number of game states that need to be reconciled. That's basically just the number of players, minus 1. You're playing Street Fighter, you just need to reconcile your game with your opponents game, and adjust player positions if they are out of sync. (2-1)^2 = 1^2 = 1. Simple

Smash has four players, twice the number as Street Fighter. (4-1)^2 = 3^2 = 9. Rollback netcode for Smash is nine times as complex as Street Fighter. Mario Kart 8 supports 12 online players simultaneously - (12-1)^2 = 11^2 = 121. Mario Kart's rollback load is 121 times as complex as Street Fighter.
What about items and stage hazards? I assume they would have to count as well.
 
This really needs to be blasted at full volume on repeat to all the people who continuously blame Nintendo/Sakurai/Bandai Namco for Super Smash Bros. Ultimate’s “trash netcode” and their “refusal to implement rollback”.

This also explains why the N64 NSO app doesn’t support rollback while the NES and SNES apps did, since the latter only support 2 players online while the former supports 4 players (and takes more resources to emulate on top of that).
They shouldn't get mad as Sakurai at least tried.
 
Yes, operating mode, via ReverseNX. It's quite clear that it works with games like Bowser's Fury, which switches framerate targets depending on operating mode. I've played around pretty extensively with both operating mode and performance profiles in different games for the fun of experimentation (forcing games that are normally sub-native into docked operating mode while handheld in particular is a treat).
You could try that mode on games like Pokemon Coffe remix or TWEWY
 
They shouldn't get mad as Sakurai at least tried.
Yet they stay mad regardless. 🤷 I’ve tried pointing out this same logic to people like that before, too, because despite not knowing all the technical details myself, I knew that Sakurai had spoken about there being drawbacks to implementing rollback in Smash before, so clearly the dev team has already tried and determined that it wasn’t worth it. People have then responded to that saying “well then they should add a separate rollback mode for 1v1 no item matches” and, like, while I’m sure it’s technically possible I doubt that’s worth doing for a variety of reasons, too…otherwise they would have done it.
 
Yeah, it's not fantastic, but it should be good enough. 102.4 MBs/ms compared to 177 MBs/ms for PS4.

Mobile RAM sucks.

Mobile RAM sucks

Not... really, it just depends on numerous factors, between clock speeds, cooling/heat control, how much power draw, and the type of mobile RAM. Like, sure, it's lower than desktop clock speeds, but mobile RAM absolutely does not suck like you think it does.
 
Yet they stay mad regardless. 🤷 I’ve tried pointing out this same logic to people like that before, too, because despite not knowing all the technical details myself, I knew that Sakurai had spoken about there being drawbacks to implementing rollback in Smash before, so clearly the dev team has already tried and determined that it wasn’t worth it. People have then responded to that saying “well then they should add a separate rollback mode for 1v1 no item matches” and, like, while I’m sure it’s technically possible I doubt that’s worth doing for a variety of reasons, too…otherwise they would have done it.
It's pretty clearly not a Smash-only problem. Persona 4 Arena Ultimax got a rollback update on all moderns platforms after significant demand... except for the Switch because of limitations on that platform. Basically all games that have rollback on other platforms don't have it on Switch. It's pretty clear that whatever is demanded of it isn't that great either on Switch's online support or by the hardware itself.
 
Not... really, it just depends on numerous factors, between clock speeds, cooling/heat control, how much power draw, and the type of mobile RAM. Like, sure, it's lower than desktop clock speeds, but mobile RAM absolutely does not suck like you think it does.

I mean, it's great relative to electricity consumption, but it feels like it loses a lot more performance relative to other hardware going to mobile.
 
0
I wasn't before, but I'm afraid of the Switch Attach name now.

😢
His condition is critical!… Give him more Switch 2 pills!… The doom is spreading! Inject the copium!… It‘s too late. Sigh It has already attached to his feelings… Maybe we could rescue him with Super Powers?…

Wii U, Wii U
 
I don't know, everytime there is a investors meeting, we think they might say something. I'll just be careful with my hopes this time. It would be something if they said it, but the last 2 investors meeting I followed here on Fami, our hopes crushed. So yeah..
The difference with this meeting is that it encompasses for the whole Fiscal Year ending in March 2025, which is the rumored timing for the next device, so there is hope that at least we can get a mention out of Nintendo
 
There's a chance (and not that low) that this may be actually more reliable for someone's formation than some degrees out there.
It's helped with some of my courses. The way things like operating systems, stacks/computer organization, and whatnot are taught somewhat abstractly. This thread has kinda helped me understand a lot of it by making it more concrete, even if it's not directly applicable to my coursework.
 
Isn't Drake's bandwidth a bit low? 102.4GB/s is lower than ps4's bandwidth
No, it isn't. Details lower down! Or you could just trust me ;-)

Where is the 102.4GB/s number from? (maybe I've seen spec or mention of that before, I guess in that case I'd need a refresher)
It's the max speed of LPDDR5 on a 128-bit bus. We know that Drake has a 128-bit bus from both the Nvidia hack and the Linux drivers, and LPDDR5 is the memory controller in Orin. Technically, it could go lower - Steam Deck also has a 128-bit bus and LPDDR5, but the OG model only goes up to 88 GB/s, probably for power reasons, though they jacked that up to the full 102.4 GB/s with the OLED model.

Technically it could also go higher, if they use a newer standard like 5X instead of 5. 5X claims power savings and performance increases, but it doesn't actually apply to Drake. The way 5X (and 4X before it) work is that the LPDDR5 standard gets set, then afterward Samsung manages to node shrink the memory and the memory controller. That creates power savings, and 5X is just an "official overclock" that allows phone manufacturers (also Samsung) to take advantage of the node shrink while waiting for the next big standard (LPDDR6) to come out.

That means for Drake, the power draw is pretty much baked into the SOC regardless of the name of the standard. As for the extra performance, it probably isn't super useful (again, see below).

Comparing the PS4's GDDR5 bandwidth isn't exactly an apples to apples comparison with Mobile-based LPDDR5 memory. For one, PS4 is x86-based vs. Switch is ARM-based. Plus LPDDR has a bit less latency compared to GDDR memory.
This is all true, but the big win for Drake over the PS4 comes from the modern GPU. GPUs (both AMD and Nvidia's, though Nvidia got their first) changed their architecture so they don't use as much memory bandwidth.

Imagine you've got two shaders, one of which does anti-aliasing and another which does motion blur (these are just examples, the shaders can do anything). Both of these work per pixel, so they need to read from memory all the information about each pixel then write to memory the final result. Both of these use memory bandwidth.

The PS4 starts at the top right of the screen, and scans each pixel right to left, top to bottom, and runs the anti-aliasing shader. Then once that is complete, the motion-blur shader does the same thing.

Drake (and all other modern GPUs) cuts the screen up into smaller rectangles called tiles. For each tile, the GPU does the same process as the PS4, it starts in one corner, runs the first shader, and then when the shader completes, it starts the second shader.

This matters because of the cache. Both GPUs have caches that keep copies of data that is currently being worked on. Cache is much faster than memory, but also much more expensive, so it's much smaller. Newer data pushes old data out of cache, under the general principle that the thing you're most likely to use again is the thing you just used.

By running the anti-aliasing shader before the motion blur shader, the PS4 guarantees that the data the motion blur shader needs first - the pixels in the top right corner of the screen - has been pushed out by the data it needs last - the pixels in the bottom left that the anti-aliasing shader was just working on.

By splitting the screen up into much smaller tiles, the whole tile fits in cache. So for that tile, once the anti-aliasing shader is finished, the motion-blur shader never needs to use memory bandwidth. It's all in cache from the previous shader!

This also has a second knock on effect - different GPU cores can be working on different tiles at the same time (there are multiple tiers of cache, some of which are shared between cores, and some of which are not). This allows a modern GPU to be reading data for one part of the frame while rendering another, instead of needing to read/render/read/render. It's like the difference between a garden hose that goes straight to the garden, and a big bucket that you have to haul from the kitchen. The kitchen faucet might push out water faster but the garden hose never turns off, so they actually move the same amount of water in the same amount of time.

TL;DR - You can't compare the memory bandwidth situation on PS4 and Drake. That leads to the second question, is the 102.4 GB/s enough for Drake. And the answer is probably "yes".

TDR;NTL;GM (Totally Did Read, Not Too Long, Gimme More):

Each core in the GPU needs a certain amount of memory to do it's work, and the faster the cores, the more reads they'll need to do, so the more bandwidth they'll need. How much bandwidth each core needs will depend on the kind of work the shader is being asked to do, which varies by engine, and by game.

So to answer this question for Drake, a chip we don't have, we need to 1) Figure out a way to measure the combination of cores and their speed. 2) Benchmark a bunch of modern games on Drake's architecture. 3) Benchmark at different levels of cores and speeds, to see how Drake's architecture scales, and 4) Benchmark with the same cores and speed, but different amounts of memory bandwidth, to see what the right amount is. 5) Compare that to Drake

Number 1 is easy - that's what TFLOPS are. Number 2 is actually also easy, the internet is full of RTX 30 benchmarks and Digital Foundry's are particularly good for this purpose.

Number 3, I'll skip the big table, because I've shared this data before, but the entry level and midrange cards scale pretty well. In other words, if you look at the TFLOPS of a card, you can guess the performance pretty well. That says that Drake, which is a very small RTX 30 GPU, will probably run about how we expect, all else being equal.

Number 4 is hard, because we can't go build an RTX 30 GPU just for testing. Fortunately, Nvidia sells enough "Super" and "Ti" versions of cards, that we can actually compare benchmarks of the same chip with more memory bandwidth. And when we do, basically, the extra bandwidth doesn't seem to matter. 25GB/s/TFLOP is pretty consistently the sweet spot, across the line.

That leaves number 5, compare to Drake. Drake has 102.4GB/s of bandwidth, at max. One tiny challenge, that bandwidth has to also support a CPU. Let's be pessimistic and ballpark 20% of the bandwidth for the CPU. That leaves ~82GB/s for the GPU to eat.

We know that Drake has 1536 cores. So we just gotta ask what clock speed we can handle. Working backwards, that's enough bandwidth to support ~1.1Ghz clock speeds, or about 3.25 TFLOPS. @Thraktor has done his own analysis with power and heat and landed on a "optimum" clock speed of ~1.3Ghz.

All of that nicely lines up. Drake has a design that seems optimized for power efficiency (lots of cores), memory bandwidth is power-expensive, and Drake's clock speed curves matches the amount of bandwidth allocated.

Those Nvidia folks seem to know what they're doing.
 
thanks for the explanation!
Quite welcome! It drives me nuts too, I hope that Nintendo turns course once Drake comes out.

What about items and stage hazards? I assume they would have to count as well.
They do make things slower, but they don't increase the time complexity. It's the difference between "how fast does it take to do one of these things" versus "how many of these things do we have to do?" More complex stages and items makes it take longer to reconcile two users to each other, more players means more reconcilliations
 
They fail to take into account DLSS.

Is there no bottom for DLSS to effectively function? Are we all positive Switch will use DLSS in handheld?

There has to be a point where power draw and clocks are so low that upscaling with tensor cores becomes an issue, no? (haven't kept up with any discussion about basement level DLSS functioning)

[edit: well gee, as i continue with the thread its being discussed more :p]

Arguing that the screen should be 720p is like arguing the Switch screen should have been 480p. Think of how many more games would have hit native res in handheld! Uh, sure, all those Switch games that do hit native 720p or close to it would have been held back for no good reason, but at least you'd have power savings. Oh, wait, screen resolution doesn't actually affect battery life, and the pixel density would be worse if the screen size was the same but the resolution was cut to 480p. We better make the screen 3DS-sized to be safe. Now we're talking!

To be fair, forums like this are to blame.

Years were spent assuring people "No no no, 720p is good! Anything beyond that is unnecessary for screen that small! Anything over 720p will just tax the system more and devalue performance!"

Seems kind of hypocritical to now chastize/mock people who question the need of 1080p.

[I think 1080p is fine, btw.]
 
Last edited:
Rollback isn't possible in Mario Kart, or Smash, and likely not in those other two games. At least not on Switch. The hardware can't do it.

There is something called big O notation which is a way of talking about how complicated an algorithm is. Algorithms aren't programs, right, like you can optimize a program to make it more efficient, but a program can never be faster than the algorithm. It's like baking a cake - you can optimize the number of dishes, you can rearrange your kitchen so all the ingredients are at hand, but you can't make the cake itself bake faster in the oven without changing the recipe.

Big O lets you describe how algorithms scale - which isn't how "fast" or "slow" they are, but how their speed changes as you increase the number of things. It's written like this, O(math problem with the letter n in it). N, in this case is the number of things.

O(n )means "each time you add a thing, this algorithm slows down by the same amount". Like going down a line of people to tell them that the restaurant is out of french fries. Each person adds the same amount of time to the process. Contrast with O(1) "this algorithm takes the same amount of time no matter how many things there are to deal with." So standing at the front of the line and just yelling "yo, we're outta french fries!"

Rollback netcode is O(n^2), where n is the number of game states that need to be reconciled. That's basically just the number of players, minus 1. You're playing Street Fighter, you just need to reconcile your game with your opponents game, and adjust player positions if they are out of sync. (2-1)^2 = 1^2 = 1. Simple

Smash has four players, twice the number as Street Fighter. (4-1)^2 = 3^2 = 9. Rollback netcode for Smash is nine times as complex as Street Fighter. Mario Kart 8 supports 12 online players simultaneously - (12-1)^2 = 11^2 = 121. Mario Kart's rollback load is 121 times as complex as Street Fighter.

If you really wanna get in the weeds, there are actually two algorithms at work. The one were counting says "how many reconciliations do we need to run to sync this frame of gameplay." But there is a second that says "how complex is the reconciliation itself".

This process of reconciling all these potentially diverging players is probably O(n ), but in this case, n is the number of states the game can be in. That's basically "number of pixels in the game field x the number of things the players can be doing". That's what I mean by big O describing how algorithms scale, not how slow or fast they are. In this case, the reconcilliation process gets slower the larger the level, and the more moves players have. Smash obviously has lots of moves, but in Mario Kart, basically each item is gonna be a "move" - or, in some cases, like the blue shell, it's effectively a new player with it's own moves!

What does this have to do with the Switch hardware? All these simulations have to be run on the CPU. The Switch has a truly remarkable GPU for a 2017 mobile device, but CPU wise, it's hamstrung. It's got a decent mobile CPU for 2017, but that was right before the mobile CPU boom. Switch underclocks those things for power reasons down to a mere 1GHz, and it only has 4 of them, where rollback code is actually pretty multi-core friendly, when done right.

In the case of Smash specifically, we know that the team implemented rollback netcode, but removed it because the cost of it took multiple frames to reconcile, increasing latency, not reducing it. So at least one Nintendo product wasn't saddled with legacy code, it was purely that the Switch's CPU hardware wasn't up to the task for the huge complexity that multiplayer Nintendo games offer.
As i know Mortal Kombat 11 and 1 uses rollback on switch.

But as you say, a 1vs1 game is less complex than Smash or Mario Kart.
 
Is there no bottom for DLSS to effectively function? Are we all positive Switch will use DLSS in handheld?

There has to be a point where power draw and clocks are so low that upscaling with tensor cores becomes an issue, no? (haven't kept up with any discussion about basement level DLSS functioning)
If Switch can do X as a graphical feature docked, fair to say it can do 1/2 X undocked. Most of us are betting on a similar situation next go around. So unless DLSS is so bad on Switch 2 that it's essentially useless for resolutions over 1080p docked, it should be useful undocked as well.

EDIT: Maybe more to your point, it seems like DLSS costs scale pretty evenly along output resolution. Surely at some absurd point (like, creating an 8x8 result image) that would fall apart, but it doesn't seem to be the case for HD and UHD resolutions.
 
Is there no bottom for DLSS to effectively function? Are we all positive Switch will use DLSS in handheld?

There has to be a point where power draw and clocks are so low that upscaling with tensor cores becomes an issue, no? (haven't kept up with any discussion about basement level DLSS functioning)

[edit: well gee, as i continue with the thread its being discussed more :p]

On PC, diss actually saves power, presumably because the gpu is less active when the tensor cores are doing diss (very possible my understanding is flawed). On a console, some devs may go the extra mile and achieve a higher degree of parallelism than is commonly achieved on PC, in which case the savings in power consumption would be smaller. But there's no evidence it woudnt be viable in handheld mode.

Dlss 1440p is roughly twice the frame time of diss 1080p, which should correspond with the gap in clocks.
 
Are they going to replace the iconic switch logo and sound? Will the logo come together horizontally instead of vertically? These are important questions

lol they are important questions!

But they really dont have to change anything. Doesnt the "sound" play when you attach a joy con already? They can simply keep playing that when the electromagnet attaches. Also, the vertical attach motion is still a viable way to attach an electromagnetic joy-con.

I mean, the entire Switch branding is built around the Joy-Con click. I can argue for why you'd want to do this, but let me go on what seems like a tangent first.

But fundamentally we don't know what Nintendo's pitch for the generation is, and Nintendo is very good at building the whole product marketing around a clear pitch. To be clear I'm not talking about the pitch for the hardware. Nintendo doesn't sell hardware. They sell experiences, and the hardware is only part of it.

"Switch" told you right in the name what the core idea of the hardware is. But the "click" sound and the Joy-Con clicking in branding connects the most delightfully tactile part of the hardware to the experience of Switching. That click isn't just an iconic part of the hardware, it is the sound of hardware switching between modes.

The other part of the pitch was big, full fat, meaty, core gamer experiences. Not just on the go but from Nintendo. The name didn't just say "this hardware Switches" but also said "We've been making these couch co-op and casual experiences for a while, but this is a Switch". And also "have you gone to Microsoft and Sony for these kinds of games? Well, consider Switching."

The folks who think that Switch 2 is a terrible, sterile name (most loudly, but certainly not exclusively @Raccoon) and the folks who think it is the only name or the company will sink - I would just say that I think both are missing what Nintendo can and likely will do. Nintendo will almost certainly not just pitch this as a sequel to Switch, even if that's what the hardware is, because that doesn't mean Nintendo games will be sequels to their Switch versions. And Nintendo can pick Switch 2 and have that name reflect so much more than "joyless upgrade".

Let me pitch you a trailer for Nintendo's next hardware:



Now, I'm not saying any part of this is what we'll get or what Nintendo wants. But I think you can see how a wishlist of random features: Cartless mutliplayer from the DS, magnetic Joy-Cons, a more modern account system - can be connected with game design - drop in multiplayer - to create a cohesive system that emphasizes a single clear idea. "Make sharing your game as easy as sharing your chocolate bar."

And you can see how the name "Switch 2" becomes slightly cheeky, playful, saying two things at once. "Yes, it's more Switch, but also, it's a new kind of Switching. Switching from single player to multiplayer, seamlessly." And you can see how the name (written Switch II) and the logo (Two joy cons, splitting into pairs) and the branding (the sound of the 2-Cons snapping apart, the logo splitting into two parts) all connects the physical feel of the console to the gameplay experience that Nintendo wants to deliver.

Which comes back to Switch Attach. Nintendo probably doesn't want to name their console just after the Joy-Con rail. But if they could find a way to talk about the games they wanna make, and the OS features they've added by referencing the rail, then I think they might. "Attach" can mean a lot of things, after all

Fun read...but there is no way Nintendo calls it "Switch 2". There is no good reason they would do this, there is nothing beneficial for them to suddenly do this, there is nothing in their history to suggest this would even be a possibility.

The name will more likely be to describe how the new Switch fits in with the family of Switch's and the Switch ecosystem of gaming.

And i like your Ad pitch, but im willing to bet much of it will also show people with older Switches (and joy-cons) gaming with people and their New Switch.
 
Rollback isn't possible in Mario Kart, or Smash, and likely not in those other two games. At least not on Switch. The hardware can't do it.

There is something called big O notation which is a way of talking about how complicated an algorithm is. Algorithms aren't programs, right, like you can optimize a program to make it more efficient, but a program can never be faster than the algorithm. It's like baking a cake - you can optimize the number of dishes, you can rearrange your kitchen so all the ingredients are at hand, but you can't make the cake itself bake faster in the oven without changing the recipe.

Big O lets you describe how algorithms scale - which isn't how "fast" or "slow" they are, but how their speed changes as you increase the number of things. It's written like this, O(math problem with the letter n in it). N, in this case is the number of things.

O(n )means "each time you add a thing, this algorithm slows down by the same amount". Like going down a line of people to tell them that the restaurant is out of french fries. Each person adds the same amount of time to the process. Contrast with O(1) "this algorithm takes the same amount of time no matter how many things there are to deal with." So standing at the front of the line and just yelling "yo, we're outta french fries!"

Rollback netcode is O(n^2), where n is the number of game states that need to be reconciled. That's basically just the number of players, minus 1. You're playing Street Fighter, you just need to reconcile your game with your opponents game, and adjust player positions if they are out of sync. (2-1)^2 = 1^2 = 1. Simple

Smash has four players, twice the number as Street Fighter. (4-1)^2 = 3^2 = 9. Rollback netcode for Smash is nine times as complex as Street Fighter. Mario Kart 8 supports 12 online players simultaneously - (12-1)^2 = 11^2 = 121. Mario Kart's rollback load is 121 times as complex as Street Fighter.

If you really wanna get in the weeds, there are actually two algorithms at work. The one were counting says "how many reconciliations do we need to run to sync this frame of gameplay." But there is a second that says "how complex is the reconciliation itself".

This process of reconciling all these potentially diverging players is probably O(n ), but in this case, n is the number of states the game can be in. That's basically "number of pixels in the game field x the number of things the players can be doing". That's what I mean by big O describing how algorithms scale, not how slow or fast they are. In this case, the reconcilliation process gets slower the larger the level, and the more moves players have. Smash obviously has lots of moves, but in Mario Kart, basically each item is gonna be a "move" - or, in some cases, like the blue shell, it's effectively a new player with it's own moves!

What does this have to do with the Switch hardware? All these simulations have to be run on the CPU. The Switch has a truly remarkable GPU for a 2017 mobile device, but CPU wise, it's hamstrung. It's got a decent mobile CPU for 2017, but that was right before the mobile CPU boom. Switch underclocks those things for power reasons down to a mere 1GHz, and it only has 4 of them, where rollback code is actually pretty multi-core friendly, when done right.

In the case of Smash specifically, we know that the team implemented rollback netcode, but removed it because the cost of it took multiple frames to reconcile, increasing latency, not reducing it. So at least one Nintendo product wasn't saddled with legacy code, it was purely that the Switch's CPU hardware wasn't up to the task for the huge complexity that multiplayer Nintendo games offer.
I thought Mario Kart 8 used some form of rollback netcode.
 
The difference with this meeting is that it encompasses for the whole Fiscal Year ending in March 2025, which is the rumored timing for the next device, so there is hope that at least we can get a mention out of Nintendo
If they would release one day after the end of the fiscal year, they probably aren't obligated to say anything if they won't want to, right? 🙂
 
If they would release one day after the end of the fiscal year, they probably aren't obligated to say anything if they won't want to, right? 🙂
They don't have to say anything regardless. Problem for them is that they have to release a forecast for this fiscal year, and with out the Switch 2 it could be a pretty poor year. Investors would not want to see such a contraction on the business.
 
On PC, diss actually saves power, presumably because the gpu is less active when the tensor cores are doing diss (very possible my understanding is flawed). On a console, some devs may go the extra mile and achieve a higher degree of parallelism than is commonly achieved on PC, in which case the savings in power consumption would be smaller. But there's no evidence it woudnt be viable in handheld mode.

Dlss 1440p is roughly twice the frame time of diss 1080p, which should correspond with the gap in clocks.

Im not worried about tensor cores using t239 power, im questioning how much "power" of a t239 chip is needed to make tensor cores function effectively.

There has to be a bottom of gpu clock speed and power draw where tensor cores can no longer adequately AI upscale a low render to 1080p/60fps...no? If so, what is the theoretical bottom?
 
Im not worried about tensor cores using t239 power, im questioning how much "power" of a t239 chip is needed to make tensor cores function effectively.

There has to be a bottom of gpu clock speed and power draw where tensor cores can no longer adequately AI upscale a low render to 1080p/60fps...no? If so, what is the theoretical bottom?
DLSS scales on output resolution only. So to take an extreme example, scaling from 1p to 1080p would take exactly as long as scaling from 1079p to 1080p.

Lets say scaling to 1080 takes around 4ms on Drake portable, then scaling to 1440p should take 4ms on Drake docked, assuming a 2x clock speed.
 
""Presumed" is not the same as "confirmed".The third party accessory vendor is explicitly backwards compatible with the game card.
so you think that new game card cases could accommodate both for people who hold onto their switch 1 and want to keep their cards for both in one place?
 
0
Rollback isn't possible in Mario Kart, or Smash, and likely not in those other two games. At least not on Switch. The hardware can't do it.

There is something called big O notation which is a way of talking about how complicated an algorithm is. Algorithms aren't programs, right, like you can optimize a program to make it more efficient, but a program can never be faster than the algorithm. It's like baking a cake - you can optimize the number of dishes, you can rearrange your kitchen so all the ingredients are at hand, but you can't make the cake itself bake faster in the oven without changing the recipe.

Big O lets you describe how algorithms scale - which isn't how "fast" or "slow" they are, but how their speed changes as you increase the number of things. It's written like this, O(math problem with the letter n in it). N, in this case is the number of things.

O(n )means "each time you add a thing, this algorithm slows down by the same amount". Like going down a line of people to tell them that the restaurant is out of french fries. Each person adds the same amount of time to the process. Contrast with O(1) "this algorithm takes the same amount of time no matter how many things there are to deal with." So standing at the front of the line and just yelling "yo, we're outta french fries!"

Rollback netcode is O(n^2), where n is the number of game states that need to be reconciled. That's basically just the number of players, minus 1. You're playing Street Fighter, you just need to reconcile your game with your opponents game, and adjust player positions if they are out of sync. (2-1)^2 = 1^2 = 1. Simple

Smash has four players, twice the number as Street Fighter. (4-1)^2 = 3^2 = 9. Rollback netcode for Smash is nine times as complex as Street Fighter. Mario Kart 8 supports 12 online players simultaneously - (12-1)^2 = 11^2 = 121. Mario Kart's rollback load is 121 times as complex as Street Fighter.

If you really wanna get in the weeds, there are actually two algorithms at work. The one were counting says "how many reconciliations do we need to run to sync this frame of gameplay." But there is a second that says "how complex is the reconciliation itself".

This process of reconciling all these potentially diverging players is probably O(n ), but in this case, n is the number of states the game can be in. That's basically "number of pixels in the game field x the number of things the players can be doing". That's what I mean by big O describing how algorithms scale, not how slow or fast they are. In this case, the reconcilliation process gets slower the larger the level, and the more moves players have. Smash obviously has lots of moves, but in Mario Kart, basically each item is gonna be a "move" - or, in some cases, like the blue shell, it's effectively a new player with it's own moves!

What does this have to do with the Switch hardware? All these simulations have to be run on the CPU. The Switch has a truly remarkable GPU for a 2017 mobile device, but CPU wise, it's hamstrung. It's got a decent mobile CPU for 2017, but that was right before the mobile CPU boom. Switch underclocks those things for power reasons down to a mere 1GHz, and it only has 4 of them, where rollback code is actually pretty multi-core friendly, when done right.

In the case of Smash specifically, we know that the team implemented rollback netcode, but removed it because the cost of it took multiple frames to reconcile, increasing latency, not reducing it. So at least one Nintendo product wasn't saddled with legacy code, it was purely that the Switch's CPU hardware wasn't up to the task for the huge complexity that multiplayer Nintendo games offer.
Doesn't Mario Kart and Splatoon use Rollback?

The main reason to smash I think is not because of HW limitations, but the complexity of the smash gameplay itself with all the item to keep tracks off. In Mario Kart if you hit an enemy and the hit is registered a couple of seconds later doesn't matter that much, in a fighting game each frame is crucial. There are different ways to handle a rollback netcode that is not limited to only player counts but also refresh rate.
 
Last edited:
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