Editorial: Nintendo Switches Course

It's almost as if they took out the main control board with the CPU and GPU, isn't it?

The Wii U GamePad contains a significant amount of free space within.

It was code-named Project Cafe, and with it Nintendo was working on a hybrid handheld/living room gaming experience. With the planning stages of development beginning in 2008, the concept eventually became a switch from the traditional console model, and the design became a large device with physical controls on each side, and a touch-enabled display in the middle. While this became the Wii U GamePad, it seems reasonable to assume that Nintendo may have been working on an early version of what we now know as “Switch” all along, but was hampered by the limitations of technology at the time. It makes sense: Nintendo had many years of experience in making portable game systems, with various iterations of the Game Boy and DS (dual-screen) handheld systems over the years; but harnessing the power necessary to provide a proper living room gaming experience, while keeping the device small and light enough to reside within the controller, was surely a daunting task. The Wii U GamePad, in its nearly complete state by the 2012 E3 convention, was quite large; but was this perhaps necessary due to the electronics that would have resided within its chunky plastic chassis? It could be that Nintendo had actually planned to fit the entire console inside of this controller design, and that is not unfathomable considering the emergence of a new, high-resolution wireless display technology during the Wii U’s development.

Intel, the world’s largest manufacturer of semiconductor chips, had created a technology known as WiDi (wireless display, now discontinued), which supported up to 720p video streams in its initial version in 2010 (and up to 1080p with version 2.0 in 2011). But WiDi was not going to be simple to implement for a game console that would connect to living room televisions, none of which were shipping with WiDi as a built-in hardware feature. A costly receiver would be required to connect the system to a TV if Nintendo had any intention of making this concept work, and even then latency would have been a concern. (Miracast would become common for wireless display connectivity, but with its introduction in late 2012 it was too late for implementation within Project Cafe, and would still introduce latency issues.) It seems safe to assume that the ambitious design of the Project Cafe prototype was already demanding significant component costs, and if the console was to be released at anything approaching a competitive price it was going to have to be scaled back somewhat. But dropping the wireless display option entirely was clearly not considered an option, as the approved concept included a handheld, touch-screen equipped controller capable of displaying game content. Nintendo obviously envisioned a gaming tablet as the future of their consoles.

Nintendo wishes it was still 2010, when this would have been relevant and cool.

The Switch is everything Nintendo wanted the Wii U to be.

With the explosion of mobile app ‘games’ commanding the attention of the casual gaming audience (something the Wii had initially done with such success), Apple’s iPad launch in early 2010 was quite influential, and Nintendo was likely convinced even then that gaming was moving in this mobile direction. The appeal of a Nintendo-branded tablet would have been immense for a company that has made proprietary hardware the basis of their software, and there was no inkling of jumping on Apple’s successful platform and developing games for the iPad and iPhone (at that time). Nintendo had been riding on the unqualified success of the Wii, and tablets were sexy in 2010, with many hardware makers vying for their share of that market. But a hardware solution such as the one found that first iPad (a proprietary SoC using highly optimized CPU cores based on ARM architecture, and a low-power mobile GPU) would not be sufficient to position a console at parity with the offerings from Sony and Microsoft. (For that matter, mobile processing has still not advanced to the point where such an option could replace a traditional console in 2017, and it was worlds away in 2010.) What to do? Nintendo solved their problem in two ways: by creating a console to act as a wireless game server with full console capability, and implementing a low-latency wireless display technology themselves. This enabled the simulation of a full game system within the controller, with a base console designed to operate as silently and unobtrusively as possible in the background.

Former Nintendo President Satoru Iwata explained:
“The Wii U GamePad isn’t for directly processing the games. Signals are sent from various input devices to the Wii U console, where it performs the processing. The Wii U GamePad then show images sent from the Wii U console. It not only exchanges data wirelessly with the Wii U console, but it also is capable of performing actions on its own, like using the TV remote features.”

Obviously no game ended up being exclusive to the built-in 6.2-inch screen on the GamePad, and the standard gaming paradigm of playing through a connected television placed the Wii U GamePad in the odd position of large, awkward game controller with a superfluous display (unless this screen was put to use for other game functionality by the developer). Just as with the DS, the touch screen could be implemented for menu system, maps or inventory management, or the like; and there was also the ability for the developer to implement what Nintendo called Off-TV Play. Many Wii U titles ended up being compatible with this mode, which did allow for the system to run without a connected television, and the GamePad operating as console with actual processing offloaded to the wirelessly-connected Wii U system.

A powerful graphics solution - unless you want to power a console. Then it kind of sucks.

NVIDIA’s Tegra X1 SoC powers the Nintendo Switch.

In many ways the Switch is simply the full realization of the Wii U concept: a hybrid console without the need for a separate box. (Though the Switch does come with a dock, for performance reasons we will discuss below). Nintendo believes that mobile processing has progressed to the point where offloading the CPU/GPU duties to a connected console is no longer necessary. To that end a partnership with NVIDIA was formed, using technology from the existing SHIELD devices to form the basis of the ‘new’ Switch console. The SHIELD family has been on the market for a few years now, and the Switch appears to borrow from both the current SHIELD K1 tablet and SHIELD TV products. The reason Nintendo chose to work with NVIDIA is simple: NVIDIA’s Tegra SoC (system-on-a-chip) boasts significantly higher gaming performance compared to other mobile platforms due to the integration of powerful GPU cores. However, this disparity in performance is strictly within the world of mobile graphics, as even NVIDIA’s lowest-cost GTX desktop parts outclass the Tegra X1 so significantly, it should raise eyebrows as to how much of an improvement the Switch might be over the outgoing Wii U from a graphics standpoint. Another issue with Tegra is battery life, and this is directly related to its GPU potency compared to standard integrated mobile graphics solutions, and to its inherent power inefficiency based on process technology. The Tegra X1 in Nintendo’s Switch is considerably more powerful than the older Kepler-based part in the SHIELD K1 (Tegra K1) gaming tablet, and NVIDIA has built the 2nd-gen Maxwell SoC on a 20nm process, down from 28nm with the Kepler-powered K1. Still, modern SoCs are built on 14 and 16nm process technology today (and the newest on 10nm), and offer better power characteristics than NVIDIA currently provides with Tegra, even if the more efficient SoC’s GPU power has yet to catch up to NVIDIA. Not only has the process technology for Tegra not caught up to the rest of the mobile industry, but no Tegra solution yet exists built with NVIDIA’s newest architecture, Pascal.

The Tegra X1 in the Switch features a 2nd-gen Maxwell GPU with 256 CUDA cores, 4GB of shared system memory with 25.6 GB/s of available bandwidth, and (according to a report published by Ars Technica) operates at 768 MHz docked, and only 307.2 MHz in portable mode. Maxwell is optimized to use memory compression to reduce overhead, but memory bandwidth is still an issue for the Switch, as the GPU will simply not be able to push as many pixels as the competition. But there is more to it than that. Raw performance of the Switch GPU, based on the reported specifications, equates to approximately 785 GFLOPs at 768 MHz (docked), and 315 GFLOPS at 307.2 MHz (portable). To put this floating-point performance into perspective, a PlayStation 4 offers 1840 GFLOPS, with the Xbox One around 1311 GFLOPS. The outgoing Wii U GPU offers 352 GFLOPS, but there is a significant difference in this measurement and that of the Switch: the only way the Tegra X1 offers the performance (GFLOPS) listed above is by employing half-precision (FP16), rather than single-precision (FP32) floating-point operations. FP16 is common to mobile graphics, and this does not bode well for the console side of the Switch. As AnandTech (the source of the X1 FP16/FP32 performance breakdown) pointed out in their preview of the Tegra X1 GPU, “FP16 operations are heavily used in Android’s display compositor due to the simplistic (low-precision) nature of the work and the power savings”, and we should not be surprised if Switch titles look more like mobile games. At FP32 the Switch would offer half of the rated performance numbers in GFLOPS, placing it just ahead of the Wii U when docked, and far below it in portable mode. It will obviously take more than optimization to make Switch games run smoothly, with lower complexity for lighting and shading (and perhaps lower resolution and frame-rates) required, compared to other consoles.

But the reported 60% drop in GPU clock speed un-docked renders that concept moot.

The Nintendo Switch might have been a capable portable machine.

To make a living room console a mobile-first device might mesh with Nintendo’s obvious strategy going forward, but it hobbles what could have been a much more potent console for the gamers who still play in front of a TV. Mobile gaming is all about convenience, but the trade-off is the lower powered hardware, and thus the inability to recreate the same experience as a current-gen console. Nintendo has created a console that is already hobbled in its docked state, and reduced to a downright miserly speed when running on battery. Architectural advancement will be needed to produce the required rendering horsepower without a significant power penalty, and the use of the Tegra X1 did Nintendo no favors. However, the need to get the product to market, with no Pascal alternative available from partner NVIDIA, undoubtedly played a role (if we are to believe that Nintendo ever cared about delivering a high-quality graphical experience with Switch). The emphasis placed on display-free gaming during Nintendo’s presentation of the 1-2-Switch title seems to confirm the inadequacy of the Switch as a mobile gaming platform, rendering this entire venture pointless.

10 Comments

  1. Lusipurr
    Posted 2017.01.19 at 14:31 | Permalink

    This is easily the most in-depth technical review of the Switch I’ve read.

  2. Sebastian
    Posted 2017.01.20 at 13:48 | Permalink

    It became more and more technical during the editing phase. A lighthearted article based on tin-hat conspiracy theories evolved into something that could almost be considered legitimate analysis.

    That was never my intent, and I apologize. Next week: fluff!

  3. SiliconNooB
    Posted 2017.01.20 at 22:10 | Permalink

    if we are to believe that Nintendo ever cared about delivering a high-quality graphical experience with Switch

    AKA: Pascal Architecture’s Wager!

  4. Cari
    Posted 2017.01.21 at 03:10 | Permalink

    I’m still convinced this is their attempt to move into the Android Google Play market. They want to change format and be a mobile game developer.

  5. SiliconNooB
    Posted 2017.01.21 at 03:58 | Permalink

    Then they have laughably mispriced it. When I see kids with pads they are usually generic Android pads from Target that cost about $80 – $120.

  6. Cari
    Posted 2017.01.21 at 06:55 | Permalink

    Yeah but they want to be the ‘premium’ manufacturer and mark up the price. Also all else fails they can dump the console and just switch all their development to the generic android market. Just wild speculation on my part I know but I can’t help but think they are thinking at least one or two steps ahead on the assumption this flops as hard as many expect it to.

  7. SiliconNooB
    Posted 2017.01.21 at 08:55 | Permalink

    It doesn’t work as a premium product either, as people who buy expensive pads expect a certain degree of functionality, and Nintendo is so restrictive with what you can do with their products that they are not fit to purpose.

    It only works as a premium product for children, which is a small market.

  8. Cari
    Posted 2017.01.21 at 09:13 | Permalink

    I don’t disagree at all. It’s why it’s doomed to fail in my eyes. I know it, you know it, the R and D team that made the damn thing knows it. It’s a complete bollock smacking disaster.

  9. Gyme
    Posted 2017.01.21 at 09:15 | Permalink

    I don’t think they would switch their development to the Play Store. The Play Store takes a bigger cut of sales than Sony or Microsoft and is much, much, much easier to pirate from. Also, many mobile gamers won’t pay much more than $5.00 for a game. If Super Mario Run is any indication, Nintendo would need to massively change their expectations if they were to make the switch to mobile game development.

  10. Cari
    Posted 2017.01.21 at 17:04 | Permalink

    True, I didn’t say it was a good idea though. Just the most likely based on how the industry covets those mobile whales.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>