• Hey everyone, staff have documented a list of banned content and subject matter that we feel are not consistent with site values, and don't make sense to host discussion of on Famiboards. This list (and the relevant reasoning per item) is viewable here.
  • Do you have audio editing experience and want to help out with the Famiboards Discussion Club Podcast? If so, we're looking for help and would love to have you on the team! Just let us know in the Podcast Thread if you are interested!

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

Bit off topic but this article did a break down of the Wii U architecture. Of note is the length Nintendo went to ensure backward compatibility which have been a topic of discussion here before. I hope Nintendo follows Xbox and PlayStation approach of 90% compatibility with improvements on newer hardware over near perfect compatibility with no improvement.

 
But why? Wo Long its a last gen game, it should be very possible on next HW. Wild Hearts may require more challenge but I’m sure K-T can pulled it if they want it.
I mean you answered the question. It has nothing to do with power but with want. Outside Ninja Gaiden, Team Ninja has been fairly absent from the Switch with these type of games. Wild Hearts is an EA collab so I’ll believe it when I see it with them bringing it over.
 
0
Bit off topic but this article did a break down of the Wii U architecture. Of note is the length Nintendo went to ensure backward compatibility which have been a topic of discussion here before. I hope Nintendo follows Xbox and PlayStation approach of 90% compatibility with improvements on newer hardware over near perfect compatibility with no improvement.

they'll probably achieve 99% just by virtue of being an ARM 32-bit processor
 
That's because they were still releasing games on hardware where SSD read speeds were not assured and had to duplicate assets in a game package to maneuver around seek times.
Ah interesting, that makes sense.

Between that and hardware acceleration for decompression of things like textures and other things, this is why PS5 game packages are fairly routinely smaller than their PS4 equivalents, sometimes by more than half (Dying Light 2 is the most extreme example of that I've seen so far).
Yeah, I had discovered the dying light example just after I posted this. Very cool.

That said, Dying Light 2 on PS5 is still larger than any Switch game. I'll be curious to see how far they can push it without texture downsampling

Nvidia is providing its own hardware acceleration for decompression, as I'm sure you're aware, and we have yet to learn how it stacks up against other implementations such as Oodle (what's used in PS5).
Oodle is a custom texture compression algorithm. The FDE likely is acceleration for Lempel-Ziv compression. Which is very cool, but ultimately even if your decompression hardware is effectively instantaneous, there is only so small you can compress too.

Very curious to see how it plays out, thanks for the info
 


Interesting video about the limitations of the current Switch. I assume Nintendo is working addressing these issues.

I found this comment under the MVG video on YouTube really interesting.
It’s about the importance of L2 cache.
The experiment from MVG shows that a better CPU + GPU clocks do not help Bayonetta 3 in the most challenging frame rate situations.
MVG´s conclusion is that the RAM bandwidth is the limiting factor in this case.

A user in his comments then makes this even more nuanced statement about Cache/Bandwidth/Resolution that i find really interesting.
I lack the technical knowledge to know if this statement is 100% true but here it is:

" The render does not use main memory itself, but the L2 cache. Nvidia supports the Tiled Cache method on Maxwell GPUs so that Binner rasterization locks MRT components before they land in main memory. However some developers when they want to enclose more steps let some leak fall into main memory as a scratch, occlusion and depht steps are large enough to simply not be cached which is when more of the system may be required. The new system needs more cache close to the computational unit and not really more external bandwidth, the effectiveness of Tegra's 256KB GM20b gives it 16796k states which almost always limits the target to sub 1080p. Bayonetta 3 uses a doubled resolution due to temporal reconstruction as the CPU itself is also a bottleneck. The Cortex A57 at 1.03GHz lags frametime in any collective scene, and any endbuffers are affected later. That's why it's not worth simply lowering the resolution, which will decrease the load on bandwidth. "

( a note again from me about the context : when the user talks about "new System" it is replying to MVG´s video in which a strictly "PRO" system is assumed as a just little bump to the overall Switch characteristics)
 
( a note again from me about the context : when the user talks about "new System" it is replying to MVG´s video in which a strictly "PRO" system is assumed as a just little bump to the overall Switch characteristics)
man, I genuinely don't know why some folks are still on that train. they gotta acknowledge the evidence at some point
 
man, I genuinely don't know why some folks are still on that train. they gotta acknowledge the evidence at some point
Yes, i always smile when this happens with MVG because i would like to think that he, as a developer, is already playing around with the new developer kits at his disposal and is just pulling our leg here and on the internet/podcasts by saying " prepare for disappointment"

 
Last edited:
MVG because i would like to think that he, as a developer, is already playing around with the new developer kits
He probably wouldn't be the kind of dev to have access to this devkit, those who do are most likely working for AA/AAA companies as it would make it easier to keep it secret.
 
man, I genuinely don't know why some folks are still on that train. they gotta acknowledge the evidence at some point

This thread feels like the only place on the Internet where the Drake leak has been actively discussed and almost everyone's on the same page about the next Switch's capabilities.

Though, I'm not one to voluntarily step into other corners of the web, so idk what the vibes are elsewhere.
 
Yes, i always smile when this happens with MVG because i would like to think that he, as a developer, is already playing around with the new developer kits at his disposal and is just pulling our leg here and on the internet/podcasts by saying " prepare for disappointment"


Nah, pretty sure even being on a podcast discussing the subject, would be considered NDA breaking.
 
0
He probably wouldn't be the kind of dev to have access to this devkit, those who do are most likely working for AA/AAA companies as it would make it easier to keep it secret.
MVG works for limited run games a company that has been recently acquired by the embracer group (THQ etc..)
On the day of the acquisition one of the specific reasons that Embracer group gave for this purchase was the " carbon engine" an engine specialized as " .. a development tool that allows legacy content to be easily ported to modern platforms."
That engine was developed by MVG.
I think he is therefore in really high standings within both Limited Run Games and Embracer.
I would presume developers of Embracer have the devkits for the next swicth.
I think if MVG has not already directly used the new devkits he has certainly informally heard about it.
 
This thread feels like the only place on the Internet where the Drake leak has been actively discussed and almost everyone's on the same page about the next Switch's capabilities.

Though, I'm not one to voluntarily step into other corners of the web, so idk what the vibes are elsewhere.
Something like "People have been speculating about a Pro since day 1 of Switch, it will eventually be right but there's no evidence. People at Famiboards are crazy and don't wouldn't know a CPU from a hole in the ground."
 
0
For sure. Would be interesting to see what they will do once 32bit support is dropped. I don't reckon for it to be a big problem though.
Wii U ports use the 32bit mode as I understand it, I'm curious if Nintendo already has a Rosetta like layer in mind for whatever follows the Drake Switch (where I assume 32bit support would be dropped).
 
No, but much to my surprise I can't find a good list of 32bit Switch games, nor a good explanation as to why it was used. I assume it made porting easier, but I dont really know.
About the actual question, if this is only about Wii U ports they are relatively few in number and all Nintendo first party titles. So I suppose patching them all is easier than making a translation layer.
 
The 2D dimensions of the Type A card are less a concern than the ~3x thickness, it means you need additional clearance in the chassis for the card slot. And that chassis is likely already jam-packed if Switch is anything to go by (the Game Card slot has space cut out inside for it and ONLY it, so only being 20% smaller than a Game Card is… eep?). Meanwhile, microSD slot is so thin and small that it’s able to sit above the heat shield.

Yeah, I'm really just playing devil's advocate, as I do think UFS would make more sense, but I think they could squeeze it in if they wanted to. Compared to, for example, increasing the size of the cooling assembly to accommodate higher power draw in docked mode, it's a much more minor change.

Oodle is a custom texture compression algorithm. The FDE likely is acceleration for Lempel-Ziv compression. Which is very cool, but ultimately even if your decompression hardware is effectively instantaneous, there is only so small you can compress too.

Very curious to see how it plays out, thanks for the info

Oodle has a few different compression products. They have a number of proprietary general-purpose compression algorithms (including Kraken, which was licensed by Sony and implemented as part of PS5's hardware decompression block), as well as texture compression (which is also licensed by Sony for PS5, but I don't believe there's any dedicated hardware related to it).

Drake will have one advantage over PS5 and XBSX/S on the texture front, though, which is hardware ASTC support, which is already in Switch. ASTC generally provides a better quality/bitrate trade-off than BC textures, which should offset the need for Oodle texture compression while also using less space in memory and cache.

Incidentally, I do wonder if an ASTC data is something they're specifically targeting with the FDE. Microsoft added support to XBSX/S for what they call BCPack, which is presumably a compression algorithm tuned specifically for storing BC format textures. The BC texture formats are a collection of relatively independent compression schemes, though, whereas ASTC has the benefit of storing everything from <1 bit per pixel to 8 bits per pixel in a single 128bit block format, which may make it an easier problem to solve. Assuming that ASTC textures constitute the bulk of game data on Drake, I wonder if Nvidia and Nintendo could come up with a compression algorithm that's hyper-optimised around that use-case.
 
Since y'all are fairly hardware literate, do you mind if I ask a question about an upcoming gaming PC build I'm planning? Feel free to say "no wrong thread" lol
 
Oodle has a few different compression products. They have a number of proprietary general-purpose compression algorithms (including Kraken, which was licensed by Sony and implemented as part of PS5's hardware decompression block), as well as texture compression (which is also licensed by Sony for PS5, but I don't believe there's any dedicated hardware related to it).
My understanding is that the PS5 hardware accelerates RLE decode, and that Oodle's texture compression is a software toolkit that can be accelerated by the hardware.
 
0
I'm something of a PC enthusiast myself
Okay, so my current plan* is to get a 3440x1440 ultrawide, and probably a 12GB 3080. My question is, how much would CPU matter here? I'm thinking of getting an i7-13700(K or KF), but would that be overkill? Would I be better off saving money and getting an i5-13600, i7-12700 or even an i5-12600? Also, would you say the benefit (if it exists) to going with DDR5 memory over DDR4 outweighs the additional cost?

*this is reasonably likely to change, when I first started pondering this over a year ago I was looking at getting a gaming laptop lol
 
I would go as far to say MVG knows about as much as DF does... which is to say ... next to nothing
that's my opinion of course
John Linneman at least has been pretty clear that he doesn't know anything about a new Switch, and MVG and Nate have been clear that anything that gets near an MVG NDA will be steered well clear of.
 
0
Okay, so my current plan* is to get a 3440x1440 ultrawide, and probably a 12GB 3080. My question is, how much would CPU matter here? I'm thinking of getting an i7-13700(K or KF), but would that be overkill? Would I be better off saving money and getting an i5-13600, i7-12700 or even an i5-12600? Also, would you say the benefit (if it exists) to going with DDR5 memory over DDR4 outweighs the additional cost?

*this is reasonably likely to change, when I first started pondering this over a year ago I was looking at getting a gaming laptop lol
so others here might have a different approach, but my number one priority with building is future proofing. DDR5 is worth it because it means less waste in the future

as for CPU, that kind of depends on your budget. the combination of a 3080 and an i5 makes me wince at first but it might not be that bad. I'm sure others will have some stronger and better informed opinions though
 
Okay, so my current plan* is to get a 3440x1440 ultrawide, and probably a 12GB 3080. My question is, how much would CPU matter here? I'm thinking of getting an i7-13700(K or KF), but would that be overkill? Would I be better off saving money and getting an i5-13600, i7-12700 or even an i5-12600? Also, would you say the benefit (if it exists) to going with DDR5 memory over DDR4 outweighs the additional cost?

*this is reasonably likely to change, when I first started pondering this over a year ago I was looking at getting a gaming laptop lol
So, I personally think that it boils down to balancing two things:
1. Your budget. Relatively straightforward, everyone understands and can think of this one on their own.
2. Your usecase. The tighter your budget, the more you have to refine your understanding of just what exactly you want to do with your PC.

If your usecase is strictly mainstream PC gaming:
-> If you plan for your build to last in the 3-5 year range: 6 big/'P' cores are sufficient. Any 12th/13th generation i5 should be fine. For a large chunk of the mainstream consumer audience, this is the default answer.
->If you want your build to try to last longer than that: 12700 (k or non k), 13600k, wait for 13700 (I'm assuming that the extra P-cores eventually outweigh the probable difference in clocks in some games, but that bet could end up wrong...), or reach deeper into the wallet for the 13700k. 13700k is typically overkill in the present though, especially since you're more likely to be GPU-bound than CPU-bound at 1440p or higher.

If your usecase includes particularly heavy multi-threaded games (uh...I hear that 4X games eventually fall under that category? Late game Factorio? Games that eventually slow down because of the constant accumulation of stuff for the CPU to handle):
12700 (k or non k), 13600k, wait for 13700, or pay up for 13700k. Caveat: the 8 P-core SKUs have higher priority here. I think that games tend to be more sensitive to inter-core latency and/or waiting on other threads to finish?

If your usecase includes casual/semi-casual 'productivity' (rendering, code compiling, video transcoding, etc.; basically, you want raw multi thread power):
12700 (k or non k), 13600k, wait for 13700, or pay up for 13700k. You're more likely to be able to get away with the 13600k here because the Gracemont cores should be more helpful here than for the previous usage.

If your usecase is primarily mainstream PC gaming but you want to leave open the possibility of dipping your toes into non-gaming heavy multi-threaded stuff:
13600k, 12600k, or the presumed 13500/13600 (non-k), or even the presumed 13400. The rumor/expectation is that the 13400/13500/13600 (non-k) is actually made from an Alder Lake die, not Raptor Lake.
Reminder/recap: 12600k is 6 Golden Cove/4 Gracemont. 13400 is presumed to be 6 Golden Cove/4 Gracemont (basically a 12600k with lower clocks). 13500/13600 are presumed to be 6 Golden Cove/8 Gracemont. 13600k is 6 Raptor Cove/8 'enhanced' Gracemont.
Raptor Cove = refined Golden Cove (slightly improved voltage/frequency curve, higher max clocks, more L2 cache, new prefetcher algorithm, one more thing related to L3*)
'enhanced' Gracemont = Gracemont with more L2 cache
One more spiel regarding difference between 12th and 13th generation**

As for DDR4 or DDR5...
Ehh, I personally think that the raw bang for the buck is still in favor of DDR4 at this time. But if your budget allows for it, going for solid DDR5 (with 13th generation) is also fine. It's possible that you'll need the memory bandwidth in the stuff you want to do in the future, but still within the lifetime of this next build. It's hard to say.
(a counter example would be my usecase, where I'm confident that for what I, specifically, want to do with my next build either isn't all that memory bandwidth sensitive in the first place and/or would perform at a satisfactory level with decent DDR4 anyway).

*apparently there's a new mechanism that can switch the L3 cache policy between inclusive and non-inclusive on the fly; that's new to me.

**Oh, yea, there's also been improvement to the ring bus (the interconnect between all the cores) between Alder Lake and Raptor Lake. So, with 12th generation, the clock frequency which the ring bus ran at was tied to the E-cores. So for people that wanted to maximize their gaming performance, they would disable the E-cores to allow the ring run faster. With 13th generation so far, the ring bus runs at a much higher clock, so people no longer need to disable the E-cores. The catch is, I don't know if that improvement carries over to the Alder Lake-die based SKUs (i5 non-K, i3, and below).
 
PS4 in handheld mode + DLSS was the claim.

Based on what we know now we can nuance that a lot. With a fairly high degree of confidence I can say that Drake will outperform the PS4, but underperform the PS4 pro, before DLSS. In most cases I would expect that DLSS can close the gap with PS4Pro, but I can imagine cases where it can’t.

Drake pixels might not be as pretty, even if Drake can go toe to toe on performance. PS4 games regularly broke 40GB. Squeezing all of that into a Switch card is likely to require some lower res assets in some places.
That's because they were still releasing games on hardware where SSD read speeds were not assured and had to duplicate assets in a game package to maneuver around seek times. Between that and hardware acceleration for decompression of things like textures and other things, this is why PS5 game packages are fairly routinely smaller than their PS4 equivalents, sometimes by more than half (Dying Light 2 is the most extreme example of that I've seen so far).
Nvidia is providing its own hardware acceleration for decompression, as I'm sure you're aware, and we have yet to learn how it stacks up against other implementations such as Oodle (what's used in PS5).
As someone who's been complaining about ballooning game sizes for years, this is amazing.
To add and further articulate on this, the switch has instants which is different from the hard drive discs in the PlayStation 4 or Xbox, the ones that they were built around. So the switch going to faster storage would be a much smoother transition than PlayStation 4 games built on an HDD going to PlayStation5 games built on an SSD.


Basically, on the PlayStation 4, there was duplicate data, but on the switch there is no duplicate data because it’s flash storage. At the same time because the Nintendo switch uses flash storage it is going one gen forward by using a much faster flash storage versus 2 gens forward from going to an SSD from an HDD.


So games don’t really need to be built around the instantaneous seeks of the switch, they already kinda are here since it’s flash storage. They’ll just slot in and benefit on the new hardware.

vs having to be patched to make use of the SSD.


So games on the switch 2 should see an increase in storage sizes, but probably not to the levels of PS4/XB1.

That said, with the FDE, the media engines on the device for video playback if there is, more potent hardware, etc., it shouldn’t come close to say RDR2 which was like >100GB


I think with smart utilization of the resources they can get it to half of that.

And while the game was downgraded, Nier Automata went from 50 GB or so on the PlayStation4 to I think 10 to 14 GB on the Nintendo switch, using the hardware resources to the best of their abilities and reducing the unnecessary bloat that was present on the PS4.


So, it’s about being smarter with it than brute forcing it.
 
so others here might have a different approach, but my number one priority with building is future proofing. DDR5 is worth it because it means less waste in the future

as for CPU, that kind of depends on your budget. the combination of a 3080 and an i5 makes me wince at first but it might not be that bad. I'm sure others will have some stronger and better informed opinions though
So, I personally think that it boils down to balancing two things:
1. Your budget. Relatively straightforward, everyone understands and can think of this one on their own.
2. Your usecase. The tighter your budget, the more you have to refine your understanding of just what exactly you want to do with your PC.

If your usecase is strictly mainstream PC gaming:
-> If you plan for your build to last in the 3-5 year range: 6 big/'P' cores are sufficient. Any 12th/13th generation i5 should be fine. For a large chunk of the mainstream consumer audience, this is the default answer.
->If you want your build to try to last longer than that: 12700 (k or non k), 13600k, wait for 13700 (I'm assuming that the extra P-cores eventually outweigh the probable difference in clocks in some games, but that bet could end up wrong...), or reach deeper into the wallet for the 13700k. 13700k is typically overkill in the present though, especially since you're more likely to be GPU-bound than CPU-bound at 1440p or higher.

If your usecase includes particularly heavy multi-threaded games (uh...I hear that 4X games eventually fall under that category? Late game Factorio? Games that eventually slow down because of the constant accumulation of stuff for the CPU to handle):
12700 (k or non k), 13600k, wait for 13700, or pay up for 13700k. Caveat: the 8 P-core SKUs have higher priority here. I think that games tend to be more sensitive to inter-core latency and/or waiting on other threads to finish?

If your usecase includes casual/semi-casual 'productivity' (rendering, code compiling, video transcoding, etc.; basically, you want raw multi thread power):
12700 (k or non k), 13600k, wait for 13700, or pay up for 13700k. You're more likely to be able to get away with the 13600k here because the Gracemont cores should be more helpful here than for the previous usage.

If your usecase is primarily mainstream PC gaming but you want to leave open the possibility of dipping your toes into non-gaming heavy multi-threaded stuff:
13600k, 12600k, or the presumed 13500/13600 (non-k), or even the presumed 13400. The rumor/expectation is that the 13400/13500/13600 (non-k) is actually made from an Alder Lake die, not Raptor Lake.
Reminder/recap: 12600k is 6 Golden Cove/4 Gracemont. 13400 is presumed to be 6 Golden Cove/4 Gracemont (basically a 12600k with lower clocks). 13500/13600 are presumed to be 6 Golden Cove/8 Gracemont. 13600k is 6 Raptor Cove/8 'enhanced' Gracemont.
Raptor Cove = refined Golden Cove (slightly improved voltage/frequency curve, higher max clocks, more L2 cache, new prefetcher algorithm, one more thing related to L3*)
'enhanced' Gracemont = Gracemont with more L2 cache
One more spiel regarding difference between 12th and 13th generation**

As for DDR4 or DDR5...
Ehh, I personally think that the raw bang for the buck is still in favor of DDR4 at this time. But if your budget allows for it, going for solid DDR5 (with 13th generation) is also fine. It's possible that you'll need the memory bandwidth in the stuff you want to do in the future, but still within the lifetime of this next build. It's hard to say.
(a counter example would be my usecase, where I'm confident that for what I, specifically, want to do with my next build either isn't all that memory bandwidth sensitive in the first place and/or would perform at a satisfactory level with decent DDR4 anyway).

*apparently there's a new mechanism that can switch the L3 cache policy between inclusive and non-inclusive on the fly; that's new to me.

**Oh, yea, there's also been improvement to the ring bus (the interconnect between all the cores) between Alder Lake and Raptor Lake. So, with 12th generation, the clock frequency which the ring bus ran at was tied to the E-cores. So for people that wanted to maximize their gaming performance, they would disable the E-cores to allow the ring run faster. With 13th generation so far, the ring bus runs at a much higher clock, so people no longer need to disable the E-cores. The catch is, I don't know if that improvement carries over to the Alder Lake-die based SKUs (i5 non-K, i3, and below).
Don't wanna derail the thread any more but just wanted to say thanks, these insights are super helpful!!
 

Yes, i always smile when this happens with MVG because i would like to think that he, as a developer, is already playing around with the new developer kits at his disposal and is just pulling our leg here and on the internet/podcasts by saying " prepare for disappointment"



Just for comparison NateDrake has been right on so many occasions now I can hardly count.
So even information that Nate has mentioned he's heard multiple times during their NateTheHate podcast, MVG has at times does not appear to be on the same page or in the loop. So Nate might just have contacts much closer to the source, which is why he's been so adamant and consistent on information given here in the past.

I've listened to every one of their podcasts together and the ongoing uncertainty from MVG on multiple Silent Hill games in the making was almost painful to hear, only because you could hear in Nate's voice that he was absolutely sure about his information and now the rest is history...
 
For sure. Would be interesting to see what they will do once 32bit support is dropped. I don't reckon for it to be a big problem though.
There are basically three options. Either they switch to custom cores which retain aarch32 support (fairly plausible with the current trajectory of Nvidia and ARM), they include lower power CPU cores that still support aarch32, or they emulate it. Right now I'm about 50/50 on the first and third option, especially as the likelihood of custom cores in general seems to be growing even outside this issue.
Yes, i always smile when this happens with MVG because i would like to think that he, as a developer, is already playing around with the new developer kits at his disposal and is just pulling our leg here and on the internet/podcasts by saying " prepare for disappointment"


Considering the studio he works with and the projects he works on, I'd be very surprised if MVG has even been officially informed of the hardware's existence yet.
No, but much to my surprise I can't find a good list of 32bit Switch games, nor a good explanation as to why it was used. I assume it made porting easier, but I dont really know.
Yeah, you'd think one of the Switch emulators would have a decent list, but I've never found one.

I suspect the existence of 32-bit Switch games is a confluence of two factors:
  • With the Switch being just barely within the 32-bit memory addressing limit and the games in question seemingly being all ports from older platforms (not just Wii U, either, to my understanding), they're probably not giving much up, if at all.
  • Most games are written in low enough level languages that there will be some level of sensitivity to 32-bit vs 64-bit (the exact amount will be very case by case), providing some incentive for ports to just stick to 32-bit to minimize risks. For games coming from older ARM platforms (mostly 3DS), it's also entirely possible that there might be libraries or middleware that the developer never or (more likely) no longer has the source for, or code that uses features that don't directly translate to aarch64, as I think some features were dropped in the transition.
Is allowing 32-bit games a decision that will increase long term maintenance costs in favor of some shorter term development gains? Probably at least a little. Was it the right decision at the time? Quite possibly, though I don't recall how much dropping aarch32 was really on anyone's radar back then, because aarch64 was still pretty new when Nintendo was designing the Switch.
 
So they're claiming the P670 performs within a few percentage points of an A78. That's pretty big if true. Would mean they've come pretty close to catching up with the Cortex A series cores. That's a pretty big step towards RISC-V reaching critical mass.
 
Does this include botw?
Every Wii U and 3DS game on the switch is 32-bit I believe, since the Wii U PowerPC CPU is 32-bit
I found this comment under the MVG video on YouTube really interesting.
It’s about the importance of L2 cache.
The experiment from MVG shows that a better CPU + GPU clocks do not help Bayonetta 3 in the most challenging frame rate situations.
MVG´s conclusion is that the RAM bandwidth is the limiting factor in this case.

A user in his comments then makes this even more nuanced statement about Cache/Bandwidth/Resolution that i find really interesting.
I lack the technical knowledge to know if this statement is 100% true but here it is:

" The render does not use main memory itself, but the L2 cache. Nvidia supports the Tiled Cache method on Maxwell GPUs so that Binner rasterization locks MRT components before they land in main memory. However some developers when they want to enclose more steps let some leak fall into main memory as a scratch, occlusion and depht steps are large enough to simply not be cached which is when more of the system may be required. The new system needs more cache close to the computational unit and not really more external bandwidth, the effectiveness of Tegra's 256KB GM20b gives it 16796k states which almost always limits the target to sub 1080p. Bayonetta 3 uses a doubled resolution due to temporal reconstruction as the CPU itself is also a bottleneck. The Cortex A57 at 1.03GHz lags frametime in any collective scene, and any endbuffers are affected later. That's why it's not worth simply lowering the resolution, which will decrease the load on bandwidth. "

( a note again from me about the context : when the user talks about "new System" it is replying to MVG´s video in which a strictly "PRO" system is assumed as a just little bump to the overall Switch characteristics)
the tegra X1 doesn’t have proper cache coherency which was introduced with Xavier, and and the tegra (all of them) can utilize the CPU cache as an extra level before hitting the system memory (RAM). With DRAKE being an offshoot of ORIN, a lot of the finer improvements to cache that nvidia has employed through the years since the TX1.
About the actual question, if this is only about Wii U ports they are relatively few in number and all Nintendo first party titles. So I suppose patching them all is easier than making a translation layer.
I don’t think that can actually be patched, it would be very difficult.

In fact, I think emulating it would be easier than actually patching it….

There are basically three options. Either they switch to custom cores which retain aarch32 support (fairly plausible with the current trajectory of Nvidia and ARM), they include lower power CPU cores that still support aarch32, or they emulate it. Right now I'm about 50/50 on the first and third option, especially as the likelihood of custom cores in general seems to be growing even outside this issue.
It would be a bit hard here, but requires more work to modify an architecture if needed, but the A510 still has AArch32 support, despite ARM’s claims. So, if they want they can take an in-order little core cluster and use that for the older titles?

Or modify it to be out of order and use that for the legacy games?


Really, I think an emulation layer would be the route the go though. Arm v9 is looking to really drop AArch32 at some point.
 
Does this include botw?
Every Wii U and 3DS game on the switch is 32-bit, since the Wii U PowerPC CPU is 32-bit
I don't think I've ever seen BotW show up in lists of 32-bit Switch games. That one in particular is a game I'd expect probably wouldn't be because it launched as a cross-platform game. It's also not exactly a niche game, so one would think it'd have come up.
It would be a bit hard here, but requires more work to modify an architecture if needed, but the A510 still has AArch32 support, despite ARM’s claims. So, if they want they can take an in-order little core cluster and use that for the older titles?

Or modify it to be out of order and use that for the legacy games?


Really, I think an emulation layer would be the route the go though. Arm v9 is looking to really drop AArch32 at some point.
If Nintendo sticks with the reference cores, then emulation is inevitable, but that's not the only outcome. If Nvidia starts building custom cores for them, then there's a strong argument to be made to just keep aarch32 so they can just kick that can down the road until it's time for RISC-V, which is increasingly feeling like more of a "when" than an "if". They could always decide to drop it anyway and just emulate, but I don't really see that being a super appealing option unless there's fairly significant downsides to keeping aarch32.
 
So they're claiming the P670 performs within a few percentage points of an A78. That's pretty big if true. Would mean they've come pretty close to catching up with the Cortex A series cores. That's a pretty big step towards RISC-V reaching critical mass.
One caveat is that one of SiFive's slides mention using the Cortex-A78 on the Snapdragon 888 and the Exynos 2100 to make comparisons between the Cortex-A78 and the P670.

As a reminder, the Snapdragon 888 and the Exynos 2100 are fabricated using Samsung's 5LPE process node. Anandtech's review of the Snapdragon 888 and the Exynos 2100 mentions that Samsung's 5LPE process node is only on par with TSMC's N7 process node (and TSMC's N7P process node) when the CPU frequency's ≤1.8 GHz. And WikiChip mentions the P670's using TSMC's N7 process node for the fabrication.

Going by Geekerwan's review of Arm's CPUs, the Cortex-A78 on TSMC's N5 process node via Dimensity 8100 is better from a performance and power efficiency standpoint compared to the Cortex-A78 on Samsung's 5LPE process node via Snapdragon 888.
ocR1sOg.png

And since nobody has benchmarked the performance of the Cortex-A78 using TSMC's N6 process node (e.g. Dimensity 1100), the closest comparison is the Cortex-A77 using TSMC's N7P process node via the Snapdragon 865 vs the Cortex-A78 using Samsung's 5LPE process node, which shows the Cortex-A77 using TSMC's N7P process node being better from a performance and power efficiency standpoint compared to the Cortex-A78 using Samsung's 5LPE process node.
rqtsEAM.png

So I can see the Cortex-A78 using TSMC's N6 process node being in between the Cortex-A78 using TSMC's N5 process node and the Cortex-A77 using TSMC's N7P process node from a performance and power efficiency standpoint.

And interestingly enough, one of SiFive's slides also mention the Cortex-A78 using Samsung's 5LPE process node has a die size area of ~2 mm², which is very interesting.
 
Last edited:
Okay, so my current plan* is to get a 3440x1440 ultrawide, and probably a 12GB 3080. My question is, how much would CPU matter here? I'm thinking of getting an i7-13700(K or KF), but would that be overkill? Would I be better off saving money and getting an i5-13600, i7-12700 or even an i5-12600? Also, would you say the benefit (if it exists) to going with DDR5 memory over DDR4 outweighs the additional cost?

*this is reasonably likely to change, when I first started pondering this over a year ago I was looking at getting a gaming laptop lol
Depends on your use case. What type of games will you be playing? What kind of framerates would you like to hit?

In general, you're better off spending less on the CPU and putting the money towards a better GPU, more RAM or a higher quality power supply. A 13600k will probably last you the entire generation.
 
Regarding the 32/64-bit situation for some games, how hard would it be to convert a 32-bit game to 64-bit if one had the source code? Would it be feasible if devs made 64-bit updates specifically for Drake?
 
Based on? I thought folks have been pointing to PS4-PS4 Pro docked before DLSS. I don’t want to misquote Nate as I can’t find the post, but I also thought that lined up with what he heard a year ago.

I’m expect better than 1080p 60fps PS4 titles based on the above. PS4 Pro would have managed that without DLSS.
I'm expecting around 1080p 60fps for PS4 quality level games at least. The actual spec of the machine is separate from that, which yeah, could be close to ps4 pro pro performance without DLSS. I'm being modest about it.
Switch is paired with mobile players last I heard in cross platform. Unless you are in a group.
I see. Mobile has already surpassed switch a few years ago.. PS4 tier.

Micron announced it's 1 beta fabrication process. First product with 16GB LPDDR5x-8500 memory, and eventually others will follow. Ready for mass production. Dunno when it's out.

Not expecting Drake to have LPDDR5x memory, (but would be a nice surprise) especially at 16GB. So maybe we can cross this one out...
 
Regarding the 32/64-bit situation for some games, how hard would it be to convert a 32-bit game to 64-bit if one had the source code? Would it be feasible if devs made 64-bit updates specifically for Drake?
This isn't a Drake problem, it's a problem for what comes afterwards. The topic has just sort of come up again because some of the recent news around ARM has gotten people thinking about what will happen long term. Drake is broadly expected to have a variant of the A78 CPU core, which retains support for running 32-bit apps.

To answer the question, though, you could port a game from aarch32 to aarch64 with the source code, but it's not going to be any easier than it would have been had they just done that in the first place. If anything, it will likely be a bit more work, as it will be code no one has touched in a while. As with BC in general, it's not really a generic or scalable solution, and they're probably better off just doing emulation if they end up in a situation where they have a CPU core without aarch32 support.

It should be noted that the list of known 32-bit Switch games includes multiple third party titles, so it's not like this is something Nintendo could just take care of for themselves.
 
Micron announced it's 1 beta fabrication process. First product with 16GB LPDDR5x-8500 memory, and eventually others will follow. Ready for mass production. Dunno when it's out.

Not expecting Drake to have LPDDR5x memory, (but would be a nice surprise) especially at 16GB. So maybe we can cross this one out...
Micron said 16 Gb, not 16 GB, which is 2 GB.
 
This isn't a Drake problem, it's a problem for what comes afterwards. The topic has just sort of come up again because some of the recent news around ARM has gotten people thinking about what will happen long term. Drake is broadly expected to have a variant of the A78 CPU core, which retains support for running 32-bit apps.

To answer the question, though, you could port a game from aarch32 to aarch64 with the source code, but it's not going to be any easier than it would have been had they just done that in the first place. If anything, it will likely be a bit more work, as it will be code no one has touched in a while. As with BC in general, it's not really a generic or scalable solution, and they're probably better off just doing emulation if they end up in a situation where they have a CPU core without aarch32 support.

It should be noted that the list of known 32-bit Switch games includes multiple third party titles, so it's not like this is something Nintendo could just take care of for themselves.
Ah, ok. Had the idea that Drake was losing aarch32 support when reading through these posts, but it's later versions of the ARM architecture that are dropping it, which for a Switch successor's successor, would be many years down the road. I just hope that Nintendo doesn't decide to stick with one gen of BC per system like they've generally done before.

Thought recompiling would be a worthwhile option, but I guess not. I did recall that Nintendo supposedly archives all games that ever graced their platforms, source code and all, including 3rd-party. I know SE reached out to Nintendo regarding their Seiken Densetsu games (that made up the Secret of Mana collection) because SE lost their code.
 
Regarding the 32/64-bit situation for some games, how hard would it be to convert a 32-bit game to 64-bit if one had the source code? Would it be feasible if devs made 64-bit updates specifically for Drake?
This is easily done in Android. Not sure the case with Nintendo since the library used is more baremetal. In android, you upload something like a pseudo source code into the store. Then the android store will compile it to several architecture (32 bit arm, 64 bit arm, x86, x64).
 
Ah, ok. Had the idea that Drake was losing aarch32 support when reading through these posts, but it's later versions of the ARM architecture that are dropping it, which for a Switch successor's successor, would be many years down the road. I just hope that Nintendo doesn't decide to stick with one gen of BC per system like they've generally done before.

Thought recompiling would be a worthwhile option, but I guess not. I did recall that Nintendo supposedly archives all games that ever graced their platforms, source code and all, including 3rd-party. I know SE reached out to Nintendo regarding their Seiken Densetsu games (that made up the Secret of Mana collection) because SE lost their code.
Even if Nintendo is currently archiving third party source code to a high enough standard to be able to modify and build it (likely not a trivial endeavor with how modern build systems are), there are a bunch of legal and technical reasons that's not really a good avenue to go down. It's the sort of thing they'd probably need explicit permission for, and their engineers would likely be completely unfamiliar with the codebases.
This is easily done in Android. Not sure the case with Nintendo since the library used is more baremetal. In android, you upload something like a pseudo source code into the store. Then the android store will compile it to several architecture (32 bit arm, 64 bit arm, x86, x64).
Even on Android, this is only sometimes true. Android apps typically ship Dalvik bytecode (which is notably not JVM bytecode, but typically derived from it) by default, which is hardware agnostic, but many apps, including what I'd estimate to be the vast majority of every game of note on the platform, also contain some amount of native code which can only run on whatever architecture(s) it's compiled for.

Android is going to have its own big dropping 32-bit support moment coming pretty soon with how the recent ARM cores are going.
 
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