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

[Thraktor]

Preview of a preview, but some early DLSS 3.0 numbers

It's definitely extrapolation, NVidia specifically mentions generating frames while the CPU bottlenecks a frame drop. It needs a buffer of input frame data in order to infer motion vectors in the OFA but also the DLSS 3.0 use case involves extrapolating frames while also supersampling.

Thanks. I suppose my confusion was from the fact that (as far as I'm aware) DLSS 2 only requires a single frame to be input to perform temporal supersampling, as the temporal aspect is handled implicitly by virtue of it being implemented as a recurrent neural network. It also specifies that the two frames are required in addition to the already generated optical flow field, as per this quote:

The DLSS Frame Generation convolutional autoencoder takes 4 inputs – current and prior game frames, an optical flow field generated by Ada’s Optical Flow Accelerator, and game engine data such as motion vectors and depth.

Perhaps the frame generation portion of DLSS 3 isn't a recurrent network, hence requiring two frames rather than one.

My hope is that something like this simply allows for Wii level motion controls, outside of VR - using the dock, for example, as a reference point, and the tensor cores for inference.

Yeah, the dock (or just the Switch tablet itself, given the joy-cons would be detached), could serve as a reference point for tracking. I'm not sure how accurate it would be possible to get a UWB solution, though. A quick search indicates accuracy in the range of 10cm to 50cm, which is fine for finding a lost pair of keys, but not great for controller tracking. I'm curious if that's a technological limit, or just a limit of current implementations based on their less strict requirements.

 

[Skittzo]

What is happening today? What new information do we have? I'm trying to collect today's information but it's getting out of hand.
I don't fully understand what is happening and also my language is not English (in fact I usually use translators to be able to communicate).
The reason for my question about what's going on today is because I'm seeing a lot of movement and comments on social media about the T239 and other clues that seem to lead us to the Switch review. Could someone explain what is happening? Thanks.

A user here found that the Linux kernel was recently updated to support T239, which is the chip number for the Drake chip that will be used in the new Switch. Along with this information it was found that T239 has 8 CPU cores in a single cluster, which was something that was expected but not yet confirmed until now. It heavily suggests that Drake uses 8 A78 ARM CPU cores.

 

[olobolger]

What is happening today? What new information do we have? I'm trying to collect today's information but it's getting out of hand.
I don't fully understand what is happening and also my language is not English (in fact I usually use translators to be able to communicate).
The reason for my question about what's going on today is because I'm seeing a lot of movement and comments on social media about the T239 and other clues that seem to lead us to the Switch review. Could someone explain what is happening? Thanks.

Basically this:

Well done on spotting this!

For anyone unsure about what this means, the important part is this:

Adding support for Tegra239 SoC which has eight cores in a single cluster

We know from a variety of sources that the T239 chip is Drake, ie the one being used in the new Switch model. It having "eight cores in a single cluster" means it has 8 CPU cores (obviously), but doesn't strictly speaking limit what those cores can be, as ARM's DynamicIQ supports clusters with mixes of different cores (eg 4x A78 and 4x A55). However, as the code would almost certainly have to be changed to support these hetergeneous clusters (ie different core types would run at different frequencies), and the commit here doesn't make such changes, we can reasonably assume that the cores are all of the same type. The only big ARM cores which can be configured with 8 cores in a single cluster are the A78 (in the A78C variant) and later, and given the T234/Orin SoC uses A78 cores, it seems very likely that T239 is using an 8 core A78C CPU.

Furthermore, the fact that T239 support is being added to the Linux kernel means that Nvidia plan to use it in products other than the new Switch. This isn't particularly surprising, as the Mariko chip (T210B01) was also created for Nintendo, but used in other products (Jetson Nano), so Nintendo don't seem to have any problem with their semi-custom parts being used elsewhere. It likely allows them to get a better deal from Nvidia.

Lastly, code being updated to support T239 likely means that there is actually hardware to run this code on. That is, at the very least, engineering samples of T239 already exist, meaning full scale production of the chip is likely to start soon if it hasn't already.

 

[SpaceGodzilla]

So what I miss the past 12 hours?

 

[niconiconick64]

The potential for VR on drake is actually interesting. I remember my old 1050ti actually being able to handle lightweight unity-based VR titles just fine.
I also remember how nintendo was interested in messing around with vr quite a bit on the switch with labo and game builder garage.

I know, pixel density on the switch's display is probably not going to be nowhere near enough for proper vr (let alone the refresh rate and hardware requirements for HFR).
But damn do I want zelda in first person on a strappable switch "pro" tablet headset...

 

[Mr Swine]

if there is any Ada feature that comes to Drake, the only one I can see coming with low chance is the SER feature:

• Shader Execution Reordering (SER) that improves execution efficiency by rescheduling shading workloads on the fly to better utilize the GPU’s resources. As significant an innovation as out-of-order execution was for CPUs, SER improves ray-tracing performance up to 3x and in-game frame rates by up to 25%.

NVIDIA Delivers Quantum Leap in Performance, Introduces New Era of Neural Rendering With GeForce RTX 40 Series

NVIDIA today unveiled the GeForce RTX® 40 Series of GPUs, designed to deliver revolutionary performance for gamers and creators, led by its new flagship, the RTX 4090 GPU, with up to 4x the performance of its predecessor.

nvidianews.nvidia.com

This would make it more efficient at doing the same job with RT or otherwise.


I don’t see 4th gen Tensor Cores or 3rd gen Ray Tracing Cores. But, something akin to an out of order executor for the GPU but useful for RT would be really nice.

Wouldn’t CUDA version 9.8 be back ported too?

 

[Skittzo]

So what I miss the past 12 hours?

Look at the posts directly above you.

 

[Foltzie]

So what I miss the past 12 hours?

The same joke told a few times ;-)

 

[Deleted member 887]

So what I miss the past 12 hours?

What is happening today? What new information do we have? I'm trying to collect today's information but it's getting out of hand.

Nvidia published an update to their linux drivers that included some CPU information a few days ago. Someone on the forums caught it, and shared it. Also, NVidia had their big next gen presentation.

I've updated my summary of everything we know, which is in the threadmarks, or here: https://famiboards.com/threads/futu...nology-speculation-st.55/page-491#post-406509

 

[kvetcha]

The potential for VR on drake is actually interesting. I remember my old 1050ti actually being able to handle lightweight unity-based VR titles just fine.
I also remember how nintendo was interested in messing around with vr quite a bit on the switch with labo and game builder garage.

I know, pixel density on the switch's display is probably not going to be nowhere near enough for proper vr (let alone the refresh rate and hardware requirements for HFR).
But damn do I want zelda in first person on a strappable switch "pro" tablet headset...

If the Meta Quest 2 can handle it, Drake can handle it.

 

[Deleted member 887]

Re: Clock Speeds, battery and Backwards Compat.

It occurred to me a couple days ago that Drake doesn't need to run 12SMs when running a game linked against NVN instead of NVN2. Yes, NVN2 hardcodes the number of SMs, so we don't expect SMs to be turned off in handheld mode. But the same isn't true for games linked against an original Switch driver.

I've been thinking of the 460MHz mode that Switch has in handheld, and how that might be pushing it for a fat 12SM architecture with a sub 10W power draw, even more so if the CPU is octo-core. But Drake could shut down SMs and drive up clocks when running in backwards compat, similar to how the Wii actually powers down the other CPUs in GameCube mode, or the DS did in GBA mode. If Nintendo is only offering better graphics via patches - if this is more like a successor than a revision, in other words, where they don't need half the library to run better on Drake, just a dozen or so games - then they don't need to offer a beefier back compat mode.

I'm not saying that Nintendo will do this, just that they can and it offers up a much wider range of clocks for Drake. 350Mhz with 12SMs is still a significant power bump, after all.

It also potentially extends battery life considerably in a backcompat mode, with Nintendo shutting off TPCs (the same way Orin does) when running an OG Switch game, and taking full advantage of the process improvements. I know it would only appeal to some players but "Patched games look better, unpatched games give you double the battery life" is a pretty damn compelling pitch.

 

[JoshuaJSlone]

From a technical point of view I'm sure they could, but from a practical point of view the small size of joy-cons would probably be a hinderance. VR controllers tend to be quite large, usually with a halo ring of tracking points on top, to make them visible to the tracking cameras, and to provide enough distance between tracking points to properly triangulate the position.

I think you've missed my point. Not to be like VR controllers, which are still being tracked by external (to it) cameras, those on the headset. I mean the headset tech itself, which is basing position on cameras built into the device itself. VR headsets do use multiple cameras to get a good idea of changing position within a room, but for a simpler purpose (advanced pointer) I'm thinking a single camera on top of a controller half could suffice. The wiimote used a camera specifically looking for the two lights on a sensor bar (and which allowed it to flip out if it caught sight of some other light sources); I'm saying replace that system with a camera that could orient itself to arbitrary surroundings, as long as you're not playing in a void.

 

[chocolate_supra]

Nm

8 or 5 or...?

 

[Kise Ryota]

I think you've missed my point. Not to be like VR controllers, which are still being tracked by external (to it) cameras, those on the headset. I mean the headset tech itself, which is basing position on cameras built into the device itself. VR headsets do use multiple cameras to get a good idea of changing position within a room, but for a simpler purpose (advanced pointer) I'm thinking a single camera on top of a controller half could suffice. The wiimote used a camera specifically looking for the two lights on a sensor bar (and which allowed it to flip out if it caught sight of some other light sources); I'm saying replace that system with a camera that could orient itself to arbitrary surroundings, as long as you're not playing in a void.

Basically the project cambria from oculus (I believe they will call it quest pro). The controllers have 3 cameras each, and all the positional tracking is done by the controller alone.

The problem is the cost. But I would love something like that (no drift anymore lol).

 

[Cybergatuno]

The potential for VR on drake is actually interesting. I remember my old 1050ti actually being able to handle lightweight unity-based VR titles just fine.
I also remember how nintendo was interested in messing around with vr quite a bit on the switch with labo and game builder garage.

I know, pixel density on the switch's display is probably not going to be nowhere near enough for proper vr (let alone the refresh rate and hardware requirements for HFR).
But damn do I want zelda in first person on a strappable switch "pro" tablet headset...

My dream would be to play a BotW-like game, be it TotK or the next, in VR and co-op with friends or family, attacking enemy camps with infinite options or just goofing around with physics.

There may be potential for VR with Drake, certainly leagues above Labo, but I don't think we're there yet. More knowledgeable people will know better.

The OG PS VR headset came with a 1080p screen I believe, with either 90Hz or 120Hz refresh rates. I'm not sure how expensive those are nowadays but I think it could be made reality if Nintendo wants that extra gimmick.

What I find odd is that none of leakers/insiders mentioned the Switch 2 screen resolution. As a developer, that would be one of the first things I would need to know. It is easy to tweak resolution though.

I'm expecting them to use the same 720p OLED screen. IMO perfect for handheld (with performance/battery considerations) but falls short for a good VR experience.

ETA: Nevermind about PS VR. It apparently has two screens, 960x1080p per eye. This is the lowest bar for VR to be marketable and still well above what a Switch 2 could do I think.

 

[Kise Ryota]

I'm expecting them to use the same 720p OLED screen. IMO perfect for handheld (with performance/battery considerations) but falls short for a good VR experience.

I would make something like the magic leap 2. You would have a proper HMD (the sensors, cameras, lenses, 2k-per-eye screen) and you would connect the HMD to the tablet (wired). The tablet would be attached to your body using a support (Nintendo loves something like that).

This solution would be good because it would be cheaper for consumers, nintendo wouldn't need to use Switch's components (SoC, ram, etc) on the HMD (so it wouldn't interfere with Switch's production), and it would offer a good experience because the HMD would be lighter and comfortable.

 

[N 2 Deep]

It is a shame this is essentially the Switch 2 but it will fall under a different name (like Switch Pro or Switch+). But Nintendo probably wants that best selling console of all time moniker

With that said, and with all of the new news and how likely fabrication and mass production has started I am fully on team this is launching in May alongside TotK

 

[Deleted member 887]

The Linux drop actually wasn't NVidia's only public drop referencing t239, as it turns out. Last month they updated their public GPU docs on github with header files defining constants for all their arches, Fermi-Ampere, and included a doc that lists T239 and T234 as "AMPERE_B" arches.

I don't think there is anything new in the header file that isn't in the NVN2 hack - in fact, since they share a header file, there is no listed difference between Orin's customized Ampere as documented here and Drake's. But worth noting

open-gpu-doc/classes/3d at master · NVIDIA/open-gpu-doc

Documentation of NVIDIA chip/hardware interfaces. Contribute to NVIDIA/open-gpu-doc development by creating an account on GitHub.

github.com

 

[10k]

Re: Clock Speeds, battery and Backwards Compat.

It occurred to me a couple days ago that Drake doesn't need to run 12SMs when running a game linked against NVN instead of NVN2. Yes, NVN2 hardcodes the number of SMs, so we don't expect SMs to be turned off in handheld mode. But the same isn't true for games linked against an original Switch driver.

I've been thinking of the 460MHz mode that Switch has in handheld, and how that might be pushing it for a fat 12SM architecture with a sub 10W power draw, even more so if the CPU is octo-core. But Drake could shut down SMs and drive up clocks when running in backwards compat, similar to how the Wii actually powers down the other CPUs in GameCube mode, or the DS did in GBA mode. If Nintendo is only offering better graphics via patches - if this is more like a successor than a revision, in other words, where they don't need half the library to run better on Drake, just a dozen or so games - then they don't need to offer a beefier back compat mode.

I'm not saying that Nintendo will do this, just that they can and it offers up a much wider range of clocks for Drake. 350Mhz with 12SMs is still a significant power bump, after all.

It also potentially extends battery life considerably in a backcompat mode, with Nintendo shutting off TPCs (the same way Orin does) when running an OG Switch game, and taking full advantage of the process improvements. I know it would only appeal to some players but "Patched games look better, unpatched games give you double the battery life" is a pretty damn compelling pitch.

Some games make mention in their configs to CUDA cores and SM counts though. Just run them all.

 

[Brofield]

Hey OldPuck, it's me again.
Oh hey, Anonymous Lurker, how is it going?

I noticed the thread got pinned, and thought I'd take a peek.
There is a lot of information in the OP if you wanna catch up.

Oh, I can't do that. There is just... so much info. Also, I'm not super technical, so even if I did read all of it, it would go over my head. Could you just tell me what we know.
Um... I honestly probably can't do that.

So you don't actually know anything?!?
We know more about this console than maybe any other unreleased console, ever.

Why can't you tell me anything then?
Imagine that you had the diagrams for a brand new car engine. You take them to an engineer, and excitedly ask questions about the car - how fast will it go? "Well, it depends on what sort of chasis they use..." what's the MPG like? "well, depends on how aerodynamic the body is and if they rate it for higher or lower RPMs" Don't you even know what the stereo system will be like??? "uh, absolutely not..."

It's the same here. We know a lot about the chip that the Next Switch will use, but there are also a lot of blanks. And we have good guesses for those blanks! But you don't care about that, you care about the games right?

Yeah, basically.
And a lot of smart people have made a lot of smart discoveries about the thing, but if I start saying specifics, I guarantee less than 1/3 of the regulars will agree with my final conclusions. At least 1 thing will be controversial. And that's why there is still a thread going even when there isn't new info.

It's like trying to solve a crossword puzzle when some of the clues are missing or blurry. We've actually filled a lot of it in, but the rest are reasonable guesses, or guesses based on guesses, or guesses based on those. It gets real tenuous after a while.

Okay but can't you tell me anything?
I'll tell you what I'll do. I'm going to compile the current as of September 18, 2022 state of affairs below. I'm going to summarize the best guesses, and I'm going to organize it from stuff we're 90% confident in all the way to "Guesses upon guesses upon guesses".

But I'm going to hide it all, because there has been a trend of disreputable people making bad-faith content out of the speculation here, and that causes lots of problems. I'm also going to hide chunks behind spoiler tags.

I'm also going to update things here in the inevitable backlash as my fellow thread-dwellers correct me, but I'm not going to update this post as new data comes in. Got it?

Got it.

* Hidden text: cannot be quoted. *


Update: Clarification from @Look over there, @Alovon11. Updated on the 20th with info from @Cybergatuno because not doing so seemed dumb, even if it came in after the 18th

 

[Pokemaniac]

Re: Clock Speeds, battery and Backwards Compat.

It occurred to me a couple days ago that Drake doesn't need to run 12SMs when running a game linked against NVN instead of NVN2. Yes, NVN2 hardcodes the number of SMs, so we don't expect SMs to be turned off in handheld mode. But the same isn't true for games linked against an original Switch driver.

I've been thinking of the 460MHz mode that Switch has in handheld, and how that might be pushing it for a fat 12SM architecture with a sub 10W power draw, even more so if the CPU is octo-core. But Drake could shut down SMs and drive up clocks when running in backwards compat, similar to how the Wii actually powers down the other CPUs in GameCube mode, or the DS did in GBA mode. If Nintendo is only offering better graphics via patches - if this is more like a successor than a revision, in other words, where they don't need half the library to run better on Drake, just a dozen or so games - then they don't need to offer a beefier back compat mode.

I'm not saying that Nintendo will do this, just that they can and it offers up a much wider range of clocks for Drake. 350Mhz with 12SMs is still a significant power bump, after all.

It also potentially extends battery life considerably in a backcompat mode, with Nintendo shutting off TPCs (the same way Orin does) when running an OG Switch game, and taking full advantage of the process improvements. I know it would only appeal to some players but "Patched games look better, unpatched games give you double the battery life" is a pretty damn compelling pitch.

It at least seems plausible Nintendo could offer performance and battery life focused modes for BC. That's something I've been thinking about for a while.

 

[Stinky Horse]

It is a shame this is essentially the Switch 2 but it will fall under a different name (like Switch Pro or Switch+). But Nintendo probably wants that best selling console of all time moniker

There's only Sony who names consoles like that, why does anyone care?
Sega's Megadrive 2 was just a redesigned Megadrive

 

[Deleted member 887]

It's bonkers to me how much we know about this thing, now. We have a fairly complete architectural understanding, a broad-ish range for clock speeds, a narrower range for memory use, and a form factor. At this point the pessimistic view and the optimistic views are starting to converge, but the bigger questions now are really about Nintendo's 5 year plan than they are about the nuts and bolts.

 

[arsen]

Found this on Github:

athena_l4t_nvidia/drivers/platform/tegra/mc/mc_utils.c at bfdeea3ad0b6a04780b7a3261ab1410b947cd56f · zbwu/athena_l4t_nvidia

Contribute to zbwu/athena_l4t_nvidia development by creating an account on GitHub.

github.com

Mention of "LPDDR4 8ch" for the "pre silicon" of t239, seems to be from last december so not sure if this is outdated or anything.

 

[Raccoon]

silly question I'm sure, but do how certain are we that T239 is Nintendo?

 

[Skittzo]

It's bonkers to me how much we know about this thing, now. We have a fairly complete architectural understanding, a broad-ish range for clock speeds, a narrower range for memory use, and a form factor. At this point the pessimistic view and the optimistic views are starting to converge, but the bigger questions now are really about Nintendo's 5 year plan than they are about the nuts and bolts.

Yeah it seems like branding and timing are the only real remaining question marks. Major ones anyway.

 

[Hermii]

Unless some feature unbeknownst to us is in Drake, no one should expect the full use of DLSS3 like frame generation, to be in it.

I’d assume it can’t even use it personally.

Why, does it require Lovelace?

 

[ReddDreadtheLead]

Re: Clock Speeds, battery and Backwards Compat.

It occurred to me a couple days ago that Drake doesn't need to run 12SMs when running a game linked against NVN instead of NVN2. Yes, NVN2 hardcodes the number of SMs, so we don't expect SMs to be turned off in handheld mode. But the same isn't true for games linked against an original Switch driver.

I've been thinking of the 460MHz mode that Switch has in handheld, and how that might be pushing it for a fat 12SM architecture with a sub 10W power draw, even more so if the CPU is octo-core. But Drake could shut down SMs and drive up clocks when running in backwards compat, similar to how the Wii actually powers down the other CPUs in GameCube mode, or the DS did in GBA mode. If Nintendo is only offering better graphics via patches - if this is more like a successor than a revision, in other words, where they don't need half the library to run better on Drake, just a dozen or so games - then they don't need to offer a beefier back compat mode.

I'm not saying that Nintendo will do this, just that they can and it offers up a much wider range of clocks for Drake. 350Mhz with 12SMs is still a significant power bump, after all.

It also potentially extends battery life considerably in a backcompat mode, with Nintendo shutting off TPCs (the same way Orin does) when running an OG Switch game, and taking full advantage of the process improvements. I know it would only appeal to some players but "Patched games look better, unpatched games give you double the battery life" is a pretty damn compelling pitch.

I wanted to clarify one thing on this, with respect to the GPU and the # of cores for BC, that’s completely dependent on what BC route Nintendo uses. A software solution doesn’t matter. But a hardware based BC would be hard coded for only 256 CUDA cores.

Series does the software route, PS5 does the hardware route for BC.


And there’s something in the hack that implies a software solution they can work with.

 

[kvetcha]

Why, does it require Lovelace?

It does, yes.

 

[10k]

Nintendo Switch Advance Spec Sheet from my ass:

• TSMC 5nm
• 8x A78C CPU @ 1.6Ghz
• 1536 CUDA Cores @ 768mhz docked (2.35TF) 460mhz portable (1.4TF)
• 12GB LPDDR5 RAM
• 7" 720p OLED screen, same form factor as current OLED
• Dpad on the left joy-con
• 3-5 Hours of battery life
• UFS 3.0 storage
• DLSS 2.x, tensor cores
• HDR10 support
• $449 USD for 128GB
• $499 for 256GB

 

[Stinky Horse]

Found this on Github:

athena_l4t_nvidia/drivers/platform/tegra/mc/mc_utils.c at bfdeea3ad0b6a04780b7a3261ab1410b947cd56f · zbwu/athena_l4t_nvidia

Contribute to zbwu/athena_l4t_nvidia development by creating an account on GitHub.

github.com

Mention of "LPDDR4 8ch" for the "pre silicon" of t239, seems to be from last december so not sure if this is outdated or anything.

The commented line seems kind of important there. The inner code block will not run on production hw. It gets the ram type and channel count from somewhere else and overwrites it here if it's on a simulated chip. Could still be either type in theory but we know Orin uses LPDDR5.

 

[Skittzo]

silly question I'm sure, but do how certain are we that T239 is Nintendo?

I feel pretty comfortable saying 100% certain at this stage. In 2021 kopite says Nintendo is using T239, then in the hack "NVN2", the proprietary API only used by switch products thus far, mentions T239 a ton.

It would be extremely confusing if somehow it wasn't for Nintendo.

 

[Hermii]

It does, yes.

Ah, then it’s off.

 

[Raccoon]

Nintendo Switch Advance Spec Sheet from my ass:

• TSMC 5nm
• 8x A78C CPU @ 1.6Ghz
• 1536 CUDA Cores @ 768mhz docked (2.35TF) 460mhz portable (1.4TF)
• 12GB LPDDR5 RAM
• 7" 720p OLED screen, same form factor as current OLED
• Dpad on the left joy-con
• 3-5 Hours of battery life
• UFS 3.0 storage
• DLSS 2.x, tensor cores
• HDR10 support
• $449 USD for 128GB
• $499 for 256GB

unyeahed because of the d-pad smh

 

[Pokemaniac]

silly question I'm sure, but do how certain are we that T239 is Nintendo?

It's the chip NVN2 appears to be targeting.

 

[maidhhc]

I liked the Hyper Switch name someone mentioned earlier!

Can't wait to see the reveal of the Super Nintendo Hyper-Switch Advance in January

 

[Deleted member 887]

Found this on Github:

athena_l4t_nvidia/drivers/platform/tegra/mc/mc_utils.c at bfdeea3ad0b6a04780b7a3261ab1410b947cd56f · zbwu/athena_l4t_nvidia

Contribute to zbwu/athena_l4t_nvidia development by creating an account on GitHub.

github.com

Mention of "LPDDR4 8ch" for the "pre silicon" of t239, seems to be from last december so not sure if this is outdated or anything.

It's definitely outdated, as it refers to Orin as also simulated/FPGA hardware, and Orin is now in production, and using LPDDR5 RAM.

It does confirm that Nvidia has been working on Linux for Drake for sometime (L4T is Linux For Tegra), and that the drops to mainline are the end of that effort, not the beginning. And that Orin and Drake were developed in tandem with each other, which tracks with everything else we know, again implying that they were ready for production around the same time. And that Drake has half the memory controller channels of Orin, which tracks with everything else we know about the Drake memory subsystem.

 

[10k]

unyeahed because of the d-pad smh

You coward.

 

[JoshuaJSlone]

It is a shame this is essentially the Switch 2 but it will fall under a different name (like Switch Pro or Switch+). But Nintendo probably wants that best selling console of all time moniker

If they cared that badly about something like that they could've squeezed it out of DS.

 

[Serif]

Everywhere I look, NVN is associated with the Switch. I think Nvidia even had a blog post talking about it being specifically developed for it, though I'm having a hard time digging it up.

With the Nvidia leak having specific filepaths like 'nvn2/dlss', it's exciting to see. Hard to be more certain than that.

 

[Hajeman]

I liked the Hyper Switch name someone mentioned earlier!

Can't wait to see the reveal of the Super Nintendo Hyper-Switch Advance in January

Nintendo hasn't named their consoles or handhelds with No.2 after the name. So for a Drake it's mostly will be named as a Super Switch or Switch Advance

 

[kvetcha]

Nintendo hasn't named their consoles or handhelds with No.2 after the name. So for a Drake it's mostly will be named as a Super Switch or Switch Advance

I really like Switch Advance.

 

[Golden Darkness]

It's definitely outdated, as it refers to Orin as also simulated/FPGA hardware, and Orin is now in production, and using LPDDR5 RAM.

It does confirm that Nvidia has been working on Linux for Drake for sometime (L4T is Linux For Tegra), and that the drops to mainline are the end of that effort, not the beginning. And that Orin and Drake were developed in tandem with each other, which tracks with everything else we know, again implying that they were ready for production around the same time. And that Drake has half the memory controller channels of Orin, which tracks with everything else we know about the Drake memory subsystem.

This seems to the current version. Maybe hunt references for the T239 here:

linux-tegra-5.10/nvidia/drivers/platform/tegra/mc at oe4t-patches-l4t-r35.1 · OE4T/linux-tegra-5.10

NVIDIA downstream Linux kernel for Jetson platforms in single-repo form, derived from L4T R35.x series BSP - OE4T/linux-tegra-5.10

github.com

 

[ReddDreadtheLead]

Found this on Github:

athena_l4t_nvidia/drivers/platform/tegra/mc/mc_utils.c at bfdeea3ad0b6a04780b7a3261ab1410b947cd56f · zbwu/athena_l4t_nvidia

Contribute to zbwu/athena_l4t_nvidia development by creating an account on GitHub.

github.com

Mention of "LPDDR4 8ch" for the "pre silicon" of t239, seems to be from last december so not sure if this is outdated or anything.

Fwiw, LPDDR4 isn’t manufactured anymore so this is very much just some prototype.

 

[Codename_Steam]

Can DLSS 3.0 run on T239 (Drake)?

 

[Pokemaniac]

Can DLSS 3.0 run on T239 (Drake)?

From how it's been described, the full functionality seems to require additional hardware beyond what desktop Ampere provides. The chances that hardware is present in Drake are not zero, but I don't think we have an especially strong reason to expect it's there currently.

That said, it's my understanding that it's supposed to fallback to more 2.x like functionality on older hardware.

 

[SpaceGodzilla]

i just want them to announce the damn thing

 

[Deleted member 887]

This seems to the current version. Maybe hunt references for the T239 here:

linux-tegra-5.10/nvidia/drivers/platform/tegra/mc at oe4t-patches-l4t-r35.1 · OE4T/linux-tegra-5.10

NVIDIA downstream Linux kernel for Jetson platforms in single-repo form, derived from L4T R35.x series BSP - OE4T/linux-tegra-5.10

github.com

Yeah, I was poking around in the various L4T repositories. Basically, t239 has its own graphics driver separate from t234, and there are a bunch of build time overrides to get it to use it's custom NVDEV, VIC, and TSEC implementations. There is also a strange alteration to the CDMA I don't understand that might be because of the differences in power gating that Drake supports.

 

[N 2 Deep]

I don't think Advanced will be the moniker, I'd love it to be but 4k, +, or Pro all seem more likely.

Maybe even Ultra

There's only Sony who names consoles like that, why does anyone care?
Sega's Megadrive 2 was just a redesigned Megadrive

Because I want continuity baby!

If they cared that badly about something like that they could've squeezed it out of DS.

Handheld vs. Home Console

Switch is technically still a home console, and there is a completely different regime running things than during Wii/DS era. I am not saying they 100% care, but it does seem they want the general public to see this as a continuation of the current Switch rather than a generational upgrade.

It could also be because they really want to have more frequent hardware upgrades going forward and Switch just becomes a tentpole console for them that will be updated every so often and the next upgrade after this Drake version they will stop supporting OG Switch hardware with their software.

 

[karmitt]

From how it's been described, the full functionality seems to require additional hardware beyond what desktop Ampere provides. The chances that hardware is present in Drake are not zero, but I don't think we have an especially strong reason to expect it's there currently.

That said, it's my understanding that it's supposed to fallback to more 2.x like functionality on older hardware.

I also assume that they’re forking things for 3.0? With 2.X being far more ubiquitous for the foreseeable future its probably still going to have plenty of work done on it - no?

I’m not fussed about the lack of a 3.0. If any meaningful improvements can happen to 2.X, they will.