A Cloud Gaming PC, Part 2
In a previous article, I discussed building a cloud gaming PC in Azure. If you were successful in building it, you probably deleted fairly soon afterward because it didn’t work very well. Being the stubborn type, I refused to give up when I was so close. After some research into offerings in AWS, I found that the G4dn family provided the best gaming support in the NVIDIA Tesla T4 and the corresponding drivers. I’ll quickly cover the process in AWS here. Please refer to my previous post for further details.
OpenVPN Access Server setup stays the same. After some research, I was able to determine that the network was not the bottleneck. I built OpenVPN Access Server on a t3.small.
Build the g4dn.2xlarge on Windows Server 2019, and follow the AWS directions to install the NVIDIA drivers. So far, so good. Now it gets a little complicated. The first flaw I noticed with the first build is that Steam never seemed to use the right display, and ended up using the Microsoft Basic Display Driver to render output. As you might imagine, the performance of this is awful. The first thing we want to do is to disable this adapter so that there’s no confusion about which display driver to use. However, by default the remote desktop session uses this driver, so first we need to change the policy on the machine to assign the graphics adapter to the remote desktop session. You can do this from Group Policy Editor:
Run gpupdate to apply the group policy and reconnect to your desktop session. From there, go to device manager and disable the basic display adapter. At this point, Steam should be able to play remotely, albeit in 1024x768 resolution. But if you turn the details overlay on in the Steam Client settings, you should see that the framerate is around what you’d expect from a decent graphics card (though it probably won’t exceed 60fps over the network). However, you’ll probably also see that the display lag is all over the map. Let’s fix that first. Here are the Steam Client settings I use:
Steam should play quite well at this point. Let’s take care of that pesky resolution problem. It’s relatively straightforward to do so from regedit. The keys you are looking for are under HKLM\SYSTEM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration. Under this key, you will see a key for each graphics driver installed in your system, and then a subkey for each monitor. See the screenshot below, showing the subject system with keys for both the basic display adapter, and the Tesla T4:
The NVIDIA keys are prefixed by “NVD”. The “MSBDD” ones belong to the disabled basic display adapter and don’t need to be updated. You also only need to update the NVIDIA key containing “NOEDID”, the virtual display used when running headless. The subkeys that need to be updated are both the 00 and 01, and the subkey 00 underneath each of those. You need to update the PrimSurfSize.cx and PrimSurfSize.cy to match the resolution you’d like to use. My research also suggested that Stride needs to be updated as well, but I don’t know how to calculate it, or what it’s used for. The suggested value for 1920x1080 is 7680, and seems to work fine.
That’s it! The last major obstacles to a decent gaming PC in the cloud were: ensuring that the system actually uses the graphics adapter, and subsequently to update the display resolution used by the virtual monitor so that games will use the correct resolution. It’s time: let’s see how it performs:
There were definitely sections of the benchmark it strained to get through, and the CPU score is quite disappointing. However, that graphics score is good enough to sustain 60fps at High to Ultra settings for most 2020-era games in 1080p, while keeping an input latency below 60ms. While not good enough for competitive gaming, it’ll certainly play both gamepad and mouse/keyboard titles without any issues and look darned good while doing so.
I hope it works out for you. Please feel free to add comments if you’re looking for a little bit of help.