Hello @els1
I don't think it's quite that simple. Google hasn't said a lot in public about these details, but I think the simplest answer is that each Stadia game instance has direct access to a d...
See more...
Hello @els1
I don't think it's quite that simple. Google hasn't said a lot in public about these details, but I think the simplest answer is that each Stadia game instance has direct access to a dedicated GPU (i.e., it is effectively running on the "bare metal" for the GPU), but is sharing a large multi-core CPU with other game instances. Sharing a large multi-core CPU works best using virtual machine technology. So, if I had to guess (and this is speculation, but based on 30 years as an engineer), I would say there's a virtual machine monitor at the bottom of the stack, with multiple virtual machines on top that slice up the available CPU and main memory according to the resources promised to each Stadia instance. This VMM also provides each VM with direct access to the GPU allocated to that VM. Inside each VM is a Linux kernel that then (again, most likely) hosts containers. So, games would be packaged as docker container images (rather than VM images). This would allow them to be cached on the local storage for each VM, accelerating the startup of the more popular games. Each VM only runs one game container at a time.
Again, this is all speculation, but it's how I would build it, and I would expect it to perform pretty well. We do some similar things (not for gaming, but for GPU-accelerated distributed parallel processing), and it works well for us. The harder part isn't the CPU/RAM/GPU sharing, though – it's the adaptive video encoding in the streamer. We don't have to deal with that for our application, but it's where Google appears to have invested the most custom engineering effort.