-
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.
-
Furukawa Speaks! We discuss the announcement of the Nintendo Switch Successor and our June Direct Predictions on the new episode of the Famiboards Discussion Club! Check it out here!
StarTopic Future Nintendo Hardware & Technology Speculation & Discussion |ST| (New Staff Post, Please read)
- Thread starter Dakhil
- Start date
Zedark
The guy with the ToV avatar
I imagine ahypothetical scenario would be this: the lowest performance profile setting would allow you to run MK8D at 720p 60 fps in handheld mode, boost some textures, and still have enough performance overhead to utilise the DLSS algorithm to internally upres to 1440p, and then let downsampling provide a better 720p image. I believe that was the original purpose of DLSS, right? Before they figured out the algorithm was so powerful that it was the best-in-biz real-time super-resolution algorithm. As such, I would imagine that that could have a profound effect on image quality. I remember someone (maybe DF?) doing a comparison for this use case, and they were quite impressed with the improvement to the sub-pixel detail like hairs and such. So yeah, if that is possible, I would say definitely do it.
If the choice is between this and a noticeably better battery life (like costing more than an hour of battery life), I think the extra hour of battery could be preferred if it is a difference between 3 or 4 hours. If the difference if more than 7 vs. 8 hours, I'd say do the DLSS downsampling.
brainchild
Moblin
As I mentioned before, this is not my proposal, but if users want the option to have use DLSS in this way, then I will do my best to provide it as an option.
I'm only talking about super sampling and then downsampling (starting from native resolution, upsampling, and then downsampling the result), which was the actual original purpose of DLSS and it's how the neutral networks were trained from the beginning.
I just want to know how much of an appetite there is for image quality conscious gamers to sacrifice a little performance (and subsequently battery life) for significantly improved image quality. Upsampling from a sub-native resolution would produce inferior image quality results when compared against its natively upsampled counterpart.
Zedark
The guy with the ToV avatar
I think Insomniac Games' post from years back is revealing: it basically states that focusing on visual quality over frame rate had a better market reception than going for frame rate. Now I think that pendulum has swung back to some degree: more people have become interested in performance, hence why I think the 60 fps modes are rapidly becoming an option in multiple games. That said, it does indicate that visuals are important, and I would think that many would appreciate an option like the one you laid out, even at the cost of performance.
Of course, it will depend on the game as well I think: If you are making Ratchet & Clank like Insomniac, then you can get perfectly coherent and fluid gameplay at 30 fps. If you're making Mario Kart, please don't sacrifice a solid 60 fps for better visual quality: you need the accuracy that 60 fps provides in order to play well at 200cc.
Anyway, these are my personal thoughts on the matter. I'm sure other people will agree or disagree.
Last edited:
ReddDreadtheLead
#TeamLate2025WithAPotentialForEarly2026
- Pronouns
- He/Him
@brainchild to give my few cents on this matter, to me it’s difficult to say if it’s something I’d like as I haven’t actually witnessed it executed in a way that makes me want to like it, aka, I haven’t actually seen much of well executed attempts. Or seen it executed much if at all.
So a super sampled image that gets AI downsampled to the screen’s resolution in a way that is a smooth scaling sound good in theory, but I’m unsure how it would pay out in practice. I believe there’s a performance penalty as well for running a setup like this?
So a super sampled image that gets AI downsampled to the screen’s resolution in a way that is a smooth scaling sound good in theory, but I’m unsure how it would pay out in practice. I believe there’s a performance penalty as well for running a setup like this?
brainchild
Moblin
If you have a PC with an NVIDIA RTX GPU you can take a look for yourself by turning on the DLDSR factor (2.25x) in the NVIDIA control panel under the DSR setting.
And yes, there is a slight computational cost as it takes resources to process DLSS and DSR/DLDSR.
Kenka
Like Like
- Pronouns
- He/Him
Lots of good answers to brainchild's question.
By the way brainchild, do you know how much time is needed to applying DLSS, DLDSR and RTXGI to a frame when running a game on an RTX 3080Ti?
Do you happen to know maybe how much time each step of the process would take?
By the way brainchild, do you know how much time is needed to applying DLSS, DLDSR and RTXGI to a frame when running a game on an RTX 3080Ti?
Do you happen to know maybe how much time each step of the process would take?
Last edited:
brainchild
Moblin
I don't know their contributions to the rendering budget off the top of my head but I'll get the numbers for you when I have some time.
ShaunSwitch
Moblin
My two cents answering @brainchild 's question.
With it being portable hardware I guess for me it depends on a number of things.
So by using DLSS and DLDSR vs just DLSS to the native res of the screen am I going to take an fps hit? Is it 30 vs 60? If the game is largely cinematic and doesn't need 60 fps I may take the hit depending on the type of game and the art style.
Secondly, I need to consider the battery life differences. If using the full grunt of the system to max IQ I get an image that's say 5% better but my battery life drops from 5/6 hours to 3 hours I would probably just take the extra battery life and let the system keep the extra overhead rather than trying to queeze that last bit of performance out of the system.
Lastly, can the extra overhead be used for RTX or other visual improvements that have greater impact such as texture detail, shadow detail etc? I'd take those over super sampling most of the time.
I haven't used DLDSR but I've used older forms of super sampling and don't find the image quality to be much improved so I would rather have more battery life and frame rate. Lock in that stable 60fps. I'm also pretty energy conscious so mine is probably a niche opinion.
With it being portable hardware I guess for me it depends on a number of things.
So by using DLSS and DLDSR vs just DLSS to the native res of the screen am I going to take an fps hit? Is it 30 vs 60? If the game is largely cinematic and doesn't need 60 fps I may take the hit depending on the type of game and the art style.
Secondly, I need to consider the battery life differences. If using the full grunt of the system to max IQ I get an image that's say 5% better but my battery life drops from 5/6 hours to 3 hours I would probably just take the extra battery life and let the system keep the extra overhead rather than trying to queeze that last bit of performance out of the system.
Lastly, can the extra overhead be used for RTX or other visual improvements that have greater impact such as texture detail, shadow detail etc? I'd take those over super sampling most of the time.
I haven't used DLDSR but I've used older forms of super sampling and don't find the image quality to be much improved so I would rather have more battery life and frame rate. Lock in that stable 60fps. I'm also pretty energy conscious so mine is probably a niche opinion.
SiG
Chain Chomp
I'd say Alex Battaglia from Digital Foundry might have attempted this "downsampling from an AI upscaled image" in one of his videos.
Edit: Sorry I had to reread your question to understand and I think I know what you're getting at: Perhaps its wanting to know if doing so would introduce "AI artifacting" so to speak?
Last edited:
I think the proliferation of performance vs quality modes is something of a side effect of games being stretched across a wide array of hardware combined with diminishing returns in resolution. Most games on PS5/XS (or even PS4 Pro/X1X) right now aren't really being designed with that hardware in mind, and thus have an excess of performance which is really pretty debatable what to do with.
Drake is likely to be in a fairly similar situation for some time, at least for Nintendo focused projects, but Nintendo themselves aren't super big on providing extensive options, so I think they'll probably just pick something.
Kenka
Like Like
- Pronouns
- He/Him
It is much appreciated that you take some of your precious time to educate a few forum dwellers. Seriously, it's awesome.
Whatever project you work on, I hope the end product satisfies you. Also, I think quite a few of us would like to know more about it!
Mr Swine
Like Like
- Pronouns
- He
I wonder how Nintendo/Nvidia will solve DLSS 2.x if Nvidia comes out with new versions that increase IQ and performance for a few %.
If release games are running on an old DLSS version and the new one would fix performance/ghosting/image quality I wonder if the games could look up at the OS to see if a newer one is installed?
If release games are running on an old DLSS version and the new one would fix performance/ghosting/image quality I wonder if the games could look up at the OS to see if a newer one is installed?
On PC is easy to patch, you only need to put the new DLSS archives on the old version folder
RennanNT
Bob-omb
They could, but don't create any expectations. Devs almost certainly don't want untested builds which could introduce new bugs to fix, NVidia will also likely avoid the responsibility of guaranteeing new DLSS versions doesn't break anything in old games they don't own.
Ghostsonplanets
Ghost in the Sales
- Pronouns
- He/Him
Either the OS will provide a new one with OS updates or Nintendo will update the DLSS version dev-side and devs choose to use the one the fits the development timeline of their project.
10k
Nintendo Switch RTX
- Pronouns
- He/Him
Thanks. I actually hate my voice but I’m self conscious.
Based on how the Switch currently manages things, I wouldn't expect any attempt to update the DLSS library of a game that's already been released.
- Pronouns
- he / him
Anything that can improve IQ without killing the frame rate is a good thing as far as I'm concerned.
60fps is a choice rather than a hardware limitation. if you aim for 60fps with DLSS, you'll get it
LiC
Member
Maybe, maybe not. So far, DLSS 2.x versions have been backwards-compatible. And rather than forcing developers to have their games run against updated versions, the Nintendo SDK can simply provide a configuration option to enable roll-forward. Presumably it would be disabled by default, but the developer could enable it to consume minor version upgrades for artifacting fixes and so on, with the downside that it won't be something they've explicitly tested.
One thing to remember is that DLSS is still something Nvidia is handling on a game-by-game basis, in direct contact with the developers. I highly doubt the new Switch model is going to be the thing to change that out of the gate. So any kind of broad solution affecting all developers like this would only happen some time in the future.
ReddDreadtheLead
#TeamLate2025WithAPotentialForEarly2026
- Pronouns
- He/Him
I expect that it, for the most part, will be resolved in a similar way that the Series consoles resolved the performance issues of a game like Control which was handled by the platform holder side via an update to the system.
You are likely correct. It was always just a theory.
I still hold that a T234 can be used as a simulator to execute software that will run on the final T239.
-We know that T234 was taped out before T239.
-We know the the first dev kit for Orin ships with the full T234 SOC.
-We know they are releasing software to flash to the dev kit so it will let you simulate the Orin 16, which has only 1024 CUDA cores and 8 RT cores.
-We know the the first member of the Orin family to reach Production level shipments is the Orin T234 in October 2022.
It would be helpful for Nintendo and Nvidia to be able to run software of real hardware as early in the process as possible. This would be built into the design plan from the start.
As LiC has pointed it, the software running on the chip does not really care if the internal layout is in 1 GPC or 2 GPCs.
So lets follow the logic of saying that T239 has a smaller die size then T234, and that it is a subset (both in the Orin family).
I believe there is nothing inside the T239 that is not also inside the T234.
T234 is the Superset.
Why do automatous cars need RT cores? TTBOMK they do not use them at all. Even in Nvidia's own documents where they try and justify their existence, they do not give any examples of how they can be used for that use case. If we follow the thinking that Nintendo was consulted on the design (we know that Nintendo has been working with Nvidia since before the Switch release), then the RTcores in T234 could be for Nintendo.
This would allow chip samples of T234 to be sent to every partner who will make any device based on a subset of its features, and validate that the chip meets the need and begin work to optimize and debug software that will need to run on it.
(T234 with 2 TPCs disabled) = GPU: 1536 CUDA Cores, 12 2nd-generation RTcores, 48 3rd-generaiton Tensor cores, 12 CUs, 2 GPCs, 6 TPCs
T239 = GPU: 1536 CUDA Cores, 12 2nd-generation RTcores, 48 3rd-generaiton Tensor cores, 12 CUs, 1 GPC?, 6 TPCs
(Please correct me if the above specs are not correct to your understanding)
Now lets say you are Nintendo/Nvidia and you want to develop and test an operating system, a graphics stack, game engine, and games to run on the T239.
Would a Tegra chip in the same family designed and produced first, with the SAME # of CUDA cores, SAME # or RTcores, SAME # of Tensor cores, SAME # of CUs, and SAME # of TPCs be of value?
Yes. This would allow you to develop real software, debug and optimize it, months or years before you can hold a production T239 chip in your hand. This would also allow you to get a large number of final dev kits out much sooner as well.
Zedark
The guy with the ToV avatar
TTBOMK is on another level where abbreviations are concerned 
I think your idea makes sense @Q-True , it could make sense if they put out T234 as dev-kits. The only question I still have regarding that is the fact that dev kits have apparently been out in the wild since at least March of last year. I wonder if the T234 chip was as available back then.
I think your idea makes sense @Q-True , it could make sense if they put out T234 as dev-kits. The only question I still have regarding that is the fact that dev kits have apparently been out in the wild since at least March of last year. I wonder if the T234 chip was as available back then.
I don't see how Nintendo working with Nvidia to accomplish the following would not also involve an "increased R&D expenditure":
-help contribute to the overall Orin design
-ensure that Orin chips will meet Nintendo's needs and include the all the features they want
-that there are things built into the design to allow Nintendo to secure the volume they need and the price they want
-with prioritization to access to final compatible silicon as early as possible to help assist their own design work
LiC
Member
The alternative is that the dev kits have been big boxes with floorswept desktop Ampere GPUs and who knows what CPU and other components in them. Not impossible, but Orin was supposed to be sampling in 2021, and I think the timing could have worked out to give a few partners a devkit in the form of an Orin prototype board. Of course there's no actual evidence to support this, it's just speculation based on the presence of GA10B in NVN2.TTBOMK is on another level where abbreviations are concerned
I think your idea makes sense @Q-True , it could make sense if they put out T234 as dev-kits. The only question I still have regarding that is the fact that dev kits have apparently been out in the wild since at least March of last year. I wonder if the T234 chip was as available back then.
Foltzie
Uncle Muji
- Pronouns
- he/him
Fair, but in the DF video on the subject a DLSS pass could potentially take almost half the rendering time available for a 60FPS title.
I'm curious what the thoughts and/or details are about how that might actually work on the next Switch.
I know I dont know enough to have an actual opinion on the topic.
ReddDreadtheLead
#TeamLate2025WithAPotentialForEarly2026
- Pronouns
- He/Him
No one doubted that ORIN could work in preliminary devkits, we simply doubt ORIN is in the switch successor, Drake is a binned ORIN, and that Nintendo would take an ORIN soc (whether binned or not) because it makes less financial sense to spend so much per wafer just to use only part of it rather than simply customize a chip that only has what they need, especially when they aren't with their back against a cliff this time around.
In the long, this is less cheap to do, spending so much to take such a gargantuan die (460mm^2, binned or not) vs a 100-200mm^2 die
In the long, this is less cheap to do, spending so much to take such a gargantuan die (460mm^2, binned or not) vs a 100-200mm^2 die
Last edited:
Crusters
Koopa
- Pronouns
- He/him
While that DF video is likely a bit outdated now, it doesn't contradict what feet said.
If that version of DLSS took up half the rendering time for 60fps, and you are adamant about targeting 60fps, you will adjust to make sure you fit everything on your end, in that half of the rendering time that's left to you, to get a dlss 4k output at 60 fps. If that means some effects need to to be toned down or cut, well, that's nothing new for targeting 60fps.
Dakhil & ShaunSwitch have made the excellent point that full Orin (T239) contains AV1 encode support!
Features like hardware AVI encode/decode could be used by a future Nvidia Shield TV product!
I expect we will see future Nvidia Shield products, and I think its also reasonable that they could contain the same chip that ends up in the next Switch.(same die, unique configuration)
The contract between Nintendo and Nvidia clearly allowed Nvidia to sell the same chip and use it for other devices. We see that the T214 chip in all the newer Switch'es is also used in the newer Nvidia Shield. Same chip.
If Nintendo was concerned about secrecy and competition, they would put a "non compete" clause into their contact with Nvidia. Along the lines of "
A) Nvidia shall not compete directly with Nintendo in the portable video game space while our shared manufacturing contract is in place
B) Nvidia shall not sell the chip we have designed together to other parties for use in a competing portable video game console
C) Nvidia will not publicly share details about their involvement in our future video game products before Nintendo has publicly announced said products."
TTBOMK The Switch remains the only portable gaming system to use the TegraX1 chip.
Also the Nvidia Shield TV contains less RAM then the Switch. I don't think that is a complete accident. I think Nintendo would be scared that if Nvidia sold a cheaper mass consumer product with the identical configuration to Switch, someone might figure out how to run Switch games on it, bypassing the need for their hardware.
I think there is a proven track record of Nvidia and Nintendo working together to each ship their own products based on the same die, and I think it is reasonable that can continue with the die for the T239. Nintendo can continue to feel safe that Nvidia will not directly compete, and they are rewarded with lower per chip costs.
10k
Nintendo Switch RTX
- Pronouns
- He/Him
Hahaha. Good to know. This helps actually.
I mostly agree with this.
The TX1 came out 2 years before the Switch. It wasnt specifically developed for Nintendo. Its not known exactly when Nintendo made the decision to use the TX1.
Mariko likely woudnt have existed without Nintendo though, and Nvidia used it in shield. But there isnt a guarantee that will happen with Drake. But I agree its not outside the realm of possibility that Nvidia will use Drake in their own product, and its extremely unlikely Drake will find its way into a product that competes directly with Nintendo.
I really dont think the ram situation had anything to do with the Shield though. There is a million goood reasons to add more ram.
D
Deleted member 887
Guest
More, actually, 2/3rds by Alex's analysis. This is a really good video on the topic, but Alex is doing a lot of back of the envelope math, both for the cost of DLSS and at the potential power of a Switch Pro SoC.
The very very short version is that the leaked device seems to run DLSS 2.5x as fast as Alex guessed. If you plug that number into the rest of Alex's analysis then 4k60fps games are possible.
Reality is, of course, more complicated, as folks have pointed out.
Here is a high level explanation you didn't actually ask for.
DLSS takes a frame, makes it higher res. The higher the res of the frame before you start DLSS, the higher quality the frame after DLSS. The higher the resolution after DLSS the longer DLSS takes. DLSS runs on the Tensor cores - the faster the Tensor cores, the faster DLSS is.
So, if you want 4k60fps, your game needs to be running at a "internal" resolution high enough that the uprezzed image is acceptable and at an unlocked frame rate fast enough that when DLSS is added in, the slowdown gets you to 60fps.
The likely minimum internal resolution would be 720p - this is the bottom end of what Nvidia calls "ultra performance" mode.
The likely minimum unlocked frame rate would be 83fps - that's taking existing DLSS benchmarks from PCs, and plugging the leaked Dane numbers inside. This is a very fuzzy estimate, btw.
A game like Mario Kart 8 Deluxe, which runs at 1080p60fps in docked mode now, needs only a modest bump (if any) in the non-DLSS parts of Dane to get to to DLSS 4k60fps. A game like Hyrule Warriors: Age of Calamity, which frequently can't get to 720p already in docked mode, caps out at 30fps, and frequently dips into 20s, needs a much bigger bump in power to get there. Games that are pushing the envelope past the Current Switch's ability entirely probably aren't going to be able to hit 4k60fps on Dane.
There are a lot of costs involved in manufacturing, and there is an order of operations that the above does not fully take this into consideration.
We also know that Nintendo likes to still try and launch their new consoles at a profit, or as close to break even as possible.
Nintendo is risk/cost averse. They will compromise and look for a solution that allows them to break even at launch.
We hear talk of 50% yields per wafer on the Samsung 8nm process.
Simplified order of operations for this example:
Scenario A: Nintendo hires Nvidia to manufacture a wholly unique chip where they are the only customer and pays all associated costs at the foundry
Scenario B: Nintendo puts an order in for a chip they were consulted on, where the die has multiple uses, and only pays based on the quantity of end product they receive
| Order things happen in | Scenario A | Scenario B |
| 1. The chip is taped out and tested | Nintendo is the only customer, pay for 100% of this -$$$ | Nvidia pays for most of this |
| 2. the wafers are made in the fab based on this design | Nintendo is only customer, they pay for 100% of the wafer -$$$ | Nvidia pays and takes on risk for their customers |
| 3. Each wafer is cut up into chips and the binning process happens. With a 50% yield, half of the chips in each wafer has defects and can not be sold as a FULL chip. | Half of the chips on each wafer do not meet the minimum bar for a Nintendo T239 and as result are worthless industrial waste without a buyer. They are written off at a total loss and thrown out -$$$ Risk=HIGH as the yield is an unknown. Sometimes it will be worse. No way to calculate exactly. | 50% of the chips in each wafer have at least one defect, can not be sold as a high end Tegra product. As many as possible of the remaining 50% are binned and sold as other products with lower clocks and fewer TPCs. As much $$$ is extracted per wafer as possible. |
| 4. Sorted chips are sold off | Nintendo pays a lower price because: -the die has other customers. -they do not need the top tier clocks -they do not need all TPCs enabled Risk=LOW as costs per final chip are fixed |
It is also very possible to have a long term plan that could involve a mix of B and A after time. A way to both keep initial costs down and save money in the long term.
For example your dev kits and console launch units could ship with a binned T234 and then have large volume orders of T239s come in and replace them as you move through the cycle.
Now I bet your telling me, that sounds crazy, sell two totally different chip designs, with different transistor counts, as the identical product, just based on the supply of these chips vs the demand!
NVIDIA Ampere Example:
NVIDIA GeForce RTX 3060 GA104
NVIDIA GeForce RTX 3060 GA106
Here we have NVIDIA selling a product to customers, with the name "NVIDIA GeForce RTX 3060", with the core specs 3584 CUDA cores, 112 tensor cores and 28 RT cores.Inside you could have either the chip:
-GA106 with 13 Billion transistors
-GA104 with 17.4 Billion transistors
This is yet another example of how Nvidia designs chips to be subsets of other chips. It's truly incredible that they have designed them so they have the option to take a binned GA104 and sell it as a GA106!
This opens up lots of options, so that they have more flexibility! Ultimately this allows Nvidia to be less wasteful, and sell more of what is in demand quickly.
We should all celebrate binning, as it's better for the environment, allowing us to make more final products from the same amount natural resources!
Look over there
Bob-omb
To satisfy my own curiosity to a limited extent on eUFS power consumption, I did find this. The chart on that page cites ~1.6W for eUFS 2.1/2.2 and ~1.8W for eUFS 3.0/3.1. It also cites up to 1.5W for eMMC.
That may sound a little funky, since we've seen 0.5W cited for Samsung's eMMC. And pdfs I've seen for a couple of other vendors' eMMC also land at 0.5W or a little less.
My suspicion regarding that is that the table is citing maximum power draw (that is, when operating at 85 Celsius), whereas ~0.5W should be for typical conditions (that is, ~25 Celsius).
A pdf I may have found for Toshiba's eUFS 2.1 does cite maximum operating currents. If I were to trust that pdf, the max values it gives (again, at 85 Celsius) for when 2 lanes are used are 200 milliamperes for lcc and 475 milliamperes for lcc2. VCC's 3.6V (for the NAND chips) and VCCQ2's 1.95V (for the controller + interfaces). 3.6V*0.2A + 1.95V*0.475A~=1.646W, which lines up with that Phison blog. Annoyingly, the pdf doesn't list currents for when active while under typical conditions/@25 Celsius. Nor is voltage listed, but by spec, typical voltages are probably 3.3V for VCC and 1.8V for VCCQ2.
Funny enough, for sleep mode, typical and max currents are listed. lccs+lccsq2 are listed with typical of 350 microamperes and max of 3505 microamperes; practically ~10x difference o.o
Anybody else willing to assume that if UFS's current behavior remains similar to eMMC, then for typical/@25 Celsius, power consumption's roughly 1/3 of the max/@85 Celsius values?
That may sound a little funky, since we've seen 0.5W cited for Samsung's eMMC. And pdfs I've seen for a couple of other vendors' eMMC also land at 0.5W or a little less.
My suspicion regarding that is that the table is citing maximum power draw (that is, when operating at 85 Celsius), whereas ~0.5W should be for typical conditions (that is, ~25 Celsius).
A pdf I may have found for Toshiba's eUFS 2.1 does cite maximum operating currents. If I were to trust that pdf, the max values it gives (again, at 85 Celsius) for when 2 lanes are used are 200 milliamperes for lcc and 475 milliamperes for lcc2. VCC's 3.6V (for the NAND chips) and VCCQ2's 1.95V (for the controller + interfaces). 3.6V*0.2A + 1.95V*0.475A~=1.646W, which lines up with that Phison blog. Annoyingly, the pdf doesn't list currents for when active while under typical conditions/@25 Celsius. Nor is voltage listed, but by spec, typical voltages are probably 3.3V for VCC and 1.8V for VCCQ2.
Funny enough, for sleep mode, typical and max currents are listed. lccs+lccsq2 are listed with typical of 350 microamperes and max of 3505 microamperes; practically ~10x difference o.o
Anybody else willing to assume that if UFS's current behavior remains similar to eMMC, then for typical/@25 Celsius, power consumption's roughly 1/3 of the max/@85 Celsius values?
Last edited:
SiG
Chain Chomp
Actually base TegraX1 had only 3GB of RAM to begin with. I believe it was Capcom who convinced Nintendo to up the specs to 4GB.
They could be doing a similar RAM spec bump over a base GA10F configuration, depending on developer feedback.
BlueManifest
Bob-omb
Whatever happened to the nvidia hackers did they just quit and act like nothing ever happened?
BlueKing
Shriekbat
They got arrested.
BlueManifest
Bob-omb
Really? I missed that
D
Deleted member 1141
Guest
I must've missed the reports on this.
Checking up, it was reported on BBC about four days ago.
Lapsus$: Oxford teen accused of being multi-millionaire cyber-criminal
Police say they've arrested seven teenagers as part of their investigation into a hacking group.
www.bbc.com
Article has more too.
NintenDuvo
The Baby
- Pronouns
- He him
oh wow Nate with the burn lol but yeah i been stopped following SMD after his reaction to the Nintendo Switch reveal, the guy is a complete charlatan
OP
OP
Actually, Orin is T234. Drake is T239.
Any murmurs coming from GDC 2022 probably won't be reported on until a couple of weeks after GDC 2022.
Nvidia already has a way to sell binned t234s it’s called Orin NX.
Will they find a way sell binned t239? It’s possible that’s what nano next is.
Your example with the rtx 3060 works because PC is a platform where size and form factor constraints isn’t a huge issue. You can get away with a lot more. I have a hard time seeing them pull that off in a compact little tablet such as the switch.
It means they would have to design the device around the t234.
Last edited:
Alovon11
Like Like
- Pronouns
- He/Them
Again, binning is a bit of an unfounded idea in relation to Drake as GA10F IS its own GPU die.
The G106 and GA104 3060's are not binns of each other, they are separate silicon branches that happen to have an overlap where the 3060 is (Same with the rumored GA107 Desktop 3050 or the GA103 RTX 3070.etc)
GA102, GA103, GA104, GA106, and GA107 are separate silicon branch chips formed from the highest end then binned down to their respective GPU SKUs, the fact that there is overlap doesn't mean GA017 = Binned GA016.
It's the same case with GA10B and GA10F, a separate GA10# designation means that chip is being designed from scratch to that rated SM count.
So all GA10B's start at 16SMs, and all GA10F's (to our knowledge) start at 12SMs
Then you bin down from there.
So Drake/T239/GA10F physically can not be a binn of GA10B, not to mention that GA10F and GA10B have different GPC/TPC layouts which makes it physically impossible to even consider GA10F as a binned version of GA10B.
So T234 (Orin, GA10B) and T239 (Drake, GA10F) are about as related as the Tegra X1 was to Desktop Maxwell, aka connected, but with notable feature differentiation in the design.
So when you have an unseen/unreleased GPU die in the NVN2-API data that has it's own branch offs from GA10B, and considering this is a game console and T239 is Customized by Nintendo, it is just likely that Orin was used as a devkit at some point in the development of NVN2 and GA10F is the actual silicon that will be used in the Drake SoC.
And with the 12SM count in the NVN2 API that means that 12SMS, aka 1536 CUDA cores and all that, is the amount of processing power we have for Drake, Binn or otherwise.
And the problem with a Lite using a binned T239 is that'd require a whole new optimization pass as the cut-down silicon would need to be clocked differently to run portable mode Drake games like the full T239 die could.
It's unesceary busywork.
The chip designation doesn't change when it gets binned. A GA104 is still a GA104 regardless of how much of it is enabled.
This is how we know Drake isn't a binned version of Orin. The chip has a different designation (GA10F instead of GA10B).
Last edited by a moderator:
