So we have something special for our readers today - an interview about LiquidVR. Or more specifically, an interview with one of the lead software architects that worked on LiquidVR: Guennadi Riguer. The LiquidVR SDK was created from the ground up to cater to VR applications on modern day GPUs. We asked Mr. Guennadi to walk us through the philosophy behind LiquidVR as well as its future prospects - all the while clearing up some fuzzy areas that we were dubious about.

The philosophy behind LiquidVR - a software ecosystem to match the hardware

The story begins from the initial advent of VR - with Oculus appearing on the scene for the first time and the emergence of a brand new market. One that would likely take the world by storm. While all the attention is currently focused on the hardware (Oculus Rift vs HTC Vive etc), once the dust settles, the software ecosystem is the one that will come under scrutiny. Before LiquidVR there was nothing that was designed natively with VR in mind. Without any further ado, let’s hear it directly from the man himself:

[GR] We at AMD are very passionate about graphics, VR with its high graphics demands is particularly exciting. However, VR is more than just pretty graphics. As a platform, it has the capacity to revolutionize how we interface with computers and provide a whole range of new experiences we haven’t even imagined. Because of that we see VR as more than ‘just another cool technology’ and we firmly stand behind the efforts to bring immersive, unique experiences to Radeon users through continued innovation of LiquidVR. We’ve been excited about VR since the very first announcements of HMD projects that are soon to hit the market. Once solutions started maturing, we looked at what pieces of the software ecosystem (OS features, APIs and etc.) were missing or were not designed natively for VR. Our goal was to create a set of solutions to unleash VR development and provide first class experience on existing systems. We identified four main features that became the foundation of our LiquidVR SDK.

So what are these features that Riguer talks about? well, there are a total of 4 features currently listed on GPUOpen right now (with a plus one):

Asynchronous Shaders : Provides in Direct3D 11 a subset of functionality similar to async-compute functionality in Direct3D 12.

: Provides in Direct3D 11 a subset of functionality similar to async-compute functionality in Direct3D 12. Multi-GPU-Affinity : Provides ability to send Direct3D 11 API calls to one or more GPUs set via an affinity mask.

: Provides ability to send Direct3D 11 API calls to one or more GPUs set via an affinity mask. Late-Latch : Provides ability update constant data asynchronously from the CPU to reduce input or sensor latency.

: Provides ability update constant data asynchronously from the CPU to reduce input or sensor latency. GPU-to-GPU Resource Copies: Provides ability to copy resources between GPUs with explicit control over synchronization.

Remember the plus one we talked about? Well, that happens to be the Direct to Display interface which was originally listed as part of the 4 features of Liquid VR but was later replaced by GPU-to-GPU Resource Copies. This feature is still present but is only available to hardware vendors that make the HMD. In fact what it does is offer a capability to render directly on-to the Headset, bypassing the operating system directly. We also tired asking Riguer to give up his favorite feature of LiquidVR but were not particularly successful.

Chasing VR 'Nirvana': 16k for each eye at 144hz

The VR market is something that has been growing steadily since its emergence into the open a few years back. To all of our tech savvy readers, I am talking about the VR market which emerged after the Oculus Rift. Headset shipments are expected to double in a few years and LiquidVR remains AMD’s primary VR focus. It is because of this that the future of LiquidVR is of significant interest to tech enthusiasts. Mr. Guennadi had the following to say about that:

[GR] LiquidVR is a set of technologies that has a very clear mission: to take maximum advantage of GPUs to enable rich and seamless content. As VR technology evolves, so will LiquidVR – we have a robust roadmap that will tackle a wide range of issues the industry already talks up as the next set of challenges we’ll be facing. We believe that with LiquidVR, AMD has helped the industry to take a first big step in this wonderful new immersive world called virtual reality. LiquidVR will continue to drive hardware and software technologies that will ultimately lead to the nirvana of VR: 16K/eye, 144Hz and above refresh rate, and virtually no latency, all in a wireless, small form factor package.

AMD has a road map in place for the evolution of LiquidVR that will grow as the industry grows. Keep in mind however, that this roadmap is far from set in concrete as you will find out later on in this article. AMD is chasing the perfect standard here which Riguer dubbed as “VR Nirvana”: 16k resolution (for each eye) and a refresh rate of 144 Hz. Although, this won't be possible for at least a few generations of GPUs maybe we will be able to see something close to that by 2020. 16k resolution would be ideal for VR because naturally, the higher the resolution of the eye piece, the less the "screen door" effect. Not only that, but a refresh rate of 144 Hz would eliminate any and all nausea issues associated with low refresh rates. For the time being however, the Oculus standard of 2k 90fps (1080p each eye) will have to do.

AMD's LiquidVR is designed for Direct3D11

One of the rather interesting things that I noticed in the white paper for LiquidVR was that it is built for Direct3D11. So the first thing I asked Riguer was to confirm my understanding of LiquidVR as well as comment about its future in an ecosystem which will soon be populated with low level APIs like DirectX12 and Vulkan. I also wanted to know whether AMD is considering any Direct3D12 implementation of LiquidVR SDK.

[GR] That’s correct – LiquidVR features are currently exposed in DirectX 11. While developers are really excited about a new generation of APIs – DirectX 12 and Vulkan, it takes time for such technologies to be adopted, become mature and available to the mainstream. A lot of development in VR is currently done with mature engines (Unreal and Unity) built with DirectX11 technology, and it would’ve been a shame if fast-paced development in VR had been stalled waiting for DirectX 12 and Vulkan to mature. This is why in LiquidVR we focused on enabling better VR support with DirectX 11, to solve challenges immediately. The DirectX 12 API is much more powerful and flexible than DirectX 11 and in some ways there is less need for delivering exactly the same LiquidVR features. We’re definitely looking at DirectX 12 integration and bringing further enhancements to it with LiquidVR.

Basically, LiquidVR was designed to offer a solution to developers as of right now – in other words, on DirectX 11. DirectX 12 and Vulkan API have not achieved maturity yet - and LiquidVR aims to offer a solution to developers who do not want to wait for them to mature. The point is to target game engines and existing SDKs that work on DirectX 11 and give them the same relative advantage (or something very close to) that DirectX 12 would go on to offer.

Essentially, LiquidVR is a solution that will be available to a very large install base and one that can hit the ground running as soon as it was implemented. LiquidVR is actually installed on all PCs running the latest Catalyst and can be triggered by the developers (assuming you have a supporting GPU). Many of the features that LiquidVR provides to DirectX 11 users are available natively to DirectX12 users - something that makes a Direct3D12 implementation of LiquidVR redundant.

The SDK was designed to be a stepping stone and the connecting link between two different eras of APIs. AMD's Mantle API had very similar aims; aims which have now been met. All that said, AMD has not completely ruled out integration with DirectX12 and is still looking to bring new features to the LiquidVR toolkit. With Oculus Rift out right now and HTC Vive launching soon - developers could take advantage of LiquidVR to gain many low level features in existing game engines. The question becomes however, whether any developer would chose to code for a transitional API. This is an approach that wasn't particularly successful with Mantle API as we know it.

Aligning AMD's LiquidVR strategy with DirectX12 and Vulkan - What is the future?

Of course, the fact that LiquidVR is not integrated with other low level APIs right now brings us to another pertinent question. What exactly is AMD's strategy for LiquidVR with DirectX12 entering the scene right now (and Vulkan following closely behind)? AMD has graciously published the LiquidVR source code on GPUOpen but how exactly will it align LiquidVR with the low level API movement?

[GR] LiquidVR is about delivering features and technologies that address particular developer needs and gaps in a software ecosystem, but we never envisioned it to remain the only solution. DirectX 12 is a much better match for VR implementations than older APIs, and we’re very happy to see such enthusiasm for DirectX 12. The key is that we’re not standing still and are not looking back. We’ll continue to bring enhancements to DirectX 12 and other APIs through LiquidVR as well as through collaboration with our ecosystem partners. Here’s another way to look at it: we’re in no way competing with DirectX 12, we just want to see it as an API with great solutions for VR that unlock the ultimate potential of Radeon GPUs. The key to all our developer-focused efforts like LiquidVR, and many others that fall under the GPUOpen initiative is to enable better use of our GPUs, giving developers more control. All of the features in LiquidVR have been designed to perfectly match our hardware and software architectures, and extract the most performance and efficiency. In order to deliver certain functions, we needed to go above and beyond what other APIs offer. For example, LiquidVR asynchronous compute offers special quality of service (QoS) controls and better integration with Direct-to-Display that is not available in other APIs.

As Riguer points out, LiquidVR was created to serve a very specific purpose: bridging the software gap that existed at the time it was created. Just like with Mantle API, AMD was playing the white knight here, but now that other (and possibly better) alternatives exist on the horizon, the future of LiquidVR becomes uncertain. LiquidVR does not compete with DirectX12 - which is a much better match for the VR industry than the former – that much is clear. But will it fade into the background completely like Mantle or become something more subtle. While it is too soon to answer that question, the fact there are still a few tricks that LiquidVR can pull off that DX12 can’t suggest that it might be the latter. In any case, only time (and AMD) will tell.