After just over three and a half years and a Facebook acquisition in between, Oculus’s first-generation Rift headset is launching today. We took a hands-on preview of the headset at GDC 2016 earlier this month and will have a formal review later, but in the meantime for those lucky backers or early pre-order customers who will be receiving their units this week, let’s talk drivers and software.

As you’d expect for such a high-profile device launch, both AMD and NVIDIA have new drivers being released in part to update their support for the Rift, along with blog posts lauding the release of the device. For both companies, the launch of VR headsets represents the opening of what could potentially be a large and profitable market for high-end GPUs. The rendering requirements of VR – both in resolution and framerates – greatly surpass the common 1080p60 monitor, and the novelty of VR could further spur on additional hardware sales. So both GPU vendors are taking the launches of VR headsets over the next two weeks very seriously.

Launch Day Drivers

Starting with AMD then, the company has released their Radeon Software 16.3.2. The big news here is of course official launch support for the Rift, including Oculus’s new 1.3 SDK (more on this in a bit). This driver is also adding support for the HTC Vive ahead of its launch next week, and AMD’s Radeon Pro Duo video card. The latter still does not have an official release date, but given the added driver support and Q2 release date, it’s clearly going to be soon.

Along with the driver release, AMD’s graphics technology group has also released a blog post on their website dubbed “Asynchronous Shaders Evolved”. In it the company offers a recap of their asynchronous shader technology implementation, and further reveals that they have assigned a formal name to their async shader prioritization capability: Quick Response Queue. AMD first talked about this ability last year when they first began discussing async shading with the public, and now in their recent drivers they have enabled the feature. Quick Response Queue goes hand-in-hand with asynchronous timewarp, which ideally is executed as late as possible and as quickly as possible to produce best results, in this case allowing AMD to send the job through at high priority without resource sharing unnecessarily slowing down the job. Do note however that Quick Response Queue is a GCN 1.1+ feature, though for the purposes of VR in particular, all of AMD’s GCN 1.0 products fall below Oculus’s recommended minimum of a Radeon R9 290.

Meanwhile over at NVIDIA, they too have a new driver release with 364.72, the third release from the R364 branch. 364.72 brings launch support for both the Oculus Rift and next week’s HTC Vive, along with the various launch titles for those headsets, and all of the features present in the latest iteration of NVIDIA’s VRWorks technology. As for non-VR gamers, this is also the game ready launch driver for Dark Souls III, Killer Instinct, and Quantum Break.

The company has also published a separate blog post celebrating the launch of the Rift. In the post NVIDIA announces that GeForce Experience’s game settings optimization service now supports VR settings as well, allowing the software to dial in NVIDIA’s optimal settings for playing various games in VR. Only a limited number of games have VR settings available at this time, but NVIDIA seems to have hit a decent chunk of the graphically strenuous titles – EVE: Valkyrie, Lucky’s Tale, and Chronos – while promising to add further VR games in the future.

News From Oculus: Async Timewarp Now In Production, Non-Oculus Store Applications To Be Flagged As “Unknown”

Tying all of this launch day activity together, Oculus has released a new blog on their developers site outlining the current state of asynchronous timewarp support for the Rift. After initially announcing their implementation of the technology just a bit over a year ago, Oculus has promoted the technology to production status for the Rift on Windows. In the post they outline a bit of the work they had to do to implement async timewarp on Windows – since it’s not a real time OS, they can’t necessarily count on getting resources allocated or jobs completed as quickly as they’d like – which in turn has involved working with AMD, NVIDIA, and Microsoft to get both OS GPU scheduling and each vendor’s GPU drivers up to snuff to handle GPU prioritization and pre-emption as they expected to use it. The blog post also confirms that Oculus is using AMD’s LiquidVR and NVIDIA’s VRWorks technologies respectively to expedite the process and access functionality not normally available via DirectX 11, which has no real concept of asynchronous shading.

The blog post also confirms the technical requirements for the async timewarp. The feature works as far back as Windows 7, but owing to the significant GPU scheduling updates made with Windows 10 and its underlying WDDM 2.0 driver stack, the feature works best on Windows 10, specifically the most recent update (10586.164). In the long run here I expect that Windows 10 will be the primary platform for VR – teething issues and all – due to the combination of WDDM 2.0 and ultimately the greater flexibility offered with DirectX 12.

Meanwhile, now that async timewarp has been promoted to a production feature, Oculus is announcing that they are enabling it by default in the Oculus VR SDK 1.3. Games using this SDK will not need to do anything special to make use of the feature, which means this should allow for a fairly rapid rollout of the feature. However the post also implies that only games that are compiled against the 1.3 SDK get this feature, which is notable since the SDK was only released today. As a result it’s not clear whether any or all launch titles have async timewarp enabled at this time, or whether it’ll need to be patched in with a future game update.

On a final note about async timewarp, in their blog post Oculus also spends a bit of time discussing how async timewarp works and what it’s used best for. There’s an especially good passage outlining how async timewarp’s re-warping capability to cover for missing frames (as opposed to updating head-tracking of a frame at the last second with an initial warp) is meant to be used as a failsafe option, and that developers shouldn’t use it to try to get away with games that run below 90fps. I especially like this passage – it’s the greatest summary of why you can’t cheat your way to VR that I’ve ever read – so I’ve gone ahead and reprinted it below.

However, ATW is not a silver bullet. Failing to maintain a consistent, full frame rate may produce visible artifacts including noticeable positional judder, particularly in the near field of view. An application that falls below 90fps rendering will get re-warped in time to avoid rotational judder, but while orientation latency is kept low and smooth, animation and player movement may judder in lock-step with missed frames. For these reasons we continue to recommend that developers do not rely on ATW to save them from low frame rate.

Finally, on a not-quite-hardware bit of news, Epic Games’ engine guru Tim Sweeney has pointed out that with the release of the Rift and the 1.3 SDK, Oculus has implemented new security and content policies on the platform. Applications compiled with the Oculus SDK but not distributed through the Oculus Store will be flagged as coming from an unknown source, and by default will be blocked. At the same time it will still be possible to run these applications, but end-users will first need to enable applications from Unknown Sources to have them unblocked.

At first glance this appears to be an attempt by Oculus to encourage developers to adhere to their development guidelines while also building up their platform. Ala the mobile app stores, Oculus will be reviewing applications and approving/rejecting submissions based on content restrictions and adherence to best developmet guidelines. Ideally this should result in a more consistent experience for users due to applications not being allowed that don't follow Oculus's development guidelines, although the content aspect of the review process is also going to be particularly important for anything that fails their content rules (and as such can never get approved), as it means those applications will have to go the Unknown Sources path. Meanwhile, the default blocking of applications compiled via the SDK but not sold on the store will also serve to encourage developers to use the Oculus platform and distribute their applications through the Oculus Store, rather than leaving Oculus out and using another store entirely.

To fray some of the concerns about the Oculus Store, Oculus is allowing developers to request keys for free, which can then be sold to users via other stores. The end result is very similar to Steam, allowing Oculus platform applications to be sold at third party stores while retaining their use of the Oculus platform. However I can’t recall a parallel of a Windows peripheral developer blocking third party applications by default, as this is typically the domain of OS vendors running closed platforms.