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

Reader mode
ReyVGM said:
60fps is a thing on every console. It's the developer's choice to decide "hey, do I use this console's power for graphics or for framerate?"
Click to expand...
I think what they meant was "if 60fps is a thing for FFVIIR on the Switch NG"
 
0
Shoulder said:
All those years in Math class telling to simplify we’re all for naught. 😒

But seriously, due to there still being architectural differences, that still does allow bespoke instructions to be used that might be better suited to the hardware involved, correct?
Click to expand...
Only if the person making them is better than a modern C compiler. Which chances are, they're probably not. It's just a lot of work for benefits that are at best minor and theoretical, and at worst, non-existent or counterproductive.
 
Whenever I try out the touchpad on a Dualsense I always think "this would be cool on a Nintendo console". Based on the Legion Go's controller it looks like a touchpad could be feasible in both docked and handheld mode. It'd be like gyro where it's another optional input for devs that isn't obtrusive to gameplay (like looking away from the TV screen at the Wii U gamepad).

I'd personally like it for a cursor, scrolling, or quick menu.
 
Atlus said:
I think it’s time for new controls. The analog sticks and L&R shoulders have been the same for a while🤔
Click to expand...
Please, no, please, please, no, they're fine. Add to them, don't... Change them. Capacitance? Neat! Get rid of them?! Trackpads INSTEAD?!!!

PLEASE NO!!!
 
eye0h said:
Why is there so much headcanon that Nintendos licensing agreement for this game is some deal with beelzebubs name at the bottom? I don’t understand why everyone is so set on the licensing agreement being so stringent despite nobody being a lawyer and nobody seeing it
Click to expand...
Probably more of a matter of there being many publishers involved with licensed properties in smash ultimate that it increases the odds of one of those publishers creating problems.
 
Kingpin722 said:
I watched this preview of the Lenovo Legion. A couple parts stood out to me, 1. One of the "JoyCons" has a stand that helps turn it into a mouse to allow for FPS gameplay on the go. 2. Which the clip I'm posting highlights, It has some glasses that connect to the Legion via USB-C and projects the devices screen into the glasses.

These seem like a couple features that Nintendo would consider adding to the successor. If the camera rumor is true, maybe is has something to do with AR/VR capability. I could definitely see Nintendo innovating on the glasses feature shown in the clip.
Click to expand...

I really don‘t see the point why you can detach those controllers in most use cases most of the time, though while I think the Steam Deck is overall the cooler PC Handheld, I think this has some interesting ideas. The mouse thing is gimmicky but could be really nice.
 
0
Kingpin722 said:
I watched this preview of the Lenovo Legion. A couple parts stood out to me, 1. One of the "JoyCons" has a stand that helps turn it into a mouse to allow for FPS gameplay on the go. 2. Which the clip I'm posting highlights, It has some glasses that connect to the Legion via USB-C and projects the devices screen into the glasses.

These seem like a couple features that Nintendo would consider adding to the successor. If the camera rumor is true, maybe is has something to do with AR/VR capability. I could definitely see Nintendo innovating on the glasses feature shown in the clip.
Click to expand...

Mouse functionality has potential but ideally would love a way to be able to do that mouse functionality while holding the joycon in a more normal orientation so that all of the buttons and the analog stick are easily accessible in mouse mode.

Come to think of it, does anyone know if the IR camera on the R switch joycon is theoretically capable to doing something like this mouse thing? Dont modern optical mice basically just use an LED light and a camera as a way to detect movement?
 
0
Bonejack said:
I think we regulars should be a bit more mean to the lurkers who post to see the hidden content.

Like ... introduce yourself, explain what you bring to the discussion.

What do the other regulars think?

;D
Click to expand...
Do lurkers even read the OP?

I feel like most new posts are like kneejerk reactions to the latest things heard in this thread, without prior context.
 
Does Nintendo include HDMI 2.1 in the NG Switch to the dock to future proof it or for the rare game that might try 4K 120 FPS?

Will they include a HMDI 2.1 cord in the box?

A AAA UE5 game wouldn’t be able to do that with all the other high end graphic features, but a stripped down game like Olli Olli World might could do it on NG Switch.
 
Danny said:
I think the significance of Nintendo merging their handheld and console divisions means that its almost permanent commitment from their part. Which means that the Switch was not a one off system, Nintendo plans to continue making hybrid console systems in the future.
Click to expand...
Merging the studios, as a decision, predates the decision to make a hybrid. Nintendo made a hybrid because they merged the divisions not the other way around.

The goal was to make development cheaper and higher quality by developing a handheld that shared an architecture with the TV console. That lead to a single device that did both, but that doesn’t lock them into only that strategy.

Nintendo could have separate handheld, VR, TV lines - or even more, like a second line of mini Pokémon handhelds - all using NVN. And knowing Nintendo there are regular experiments on all of those things and more, ongoing all the time.

Experiments which will likely never make it to market, or will wind up in accessory products like Mario Kart Live, or at the theme parks. The hybrid is here to stay, simply because it’s a good idea, not because Nintendo put all their eggs in the hybrid basket.
 
TheSentry said:
Does Nintendo include HDMI 2.1 in the NG Switch to the dock to future proof it or for the rare game that might try 4K 120 FPS?

Will they include a HMDI 2.1 cord in the box?

A AAA UE5 game wouldn’t be able to do that with all the other high end graphic features, but a stripped down game like Olli Olli World might could do it on NG Switch.
Click to expand...
Recent Nintendo is unlikely to include things "just in case". That ended with the GC.
 
PedroNavajas said:
Recent Nintendo is unlikely to include things "just in case". That ended with the GC.
Click to expand...

I recently discovered that my original GCN, which was thought to be lost, was actually sitting in a box at my parent's house with my brother's name on it rather than mine. And it's the original model with the Digital Out connection, so a simple HDMI adapter would work wonders to keep the thing going.

But then I do have my Wii U still, and homebrew is still popular on it. Would make a great multigenerational gaming console. :sneaky:
 
0
Concernt said:
Only if the person making them is better than a modern C compiler. Which chances are, they're probably not. It's just a lot of work for benefits that are at best minor and theoretical, and at worst, non-existent or counterproductive.
Click to expand...
There are some things compilers aren't always great at, notably vector (SIMD) code. This isn't so much that vector code is much more difficult to compile than scalar code (although it is a bit), but moreso that vector support on CPUs is a complete mess of different standards, so compiling code that will work well across a wide range of hardware is a pain. As an example, here's a diagram of the current state of vector extensions on x86:

F0YQqe4WwAEshd1


Vector heavy code will typically be implemented using intrinsics to target specific hardware capabilities. Intrinsics aren't exactly assembly language, but they map directly to assembly language for a given processor. For consoles this is relatively simple, as someone writing code for, say the PS5, will know the exact set of instructions in the diagram above that the Zen 2 core supports, and can write code using intrinsics for those instructions without worrying about the rest. If you want vector-heavy code to run well across a wide range of hardware on PC, you'll probably have code that has a lot of switch statements with intrinsics for whichever of the 31 different feature sets you want to support. An ARM chip like TX1 or T239 will then need different vector intrinsics from an x86 chip.

Incidentally, as the discussion of whether Nintendo will or should use newer ARM CPUs like the A710 or A715 has come up now and again, this is probably the best argument to do so, because of the SVE2 vector instructions supported by ARMv9 CPUs from the A710 onwards. These are independent of vector length, which substantially simplifies the problem of optimising for different architectures (although ARM was already a lot simpler than the x86 diagram above), but they're also much better for auto-vectorisation, where the compiler finds ways that scalar code (mostly for loops) can be mapped to vector instructions to increase performance. Game developers would still use vector intrinsics wherever they can, but SVE2 would make their job a bit easier when it comes to having a single set of intrinsics which will work well across a wider range of hardware, and allowing the compiler to catch some additional vectorisation opportunities which the developer may have missed.
 
Serif said:
Whenever I try out the touchpad on a Dualsense I always think "this would be cool on a Nintendo console". Based on the Legion Go's controller it looks like a touchpad could be feasible in both docked and handheld mode. It'd be like gyro where it's another optional input for devs that isn't obtrusive to gameplay (like looking away from the TV screen at the Wii U gamepad).

I'd personally like it for a cursor, scrolling, or quick menu.
Click to expand...
I always through the back touch pad on Vita was a dumb idea that Nintendo would've pulled off better.
 
Serif said:
Whenever I try out the touchpad on a Dualsense I always think "this would be cool on a Nintendo console". Based on the Legion Go's controller it looks like a touchpad could be feasible in both docked and handheld mode. It'd be like gyro where it's another optional input for devs that isn't obtrusive to gameplay (like looking away from the TV screen at the Wii U gamepad).

I'd personally like it for a cursor, scrolling, or quick menu.
Click to expand...
Would definitely be great for radial menus.
 
D36 said:
I hope something crazy doesn't happen again that makes this thread zoom by half a dozen pages. I wanna finish watching One Piece Live Action tonight and I'm worried I'll be way behind again. 😅
Click to expand...
TBH I love when that happens lol.

So much juicy stuff you get to catch up on instead of pages of us thirsting so hard for leaks. 🤣
 
Kingpin722 said:
I watched this preview of the Lenovo Legion. A couple parts stood out to me, 1. One of the "JoyCons" has a stand that helps turn it into a mouse to allow for FPS gameplay on the go. 2. Which the clip I'm posting highlights, It has some glasses that connect to the Legion via USB-C and projects the devices screen into the glasses.

These seem like a couple features that Nintendo would consider adding to the successor. If the camera rumor is true, maybe is has something to do with AR/VR capability. I could definitely see Nintendo innovating on the glasses feature shown in the clip.
Click to expand...

Man this device looks so cool. Glad we're seeing more handheld PCs, I love my Steam Deck and I love seeing what other companies can do. The FPS mode would be such a neat feature for a future Switch!
 
0
Another crazy idea i just hatched
what if the rumored camera like thing on the console
is actually a PROJECTOR??? Somethin that could be used during a campfire, or in the backyard to watch netflix/play smash with the buddies?
eh? eh?
 
Shoulder said:
But seriously, due to there still being architectural differences, that still does allow bespoke instructions to be used that might be better suited to the hardware involved, correct?
Click to expand...
No? Yes? Depends on what you mean by bespoke instruction.

No, in the sense that there will not be bespoke Nintendo-only CPU instructions.

Yes, in the sense that there are places that one architecture is superior at to the other. But that advantage is already represented in the benchmarks. Thraktor has a good example in his above post. Let me walk you through another one.

A developer needs to add 1 to a number. They write code like this*

Code: 
int increment(int num) {
    return num++;
}

A function increment takes a whole number (an integer), named num and sends back (returns) num + 1 (++ is shorthand for +1**). The extra int before increment is just a promise that we'll never return anything that isn't an integer, and the punctuation is just that.

This is the C programming language. Your computer doesn't understand C from anything else. Your computer only understands its ISA - Instruction Set Architecture - and ARM and Zen CPUs have different ISAs. But most of the time, developers don't worry about that - they write code in C because a compiler will translate this generic code into the specific ISA for whatever CPU you want to run on.

The compiler that Nintendo uses is called Clang - here is Clang turning that C code into ARM code.

Code: 
increment(int):  
        sub     sp, sp, #16
        str     w0, [sp, #12]
        ldr     w0, [sp, #12]
        add     w8, w0, #1
        str     w8, [sp, #12]
        add     sp, sp, #16
        ret

You might have been able to understand the C just by reading it, or at least with a quick explanation, but this is nonsensical. Even to most programmers, in fact. The important thing in this context is that it's 8 lines long. Now let's look at the x86 example, the ISA that Zen uses, generated by the same Clang compiler.

Code: 
increment(int):     
        push    rbp
        mov     rbp, rsp
        mov     dword ptr [rbp - 4], edi
        mov     eax, dword ptr [rbp - 4]
        mov     ecx, eax
        add     ecx, 1
        mov     dword ptr [rbp - 4], ecx
        pop     rbp
        ret

Wildly different right? There are some similarities, but for the most part, this is a different thing entirely. And you'll note, this is 10 instructions long. All else being equal***, the ARM code will run 20% faster than the x86 code. In this narrow case, the design of the ARM ISA is superior.

However - that "superiority" - and any others, as well as any inferiorities - is already baked into benchmarks. Because benchmarks are also written in C and compiled. So while there might be plenty of theoretical advantages of one architecture over the other - and the big one is just that ARM is delivering great performance for every watt of electricity spent, even if the ceiling on that performance is lower - they don't exist above and beyond the benchmarks

Where benchmarks fall down is when they don't accurately reflect how the system will be used. Geekbench is pretty good in that all of its benchmarks are derived from real world code that runs on desktops all the time. It compresses a file, renders a webpage, loads a PDF, etcetera. But that doesn't make it a perfect representation of game load, and even a game oriented benchmark won't reflect every video game.

You can scroll down and see the individual sub-benchmarks. You can see that Switch looks good partially because image processing benchmarks are so much unbelievably faster on ARM. That is almost definitely because of the vectorization instructions that Thraktor was talking about before. But in a game's context, it's highly likely that these sorts of operations wouldn't happen on the CPU at all, they'd happen on the GPU. In which case, a game console might underperform the benchmarks considerably.

That's why benchmarks try to perform lots of different tasks. Because on a frame-by-frame basis, a CPU is going to execute thousands of operations, and a few of them might favor one architecture and the rest another, and you need to stress the CPU in lots of different ways to see what real world performance will look like.

Deep, extended optimization is often about replacing easy-to-understand, logical code with hard-to-understand, deeply insane code that doesn't look anything like a smart way to solve the problem, but happens to hit the optimal path more often on your target architecture. That's why optimization is so often the final pass in building any game, or really any software period.

* they would never write code like this, because it's a silly thing to have a function do, but it's an example
** it actually has some nuances that are not worth getting into here about order of operations, but ignore that for a sec
*** all else is never equal, of course
 
I wasn't expecting that mouse feature on the lenovo legion go, really cool IMO.

But I very much still prefer the gyro + analog stick combo.
 
Thraktor said:
Edit: Although if we're talking about true mixed precision workloads, where games are running a mix of FP32 and FP16 code, I wouldn't discount the fact that Ampere can run both concurrently. On Switch/PS5/XBSX if a game is running a mix of 50% FP32 and 50% FP16, you're only going to get a 33% speedup over pure FP32, as you have to take cores away from FP32 work to run FP16 code. On Ampere you could get as much as a 100% speedup.

As a real-world comparison, if we were to compare the Series S to a 1GHz T239 in performance on 100% FP32 workloads, the Series S would hit 4.0 Tflops to T239's 3.1 Tflops. At pure FP16 workloads, the Series S would outperform T239 by 8.0 Tflops to 3.1 Tflops. However, if we change to a workload that's a 50/50 mix of FP32 and FP16 code, the Series S could hit 5.33 Tflops, whereas T239 at 1GHz would be capable of 6.14Tflops. Of course we shouldn't directly compare Tflops numbers between very different architectures, and there are many other factors like memory bandwidth, etc, etc. The important thing isn't the absolute numbers, but the fact that in use-cases where developers are utilising a mix of FP32 and FP16 code, the fact that Ampere has distinct ALUs for FP32 and FP16 code which can operate concurrently is a worthwhile advantage over the single set of ALUs of RDNA, even though the latter may hit higher theoretical performance on one or the other.
Click to expand...
Sorry for coming back to this post (now over a month old), but I'm not quite understanding how that T239 number of 6.14TFlops is achieved. I do see you mention below the bolded about distinct ALUs for the two, but is this meant as some combination of using CUDA cores for FP32 and tensor cores for FP16? That even though a tensor core can theoretically do 8x the FP16 operations that a processing block (1 of 4 in an SM) of 64 CUDA cores can do (based on ratios in the whitepaper), it is limited by the ALUs?
 
oldpuck said:
Merging the studios, as a decision, predates the decision to make a hybrid. Nintendo made a hybrid because they merged the divisions not the other way around.

The goal was to make development cheaper and higher quality by developing a handheld that shared an architecture with the TV console. That lead to a single device that did both, but that doesn’t lock them into only that strategy.

Nintendo could have separate handheld, VR, TV lines - or even more, like a second line of mini Pokémon handhelds - all using NVN. And knowing Nintendo there are regular experiments on all of those things and more, ongoing all the time.

Experiments which will likely never make it to market, or will wind up in accessory products like Mario Kart Live, or at the theme parks. The hybrid is here to stay, simply because it’s a good idea, not because Nintendo put all their eggs in the hybrid basket.
Click to expand...
Yup, next Switch aka Switch 2 will definitely be a Hybrid. But next gen after Switch 2, Nintendo can experiment again maybe a hybrid with 1 new addition TV only console that compete head to head with a PS6, who knows
 
0
Saturnman789 said:
Another crazy idea i just hatched
what if the rumored camera like thing on the console
is actually a PROJECTOR??? Somethin that could be used during a campfire, or in the backyard to watch netflix/play smash with the buddies?
eh? eh?
Click to expand...
Ngl, would be interesting. Projectors are big tho. See the Lenovo Yoga Tab 3 Pro
 
oldpuck said:
No? Yes? Depends on what you mean by bespoke instruction.

No, in the sense that there will not be bespoke Nintendo-only CPU instructions.

Yes, in the sense that there are places that one architecture is superior at to the other. But that advantage is already represented in the benchmarks. Thraktor has a good example in his above post. Let me walk you through another one.

A developer needs to add 1 to a number. They write code like this*

Code: 
int increment(int num) {
    return num++;
}

A function increment takes a whole number (an integer), named num and sends back (returns) num + 1 (++ is shorthand for +1**). The extra int before increment is just a promise that we'll never return anything that isn't an integer, and the punctuation is just that.

This is the C programming language. Your computer doesn't understand C from anything else. Your computer only understands its ISA - Instruction Set Architecture - and ARM and Zen CPUs have different ISAs. But most of the time, developers don't worry about that - they write code in C because a compiler will translate this generic code into the specific ISA for whatever CPU you want to run on.

The compiler that Nintendo uses is called Clang - here is Clang turning that C code into ARM code.

Code: 
increment(int): 
        sub     sp, sp, #16
        str     w0, [sp, #12]
        ldr     w0, [sp, #12]
        add     w8, w0, #1
        str     w8, [sp, #12]
        add     sp, sp, #16
        ret

You might have been able to understand the C just by reading it, or at least with a quick explanation, but this is nonsensical. Even to most programmers, in fact. The important thing in this context is that it's 8 lines long. Now let's look at the x86 example, the ISA that Zen uses, generated by the same Clang compiler.

Code: 
increment(int):    
        push    rbp
        mov     rbp, rsp
        mov     dword ptr [rbp - 4], edi
        mov     eax, dword ptr [rbp - 4]
        mov     ecx, eax
        add     ecx, 1
        mov     dword ptr [rbp - 4], ecx
        pop     rbp
        ret

Wildly different right? There are some similarities, but for the most part, this is a different thing entirely. And you'll note, this is 10 instructions long. All else being equal***, the ARM code will run 20% faster than the x86 code. In this narrow case, the design of the ARM ISA is superior.

However - that "superiority" - and any others, as well as any inferiorities - is already baked into benchmarks. Because benchmarks are also written in C and compiled. So while there might be plenty of theoretical advantages of one architecture over the other - and the big one is just that ARM is delivering great performance for every watt of electricity spent, even if the ceiling on that performance is lower - they don't exist above and beyond the benchmarks

Where benchmarks fall down is when they don't accurately reflect how the system will be used. Geekbench is pretty good in that all of its benchmarks are derived from real world code that runs on desktops all the time. It compresses a file, renders a webpage, loads a PDF, etcetera. But that doesn't make it a perfect representation of game load, and even a game oriented benchmark won't reflect every video game.

You can scroll down and see the individual sub-benchmarks. You can see that Switch looks good partially because image processing benchmarks are so much unbelievably faster on ARM. That is almost definitely because of the vectorization instructions that Thraktor was talking about before. But in a game's context, it's highly likely that these sorts of operations wouldn't happen on the CPU at all, they'd happen on the GPU. In which case, a game console might underperform the benchmarks considerably.

That's why benchmarks try to perform lots of different tasks. Because on a frame-by-frame basis, a CPU is going to execute thousands of operations, and a few of them might favor one architecture and the rest another, and you need to stress the CPU in lots of different ways to see what real world performance will look like.

Deep, extended optimization is often about replacing easy-to-understand, logical code with hard-to-understand, deeply insane code that doesn't look anything like a smart way to solve the problem, but happens to hit the optimal path more often on your target architecture. That's why optimization is so often the final pass in building any game, or really any software period.

* they would never write code like this, because it's a silly thing to have a function do, but it's an example
** it actually has some nuances that are not worth getting into here about order of operations, but ignore that for a sec
*** all else is never equal, of course
Click to expand...
For this example you'd actually want
Code: 
int increment(int num) {
    return ++num;
}
as doing num++ is equivalent to doing
Code: 
auto k = num + 1;
return num;
while ++num is equivalent to return num + 1

Which gives diff asm:
aarch64:
Code: 
test(int):                               // @test(int)
        sub     sp, sp, #16
        str     w0, [sp, #12]
        ldr     w8, [sp, #12]
        add     w0, w8, #1
        str     w0, [sp, #12]
        add     sp, sp, #16
        ret
x86_64:
Code: 
test(int):                               # @test(int)
        push    rbp
        mov     rbp, rsp
        mov     dword ptr [rbp - 4], edi
        mov     eax, dword ptr [rbp - 4]
        add     eax, 1
        mov     dword ptr [rbp - 4], eax
        pop     rbp
        ret

However this is not what you're going to get in a production program in practice as this is without compiler optimizations, with optimizations you get:
aarch64:
Code: 
test(int):                               // @test(int)
        add     w0, w0, #1
        ret
x86_64:
Code: 
test(int):                               # @test(int)
        lea     eax, [rdi + 1]
        ret

In this case they both become two instructions, in most/many cases aarch64 is going to require more instructions than x86 to do the same things. But the instructions on aarch64 are going to be less complex and take less time to perform than x86's complex instructions.
 
Hermii said:
What exactly was too good to be true?
Click to expand...
implying Switch sucessor is a portable PS5 and this suposed port for Final Fantasy 7 remake, took no time to be ported/adapted to Nintendo next hardware, everyone is expecting a hybrid console with similar if not superior PS4 like specs, sort of a portable PS4.
 
Reader mode
You must log in or register to reply here.
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