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

here's a good demonstration of RTGI and 60fps. series s runs at a dynamic 720p to 1512p. high resolution and 60fps is definitely an ask. but Drake is better at RT (especially since this RTGI method is nvidia's RTXGI). but this is still a game designed for higher performance machines (let's ignore the fact that there's a non-RT mode on PC) so I wouldn't say RT and 60fps is off the table, since weaker hardware has demonstrated RT and 60fps with less bespoke solutions

 
Oh, there's a little of exaggeration in a completely harmless post about how much I want Switch 2 to be announced?That surely means I have no life outside of it and I don't play videogames. Very smart on your part.

Really, why this rudeness suddendly?
I think you are reading way too much into the post. I can't speak for the posters intent but to me It never suggested you have no life, it was a playful suggestion to play some video games.
 
I think you are reading way too much into the post. I can't speak for the posters intent but to me It never suggested you have no life, it was a playful suggestion to play some video games.
I don't want to go so off-topic and deviate the thread, so this is the last thing I'm going to say about this topic.

A joke is all about context. We've made, collectively, lots of jokes about how people in this forum loves to talk about videogames but not playing them and stuff like that. That's fine. Going to a stranger and telling him to go touch some grass is not a thing I can interpret as a friendly joke. Maybe I'm weird, but I think that is a basic social skill.
 
It may be the case that building a stepwise rendering pipeline consisting of these three components (base image rendering, DLSS upscaling, higher-res post-processing, where step 1 of frame 2 can be launched while steps 2 and 3 of frame 1 have not yet finished) requires changes to the game engines that so far have not been identified as worthwhile investments considering the games run well without this significant optimisation.
To my knowledge, most game engines on PC don't do even the non-DLSS equivalent of this, which is rendering in parallel to game logic. Unsurprising as there are latency costs, and it makes implementing a functional frame limiter really hard.

Nintendo's high level graphics libraries have this built in, and can hide it from the engine developer. Nintendo recommends rendering in parallel with CPU as the default, but encourages you to turn that off if you're building something like a fighting game or a rhythm game, as the latency cost is pretty detectable.

Implementing this level of separation would be a prerequisite for doing multiple pass parallel rendering with DLSS, which I imagine would require pretty tricky inter-thread coordination and locking. Thread A samples the controller, runs game logic, and passes rendering to thread B. Thread B renders the scene with no upscaling or post processing (and ideally, no UI). Thread C takes the scene and runs DLSS, then post processing, then slaps the UI on top.

Thread A needs to be able to back up if thread B is still busy or if thread C is still busy. Thread B needs to back up if thread C is still busy, and thread C needs to manage the buffering and the V-Sync. That's actually trivially easy. But the trivially easy implementation just results in these things going one after the other 90% of the time, so no performance uplift.

Interesting, thanks for mentioning this.
Moving post-processing after DLSS, and doing it at the output resolution is one of the requirements of a "good" DLSS implementation from Nvidia's point of view. Post processing can remove data that DLSS wants for a good upscale, especially something like motion blur or depth-of-field. Also texture resolution/mip-maps should be set as if the game were running at the output resolution. None of these things are required, but if Nvidia is featuring the implementation, you can be sure they're doing it, and all those add costs.

I would say that it's worth noting that if these things are required for a "good" DLSS implementation, then DF may not have found exactly what the chip is and is not capable of, but it was a decent insight into what were likely to get from high quality games.
 
I don't want to go so off-topic and deviate the thread, so this is the last thing I'm going to say about this topic.

A joke is all about context. We've made, collectively, lots of jokes about how people in this forum loves to talk about videogames but not playing them and stuff like that. That's fine. Going to a stranger and telling him to go touch some grass is not a thing I can interpret as a friendly joke. Maybe I'm weird, but I think that is a basic social skill.
Didn't see the grass comment, with you on that one. That was a separate poster.

But yea, let's move on.
 
To my knowledge, most game engines on PC don't do even the non-DLSS equivalent of this, which is rendering in parallel to game logic. Unsurprising as there are latency costs, and it makes implementing a functional frame limiter really hard.

Nintendo's high level graphics libraries have this built in, and can hide it from the engine developer. Nintendo recommends rendering in parallel with CPU as the default, but encourages you to turn that off if you're building something like a fighting game or a rhythm game, as the latency cost is pretty detectable.
Is that why I notice horrendous analog stick input lag on the Switch, especially on 30FPS first person shooters and especially when using it in handheld mode?
 
I am sure we all can wait. Ever since they started doing flash sales on consoles, I know a lot of us have a back log that needs attention. On the Switch, I am trying Duke Nukem 3D.
 
Moving post-processing after DLSS, and doing it at the output resolution is one of the requirements of a "good" DLSS implementation from Nvidia's point of view. Post processing can remove data that DLSS wants for a good upscale, especially something like motion blur or depth-of-field. Also texture resolution/mip-maps should be set as if the game were running at the output resolution. None of these things are required, but if Nvidia is featuring the implementation, you can be sure they're doing it, and all those add costs.

I would say that it's worth noting that if these things are required for a "good" DLSS implementation, then DF may not have found exactly what the chip is and is not capable of, but it was a decent insight into what were likely to get from high quality games.
Great post as usual! You are great at explaining things, didn't think of it that way before.

I'm curious if you think Nvidia/ Nintys requirements for a "good" dlss implementation will be different than on PC, where frametime cost is a much smaller concern.
 
Originally i was gonna ask if 12GB was gonna be enough to last the entire gen. but I realize I don't really know what the next big push in video game tech {like the next 10 years) is gonna be so what do you all think it's gonna be? Just more refinement on current RT techniques?
I'll bite.

The big one is obviously neural rendering, which we're going to get from both sides. On the right we're going to get a continuation of what DLSS does, where machine learning is used to quickly guess what would have been rendered if you'd thrown a lot of GPU power at the problem. Even if DLSS upscaling, frame generation, and ray reconstruction are all very different technologies, they all fall under that umbrella.

@Thraktor and I have tried to figure out what's next for DLSS itself, in version 4. I see two strong possibilities. The first is just to uplift existing post processing effects into DLSS. DLSS motion blur, DLSS depth-of-field, DLSS film grain. One of DLSS's hangups is that good implementations need to do these things after DLSS runs, at a higher resolution. To me, these things seem like prime candidates for an AI to handle anyway, and putting them into the DLSS core would offer performance advantages and developer simplicity.

The second is for AI to pick up more of the ray tracing pipeline. Right now DLSS handles denoising, which was the obvious one, and even some of us amateurs called it as the next step well before it was announced. That's still in the maturation phase, but last year Nvidia released a paper on neural BDRF. I don't think the solution presented here is viable as-is, but moving BDRF into the tensor cores opens up some interesting possibilities.

This isn't so much a "refinement" of current RT techniques, so much as it's totally new techniques designed to get the result that older techniques get on much more powerful hardware.

On the left side, though, neural rendering can also mean copyright erasing generative AI. And I'm sure we're going to see plenty of that, but it's going to come on the tools side, not in real time (I think).

Past rendering, there is interesting work in neural physics, neural animation, neural shading as a more generalized tool.

Past AI, I think game engines need to pay down their technical debt on threading (lots of work), and provide a model to developers that lets them scale across threads without pushing the entire cognitive load of threading into the game dev's heads.

We're going to need to start scaling more smartly around memory, because it just isn't growing like it used to. That will require new data formats (oh hey neural compression), new approaches to geometry. But the upside of that, potentially - the end of pop-in, the end of muddy close up textures, the end of obvious tessellation far away.
 
Oh, there's a little of exaggeration in a completely harmless post about how much I want Switch 2 to be announced?That surely means I have no life outside of it and I don't play videogames. Very smart on your part.

Really, why this rudeness suddendly?
Don't worry, we're good. It was my turn to have a go at the meme this time, I am happy I could finally contribute.
 
You just up and decided to fill this place with my favorite posts for some reason
futurama-bender.gif
 
Oh, there's a little of exaggeration in a completely harmless post about how much I want Switch 2 to be announced?That surely means I have no life outside of it and I don't play videogames. Very smart on your part.

Really, why this rudeness suddendly?
I apologize for the dumb post! It was meant in jest.
 
Last edited:
Great post as usual! You are great at explaining things, didn't think of it that way before.

I'm curious if you think Nvidia/ Nintys requirements for a "good" dlss implementation will be different than on PC, where frametime cost is a much smaller concern.
Requirements might have been a strong word. It's what Nvidia recommends as best practice in their programming guide, but in some developer talks they've mentioned that, even when Nvidia is working with a developer directly, sometimes their engine (or their deadline) makes getting "good enough" a priority over "best possible." They've specifically mentioned that there are games they've worked on that need to do DLSS after post-processing, and it still works.

I expect that Nintendo/Nvidia will just integrate the existing best practices into their documentation, but it will be up to devs to decide what to do. I can certainly imagine a developer deciding that the performance wins of a less-than-optimal DLSS implementation are totally worth it.

What might be interesting is if we had some kind of example of "1440p, well implemented DLSS" versus "4k, fast-and-loose DLSS" so we could could see, subjectively, which folks might prefer. It would be especially nice if it was in a format where folks could stream the comparison to their smart TVs without a shitload of compression artifacts. One thing that I think gets lost when we talk about these things - folks are hunched over their computer looking at stills or compressed youtube video, and making conclusions about the "best" technique. It would be great to have a way to see something blown up on a huge TV... but 6 feet away and see what they can notice then.

Or the reverse on a tiny handheld screen. That's part of why the Steam Deck shifted my opinions on FSR. FSR is demonstrably shittier at lower resolutions and higher upscaling factors, by like... a lot. But there is no handheld hardware for trying out DLSS! There is no one doing comprehensive testing of DLSS vs FSR wired up to a 50+ inch television. I was playing Control for like 50 hours on my Steam Deck before I noticed FSR artifacts - artifacts I'd seen hundreds of times in comparison tests - that were cropping up regularly in game play. It would be one thing if FSR didn't offer a technical benefit, but it's substantially faster.

I started to see how DLSS was a great feature, but not necessarily a "every AAA game will use this" tool. I also started to see more value in Ultra Performance than I had before. It's not a gorgeous upscale, but again, we're talking about game under console conditions, very different from the way these technologies have been tested in the past.

TL;DR - developers will have a range of choices when it comes to upscaling. I think that instead of the number of choices coalescing quickly around a single option, I expect the options to expand over the course of the generation, as AMD, NVidia, and Epic continue to compete and collaborate.
 
Do you think Devs will target 40fps on Switch 2 for games that target 60fps on series S/X/PS5 for its performance mode, or just stick to 30fps? I think 40/45 fps being more common on Switch 2 depends on whether the portable screen can support it or not.
 
Do you think Devs will target 40fps on Switch 2 for games that target 60fps on series S/X/PS5 for its performance mode, or just stick to 30fps? I think 40/45 fps being more common on Switch 2 depends on whether the portable screen can support it or not.
Given that it's probably not a 120 Hz screen, they'd probably target 30 fps as usual.
 
Do you think Devs will target 40fps on Switch 2 for games that target 60fps on series S/X/PS5 for its performance mode, or just stick to 30fps? I think 40/45 fps being more common on Switch 2 depends on whether the portable screen can support it or not.
I think Nintendo values parity and wants games to run the same frame rate in both modes (yea I know Bowsers fury, that was the exeption). The majority of TVs are 60hz and only support 30 and 60fps. So those will remain the standard framerate targets.

If it was a pure handheld, I could see Nintendo letting devs target a variety of framerates, and having a panel that supports that.
 
you're saying we should curb our enthusiasm?
at this point it's not like we're going to wait much longer. The thing is coming out this year and due for an announcement either this fiscal quarter or next.
It's not like we need to temper expectations either. The specs of this thing are pretty much well-known bar the CPU clocks, so we can deduce easily enough how it'll perform and how powerful it is in general.

The current question without answer is more about if it'll have a new gimmick, however small it may be.
 
Do you think Devs will target 40fps on Switch 2 for games that target 60fps on series S/X/PS5 for its performance mode, or just stick to 30fps? I think 40/45 fps being more common on Switch 2 depends on whether the portable screen can support it or not.
you need a vrr screen for that, which not many people have. and nintendo most likely won't put into their screen, especially if they're going LCD for teh sake of costs
 
at this point it's not like we're going to wait much longer. The thing is coming out this year and due for an announcement either this fiscal quarter or next.
It's not like we need to temper expectations either. The specs of this thing are pretty much well-known bar the CPU clocks, so we can deduce easily enough how it'll perform and how powerful it is in general.

The current question is more about if it'll have a new gimmick, however small it may be.
I think we’re probably 2.5 months maximum away from the reveal of this thing. We’re getting to the doorstep. We’ll get our direct early February. And after that the next thing is the announcement of Switch 2 is how I see it.
 
you need a vrr screen for that, which not many people have. and nintendo most likely won't put into their screen, especially if they're going LCD for teh sake of costs
Even the lcd SD supports 40hz. I don't think cost would be prohibitive if Nintendo really wanted to have the feature.

I don't think they really want it though, pure for parity reasons with docked mode.
 
Out of curiosity, is it likely future DLSS versions will require beefier tensor cores? Or could they be optimized for previous hardware with existing tensor cores?
Depends on what the versions add. Different parts of DLSS 3.2 only work with new hardware, while optimizations and some new features still work with older hardware. It really depends on what NVidia is trying to accomplish and if that needs more hardware.
 
I think we’re probably 2.5 months maximum away from the reveal of this thing. We’re getting to the doorstep. We’ll get our direct early February. And after that the next thing is the announcement of Switch 2 is how I see it.
I think we would be hearing a lot more by now right? If Nintendo doesn't do a superbowl ad on the Switch 2, then they won't rush.
 
Is that why I notice horrendous analog stick input lag on the Switch, especially on 30FPS first person shooters and especially when using it in handheld mode?
It's gonna vary game to game, but if this is the issue it'll affect all inputs, not just the stick. So if you're seeing similar lag with button presses, very possibly.

It may also be a vsync implementation issue. Triple buffering creates this weird scenario where the lowest latency solution on PC is the highest latency solution on console
 
I can see Nintendo eventually evolving the Switch to do something like the Ayaneo Slide, but with a second screen instead of a keyboard.
Maybe by Switch 3 they can get everything refined enough to be able to dock, detachable controllers and with great performanc...


I fucking love this idea. I guess when you dock though it would work kind like Wii U...

Which is fine by me! Can't see it with Switch 2 only because of costs and other things they're probably R&Ding but it's fun to think about.
 
I think we would be hearing a lot more by now right? If Nintendo doesn't do a superbowl ad on the Switch 2, then they won't rush.
they would need for to reveal it by mid-February for that to happen. I don't think next week is plausible for it, since Peach is most likely gonna get dived into this one (there was a Nintendo Live Tokyo featuring it that was cancelled around then, so the marketing push will probably happen pretty soon)
 
I'll bite.

The big one is obviously neural rendering, which we're going to get from both sides. On the right we're going to get a continuation of what DLSS does, where machine learning is used to quickly guess what would have been rendered if you'd thrown a lot of GPU power at the problem. Even if DLSS upscaling, frame generation, and ray reconstruction are all very different technologies, they all fall under that umbrella.

@Thraktor and I have tried to figure out what's next for DLSS itself, in version 4. I see two strong possibilities. The first is just to uplift existing post processing effects into DLSS. DLSS motion blur, DLSS depth-of-field, DLSS film grain. One of DLSS's hangups is that good implementations need to do these things after DLSS runs, at a higher resolution. To me, these things seem like prime candidates for an AI to handle anyway, and putting them into the DLSS core would offer performance advantages and developer simplicity.

The second is for AI to pick up more of the ray tracing pipeline. Right now DLSS handles denoising, which was the obvious one, and even some of us amateurs called it as the next step well before it was announced. That's still in the maturation phase, but last year Nvidia released a paper on neural BDRF. I don't think the solution presented here is viable as-is, but moving BDRF into the tensor cores opens up some interesting possibilities.

This isn't so much a "refinement" of current RT techniques, so much as it's totally new techniques designed to get the result that older techniques get on much more powerful hardware.

On the left side, though, neural rendering can also mean copyright erasing generative AI. And I'm sure we're going to see plenty of that, but it's going to come on the tools side, not in real time (I think).

Past rendering, there is interesting work in neural physics, neural animation, neural shading as a more generalized tool.

Past AI, I think game engines need to pay down their technical debt on threading (lots of work), and provide a model to developers that lets them scale across threads without pushing the entire cognitive load of threading into the game dev's heads.

We're going to need to start scaling more smartly around memory, because it just isn't growing like it used to. That will require new data formats (oh hey neural compression), new approaches to geometry. But the upside of that, potentially - the end of pop-in, the end of muddy close up textures, the end of obvious tessellation far away.

You talked about DLSS being used to “…quickly guess what would have been rendered…” And you mentioned post-processing effects like motion blue, DOF, film grain, etc.

What I’m curious though is could Tensor cores be used to upscale other aspects of the graphics pipeline such as particle effects, textures, lighting, shadows, etc? I know DLSS has Ray Reconstruction, which sounds kinda like what I’m getting at, but that appears to reflect on Ray-Tracing in general.

DLSS for the most part has relied on improving resolution, and frame rate, but at what point do we allow Tensor cores to effectively render the entire game? Or is it more nuanced than that?
 
Last edited:
Nintendo kinda did something similar in the past: they released the Gameboy Advance then a couple years after it released the DS.
They release the DS because Sony release the PSP. Don't forgot that Nintendo lose the console market for Sony and was afraid to lose the portable mart too. The way they found to fight back is creating a "third pillar".
 
Regarding joy-con comfort, the Steam Deck has spoiled me immensely in terms of ergonomics.
I've tested perhaps too many grip and controller alternatives for the Switch, including the Hori split pad pro / fit and the Satisfye grip.
Funnily enough this has been the most comfortable to hold, the smallest option:

image_6_149c5dc8-19a2-4d7f-a36b-51e5baa0b552.jpg


It's all because of the butt. My hand wants something to wrap around. I don't think they need to make the console significantly 'wider' than the original Switch for more ergonomic controls, but adding enough depth would help.

I was prompted by the AYANEO Lite here ("the tasteful thickness of it...").

Ayaneo-Next-Lite-2.jpg


I know some don't like how the buttons and sticks are oriented vertically on the existing joy-con for comfort but I am skeptical they would move away from that positioning. We already expect the console to be larger and I'm not sure they'd want to make it wider like the Deck.

Dumb question: what joy cons are those?
 
you need a vrr screen for that, which not many people have. and nintendo most likely won't put into their screen, especially if they're going LCD for teh sake of costs
Sorry to post you twice, but is that really true though? VRR is a screen that syncs output with the source. A panel with multiple fixed hz modes which I assume what SD has, is not VRR?

My old 1080p tv supports 24hz mode for Blu-rays. It certainly isn't VRR.
 
To my knowledge, most game engines on PC don't do even the non-DLSS equivalent of this, which is rendering in parallel to game logic. Unsurprising as there are latency costs, and it makes implementing a functional frame limiter really hard.
I could be completely wrong since you have much more experience than me in this regard. But I have the real impression that most games today already run with the CPU and GPU working in parallel on different frames.
That's why if a CPU today runs a game at a maximum of 40 FPS, adding a better GPU won't improve performance.
 
Out of curiosity, is it likely future DLSS versions will require beefier tensor cores? Or could they be optimized for previous hardware with existing tensor cores?
Depends on what the versions add. Different parts of DLSS 3.2 only work with new hardware, while optimizations and some new features still work with older hardware. It really depends on what NVidia is trying to accomplish and if that needs more hardware.
I wrote a long technical response here, but I don't think the technology actually matters that much.

If the Switch were a graphics card, it would be the most popular graphics card in the world. Nintendo isn't just a customer of Nvidia's, picking up the tech that Nvidia is developing in a vacuum. They're active partners with each other. Nvidia makes money if their next gen graphics cards have more bells and whistles. Nvidia also makes money if their major console partner has said bells and whistles.

And if the bells and whistles are in the Switch 2, that increases the number of games that will support those tools, and support them at a high level of quality.

RTX 50 will get cool stuff, and if Nvidia can leverage that extra power of course they will, and I'm sure they've got research teams working on it. But there is definitely cold hard cash invested in making those features scalable all the way down to the Switch 2's level of performance.
 
Sorry to post you twice, but is that really true though? VRR is a screen that syncs output with the source. A panel with multiple fixed hz modes which I assume what SD has, is not VRR?

My old 1080p tv supports 24hz mode for Blu-rays. It certainly isn't VRR.
Right none of the Deck screens support VRR but they have fixed Hz values they can switch to including 40, 60, 90 and some in betweens, which can improve input lag in low frame rate high refresh rate pairings like 45 fps @ 90 Hz.
 
I could be completely wrong since you have much more experience than me in this regard. But I have the real impression that most games today already run with the CPU and GPU working in parallel on different frames.
I may be incorrect in this in the architecture, but in terms of load, if you benchmark a game you can see alternating periods of CPU load and GPU load, so at the very least there is inefficient use of these resources. Which is understandable, parallelism is hard.
That's why if a CPU today runs a game at a maximum of 40 FPS, adding a better GPU won't improve performance.
I suspect this is just because of the CPU not being able to keep the GPU fed. You can be CPU bound regardless of how threaded your implementation.
 
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