References to Stadia Instances Using NVIDIA GPUs Appear on Stadia’s Github

WARNING: before shouting from the rooftops that Stadia “Gen 2” hardware is clearly imminent, keep in mind that the evidence described below is far far from an official announcement of new hardware going into production. Stadia Linux instances with NVIDIA drivers running on top of NVIDIA hardware could be used for the purposes of testing, evaluation or a number of activities that are a lot more mundane than an imminent release into production for Stadia gamers.

With that said, let’s continue. Google Stadia maintains a set of public GitHub repositories that appear to contain most of what one would need to build a Docker container of the Stadia Linux environment. This also includes their own fork of the Linux kernel and graphics drivers/libraries.

Google routinely keeps these repositories up to date by pushing their internal commits to the public branch. It was just brought to our attention by Twitter user @jukkatawast that a recent update has revealed commits from May that include some very juicy changes!

In particular, if you look at a commit from May 17th, there are clear references to Stadia instances that use NVIDIA GPUs. The commit message reads as follows:

Add support to the kokoro job script to generate
a disk that contains the UMD/KMD NVIDIA modules
and corresponding support files required for
instances that use a NVIDIA gpu.

The disk is generated from a preprocessed package
that contains NVIDIA kernel headers and UMD stored
in GCS.

To create an NVIDIA disk the script requires setting
the NVIDIA_DRIVER_VERSION env var. If the var is not
set it will generate a new kernel image with the AMD
modules.

The disk is not self contained and must be mounted
with the corresponding kernel disk.

Here “kokoro” appears to refer to an internal Jenkins continuous integration implementation (an automated testing platform) at Google and UMD/KMD refer to the NVIDIA “User Mode” and “Kernel Mode” drivers. Related scripts show the NVIDIA driver being loaded (using the Linux “modprobe” command).

What this amounts to is that, in the testing framework, if a certain environment variable is set, the container is built/tested for NVIDIA GPUs; if not, it defaults to AMD GPUs.

We should mention that other recent commits refer also to the Vulkan 1.3 API set and other performance enhancements.

What does this all mean? Well, we again caution against jumping to conclusions, but it does appear that Stadia instances are being tested on top of NVIDIA GPUs for … some reason.