Which still describes the Dev unit photographed to a tee. So we are relying on the memory and processor on the second board being a prototype future dock, rather than just to aid development. I guess it's possible as a 4k version as the guy speculates. Would the USB be good enough for the CPU to access the other Ram at native speeds?
Assuming you're talking about
this dev unit, it doesn't seem to be the described device at all.
- It's a single physical unit, whereas the leak describes a separate enhancer which "connects to the back of the main unit motherboard via some sort of PCI bridge"
- It doesn't have the mini DisplayPort connector nor "2 unknown circular ports"
- It predates the leak by several months, and the leaker specified that they were "planning to make" them in late November. It wouldn't make any sense for there to be photos of the unit several months before it was made.
The photographed dev kit just seems like an early piece of dev hardware from before the joycons were finalised (notice the lack of joycon rails on either side), and before they had it running in portable mode off battery power.
Regarding RAM, no, neither the CPU nor GPU would be able to access the other's RAM at native speeds. The connection between the two might be in the order of 2GB/s if they're using a PCIe based USB-C alt mode, whereas the Switch's standard RAM is either 25GB/s or 50GB/s, and the GPU's RAM would be perhaps 100-128GB/s. Memory management between the two would be important, although it shouldn't be too much different than it is on PC.
I suggested many times that the fan could act like in modern desktop GPUs. My MSI GTX 970 has a 0 rpm mode in idle and with less intensive games, but it kicks in when demanding titles push it more and the temperature goes up. I imagine that the little fan in the Switch could do the exact same thing to avoid throttling.
Yeah, you're right. I got caught up in the whole "portable mode" vs "docked mode" paradigm, but it makes a lot more sense to just link the fan to temperature, irrespective of mode.
This is pretty exciting, i'm really curious to see if this "enhancer" device will actually be released on the market. I think it would be smart, it's basically an optional accessory that replaces your dock to boost power for people who want better docked performances (for example people with a 4K TV), and it shouldn't be too hard for Nintendo to make 4K patches for existing major titles (like Zelda, Mario, MK, Xenoblade 2 or Splatoon) and support 2-3 different res going forward. Seems like the machine was designed for this, the SCD patent has been around for a while, not to mention that they unified their development teams. It's still much easier than making Smash 3DS and Wii U, Super Mario Maker 3DS and Wii U, Yoshi 3DS and Wii U, Mario kart 7 and 8, etc...
Technically it shouldn't be all that difficult for Nintendo to add 4K support to their existing games (it helps that their development environment is going to be catered towards multiple performance targets and resolutions already), and they should be able to do so even with a GPU that's far less capable than the GP106 (although it's possible, or even probable, that the GP106 is a stand-in for a GPU that's closer to something like the GP107 in performance).
The thing that puzzles me is why they'd release it as an add-on for Switch rather than a stand-alone console. A stand-alone console would cost a little more, but it would have a massively larger potential audience, and they could perhaps get some more western third-parties on board if they didn't have to also support the regular Switch (while Nintendo games and less technically demanding third-party games would still run on both).
Why not both? More seriously, though, I don't really see Nintendo going all-in on dedicated VR hardware. I feel like they're best off either going the route of a google cardboard-style solution that's cheap enough to be packed in with a game for $60, or waiting until stand-alone VR headsets come down in price and just supporting OpenVR with whatever stationary console-type-device they've got at that point. In the latter case they could focus their hardware efforts on upgraded joycons with positional tracking which could be used both in and out of VR.
There are no (console) games that can use 100% half-precision (fp16), though. You should expect at best something like a third extra (AT MOST). Full fp16 usage only happens on simple games (with no need for very precies computations), which in turn don't need much processing power to begin with. Still, 1/3 extra power would be a great boost, giving an effective 600 GFLOPS FP32 equivalent and in theory up to 1/3 extra due to architecture means 900 GFLOPS and closer than 2/3 of XB1 power. Nothing to scoff at. Still both the fp16 boost and the architecture boost are uncertain value, so we can't conclude too much yet.
The usage of half-precision doesn't really have anything to do with whether the game is "simple" or not, but rather whether any particular graphics algorithm is stable and consistent at the lower precision. If you think about it, the output of a pixel shader algorithm is typically only 8 bits (the bits per colour per pixel on a non-HDR framebuffer), whereas the mantissa of an IEEE 32-bit floating point number is 24 bits, and an IEEE 16-bit float has an 11 bit mantissa. Even the 16-bit float, with a constant exponent, is 8 times as precise as the result needs to be. Depending on the algorithm, it's possible that higher precision may be required during intermediate steps, but this is largely independent of how simple or complex the technique being used is. A sophisticated, lifelike rendering technique may output perfectly while calculating at FP16, whereas a relatively simple one may exhibit artefacts at that precision, just down to idiosyncrasies of the algorithms used. It may also be possible for an algorithm to be altered to function properly at FP16, or for a different algorithm to be swapped in instead to benefit from the increased speed of the lower precision calculations.
There are a couple of areas where FP16 generally can't be used, most notably for vertex shaders, and also for depth buffers (although reversed or logarithmic FP16 depth may be usable in some scenarios in theory). Vertex shaders typically only constitute a relatively small proportion of a GPU's workload these days, though, and the only reason unified shaders operate at 32 bit precision is to accommodate them (prior to unified shaders it was common for pixel shaders to operate at 16 bit or 24 bit precision).
It's hard to find good info on what proportion of modern graphics code can be run at FP16 without issue, but the info we do have bodes well for Switch. Unreal Engine 4 runs
all pixel shaders at FP16 on mobile by default (so presumably on Switch, also), which could be 70-80% of the shader workload, depending on the game. The Ubisoft developer also claimed a roughly 70% ratio of FP16-compatible code, so I'd expect real-world performance to be quite a bit higher than pure FP32 numbers would suggest.
