It’s June 2022. You’ve just got an Oculus/Meta Quest 2 and you’re raring to use it for PC Virtual Reality. You plug it in, only to find the image quality in VR is fuzzy, blocky or even scrambled, or the computer keeps crashing. You have an AMD Graphics Card. Welcome to hell. Here’s the situation:

Virtual Reality State-of-play

As of writing there are two main ways to get into VR: Standalone headsets and PCVR headsets.

• PCVR headsets are designed to be plugged into a powerful gaming computer. This computer does all the heavy lifting of rendering the VR graphics, then sends them to the headset via a big display cable. This is the original experience touted during the media rush in 2016 for the Oculus Rift CV1, and the current posterchild for this type of headset is the Valve Index, which uses two or more external ‘base stations’ setup in a room to track the player within the space bordered by the stations. The base stations provide the best possible tracking with a good amount of coverage, and can track more than just the headset and it’s controllers. These are typically used by VR enthusiasts who are willing to spend a decent amount of money, time and space on a VR setup. You may have seen VR full-body tracking videos on Youtube; these usually use an Index setup. A full setup of this kind typically costs a lot of money, but grants a high level of flexibility and expansion.

• Standalone headsets are designed to be used on their own, and have a computer in the headset itself that can render limited VR experiences. The Meta (Oculus) Quest 2 is the current posterchild for this type of experience, and is fairly popular at the moment thanks to it’s low price and pretty extensive feature-set. This headset uses ‘inside-out’ tracking, meaning head and controller movements are tracked by the cameras on the headset itself. This eliminates the need for base stations, but introduces algorithmic fuzzing into the tracking of controllers, which can regularly leave the sight of the headset cameras, however overall tracking is very good. The headset itself can play some impressive VR games (many people have bought this headset exclusively to play Beat Saber for example), but because of the small size and limited cooling situation, most experiences are performance limited, meaning they play simply or look worse than their PCVR counterparts. However, these headsets can be connected to a PC either via a long USB cable or by Wi-Fi, which gives you the ability to access higher-end PCVR game experiences. Since USB and Wi-Fi can’t push as much data as a phat display cable can, video from the PC needs to be compressed to do this.

The Problem: Video Encoding

You (and I) want to use the ‘standalone’ Quest 2 for PCVR. The PC only has USB or Wi-Fi bandwidth, and needs to compress video before sending it to the headset to be decompressed. This process needs to be done fast because any latency will lead to a delay between the player’s movement and the response in the headset. This delay will typically induce motion sickness in VR. There are a couple of tricks done by the hardware to reduce the percieved delay, thanks to the Asynchronous Timewarp feature, and some controller movement prediction. This works well when the hardware is producing the frames at reasonably low latencies. You want as low a latency from the game to the headset and back as possible, but you can tolerate a few tens of milliseconds worth of delay without a significant effect on stomach or gameplay. This opens up the opportunity for video compression to be a slight part of that delay.

The Quest 2 supports H.264 and HEVC (also known as H.265) video decompression, two very common internet video codecs. HEVC is newer, and results in higher quality for the same amount of data. On the PC side, typically the fastest video encoder is on the graphics card in recent years. However, AMD cards aren’t as good at encoding H.264 videos as NVIDIAs are. They are slower at it, and the result is a lower quality image. In a situation where the video they are compressing is directly in front of your face as is the case in VR, AMD’s lacking compression is more apparent than ever; you will see blocky artifacts, obvious color banding, smearing of high complexity scenes, etc. Compounding matters further, even the most modern AMD GPU, tasked with encoding an H.264 steam that has a pixel width bigger than ~2700 will result in a latency spike from around 4ms to 10ms. At 90hz, this is almost an entire frame worth of lag before the frame is even transported to the VR headset! For comparison, NVIDIA’s encoder gets it done in 2-3ms.

Example of H.264 at a low bitrate absolutely obliterating some Monster Hunter World footage

As mentioned, the Quest 2 and new AMD hardware also support HEVC, a newer and higher quality compression solution. AMD’s new cards were pretty decent at it. Unfortunately, it’s been broken since AMD driver updates from November 2021. On any newer drivers, using HEVC for VR encoding will cause a driver crash while playing most VR games. An easy test to confirm this is to try playing Beat Saber via Virtual Desktop with HEVC enabled in the streamer settings. Typically the game will crash the AMD driver shortly after launch.

So, just downgrade the driver and wait for a fix, right? Well… the last driver with working HEVC was 21.10.1 back in October 2021, and this problem has persisted for 7 months and counting. AMD has also improved their game performance (particularly in DX11 which is used in a lot of VR games) quite a bit in that time, meaning you are trading HEVC image quality for game performance if you want to juggle drivers. How annoying! As of writing, the most recent AMD official, optional driver is 22.5.2. HEVC is still broken and crashes the driver, and H.264’s bitrate has been constrained to a degree that makes streamed VR quality worse than ever! If you’ve been dabbling in VR for a while, you have had your image quality experience get worse and worse as your GPU game performance improves.

Slightly less of a problem(?): Motion Smoothing

I can’t personally vouch for this one as much as the above issue since I have mostly seen mixed results per game, per API, per broadcasting solution, per person, etc. The cause of the issue is unclear and I can’t entirely pin the blame on AMD for this since I don’t know where the issue is occurring in each situation, but I will expand on it below:

In VR, the user needs to get consistently smooth updates to the LCD in the headset that correspond with their movements in order to avoid motion sickness. To achieve this, games run at a high framerate that matches the refresh rate of the headset so that frames always arrive smoothly to the eyes. However, VR headsets are often pushing 4k or above framebuffers and expecting 90-144fps to reach their target refresh rate. This is pretty hard for most middle-of-the-road hardware to consistently hit, if at all. In times where the framerate drops below the target refresh, both main VR APIs have implemented a form of fake frame insertion to make up for the missing frames, known on SteamVR as “Motion Smoothing” and on Oculus platforms as “Asynchronous Spacewarp” (different from the aforementioned Asynchronous Timewarp).

Asynchronous Spacewarp example diagram, from official Oculus presentation

VR software in it’s current iteration is often in a ‘hobbyist’ or experimental support state, and many games are not well optimized for the hardware. As a result, there is a lot of stutter that the smoothing feature is meant to fix. On NVIDIA hardware, this feature typically works, meaning stutters and framedrops are not as apparent or sickness inducing. However, for some reason this doesn’t work correctly on AMD hardware. Typically the feature enables too late, or doesn’t enable at all when framerates drop, resulting in a juddery experience for the user in the headset, which can be stomach turning. I can only speculate on why this doesn’t work. Maybe AMD graphics cards are not presenting performance metrics to the VR API on time for it to decide to kick into smoothing mode? Maybe the GPU can’t easily switch from 90 frames to 45 with insertions and back without a bit of stutter? Whatever the reason is, you will experience more unexpected stutters and slowdown with AMD cards, regardless of the performance tier, unless you can adjust your settings to keep the framerate at the refresh rate at all times. This usually means compromising resolution and graphical settings that would otherwise be acceptable on the equivalent NVIDIA hardware. In some games (Microsoft Flight Simulator), achieving an appropriately high framerate is practically impossible, and this feature needs to be used at all times for normal play.

What’s AMD doing about these problems?

Unfortunately unclear. AMD have been radio silent on the encoder issue for months, and because of the fractured and niche nature of the VR hardware community, there has been no community effort to get a response from them yet. Some users are not aware of the issue, or they are relegated to software specific communities such as Virtual Desktop’s Discord (where most users will suggest you buy an NVIDIA card instead) or various VR enthusiast spaces on Steam Communities, AMD Community Forums, etc. Some people are not aware of the issue at all, since Oculus official Link software simply picks H.264 without informing the user. If the user never experienced better quality, they may just assume the blocky H.264 experience currently available is the standard. Some users simply switched to an NVIDIA card after being made aware of the issue. The creator of Virtual Desktop ggodin has contacted AMD multiple times about the encoder issue and AMD appear to break this featureset regularly. The official Oculus Link solutions simply avoid surfacing HEVC support at all.

I’ve heard from the Virtual Desktop Discord that this is not the first time AMD has broken their video encoders and then not done anything to fix them for a while. AMD is probably counting on this issue to remain niche so they can safely ignore it and only risk a small subset of users actually abandoning their products. I think this is a really embarrassing tactic, especially as someone who would like to see AMD maintain competitiveness with NVIDIA. HEVC encoding support is touted in the specs of modern AMD GPUs. Many users who are looking to buy an AMD GPU are not aware that this feature they are expecting to utilize doesn’t work properly, since no official channels state it as a known issue and the concern from the community is fractured. Perhaps I’m underestimating the workload required to get previously-working encoder support going again, but shouldn’t this be a relatively easy fix for AMD?

As for the Motion Smoothing issue, for now, speculation on the cause of this issue is anecdotal, and I don’t have multiple hardware configurations I can use to run comparison tests. We need more people using various VR hardware with good data to further clarify where/why this problem occurs. I can’t really pin the blame on AMD when I’m not sure where this issue is actually occurring in the software chain.

What To Do?

If you are buying a computer with VR as one of the primary use-cases, you gotta buy NVIDIA. However, there are a lot of reasons why you might not be able to do this. Maybe the market in your country prices these cards radically different, or availability is low, or you are a nerd who likes AMD’s open source support that allows for a stable Wayland environment and a mixed-adaptive-sync multi-monitor setup?

Anyway, if you’re stuck with the AMD like I am, you can still get a compromised albeit decent VR experience. Oculus Link will set most of the variables for you, but you can check out Espionage724’s wiki page where he details performance results of the encoders and useful settings for an RX 580 and an RX 6600 XT. On Virtual Desktop, you are at the mercy of whatever driver you have installed. Check VD’s Discord for announcements that report the latest working AMD driver and recommended settings. If you want to avoid the Motion Smoothing issue, the simplest solution is to just adjust your rendering resolution (sometimes referred to supersampling) down until your hardware can hit the refresh rate consistently. This issue is probably less apparent on Quest 2 setups since the timewarp feature is done by the headset, and doesn’t get affected by the framedrops like it might on standalone headsets.

Lastly, nag AMD! Crash the driver and submit bug reports each update. Post your experiences here in this AMD Community Thread, but keep it respectful. These issues should be at least acknowledged and clarified by AMD. If there is a reason why the HEVC encoder can’t be fixed, I would like an explanation! Features should not go unusable for months without word from the company whether they will be fixed. As time drags on, I’ve become increasingly disappointed in AMD, despite having a preference for their hardware thanks to good open source support and some of NVIDIAs less attractive business practices. The fact that they are cheaper for the same rasterized performance in my market also helps…

That’s it for now. Given that AMD has caught up in rasterization in the last generation, it’d be nice for them to catch up in features as well, or at least the ones that they claim the hardware supports, like HEVC encoding. I’m hoping for a future where AMD users will have a good VR experience and would like to be a part of that future, but I’m not going to hold on forever.

---

Credit to Irasutoya for funny VR example images