You may know that I really like small, efficient APU-based builds. At this point in time, they’re so close to being a viable mainstream option for gaming, especially the Ryzen 6000-series mobile APU-s. Forza Horizon 5, at 1080p high settings? Yes, they’re that good.

I don’t have the new Ryzen 6000 series APU-s to play around with, but what I do have is an AMD Ryzen 5 PRO 4650G and a HTC Vive Cosmos VR headset. I’ve noticed that my NVIDIA GTX 1060 manages to hit frametimes of 2-3ms in Beat Saber while the limit is at 11.1ms (90 Hz), which means that Beat Saber is probably quite easy to run. But can it run on integrated graphics and still be playable?

There’s been some work done in this area before as well:

• LowSpecGamer tried out Half Life Alyx on a Ryzen 3 3200G

• The Mysticle testing Beat Saber on integrated Intel graphics

Test setup

Here’s a quick rundown of the specs of the test PC:

• CPU: AMD Ryzen 5 PRO 4650G
• GPU: Radeon Vega 7 integrated graphics
• RAM: 16GB DDR4-3200 kit
• Motherboard: ASRock X570M Pro4
• Cooling: adequate
• Storage: plenty

To get the authentic, out of the box experience, I did not overclock any component, unless you count using the XMP profile on my memory sticks to run them at 3200 MT/s as overclocking.

The test PC usually has an NVIDIA GTX 1060 6G inside it, because it’s a gaming PC, after all. In my first test attempt I kept the NVIDIA GPU inside the PC since I was lazy. I connected my TV to the HDMI port located on the motherboard, and connected the VR headset to the DisplayPort present on the motherboard. What I found out was that by default games would still utilize the NVIDIA GPU, passing the final image to the integrated Vega 7 graphics, which then shows it on the big screen. This type of setup is commonly found on laptops that have a discrete GPU in addition to the integrated GPU, I just didn’t expect this to work out of the box on a desktop setup.

To do proper testing, I removed the dedicated GPU, updated the AMD GPU drivers to the latest available version at the time of writing, and got down to testing.

First attempt with Beat Saber

Beat Saber is a very popular VR game, and for good reason. It’s the perfect candidate for testing low-end VR gaming as it’s not that complex graphically and even runs on standalone headsets, such as the Quest 2.

I set everything up, started the game, and was surprised that it even loaded! The success stopped there, as I quickly noticed that the resolution used for the headset was automatically set to the lowest available resolution, resulting in text that was absolutely unreadable.

Unreadable text didn’t stop me, so I navigated to the song list and picked something familiar. The result? It works, barely.

The game ran at a very low resolution, and even then the best it could do was between 45-80 frames per second. As you can see from the screenshot, the experience was not a fluid one. I could still hit the boxes, but it just didn’t feel good. At least it’s somewhat playable, and the headset still rendered my head movements in 90 Hz, reducing the risk of motion sickness.

Judging by the SteamVR performance statistics, I noticed that it was perfectly happy with running the game at half the framerate (45 Hz), and unhappy about inconsistent frametimes.

Test attempt #2

To understand the performance fluctuations better, I started up MSI Afterburner and enabled the on-screen display.

With the second attempt, I also made one important change to the configuration. I set the TV connected to the machine from 4K resolution down to 720p to avoid taxing the APU with any extra load.

I launched Beat Saber and while the resolution was still garbage, there was a notable improvement in the performance.

The frametimes were much more consistent now and very close to the 90 Hz mark. It does still stutter, as you can see from the SteamVR performance statistics, but at least now it’s a much more playable experience.

From the statistics provided by MSI Afterburner, you can clearly see that the performance is so close to being playable, with the integrated GPU maxing out at a somewhat stable 85 FPS, but then dropping down to a more stable 45 FPS and staying there for a while. The game fluctuates between those two levels of performance.

You can still call the game somewhat playable, though. It’s not the best experience and you’re not going to set any world records while running at half the refresh rate, but it’s something.

APU-s, VR and the future

The performance increases in APU-s aren’t fast enough to catch up with discrete GPU-s just yet. Relying on system memory that’s optimized for latency rather than memory bandwidth and then sharing that same memory with the CPU is also a compromise that you cannot work around that easily.

This test shows what the integrated Vega graphics are capable of. With the release of the Ryzen 6000 series mobile APU-s, the performance of the integrated graphics has been increased yet again, with the GPU architecture now based on RDNA 2.

Based on the results of my testing and seeing how the new APU-s perform in games, I’m betting that the new APU-s should be able to run some VR titles at a more stable 90 Hz on a similar screen resolution.

Is this enough to consider them as a viable option for VR gaming in general? Probably not. Games like Half Life Alyx can bring the NVIDIA GeForce GTX 1060 to its knees, and that’s at the lowest graphics preset! But if you’re like me who spends 90% of their time in VR playing a graphically simple game like Beat Saber, then it might be an option worth considering, especially in a market where discrete GPU-s cost an arm and a leg. The great GPU shortage of 2021-2022 is showing signs of easing, but we’re not quite there yet.

Future steps

It’s probably possible to improve the APU VR gaming experience by applying some tweaks and fixes, such as the VR performance toolkit. However, that won’t reflect the out of the box experience that you’d get. Casual VR players are unlikely to go and seek such tweaks out.

Trying to lock the refresh rate to something like 45/60/75 Hz may also improve the stability of the experience.

For the time being, I will just continue playing VR with a dedicated GPU, but I am cautiously optimistic about the future of VR on APU-s.

I’ve been running my all-in-one PC for a while now. It was my desktop, my NAS and my gaming PC. However, during the next couple of months I kept hitting small bumps along the road. Most of these were quite straightforward to fix, but there is one that finally convinced me to go back to a simpler setup.

iSCSI

As mentioned in one of my previous posts, I had set up the storage on my gaming VM over iSCSI. If you don’t know what iSCSI is: think of it like a hard drive that you can hook up to your machine over the network. This setup had a couple of benefits: the amount allocated to the VM was flexible and I would always have a snapshot of my game data in case the Windows VM decided to nuke itself.

What I didn’t take into account was the configuration. tgt allows you to define the IP address of the client machine, which can be seen as an additional layer of security. My gaming VM has two virtual NIC-s, one pointing to the actual physical network, and another one to a virtual one. This resulted in the iSCSI connection being flaky on startup: the disk was not present in the VM on first boot, but was there after a reboot.

This issue was gone once I removed this restriction from the iSCSI target configuration on the Linux VM. My best guess is that the iSCSI stack in Windows might have tried to initiate a connection over the wrong NIC, depending on whichever one was brought up first.

After “solving” this issue, it had been smooth sailing.

GPU audio issues

When the Windows VM had been on for a while, the HDMI audio output would start to glitch out after a while, with the audio sounding slow, robotic and garbled. After doing some research, I found some resources that mentioned enabling MSI interrupts in Windows. The guide for this can be found over at Guru3D forums.

After tweaking the Windows registry settings and reminding myself that I do have snapshots to fall back to in case I mess up, I got the issue fixed.

GPU driver issues

Whenever there’s a new big and popular game released, NVIDIA usually releases an updated version of their GPU drivers. I try to keep my software up to date, so I usually install these updates when they come out. Just one problem: when I upgrade the GPU drivers in the VM, the screen will stay black. After some time passes, I have to force a reboot using virt-manager.

I have not looked into this issue yet as it only happens during driver updates, but it’s definitely an annoying thing to have.

UEFI and CSM

UEFI updates have a bad habit of resetting all the custom settings that you have made, and at least with the motherboards I have used, the settings cannot be restored if the backed up settings are from an older UEFI version. This means that I have to navigate the UEFI quite often to configure all the settings that I need to have in place for VFIO to work.

There is one setting that I didn’t expect to cause that much trouble though: CSM support. CSM (compatibity support module) is generally enabled by default and allows you to boot off of legacy operating systems if needed. I don’t have that requirement, so I went ahead and set my boot options to boot in UEFI mode only.

Reboot, start up Fedora, and boom, anything VFIO related is spewing errors like crazy.

Turns out that enabling UEFI only mode in UEFI settings somehow grabs the GPU and causes problems when you try to then pass the GPU to a VM. While in this mode, I noticed that the GPU was also shown in a separate menu in UEFI settings. Enabling CSM support fixed this issue for me.

VR and USB issues

With the situation in the world being less than optimal, I decided to spice up my gaming setup with the addition of a HTC Vive Cosmos in case in-door activities become much more popular suddenly.

First issue: I can’t get the damn thing working. My gaming VM setup has the inateck KT4006 passed through so that I can plug peripherals to the PC and make them available to the gaming VM with ease. After plugging everything in according to instructions and turning the link box on, I’m met with a barrage of USB connected-disconnected sound effects. 6 or 7 cycles later the sound stops, and with that do the rest of my USB devices.

I took the USB 3.0 card and tried it in an older machine that doesn’t have a fancy VFIO setup on it. Same issue. However, when connected to an USB 2.0 port, the setup shows a warning in VIVE Console, but at least it works! Since my PC literally has no USB 2.0 ports, I had to get a bit creative and plug an USB 2.0 extension cable between the PC and the USB 3.0 cable coming from the link box.

With the help of my friend I got confirmation that the issue is indeed with my USB ports. I also ordered a different USB PCIe card from inateck, this time the inateck KTU3FR-4P. I made the assumption that since the VIVE support page also recommends an inateck card, then they must be fit for purpose.

Nope. The second card apparently has the same chipset and the same issue.

What did end up working was a random VIA USB 3.0 PCIe card, which shows up as VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller on my machine. Just one issue: it has PCIe device reset issues. If I shut down the Windows VM and start it up again, I would sometimes get a bunch of IO_PAGE_FAULT errors in my kernel logs. No worries, guess I’ll just avoid rebooting a notoriously reboot-happy OS.

Latency: the straw that broke the camel’s back

If there’s one thing you don’t want to see in a VR gaming setup, it’s latency.

I’ve covered the tweaks I’ve made to my setup in a previous post. Turns out that those might not be enough. The CPU isolation using systemd works well in general, but not with kernel threads.

Whenever I did something IO heavy on an NVMe-based btrfs file system, it would introduce stutter to the gaming VM. Running a scrub operation on the filesystem was enough to put a huge load on the CPU, likely due to the raw speed that the NVMe SSD-s can provide. This results in the gaming VM experiencing stutter that ruins the whole experience.

Here’s an illustration.

Similar issues could be observed whenever I tried to run another VM that shares the same cores.

I looked into alternative solutions as well, and it does seem to be possible to also isolate those CPU cores from the kernel. They will probably work to some extent, but implementing them feels a bit hacky at the moment. I’m hoping that in the future these kinds of tweaks will be exposed as a simple checkbox in virt-manager itself.

At that point I had enough. If I’m not going to be able to use the machine for other purposes at the same time without experiencing all these issues and having to work around them, then I’ll just go back to a simpler setup. I’ll lose some of the benefits, but at least I don’t have to spend time debugging all these issues.

Conclusion

VFIO and virtualization are still interesting topics to learn about and try out, but for my use case they are just too limiting. I’d imagine that an use case that didn’t have such strict latency requirements would still be able to run just fine, unfortunately gaming just isn’t one of them.

This experience has been quite fun in general, but I’m calling quits, at least for now. The one machine that does it all turned out to be a jack of all trades, master of none.