• Hey everyone, staff have documented a list of banned content and subject matter that we feel are not consistent with site values, and don't make sense to host discussion of on Famiboards. This list (and the relevant reasoning per item) is viewable here.

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

Oh, so it’s the same info as before?

These last couple of pages seemed kinda optimistic on the released date and the power level seemed better than before.

Oh well.
It makes sense to release it this year for a number of reasons but there are still very few concrete rumors about release timing.

As for power, since it leaked last year it's been known that it was a massive upgrade. Nothing really has changed there, just some people being more/less optimistic on the clock speeds.
 
It makes sense to release it this year for a number of reasons but there are still very few concrete rumors about release timing.

As for power, since it leaked last year it's been known that it was a massive upgrade. Nothing really has changed there, just some people being more/less optimistic on the clock speeds.

Ah, okay then.

Thank you!
 
I think "We Don't Talk About Bruno" might be the best short video at showing the benefits of ray-tracing.



The sheer amount of complex lighting situations that happen in this short segment are breathtaking.

A lot of games don't really benefit from ray-tracing because the games are designed around very simplistic lighting situations that can be handled without ray-tracing so there's not a lot of benefit.
 
Lovelace-derivative SoC would surely confirm a 5nm (4nm) process, as that's what it starts on, IIRC.
Drake most likely uses an Ampere based GPU, not an Ada Lovelace based GPU, especially with Drake's GPU inheriting the Tensor cores from consumer Ampere GPUs, and the only known feature Orin and Drake inherited from Ada Lovelace GPUs is AV1 encode support. (Drake does inherit Orin's Optical Flow Accelerators (OFA) (here and here), but how comparable Drake's OFA is to Ada Lovelace's OFA is unknown.)

Hidden content is only available for registered users. Sharing it outside of Famiboards is subject to moderation.
Hidden content is only available for registered users. Sharing it outside of Famiboards is subject to moderation.
 
There is evidence that even though Drake is Ampere based architecture, it would receive some ADA Lovelace features. This is similar to how the Maxwell architecture for the Tegra X1 had features that Nvidia hadnt implemented into their graphics card lineup until they moved on to the Pascal architecture. Drake uses customized architecture regardless, and at this point if some customizations are needed for complete Maxwell shader support within the hardware, it seems to me that Nvidia is capable of doing that. If you can add in features from Ada into the Ampere architecture, why not Maxwell?
 
Video is up. Don't think I can self advertise, but I figured I would let you guys know given that fami helped make the video happen! Thanks guys.

Doesn't have the fanciest of editing as I am waiting on my mac studio to arrive and using an underpowered laptop right now, but I hope I did a good job. When I revisit the topic in the future with updates were going to have all sorts of fancy graph and other stuff. Just waiting on the new computer!
 
* Hidden text: cannot be quoted. *
[/HIDE]
Hidden content is only available for registered users. Sharing it outside of Famiboards is subject to moderation.

* Hidden text: cannot be quoted. *
Hidden content is only available for registered users. Sharing it outside of Famiboards is subject to moderation.


* Hidden text: cannot be quoted. *
[/HIDE]
Hidden content is only available for registered users. Sharing it outside of Famiboards is subject to moderation.
 
Why?

Switch has done just fine with super demanding games. TW3 is an enormous open world, if that can run decently then what's stopping a fairly linear FPS?

I don't believe for one second that COD is "special" in such a way that porting it would be impossible or lead to horrible results, the reason it has not yet happened is purely due to publisher politics. And file size I guess.


I mean Warzone, not CoD MP. Warzone struggles on PS4 and Xbox One. I just think the compromises would be too vast for it to run well on Switch. I dunno if Apex Legends is a good benchmark, but if they could hit that performance after all them patches consistently then that would be a win.
 
Video is up. Don't think I can self advertise, but I figured I would let you guys know given that fami helped make the video happen! Thanks guys.

Doesn't have the fanciest of editing as I am waiting on my mac studio to arrive and using an underpowered laptop right now, but I hope I did a good job. When I revisit the topic in the future with updates were going to have all sorts of fancy graph and other stuff. Just waiting on the new computer!
"How is Nintendo doing that without charging 500 or 600 dollars?!"

Well... they might be.
 
I think "We Don't Talk About Bruno" might be the best short video at showing the benefits of ray-tracing.



The sheer amount of complex lighting situations that happen in this short segment are breathtaking.

A lot of games don't really benefit from ray-tracing because the games are designed around very simplistic lighting situations that can be handled without ray-tracing so there's not a lot of benefit.

Disney Animation Studios are absolute masters.

But its also a movie that was not rendered in real time.
 
"How is Nintendo doing that without charging 500 or 600 dollars?!"

Well... they might be.
I feel the $399 price is the most likely, but I cant completely write off a $499 price if Nintendo plans on continuing to offer the OG Switch for a couple more years with most titles being cross gen. Its a lot easier to maintain the current Switch OLED price at $350 if the next Switch will launch at $499. I suspect that price would be just fine for year one, but they will really have to market this thing as a powerful premium product.
 
"How is Nintendo doing that without charging 500 or 600 dollars?!"

Well... they might be.
I don't think they will. I know it's a new president so we never know, I just think they won't go above $399.99. I think they can hit that price too and still make SOME money. Not much. Maybe only $10 profit per system, but that's profitable.
 
I don't think they will. I know it's a new president so we never know, I just think they won't go above $399.99. I think they can hit that price too and still make SOME money. Not much. Maybe only $10 profit per system, but that's profitable.
I'm totally with you and agree. There is still that distinct possibility they would go for it though lol. Let's hope not.
 
Wait… So I haven’t been checking this forum as much lately (work, school, etc.).

I come back and now it seems like everyone is convinced that not only will the new Switch be pretty powerful (compared to the original Switch), but it will also be released this year as well???

How much have I missed?! xD

I personally still think that it will be revealed this year and released the next.
 
Video is up. Don't think I can self advertise, but I figured I would let you guys know given that fami helped make the video happen! Thanks guys.

Doesn't have the fanciest of editing as I am waiting on my mac studio to arrive and using an underpowered laptop right now, but I hope I did a good job. When I revisit the topic in the future with updates were going to have all sorts of fancy graph and other stuff. Just waiting on the new computer!
Good job, enjoyed it.
 
You are incorrect, but it's a common mistake. Let's also clarify what we mean by HAL. HAL has at least three meanings in the context of an Nvidia driver. HAL is a term of art in the Windows NT kernel and all drivers have to interact with the HAL. HAL also refers to a hardware block in a modern Nvidia GPU which facilitates the UDA. And HAL is also the term used to refer to the software layer inside the driver that communicates with the HAL block on chip.
It should be obvious that the HAL we're referring to is the UDA specific HAL. You're assuming I don't know what a HAL is. By my phrasing I can see how one might assume I don't what HALs are. I had assumed that because of the context of the discussion that I don't need to specify which specific HAL I'm talking about.
A driver lives in either ring 0 or, in the case of microkernals, ring 1. Meaning that they run in the most privileged parts of the system and have sufficient permissions to talk directly to the underlying hardware.

A driver implements a generic software layer that applications which don't live in those privileged rings can use to talk to the hardware in a standard way regardless of which specific piece of hardware is underneath. In the case of a video driver, a huge component of this driver is effectively a complete Graphics API implementation, like DirectX, or NVN, or OpenGL.

The vast majority of this stack is generic across devices. The majority of a DirextX implementation is the same regardless of the hardware. Beneath that, most pieces of hardware from the same vendor have the same structure. An Nvidia GPU might have 20 SMs or 80 SMs, but the SMs operate the same. An Nvidia GPU might have an Optical Flow Accelerator which runs the same microcode, but lives at a different interrupt location on chip.

One way to handle drivers is to have templated piece of software, and when a new GPU is made, all you have to do is plug in all these few thousand facts about the GPU, update the various bits of microcode, and then build your new driver binary.

The innovation of the UDA is to actually take all those facts and plug them into a hardware block on the physical GPU itself, and make sure that the hardware block lives in the exact same location on every single GPU you make. When the driver loads, it goes to a known location on chip, loads up the all those facts, populates them into internal tables, and then makes them available to the generic portions of the driver code.

Critically - the driver doesn't need to query the HAL. If the HAL was, instead, a hardware block that gated all access to the underlying hardware it would be a huge performance bottleneck, and new drivers would have trouble adding new features. Instead if it just knows all of these facts about the hardware it can skip the HAL entirely.

It doesn't matter if the Tegra chips still have the HAL hardware block in place if the driver doesn't use it. And if a driver doesn't use it, and it gets moved to a new piece of hardware, the fact that the NEW device has a HAL is irrelevant, because the software portion will ignore it anyway.

You can run a decompiler over a Nintendo Switch game and plainly see the embedded driver level Maxwell microcode and interrupt addresses. Facts that are normally queried from the HAL are hard coded into video games.

Nintendo Switch games cannot directly initialize a non Maxwell GPU. On a Maxwell GPU, they cannot address more than the two SMs that are in the TX1. And they cannot use NVENV, NVDEC, and OFA on Maxwell GPUs where those live at different interrupt/bus addresses than the TX1s."
.
I understand how drivers and ring 0 work. You don't need to explain this to me. Although others may find it useful. (Sidenote: Anti cheat using Ring 0 is unsafe and unnecessary, they can do their job without accessing ring 0, where mostly only drivers should be. Your anti virus doesn't even need ring 0 access to do its job.)
.
I was touching on not needing the HAL per sey by talking about the unified instruction set. Which means that the next gen chips after X1 still use the same core instructions as a foundation. Because of the unified instructions a lot issues are already mitigated in advance. The Maxwell drivers on the Switch don't need to initialize a PC GPU. And if it does or not doesn't really matter. It needs to initialize the Tegra SoC versions, not PC GPUs. Telling me it won't work on a PC GPU natively doesn't mean much. Of course it won't, its on ARM, not x86. If the Maxwell code can't initialize the ARM version of Orin then you have my attention. I would not expect it to initialize any non ARM hardware. The fact that it can at all speaks highly for the UDA's capabilities.
.
I guess I assumed that it would be understood that the UDA gets adapted to ARM so the ARM version of UDA isn't going to 1:1 with the Windows version. Which doesn't really matter, and isn't the point. The point is that the UDA is too valuable too lose. I don't see Nvidia ditching it when it can help them sell chips to vendors. Yes, the ARM version is going to be specific to ARM, that should be implicit.
.
Well, it actually isn't, since that isn't what the word Appeal means, but I think arguing about the definition of Appeal to Authority is beyond the scope of the discussion, and will end in looking at a dictionary - in other words, an appeal to an authority :)

Fortunately, I don't need an authority on the subject, as I have confirmed this fact about the drivers myself. You are welcome to perform the same process if you doubt my authority, that's perfectly valid. Just as I doubt your authority based on having read the patent paper.

Appeal to Authority is the correct and proper name for that logical/formal fallacy. You're nitpicking semantics and creating a strawperson fallacy.
In logical and formal argumentation it is a fallacy to use authority as proof. Below are sources that explain the fallacy. It's worthwhile to educate yourself about formal fallacies and logical argumentation.




This is factually inaccurate. The first is, again, you can plainly see the Maxwell microcode when you extract it from published Nintendo games. You don't need to go to the Dark Web and look up leaked internal Nvidia documentation on the Switch's shader compiler to verify that it doesn't include the UDA ISA by default, but that would be another way of doing it.

Switch games do not use the UDAs ISA, they use raw Maxwell microcode. And Ampere does remove some of those instructions. Ampere cannot run all Maxwell shaders without changes. Nvidia's doesn't document their full shader ISA, but they do document the the fact that there are breaking changes between the architectures.

In fact, games on PC don't use the UDA ISA. They use GLSL or and equivalent, because the UDA ISA is only supported by Nvidia, and Elden Ring would like to run on your AMD box as well. The value of the UDA is in large scale data center applications where the overhead of a shader compile is quickly lost in long running GPU compute operations.

I am not aware of Nvidia referring to the Unified Instruction set as a "UDA ISA." Can you show a reference where Nvidia uses that terminology? It is the first I've seen it.

As I understand the unified instruction set the maxwell microcode inherently uses the unified instructions. The unified instruction set is core to the Nvidia architecture. The Unified instructions are at all levels. Otherwise we would need a specific driver for every new GPU generation like the before fore times.

You keep fixating on shaders specifically. They are important and all. But there is a lot more going on with GPUs than shaders. What about vertex calls, rasterization calls, etc?

Did you read the patents? They address microcode, etc.

Example:

"Unified microcode assembler 240 converts the shader program assembly instructions in vertex shader program 215 and fragment shader program 220 into microcode for execution by vertex processing unit 255 and fragment processing unit 260, respectively. GPU unified microcode assembler 240 is configured to operate in a runtime mode in order to output the shader microcode to the appropriate execution unit within graphics processor 250 as the shader microcode is generated. GPU unified microcode assembler 240 determines which of the execution units within graphics processor 250, e.g., vertex processing unit 255 and fragment processing unit 260, a shader program targets and includes domain specific interfaces corresponding to the inputs and outputs of the target execution unit. In some embodiments of the present invention, the target execution unit is identified by a header or tag in the shader program, e.g., vertex shader program 215 and fragment shader program 220. Vertex processing unit 255 and fragment processing unit 260 execute the shader microcode produced by GPU unified microcode assembler 240 and graphics processor 250 outputs processed graphics data 270."

Source: https://patents.google.com/patent/US8154554B1/en - "Unified assembly instruction set for graphics processing"
The UDA isn't a thing you can remove, it is a methodology. If you are referring to the HAL on hardware, I'm not saying it's gone either. I am saying that decompilation clearly demonstrates that the HAL isn't used by Nintendo Switch games.

The Nintendo Switch uses a single flat memory pool for both the System and the GPU. For performance reasons, games on Switch have access to privileges not available to games on PC. The side effect of this model is that the game - application code - is responsible for managing a number of resources that are usually contained inside the kernel driver or an external Graphics API Library, including the memory pool.

Using the HAL and generalizing that code causes games to allocate larger pools of memory than are necessary on Switch, to invoke a CPU intensive compile operation for shader code, and to insulate developers who know the exact hardware profile they are targetting to go around their ass to the get their elbow to make optimizations (like number of work queues) that simply not using the HAL would make easy.

There is a significant performance win for building the API/Driver architecture this way, and is one of the reasons that consoles generally are able to deliver the kind of performance they do - for an example of what happens with identical hardware on HAL based driver stack, look no further than the Nvidia Shield, which runs Android, versus similar games running on the Switch, and both using the TX1.

You don't need to use the HAL if you're using the same hardware...
Of course the HAL is not in use right now. There's no need to use it.

The UDA is more than a methodology. It's core component of the Nvidia architecture. The Unified instructions set means that the UDA is more than a simple methodology. It is patented as an invention, not a process. And that matters.

Again, of course they're going to adjust things specifically for ARM and not do it how windows does it. Of course the UDA will need to be adapted.

The fact that a switch game can initialize a Maxwell GPU for PCs says a ton about how versatile and useful the UDA is.

The reason that is even possible is because of the UDA. I did not even know that a Switch game can initialize a Maxwell GPU until you mentioned it. I assumed that wouldn't happen because ARM isn't x86.

Also reframe this and remember this is a much more powerful SoC running much older games. I think it's safe to presume that the new Switch will have enough headroom that the HAL helping out with old games won't be too much overhead. Remember that because of the limits of the X1 they super slimmed a lot down. We can not assume that the new Switch will do the same. You're kind of assuming the new Switch will have the same limits as the old one. And putting everything in that frame.
 
* Hidden text: cannot be quoted. *
This doesn’t need to be hidden here anymore, so I’ll avoid using it for this part. Yes those were custom built for Nintendo, but it was a multi chip design that had a PowerPC CPU and an ATI GPU.

Wii U used an AMD GPU (AMD acquired ATI) that put the Wii/GCN GPU and caches inside the Wii U GPU. The CPU was the same, but tripled and added cache. So, when the Wii U entered vWii mode it just didn’t use the other cores or the rest of the Wii U GPU. The Wii U really has a whole Wii inside it, and you’d need to mod it just so that you can play GCN games on it (digitally though, no drive for mini disc) since it has a Wii in it, baked into the silicon. The Wii games only saw what the Wii used.

The GCN and Wii aren’t that different, the latter is clocked higher and uses different memory and more of it, but otherwise the Wii is just a GCN pro. It’s not a joke to say there that the best comparison I can put for it is that the Wii is to the GCN what the GameBoy Color is to the GameBoy original. That’s how different they are in the general sense, ie, not much.

Most games are multiplat yeah, and they communicate with the API that communicates with the hardware, but PC isn’t a fixed platform like a console so there’s nothing to really fix it to. A console they know how or what it’ll do and it’ll have even lower level access than a PC can.

NVN, GNM and the XB version of DX12 is a very thin layer from the hardware as it’s the only place they are meant for.


That said these days games aren’t coded to the metal (anymore I think? Unless there’s a rare exception to extract more performance). But I remember a dev on Era mentioned that it wasn’t uncommon for devs to “go out of spec” in development, so who knows?


Anyway, they’d aim to get the lowest percentage but basically, just including the 2 Maxwell SM into the Drake SoC doesn’t automatically guarantee that it’ll be the lowest, there’s still work required regardless of what they choose.
 
Last edited:
This doesn’t need to be hidden here anymore, so I’ll avoid using it for this part. Yes those were custom built for Nintendo, but it was a multi chip design that had a PowerPC CPU and an ATI GPU.

Wii U used an AMD GPU (AMD acquired ATI) that put the Wii/GCN GPU and caches inside the Wii U GPU. The CPU was the same, but tripled and added cache. So, when the Wii U entered vWii mode it just didn’t use the other cores or the rest of the Wii U GPU. The Wii U really has a whole Wii inside it, and you’d need to mod it you can just play GCN games on it since it has a Wii in it, baked into the silicon. The Wii games only saw what the Wii used.

The GCN and Wii aren’t that different, the latter is clocked higher and uses different memory and more of it, but otherwise the Wii is just a GCN pro. It’s not a joke here but the bets comparison I can put is that the Wii is to the GCN what the GameBoy Color is to the GameBoy original. That’s how different they are in the general sense.

Most games are multiplat yeah, and they communicate with the API that communicates with the hardware, but PC isn’t a fixed platform like a console so there’s nothing to really fix it to. A console they know how or what it’ll do and it’ll have even lower level access than a PC can.

NVN, GNM and the XB version of DX12 is a very thin layer from the hardware as it’s the only place they are meant for.


That said these days games aren’t coded to the metal (anymore I think? Unless there’s a rare exception to extract more performance). But I remember a dev on Era mentioned that it wasn’t uncommon for devs to “go out of spec” in development, so who knows?


Anyway, they’d aim to get the lowest percentage but basically, just including the 2 Maxwell SM into the Drake SoC doesn’t automatically guarantee that it’ll be the lowest, there’s still work required regardless of what they choose.
Isn't already the case that... Drake doesn't have Maxwell SMs, full stop?

I'm certain backwards compatibility will be a software solution, rather than a hardware one. Extra silicon doesn't have any evidence to support it, would complciate development, would drive up power consumption and BOM, and Nvidia already has experience building virtualization environments for their hardware. Again, including Switch virtualization, which is included in the SDK.
 
I mean Warzone, not CoD MP. Warzone struggles on PS4 and Xbox One. I just think the compromises would be too vast for it to run well on Switch. I dunno if Apex Legends is a good benchmark, but if they could hit that performance after all them patches consistently then that would be a win.
There has been games in the past that struggled on ps4, Xbox that were ported to switch and run fine with little compromise. Can’t list them off the top of my head but they are out there. I don’t think cod will be any different
 
Good job, enjoyed it.
Thanks. As I said once I am back up and running with the mac studio, next time I cover it when updated we'll dive deep into some fancy graphics, comparison charts, and all that to help visualize it. I plan to really up the editing on my videos with that sort of stuff once I get my grip on Final Cut since I'm also switching away from Premier at the same time. Should figure it out pretty quick, already been watching tutorials.
 
Video is up. Don't think I can self advertise, but I figured I would let you guys know given that fami helped make the video happen! Thanks guys.

Doesn't have the fanciest of editing as I am waiting on my mac studio to arrive and using an underpowered laptop right now, but I hope I did a good job. When I revisit the topic in the future with updates were going to have all sorts of fancy graph and other stuff. Just waiting on the new computer!
You should donate a portion of the advertising revenue to Famiboards 😊
 
Just caught nintendo primes video on youtube. Wow if these numbers are accurate to what they release and they can pull off backwards compatibility, buy your Nintendo stock now while its cheap!
 
@NintendoPrime @oldpuck @Alovon11 @Dakhil @LiC @Thraktor @ReddDreadtheLead (just naming people who can check my work here, I got 3 hours of sleep and am powering through work on my second cup of coffee right now)

I recommend scrolling to the bottom and reading the TL;DR: first. It should give the immediate answers, if there is more questions about other aspects of the hardware, or if my explanation is long winded/not clear, please @me.

In order to understand the upgrade "Switch 2" offers, we first need to look at Switch specs:

CPU-


TX1 ARM, 4 A57 cores @1GHz (one core reserved for the OS)
T239 ARM, 8*A78C cores ~1GHz-2GHz (one core reserved for the OS)

Upgraded result to CPU:
A78 is 3 times faster than A57 cores per clock, giving between a 7 times and 14 times performance jump, A78 cores are also faster than Ryzen 2 cores used in PS5/XBS per clock, but clocked much lower, so a 2GHz clock would result in somewhere above 50% of the CPU resources found in PS5/XBS, and far beyond last gen consoles.

When compared to Steam Deck, Steam Deck has 4 cores and 8 threads, while Drake has 8 cores/threads, if Drake is clocked at 2GHz, it would offer a similar CPU resource to Steam Deck, although Steam Deck's CPUs clock to 3.5GHz, because pairs of threads share resources between each core, the overall performance drops here, with somewhere in the neighborhood of 70-80% of having 8 cores at that clock, Drake's 2GHz cores would offer ~70% of 8 cores at 3.5GHz so while Steam Deck has more CPU performance, but it shouldn't be by very much.


RAM-


TX1 4GB 64bit LPDDR4/LPDDR4X ~20GB/s in handheld mode, 25.6GB/s docked (~800MB reserved for os iirc)
T239 8GB to 16GB 128bit LPDDR5(x?) over 60GB/s in handheld mode, up to 102GB/s (137GB/s if lpddr5x).

Upgraded result to the RAM:
3.2GB RAM @20-25GB/s vs 7-15GB RAM @60-102GB/s, we are talking about 3 to 4 times the capacity and speed of Switch, 12GB is probably the most realistic capacity.

102GB/s would be around PS4's 176GB/s RAM speed when architecture advantage is taken into account, as these architectures are far more bandwidth efficient. This should allow for third parties to bring their games forward onto the platform without much problem, bandwidth is less an issue of direct comparison with other devices, and more about individual system's available bandwidth, this is about preventing bottlenecks, rather than increasing performance, so hard to say how this compares to current gen consoles, Steam Deck for instance has 88GB/s of memory bandwidth, but it's a good balance for that system.


Storage-


While storage is unknown, what we do know is the range of storage that could be used:
First, Switch's internal storage is 100MB/s, it uses EMMC.
When compared to Drake, EMMC actually has a speed of 400MB/s, so if it uses this type of memory, expect a 4 times increase in read speeds.

UFS is also a type of storage that could be used, here the minimum speed is twice as fast, and could easily match XBS internal storage if needed.


Load times-


This is a reflection of above's specs, it also would have something to do with the decompression block found in Drake, but lets just go over minimum gains, as that is where we should discuss this, and we will also only be talking about Switch gen 1 titles, because next gen titles we have no real idea about.

If you run across a Switch game (not in the cloud) that takes 30 seconds to load, Drake should load that same data in 7 seconds or less. Most Switch games load in about half that time, so here we are talking about ~3 seconds on Drake. It could be faster if it does use UFS, and there will always be rare hiccups where games just take longer to load, but the direct comparison here is over 4 times faster than Switch.


GPU-


TX1 256 Maxwell cuda cores @ 460MHz and 768MHz for 235GFLOPs and 393GFLOPs
T239 1536 Ampere cuda cores @ 660MHz* and 1125MHz* for 2TFLOPs and 3.456TFLOPs, 48 Tensor cores, 12 RT cores

TX1 Maxwell is a 2015 design that is the 3rd iteration of Maxwell, much closer to Pascal architecture, borrowing most noteably 16fp at 2:1 cuda cores, or twice the flops at half the precision.

Ampere is over half a decade newer, it has mesh shaders, VRS, and a slew of other GPU features, that increase raw speed beyond what paper math can tell you, I'll discuss DLSS a little later, because it's much clearer to see what it offers if we separate it from the other GPU features.

Drake's GPU is 6 times bigger than Switch's, in handheld mode given these speculative (possibly real) clocks, it would out perform PS4 before DLSS is used, again even beyond just having more raw performance over the PS4, it also has those GPU features that the 2011 GPU architecture found in PS4, is lacking. VRS is said to offer a 20% increase in performance, and mesh/geometry shaders, can offer 25% increase in performance as well, just these do features combined can add 50% performance increase to the same architecture per flop. Comparing GCN to Ampere is much less precise, but we can look at the raw performance here and conclude that Drake > PS4. “if the engine supports the features that is, which will enable the game to make use of it. However, even if these aren’t accounted for there’s been a decade of improvements between architectures of the early 2010s and architectures now, Drake should be ahead, and if all things are considered it should be more efficient at doing the job if enabling other unique features” -Redddeadthelead

When compared to Steam Deck's RDNA GPU, it has these features and while the GPU is generally clocked lower for 1.3TFLOPs, it can reach 1.6TFLOPs, and it does have these features, as well as a flop advantage over Ampere in PCs, however in a closed environment, Ampere should pick up ground, I'd put 1.6TFLOPs Steam Deck around the same as a 660MHz clocked (2TFLOPs) Drake GPU, before DLSS is applied. Once DLSS is applied, it can significantly drop the required performance and offer a higher resolution, and if Drake is capable of frame generation, it could further expand this lead, basically a PS4 Pro to XB1X in your hands at the very best, however it's best to just think of it as a Steam Deck with DLSS on top. (Steam Deck is also a poor FSR2 system, so it really can't offer it's own competitive upscaling tech).

When docked, Drake at 1.125GHz offers 3.456TFLOPs, this should be similar to XBSS' 4TFLOPs. DLSS should help it match whatever XBSS can do with FSR2, and if it comes with 12GB or more RAM, it might actually have less of a RAM issue than XBSS, even though the RAM is half as fast, because RAM speed is more about bottlenecks as I discussed above.


The TL;DR
Drake's CPU is somewhere around Steam Decks, slower, but in the ballpark. (more cores, same threads, less clock) ~85% of SD?
Drake's GPU in handheld should offer similar, but better performance over Steam Deck, ~130-200%
Drake's GPU in docked should match or exceed XBSS, thanks to DLSS being superior to FSR2. ~80-100%
Drake's RAM is 3 to 4 times the capacity and speed of Switch's, and should fit well with current gen consoles.
Drake's Storage is at least 4 times faster than Switch's and load times should shrink in Switch gen 1 games by over 4 times.
Man as much as I love what I'm reading, it sounds like stuff you'd see in a home console. I doubt we'd see higher than current Switch clocks in the next Switch. So around 1.4tf portable - 2tf docked sounds more feasible and believable.
 
Yup that’s one

.............................................. Nier Automata's original release did not have hyper competent programming as the series was extremely small. This is best shown by the PC release being fucking horrific at launch.

By the time the Switch port started development, Nier was a much higher priority for Square.

The comparison is very weird. Call of Duty is as optimized as possible on every platform it's launched on.
 
If you believe Call of Duty can be losslessly compressed 50% (very optimistic and something that will be very hard to do while still having good framerates and load times)

You end up with a 125 GB file size, lol.

Activision also clearly believes that Call of Duty sucks at less than rock-solid 60 FPS. You're going to have to make some truly heroic graphical compromises to get this file size to 50 GBs while maintaining 60 FPS.
They may split it up into separate downloads so people only play the modes they want, but at the end of the day, having the full experience would require at least a 256 GB micro SD. It's also likely there's just a lot of junk data and that work has already been done.

As a reference Warframe is 35 GB on Steam and 20.5 GB on Switch so its around 60% the size and that can probably be culled to remove old data, which the devs will occasionally do.
 
They may split it up into separate downloads so people only play the modes they want, but at the end of the day, having the full experience would require at least a 256 GB micro SD. It's also likely there's just a lot of junk data and that work has already been done.

As a reference Warframe is 35 GB on Steam and 20.5 GB on Switch so its around 60% the size and that can probably be culled to remove old data, which the devs will occasionally do.
I mean on base Switch it would only be downloading one set of extremely low res, compressed textures, Vs PC where it downloads many different textures at absurd resolutions and (almost) no compression.
 
0
Man as much as I love what I'm reading, it sounds like stuff you'd see in a home console. I doubt we'd see higher than current Switch clocks in the next Switch. So around 1.4tf portable - 2tf docked sounds more feasible and believable.
I have been the “same clocks” cheerleader for a while, so I tend to agree. But even that would be in the ~2.3TF region docked, so you're still underestimating a bit.

While I am more conservative than @Z0m3le on his clock numbers, he isn't making them up. He does have a source for them - I disagree on his interpretation of that source, but it isn't an arbitrary pick.

There is also some reason to think that Nvidia and Nintendo have gone to a better-than-Orin process node. At that point these 50% increases over the Switch's clocks start to look pretty reasonable in terms of power draw.
 
Quoted by: TLZ
1
Looking at the comments on NintyPrime's video and it's kinda shocking how few people understand the power of the Series S. There are folks in there saying that it will be an Xbox One X, but with more modern features, not a Series S.

My friend, if you update the One X with more modern features, you get a machine that would eat the Series S for breakfast.
 
Looking at the comments on NintyPrime's video and it's kinda shocking how few people understand the power of the Series S. There are folks in there saying that it will be an Xbox One X, but with more modern features, not a Series S.

My friend, if you update the One X with more modern features, you get a machine that would eat the Series S for breakfast.
Are you suggesting the Switch [REDACTED] will eat a Series S for breakfast, or that it will be basically a Series S?

Personally I'm on the side of the eating-of-breakfast, the math just works out like that. 2.4TF with DLSS is a PS5 lookalike, not a Series S. 3.5TF... and... Yeah, look out Xbox Series X. You might be the most powerful but you might struggle with the framerate where the nimble Nintendo doesn't, even if it has to smash the internal res back to 2010 to do it.

That said I think it'll be TREATED more like a One X by Nintendo and initially by third parties, getting Xbox One/PS4/Switch 1 games with very little changes except for a massively increased resolution. I think it'll take a couple years for it to show its true colours.

I think the reality will probably be pretty straightforward:

Series S assets, with a lower internal resolution, but with lashings of upscaling, making it "look" more capable, while not being so.

Watch at least one outlet call it a "portable PS5" around launch.
 
I welcome the day where "because Nintendo" will stop being used as justification for arbitrary lowballing or wacky meme predictions that defy business logic.
 
Last edited:
I think that oldpuck's referring to how if you take something the size of the One X but update its stuff, it's actually rather a beast.

For example, keep the 384-bit memory bus width, but update from GDDR5 to GDDR6. Keep the 40 CU's, but update from GCN to RDNA2, bump the clock up thanks to node + RDNA2 changes (to compare, the Series S is 20 CU's and Series X is 52 CU's). Update the CPU.
...actually, the 384-bit bus would be rather ludicrous with GDDR6; that's wider than the Series X (320-bit), for example. (Series S is 160-bit wide)
 
I am curious as to why Microsoft opted for such a design. What advantage is that supposed to bring over keeping all 5 modules together and logically partition away the OS chunk?
 
I am curious as to why Microsoft opted for such a design. What advantage is that supposed to bring over keeping all 5 modules together and logically partition away the OS chunk?
Security, performance, and price.

Pennies matter in quantities of a million. If they can give games adequately fast RAM and enough of it and save a buck on RAM only the OS is expected to use, that's a win win.

Series S doesn't even have slim margins, they're taking a hit on every single unit. It is price optimised to the absolute maximum. The odd RAM configuration is part of that. A GPU designed to be made from defective Series X GPUs, OR for a Series X GPU wafer to be able to make 2.

Honestly I love the Series S from a design, engineering, and even usage perspective. Call me a weirdo but I think it's the easiest console to use all-around.

I'll be very glad to see a Nintendo console nipping at its heels in performance and leapfrogging it in resolution.
 
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