I think there's more to it than we even realize as well.
I am not a programmer, never typed in a line of code in my life, but I do at least understand that all these systems are very complicated with thousands and thousands of lines of code that must work in harmony. Case in point, the whole concept of going from Docked to Handheld with the Nintendo Switch. There must be some code written that tells the system "Hey, you're in docked mode, so do X,Y, and Z to the SoC." "Ok, great. Thanks!" I'm probably oversimplifying it, but my point is this whole process of going from docked to handheld, and vice verse must work. Every. Single. Time. And work fast, work well, and each game is coded in a way to adjust that on the fly whether it's the game itself doing it, or the system. I don't know specifically. Again, with the Switch, it just works. And it works very well. I can attach, and remove the Switch from the dock over and over again, and it'll always work. That to me just sounds like good programming, but maybe I'm again oversimplifying it.
I think I'm right in saying no current eGPU setup, where it's any Thunderbolt 4 Laptop w/ an eGPU enclosure, or the Asus ROG Ally w/ the XG Mobile, can do what the Switch can do in terms of just picking the device up, and it works. No input needed from the user.
This is something Nintendo would want to solve with a Supplemental Computing Device. It couldn't have any lag, or require external input from the user. It would have to work like the Switch 1 currently works going from docked to handheld, and vice versa. I remember this SCD patent showing up during the Wii U days, and I do wonder if this was something Nintendo at one point prototyped, but decided it was cheaper, and less complicated if they simply had an additional chip that would communicate directly with the Switch to tell it if it was in docked, or handheld mode.
Like you said, was probably better to have a beefier chip on board, and underclock it between the two modes rather two separate chips.
Again, if someone smarter than me can correct me on certain details, and nuances of how the Switch works between the two modes, please feel free.
I can only guess how it works and would also like an explanation to be honest.
(but my guess would be: when the system is docked, after the USB handshake happened and the system knows to what it was docked it sends an interrupt and the game pauses after the last frame, it sets a flag that from the next frame the engine should use the different render profile, sends a command for the gpu driver that it should switch to the different profile (higher clocks, external out instead of display), and when this has done sends the game another interrupt to comunicate to resume. Now the game starts again and renders the next frame, but with the new gpu profile.
At least thats my guess.
Can someone with knowledge describe the difference between what the CPU does, and the GPU? Like maybe in terms of a game like TOTK? (Ex: the CPU handles load times while GPU handles enemies on screen, or whatever I’m sure I’m wrong.) A few pages ago it was said the A78C is much weaker than Zen2, and I just want some real world context. From my understanding, CPU and RAM bandwidth will be the biggest bottlenecks for Switch2. I want to learn more about what CPUs do in general. Like what is a “CPU heavy” game?
Game logic (where is what, what is happening, physics, what needs to be kept track, what needs to be rendered,...) -> CPU
Visuals (deciding what of the objets that are given are visible, rendering the scene, post processing, filters, compositing different rendering steps, etc) -> GPU
Thats the reason that cpu load cant really scale between docked and handheld (it would lead to it being able to handle less stuff in handheld mode, think: having problem with 50 enemies on screen while its fine docked, or that the physics simulation would be less precise and would feel different between handheld and docked), and is also why a strong cpu is important for ports. In the worst case you would need to cut framerate to have more time per frame to calculate the stuff.
Easy tricks how ports reduced cpu load on switch ports: render less background characters then the other consoles, having flags not be moving in the background, etc. But thats between different consoles, that would hardly be an option between different states like the switch.
On the other hand, if the gpu is weaker, you can reduce the amount of details to reduce the amount of work it has to do.
Rendering less pixel -> bam. rendering the shadows with so much details takes way to long? no problem, render everything in high resolution, but shadows (since its rendered in its own step) in a quarter of the resolution.
There are obviously limits to how much you can scale GPU tasks.
And the reason why ram can switch between fast and slow modes between docked and handheld:
its shared with the cpu, the GPU will use less of its bandwidth when its using a lower clock speed, and the cpu is not using more, so there is free bandwidth that is not being used. So reducing the clock speed means it needs less voltage and less power without impairing either CPU or GPU.