A53 and A57 have fixed cache line sizes of 64 bytes
- Status
A53 and A57 have fixed cache line sizes of 64 bytes
D
Deleted member 11852
Guest
Digital Foundry: New performance mode boosts Switch mobile clocks by 25 per cent
Digital Foundry on how developers can access more Switch GPU power, plus analysis of the recent teardown.
Digital Foundry on how developers can access more Switch GPU power, plus analysis of the recent teardown.
Meaningful snippets:
The difference between 16nm and 20nm isn't actually about transistor size, but more about the 3D 'FinFET' transistors on the lower node. A 16nm SoC would be approximately the same size as the existing 20nm Tegra X1, but the difference here is that the teardown reveals a processor with seemingly identical dimensions. Also interesting is that the processor is surrounded by the same surface-mounted arrangement of what are likely to be decoupling capacitors, there to reduce noise on the power lines. The initial conclusion we have is that we are looking at a more lightly modified X1, still on the 20nm process, which ties in more closely with the clocks we reported - and indeed every non-Foxconn spec leak seen to date.
However, there is some interesting news. While the main clock configurations for docked and undocked modes remain the same, Nintendo has added to the available performance modes available to developers in a recent update. However, we're looking at a bump to mobile GPU power, not a validation of the Foxconn clock-speeds. If the frequencies reported there were ever running on Switch, we believe they may well have been a stress test of thermal limits on the X1-derived hardware, designed to offer Nintendo a best-case scenario on just how far the processor could be pushed with its chosen cooling assembly, before finalising its retail specification. Modern consoles tend to be more conservatively clocked in order to ensure stability and reliability.
As things stand, our previously reported CPU and GPU clocks remain the default configurations for docked and handheld modes. However, having looked first-hand at a revised version of the document we previously saw in December, a new 'NX add-on' note appended to the doc introduces an expanded table of operating modes. This is how the table looks now, with the new additions in bold.
Available CPU Speeds, Available GPU Speeds ,Available Memory Controller Speeds
Undocked: 1020MHz, 307.2MHz/384MHz, 1331.2MHz
Docked: 1020MHz, 307.2MHz/384MHz/768MHz, 1331.2MHz/1600MHz
The key addition is a new mode seemingly designed to beef up handheld performance. Developers can opt for a 384MHz GPU clock - a straight 25 per cent uplift in compute power compared to the default 307.2MHz option. Both frequencies are available to developers in what it calls 'normal mode' operation - and to be clear, users will not be able to choose between them. Additionally, adjustments have been made to available memory bandwidth. In our prior story, we revealed that in undocked mode, developers could choose between running the LPDDR4 memory at either 1600MHz or 1331.2MHz. The 1600MHz option is now only available in 'boost mode' - when Switch is docked - while 1600MHz support in mobile mode is deprecated. As before, developers can opt to run handheld modes while in the dock too, and to be clear, the documentation has no new modes for docked performance. On top of that, we should stress that not all games will use the 384MHz GPU mobile mode - game-makers will choose the best fit for their projects, and 307.2MHz remains the default option.
The difference between 16nm and 20nm isn't actually about transistor size, but more about the 3D 'FinFET' transistors on the lower node. A 16nm SoC would be approximately the same size as the existing 20nm Tegra X1, but the difference here is that the teardown reveals a processor with seemingly identical dimensions. Also interesting is that the processor is surrounded by the same surface-mounted arrangement of what are likely to be decoupling capacitors, there to reduce noise on the power lines. The initial conclusion we have is that we are looking at a more lightly modified X1, still on the 20nm process, which ties in more closely with the clocks we reported - and indeed every non-Foxconn spec leak seen to date.
However, there is some interesting news. While the main clock configurations for docked and undocked modes remain the same, Nintendo has added to the available performance modes available to developers in a recent update. However, we're looking at a bump to mobile GPU power, not a validation of the Foxconn clock-speeds. If the frequencies reported there were ever running on Switch, we believe they may well have been a stress test of thermal limits on the X1-derived hardware, designed to offer Nintendo a best-case scenario on just how far the processor could be pushed with its chosen cooling assembly, before finalising its retail specification. Modern consoles tend to be more conservatively clocked in order to ensure stability and reliability.
As things stand, our previously reported CPU and GPU clocks remain the default configurations for docked and handheld modes. However, having looked first-hand at a revised version of the document we previously saw in December, a new 'NX add-on' note appended to the doc introduces an expanded table of operating modes. This is how the table looks now, with the new additions in bold.
Available CPU Speeds, Available GPU Speeds ,Available Memory Controller Speeds
Undocked: 1020MHz, 307.2MHz/384MHz, 1331.2MHz
Docked: 1020MHz, 307.2MHz/384MHz/768MHz, 1331.2MHz/1600MHz
The key addition is a new mode seemingly designed to beef up handheld performance. Developers can opt for a 384MHz GPU clock - a straight 25 per cent uplift in compute power compared to the default 307.2MHz option. Both frequencies are available to developers in what it calls 'normal mode' operation - and to be clear, users will not be able to choose between them. Additionally, adjustments have been made to available memory bandwidth. In our prior story, we revealed that in undocked mode, developers could choose between running the LPDDR4 memory at either 1600MHz or 1331.2MHz. The 1600MHz option is now only available in 'boost mode' - when Switch is docked - while 1600MHz support in mobile mode is deprecated. As before, developers can opt to run handheld modes while in the dock too, and to be clear, the documentation has no new modes for docked performance. On top of that, we should stress that not all games will use the 384MHz GPU mobile mode - game-makers will choose the best fit for their projects, and 307.2MHz remains the default option.
What's the choice selection criteria for devs? That is, why not clock higher? It's not as if you can advertise 'low battery consumption' as a feature of your game to sell it where all the other games are prettier while they burn through watts 80 MHz faster!
D
Deleted member 11852
Guest
Maybe just need? Most games will eat all the performance available but many games will likely run fine at lower clocks.
But why would you pick lower clocks? Let's say your game is running okay at the lower clock - enable the higher clock and you'll have a more stable framerate when things get busy. Some games like match-three won't need it, but otherwise I think just keeping the higher clock speed will be the preferred choice, to the point I'm not sure why it isn't just set to that.
Max memory clock in handheld mode has dropped, likely contributing to the headroom for an increase in GPU clocks.
Seems like a reasonable tradeoff - it's at max docked clocks that the highest level of BW will be most needed.
Hopefully this can put to bed the arguments about Foxconn leak clocks and a secret last minute switch to A73 cores.
Seems like a reasonable tradeoff - it's at max docked clocks that the highest level of BW will be most needed.
Hopefully this can put to bed the arguments about Foxconn leak clocks and a secret last minute switch to A73 cores.
D
Deleted member 11852
Guest
Running at higher clocks with wasted cycles is likely worse for the battery than running at a lower clock. That's really the only reason that makes sense. Well that and thermal considerations.
Yes, that's the principle. However, the choice of which clock to use is the devs. Using the higher clock gives a performance advantage to help sell your game. Using the lower clock gives you better battery life that doesn't help sell your game. So why would any devs choose to use the lower clocks? As a silent favour to their customers to give them a bit of extra battery life?
Rikimaru
Veteran
I'm sure titles like BoxBoy could get > 120 fps on lower clocks.
Higher resolution and limited bandwidth still seems to be the most obvious answer. There's a lotta foliage in Zelda.
But the memory clock increases in docked mode...You think that would mitagate it...Unless it's simply not enough for this game going from 720p -> 900p
D
Deleted member 11852
Guest
Unless the Switch screen supports 120hz, that'd be pointless.
That'd be my guess. 56% increase in resolution, but only a 20% increase in BW. Though depending on the BW required by the (presumably unchanged) CPU workload, that might not be as bad in practice as it looks on paper.
With the new lower cap on mobile BW, I wonder if mobile Zelda might suffer frame rate drops in the same places as docked mode, only less severe.
I'm looking forward to seeing DF's analysis of both modes in the places where there are drops!
I think a great deal of the games released on Switch can and will utilize the standard portable clocks. There are a ton of Indie games that will run with no issue, and games like Super Bomberman R will have no issue. I would bet even Shin'en has Fast RMX running in base settings, seeing as how the docked version runs 1080p 60fps with four player split screen. Battery life is a concern, and I would think it wise of the developer to be considerate of the player with battery life, just like they are with any other performance aspect. It could also make the developers life harder when shooting for a 720p portable and 1080p docked. Yes the higher clocks make the 720p portable mode that much easier to maintain the desired performance, but then moving to 1080p docked becomes that much tougher. It would certainly not be in the best interest of the game developer to be forced to make sacrifices when moving to the big screen where they will be far more noticeable. The boost mode may be the most beneficial for developers not interested in bumping to 1080p docked. Perhaps they are targeting 720p both portable or docked, with higher settings and perhaps better AA docked. Or even a 720/900p setup like Zelda BoTW. I'm sure a lot of AAA games will use this boost mode, but I also bet most of them will not be shooting for 1080p docked either.
Zelda BoTW performance is getting blown out of proportion. Did people suddenly forget that DF had a 40 minutes of footage to dissect last month and only had a couple of performance dips? I believe John from DF even mention at Gaf that they couldn't replicate the performance drops by simply going to the same area doing the same thing. These drops are the exception, and not the rule. Are we to believe Edge just game Zelda BoTW a 10/10 if it had serious performance issues? I believe @function is right, Zelda BoTW is probably taxing memory bandwidth pretty hard at 900p, and occasionally this causes some stutter. I also believe that some of it is a streaming issue that is probably very hard to replicate, and thus will happen from time to time. It has been a thing in the Batman games for years.
Zelda BoTW performance is getting blown out of proportion. Did people suddenly forget that DF had a 40 minutes of footage to dissect last month and only had a couple of performance dips? I believe John from DF even mention at Gaf that they couldn't replicate the performance drops by simply going to the same area doing the same thing. These drops are the exception, and not the rule. Are we to believe Edge just game Zelda BoTW a 10/10 if it had serious performance issues? I believe @function is right, Zelda BoTW is probably taxing memory bandwidth pretty hard at 900p, and occasionally this causes some stutter. I also believe that some of it is a streaming issue that is probably very hard to replicate, and thus will happen from time to time. It has been a thing in the Batman games for years.
Rikimaru
Veteran
That's the point. It does not need high clocks.
It has issues. Not even 60 fps. Built on Unity.
I had assumed it was 60fps, but perhaps they settled on 30fps to make a locked framerate more easily obtainable. Perhaps Super Bomberman R was a bad example, but we know Mario Kart 8 runs flawlessly 1080p docked and 720p portable. If MK8 needed the performance boost in portable mode, I doubt we would be seeing 1080p 60fps docked. Memory bandwidth requirements are going to go up quite a bit when rendering at 1080p. The performance mode in portable only makes the jump from 720p to 1080p more problematic.
I honestly see it being used by a lot of AAA publishers like Ubisoft with a game like Steep, where they probably have no intention of rendering in 1080p docked. I could see them stick with 720 both portable and docked, and simply up the settings for docked and perhaps some better AA.
I doubt anyone's actually following my argument.
Let's say BoxBoy doesn't need the higher clocks (it doesn't). What's in it for the dev to use the lower clocks? It improves the user's experience, increasing their battery life a bit. But no-one's going to know you've done that and that their battery lasts a bit longer playing BoxBoy than Zelda. Sales of your games aren't going to increase because you've chosen the lower clocks. And given the lower clocks will never be of benefit to the developers where higher clocks often will, why even have them as an option? Just set the base clock at 384 MHz and be done with it!
Last edited:
- Status
Similar threads
