• 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!)

For the record, I still believe that Tegra 239 is one of the best mobile chips available, and that i would take Nvidia at 8nm over Qualcomm at 7-6nm.
 
At least this will give some room for a mariko-tier upgrade in the future.
What upgrade

8N is a deadend node, there is nothing after that unless they pay hundreds of millions to rebuild it at a different foundry or a process with a completely different technology at the same foundry.



This is why I don’t think it’s 8 nm because the path is literally nonexistent, in the sense that who would spend this much to rebuild it twice, it ain’t free or cheap. If they’re going to have 8 nm the only next option is 5 nm from Samsung which uses a completely different technology you have to rebuild the entire chip with the technology in mind. That is not cheap whatsoever.


Then you have the possibility that they do it at TSMC’s Foundry, but if it started at Samsung 8 nm, they cannot carry over anything that was used to build the chip at Sampson over to TSMC because there’s intellectual properties associated already integrated into the silicon itself. You have to rebuild it with TSMC’s IP in mind at the new foundry.

You’re basically making a new chip twice. There is one node that exists that incorporates future library technologies that makes the path to that future node much easier to work with, and also doesn’t require them to rebuild it from scratch (twice) with these new foundries.



This shit ain’t free.



Like I need y’all to see this with me, manifest with me:


if it is at Samsung 8 nm and Nvidia‘s next products are at TSMC’s is 7 or 5 mm, then the next most likely path would be one of those two. However, the problem is Samsung has their own libraries that they implement into the silicon, and TSMC has their own libraries that they implement into their silicon. What you build at Samsung stays at Samsung and what you built at TSMC stays at TSMC. You cannot license this out because it requires you giving your trade secrets to a different foundry and for them to produce it. Nintendo is literally going to follow NVidia where they go.




That said none of this is confirmation that it’s 8 nm, it’s just at 8 mm is not as inefficient as we thought.

If you’re fine with OG battery life….


There’s one node that could probably work.
 
Last edited:
There is literally nothing of note which isn't there already.

This is…a really weird thing to say, but an especially weird thing to say after listing a long list of third party games that are not on Switch but saying they don’t count because “the ship has sailed” or whatever.

There are notable third party games that are not (yet) on Switch. I don’t really see how that’s a controversial point…?
 
We take it for granted, as members of an enthusiast forum, our ability to look past a name and figure out the hardware behind it.

A name like "New Nintendo Switch", we think "oh, like the New 3DS, which was upgraded 3DS hardware with exclusives". Thats not immediately clear to everyone. Heck, when it first revealed I thought the big deal was improved 3D and a second stick. I didn't even want one because most of my games would look and feel the same. It feels like underselling this device's power.

Same with Switch 4K model, "So it has a 4K screen?". Nope. "Oh, so it does 4K for every game?" Nope. We here know about DLSS and that a new chip is required for 4K to be feasible and that the new chip is a substantial leap. "Why should I buy this? I only play portable / don't have a 4K display". You see these kinds of comments even on enthusiast forums.

Drake is an upgrade across the board, it is the next gen Switch. If they have a low key name it's just going to work against them, even if the rest of their marketing is solid. A lot of folks never look past the name.
I agree, but i truly hope they dont go with new, they most likely wont anyway.
4k is also not a thing i like, and the usual "super, advance" just feel like nostalgia from certain users.

2 is the best, no matter how boring it is.
 
Wait a moment, so even at the second lowest estimated GPU clock (handheld mode), drake even on 8nm would be comparable to a steam deck @ the maximum power hungry 15W setting*?
*(1.6 TFLOPs FP32) I know, I know, "don't use tflops as a measure" but first, we don't have a real measuring method yet and second, we are comparing two very recent archs both of which have similar estimated bandwidth, power budgets and use shared system memory rather than their own.

Also, I noticed that even older A78 SoCs like the Snapdragon 888 are somewhat close to Steam deck's CPU performance in benchmarks alone:
Not only that, but A78 ARM CPUs are also close to mobile x86 CPUs in terms of L3 cache iirc.

Also, I know ARM isn't really comparable to x86 in geekbench since they use different instructions, and their IPC is different. But it certainly didn't stop people from comparing Apple's M1 to PC oranges back in 2020...
 
0
Ultimately I think you are right in that the console will be engineered around its biggest bottle neck, that being the memory bandwidth, pushing too far beyond 3TF from the GPU doesn't make sense if the memory bandwidth becomes an issue, no node change is going to solve that problem, even using LPDDR5X would only help a little. So there is a theoretical ceiling for performance based on the above, they then just use a node that can hit or get close to that ceiling for their target battery life.

So it doesn't matter if its 8nm Samsung or 4nm TSMC, that memory bottle neck still dictates what the new switches performance will be like.

This is likely going to remain a bottleneck for this style of hardware for some years too. Unless Nintendo and Nvidia somehow crack reading and writing data to DNA or something.

But they said the bandwidth could be 102gbps which is more than even on iPhone, I seem to remember zombi3 saying it wouldn't be a problem.
 
0
I think they’ll be a little bit more focused on the dramatic performance increase this time, because it enables a bunch of ports of third party games in the way that the New 3DS getting a CPU/RAM bump really didn’t. But there will be more to the new Switch hardware story than just a better SoC, and they’re not ever going to choose a name that suggests that the new SoC is the only or primary improvement. They know a lot of their market does not really care that much about visual fidelity.
4k is also not a thing i like, and the usual "super, advance" just feel like nostalgia from certain users.
I'm not particularly nostalgic for Super or Advance (wasn't even alive for Super) but they are precedent, the previous two times Nintendo marketed a more capable next-gen device while sharing the brand name of the previous one.

But if they intend to communicate not just power, but enhanced feature as well, then I'm reminded of the Apple Watch Ultra that was just announced. Enthusiast focused and a bunch of features packed in. When I compare other devices like the Galaxy Ultra, the Ultra variant has more features alongside power.
Ah, but then there's the Roku Ultra, marketed as their "fastest and most powerful player". So it's a pretty flexible moniker, and fits with "Ultra HD" (4K). And deep pull, but it reminds me of the Ultra 64 before it was finalized to Nintendo 64.

I agree that Switch 2 gets the point across just fine, though. People usually expect more features and power from a numbered iteration.
 
0
I don't know how much technology this actually shares with the Optical Flow stuff being done with the 4000 cards, but it reminded me of this NVIDIA demonstration from 4 years ago which I've always found impressive.

So Yuzu devs are expected to clown Nintendo? Huh. Neat.
Emulators always always always have more flexibility than real machines doing backwards compatibility in a more straightforward way. But also usually far worse compatibility.
Now "Switch Pro"...tell that to the people trying to get a Nintendo Switch Pro Controller. Do they mean the system or the controller?
I 0% think Pro will be used, but I also think this part matters about as much as people getting the Nintendo Switch confused with the RF Switch used for NES.
 
0
Everyone, I'm telling you, it's going to be The Nintendo Switch Up.

UPscales games with AI for better performance.
UP to 4k resolution on the TV.
UP to 120 FPS in docked mode.
UP to you how you want to play.

Oh and my only concern with Drake now is how broke I am going to be buying all of the resident evil ports when they inevitably all land.....
 
@Anatole this should be an interesting read for you, especially the DLSS part.
Sure, I think this outlet made assumptions about that aren’t supported by what Nvidia has released. The “pairs of images” thing is confusing people, but I’m confident now that it’s calculating the optical flow field between the current frame and previous frames, not between the current frame and the next frame. It’s clear from the flow diagram and their description of the inputs.

It’s analogous to explicit methods in numerical simulation, where you use the current point and previous points to estimate the next point in time. With a single previous time point, you can calculate velocity, and with several previous points, acceleration. There are stability issues with explicit methods when you don’t take a small enough timestep, but alternating the generated frames with real frames should prevent them from being apparent. I suppose then it would be the neural network’s job to account for sudden impulses, disocclusion, etc.
 
It's surely intermediate frames rather than future ones, or else there would be horrible issues any time you panned/rotated the camera quickly, right?
I think if the hardware is fast enough, it can reduce the appearance of that perhaps. However, I do feel like further testing needs to be done to actually see if there is no trailing or defects in the algorithm for what you see.



Because this is a very computationally heavy and I’d imagine very bandwidth heavy, needs a ton of information to do it.


I think the reason Ampere and Turing don’t have it is that they don’t use some super large cache to store enough data in lower latency to which the GPU can create the image with.

Ampere and Turing would have to deal with the GDDr6X very high latency to fetch data every time in order to do it. Mind you, there is L2 latency too but not as severe as the 6X memory.


All evidence up until now has pointed to a TSMC node. What has changed that suddenly everyone is so sure of Samsung's involvement?

It’s not really like that, but some have “Because Nintendo is cheap” energy and are only thinking of the memoir, and not the biography.



Really, the only confirmation is that 8N isn’t as inefficient, but that does not mean Drake is 100% on 8N.


8N being inefficient wasn’t the only reason people were doubting this.
 
It's surely intermediate frames rather than future ones, or else there would be horrible issues any time you panned/rotated the camera quickly, right?
Engine motion vectors, the depth buffer, and the optical flow field should theoretically give enough information to handle that transformation except at the edge of the frame, where all the pixels rendered would be brand new. We’ll see how well it works in practice.
 
I feel like outside of some unique experimenting like with LABO, Nintendo is years away from being ready to release something high-end VR related.
Right. DLSS is available to VR headsets that use Nvidia’s product stack (why wouldn’t it be?) but the addition of DLSS does not suddenly turn the new Switch hardware into a compelling VR platform. For…lots of reasons, the largest of which is that I don’t think Nintendo really likes or cares about VR that much.
 
Right. DLSS is available to VR headsets that use Nvidia’s product stack (why wouldn’t it be?) but the addition of DLSS does not suddenly turn the new Switch hardware into a compelling VR platform. For…lots of reasons, the largest of which is that I don’t think Nintendo really likes or cares about VR that much.
Not to mention we shouldn't really be expecting a screen resolution that can do VR all that well.
 
This is…a really weird thing to say, but an especially weird thing to say after listing a long list of third party games that are not on Switch but saying they don’t count because “the ship has sailed” or whatever.

There are notable third party games that are not (yet) on Switch. I don’t really see how that’s a controversial point…?
Also, for my money, Elden Ring would absolutely be a hardware sales driver for the new Switch, especially if DLC is released for it.
 
Engine motion vectors, the depth buffer, and the optical flow field should theoretically give enough information to handle that transformation except at the edge of the frame, where all the pixels rendered would be brand new. We’ll see how well it works in practice.
I'm just going by their Cyberpunk picture, but it implies per-frame latency as going from 3.6 frames when DLSS 3/RTX is off, to 5.6 frames when DLSS/RTX is on. The individual frames themselves are >4x more frequent though, which would give room for the claim that responsiveness is improved.
 
That's a bit unfair. I have always tried to be reasonable with my expectations. I think is reasonable to be disapointed to get an older node when much better ones are mature and available.
It's the context that you are missing, there is a limit to how powerful the device can be without being very expensive, you are also spreading dispair, and 8nm isn't even confirmed yet... I can understand if the performance could run away with say double, but because the memory bandwidth is limited to 102GB/s, 3.2tflops being discussed here is twice steamdeck's performance before DLSS... It's really good if it's 8nm, it's even better if it's Samsung 5nm or TSMC, but Drake being as powerful as it is? That's a huge win.
 
I'm no expert on APIs, custom processors, architectures, etc., but how likely is it that Nvidia has future-proofed Drake with parts of Lovelace (according to early rumours) and something from DLSS 3.0?

Not that DLSS 2.0 isn't already a great thing for a handheld.
Don’t get your hopes up.
 
All evidence up until now has pointed to a TSMC node. What has changed that suddenly everyone is so sure of Samsung's involvement?
Orin is on 8nm and its power draw was very fat based on Nvidia's docs. Estimates for the PVA and DLA power consumption were pretty small (I did them, and as it turns out I was pretty close!), leaving the GPU eating more power than we thought Switch could reasonably use. @BlackTangMaster has access to an Orin AGX, and got finer grained power numbers that showed how much of Orin's power draw actually goes to the GPU, and now the power draw looks more reasonable.
 
I'm no expert on APIs, custom processors, architectures, etc., but how likely is it that Nvidia has future-proofed Drake with parts of Lovelace (according to early rumours) and something from DLSS 3.0?
I've been going through the recent Linux drops for Tegra, where they've added support for Drake. Drake's OFA driver - the OFA is what DLSS 3.0 uses for its special sauce - is the same as Orin's, unlike some other parts of T239, where it overrides the Orin driver.

So as close to 0% as we can imagine at this point.
 
Not to mention we shouldn't really be expecting a screen resolution that can do VR all that well.
There's no reason the hardware couldn't be paired with an external headset, though. The hardware in the Meta Quest is nowhere near as powerful as what we're dealing with here and it still offers a very impressive VR experience.
 
Everyone, I'm telling you, it's going to be The Nintendo Switch Up.

UPscales games with AI for better performance.
UP to 4k resolution on the TV.
UP to 120 FPS in docked mode.
UP to you how you want to play.

Oh and my only concern with Drake now is how broke I am going to be buying all of the resident evil ports when they inevitably all land.....

I like this name as well but since this mock up was created already by someone I thought Nintendo might not want to use it.

 
At least this will give some room for a mariko-tier upgrade in the future.
The problem with this is Nintendo will aim for a lower clock speed as a base for the next system. Further die shrinks will only improve battery life because the speed cannot be change anymore for compatibility's sake.
 
0
Linux updates:

I've been going through the Linux updates that Nvidia has been dropping (since August!) for Drake. I've not been posting them since they are, for the most part, not interesting, but it's now come up enough times I thought I'd write it up.

Real short - there are places where Drake uses a generic Tegra support for a feature, or where it uses a "T23x" support that it shares with Orin, or it uses the Orin support directly, or where it loads in its own specialized T239 support. Specialized support doesn't mean that features work differently - it could be something as simple as "This ASIC lives on a different physical part of the chip". Things of note

The OFA Driver: This has become relevant in the wake DLSS 3.0 and Lovelace's enhanced OFA. The OFA driver is identical for Orin and Drake.
Falcon/TSEC: FAst Logic CONtroller, used in lots of things. Drake's seems to be different from Orin. A Falcon is used in TSEC, the Tegra Security Coprocessor in the X1, which accelerates cryptography and is part of the secure OS boot process that prevents the Switch from being jailbroken

Memory Controllers: Drake has half of Orin's MC channels, 8 instead of 16.

USB: T239 supports only three USB2/USB3 ports (Orin has 4, at least in these drivers)

Interesting Timing Bits: Drake Linux was being developed on software simulation in January of last year. In April, there were a set of Drake related updates that seem to indicate that actual engineering samples were being produced. In July, the code was branched to consolidate Orin changes for public release so that Drake work could continue. Any further references to Drake in the various public repos since are entirely updates to places where Drake share's Orin's driver, but needs a Drake specific exception (like the cpu-freq updates). This is likely so that there is a One True Source for Orin drivers and Drake dev can simply pull it from upstream, rather than maintaining multiple forks at Nvidia that are constantly cross merging.
 
I've also updated the summary post in the wake of DLSS 3.0 chatter, and the new power numbers, mostly scrapping some analysis that was out of date, and eliminating some now proven-untrue pessimism
 
0
Orin is on 8nm and its power draw was very fat based on Nvidia's docs. Estimates for the PVA and DLA power consumption were pretty small (I did them, and as it turns out I was pretty close!), leaving the GPU eating more power than we thought Switch could reasonably use. @BlackTangMaster has access to an Orin AGX, and got finer grained power numbers that showed how much of Orin's power draw actually goes to the GPU, and now the power draw looks more reasonable.
It’s not access to ORIN AGX, it’s just access to their power tool software. If you have an account with nvidia you can also play with it.
 
What is the difference between Orin and Drake? What is each thing? I thought it was the same (Nvidia graphics chip)

Orin refers to the series of automotive orientated system on chips developed by nvidia.

Drake is a specific system on chip developed by nvidia for Nintendo, as far as we know its based on Orin but separate from the Orin family.
 
Interesting Timing Bits: Drake Linux was being developed on software simulation in January of last year. In April, there were a set of Drake related updates that seem to indicate that actual engineering samples were being produced. In July, the code was branched to consolidate Orin changes for public release so that Drake work could continue. Any further references to Drake in the various public repos since are entirely updates to places where Drake share's Orin's driver, but needs a Drake specific exception (like the cpu-freq updates). This is likely so that there is a One True Source for Orin drivers and Drake dev can simply pull it from upstream, rather than maintaining multiple forks at Nvidia that are constantly cross merging.
engineering samples being out in April 2021 is interesting. either that means devs were working on simulated kits or they were working on analogues. I would bet on there being orin-based kits before then
 
Orin refers to the series of automotive orientated system on chips developed by nvidia.

Drake is a specific system on chip developed by nvidia for Nintendo, as far as we know its based on Orin but separate from the Orin family.

Thank you very much for your answer.

So Drake is a chip based on Orin (Orin is an automotive series of chips).

Drake's architecture (based on Orin) is Ampere.

And what does the name T239 refer to then?
 
What upgrade

8N is a deadend node, there is nothing after that unless they pay hundreds of millions to rebuild it at a different foundry or a process with a completely different technology at the same foundry.
You are correct, of course, but I think we're stuck with that no matter what. Ampere-B has been on Samsung 8nm the entire time, Orin was built on 8nm, and we know T239 shares design with T234. There is likely not a cost advantage porting to TSMC now over porting to TSMC later, because it's going to be a port either way, as opposed to being built fresh on TSMC.

Of course, Ampere-A was already on TSMC 7nm, and the ARM uses custom verilog libraries to support a wide range of nodes out of the box for their CPUs. At least some of the groundwork was laid well before Drake dev started
 
Thank you very much for your answer.

So Drake is a chip based on Orin (Orin is an automotive series of chips).

Drake's architecture (based on Orin) is Ampere.

And what does the name T239 refer to then?
T = Tegra, the range of system on a chip that Nvidia makes. T234 is the internal name for Orin. T239 is the internal name for Drake. The chip in the original switch was T210
 
0
Thank you very much for your answer.

So Drake is a chip based on Orin (Orin is an automotive series of chips).

Drake's architecture (based on Orin) is Ampere.

And what does the name T239 refer to then?
T239 is the internal identifier for Drake. Drake is just a codename.
 
Orin is a family of AI chips for AI developer boards. Drake is the code name for Switch 2. They are expected to share a lot of the designa.
Not quite, Drake is the code name of the chip in the next Switch, not the code name of the entire device.

Thank you very much for your answer.

So Drake is a chip based on Orin (Orin is an automotive series of chips).

Drake's architecture (based on Orin) is Ampere.

And what does the name T239 refer to then?
T239 is the Tegra series number for the Drake chip. Basically T239=Drake like T234= Orin
 
engineering samples being out in April 2021 is interesting. either that means devs were working on simulated kits or they were working on analogues. I would bet on there being orin-based kits before then

This lines up with what Polygon said and Nate confirmed that new dev kits had gone out recently as well.

I'm not knowledgeable on the industry at all, but I imagine putting out a batch of final silicon dev kits is the next logical step after the engineering samples pass the test.
 
I'm just going by their Cyberpunk picture, but it implies per-frame latency as going from 3.6 frames when DLSS 3/RTX is off, to 5.6 frames when DLSS/RTX is on. The individual frames themselves are >4x more frequent though, which would give room for the claim that responsiveness is improved.
Oh sure, I had thought you were talking about the image quality breaking down with camera rotation. I don’t know enough about how the scheduling works to say anything on how the latency shakes out.
 
0
It's surely intermediate frames rather than future ones, or else there would be horrible issues any time you panned/rotated the camera quickly, right?
If it were just creating in-between frames from two finished frames, it would be little different than a higher quality version of what most TVs already offer. It would also necessarily add image latency, since you'd need to render frame A to create in-between frame A-1, and hold back frame A another 1/60 or 1/120 of a second or whatever the case may be.
 
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