AMD combines all of its VR related assets and tools into its LiquidVR branding, and with the Crimson launch last year it integrated the LiquidVR assets into the consumer driver set in preparation for the onslaught of 2016 VR headsets and content that entered the market. With Crimson ReLive, three new assets are being added into the platform.

LiquidVR: Affinity Multi-GPU

When AMD launched the RX480 it was advertised as a VR Ready card, and when combined with another RX 480 and DirectX12, offered great performance. DirectX 12 offers many different modes for multi-GPU, with alternate frame rendering or separate asset rendering depending on the mode used. Affinity Multi-GPU takes that AFR concept but splits it per-eye for virtual reality. This allows each card to work independently on each eye, resulting in up to 20x lower frame re-projection as reported.

The main benefit here is that each card should be working near its peak load, and can compensate if one GPU has a longer-than expected frame, although it means maintaining timing and can make sharing assets an issue. Nonetheless, AMD has stated that during complex scenes it will certainly help the immersion factor.

LiquidVR: MultiView and MultiRes Rendering

For virtual reality, multi-projection is not a new concept but is important in the sense that different cameras will render different objects either at a closer range, or not at all if they are hidden. MutliView on AMD’s side of the fence is a tool to aid in multi-camera rendering by optimizing shared assets and reducing the processing overhead.

MultiRes Rendering is a solution to the fact that humans can only focus on a small fraction of what they see in front of them, and as a result we don’t really need everything in view at the best detail. The MultiRes tool will make the GPUs spend more time improving the quality of the assets in focus and less time at areas that will be of low focal importance. AMD slightly confuses the matter by saying ‘pixel density’ but in this case it means more along the lines of higher resolution rendering for the part in focus being downsampled for a given area for a better quality visual where it matters.

It should be clear by now that one of the main things about virtual reality is ‘with limited compute, how can you make what the user sees better?’ and the solution to that is to cut what you can’t see and de-emphasize content that is less important. MultiView and MultiRes are along these lines (as well as technologies from other vendors). Ultimately MultiRes can be particularly important when combined with Depth of Field filters mentioned above – if it’s going to be blurred through DoF anyway, there’s less reason to spend time improving the rendering quality of the content before it is blurred.

LiquidVR: TrueAudio Next

While TrueAudio was announced and released several years ago, and despite only a small handful of games using it, moving to VR makes it more important to calculate where audio comes from and how it propagates through a particular scene. Crimson ReLive now adds the TrueAudio Next package into the consumer and professional drivers for supported cards in order for titles and content that use the TrueAudio tools to take advantage of dynamically propagated audio. Audio is one of those tricky elements where it requires individual filters based on location/reflection/reflection on different surfaces for each audio sample and often completely different filters on different samples simultaneously (a scream through glass combined with heavy boots on a metal grating from around the corner). In a VR environment these calculations can add up as samples and complexity increase without the proper tools to manage.

2016 into 2017: Developer Tools Crimson ReLive: Radeon Pro Drivers
Comments Locked


View All Comments

  • negusp - Thursday, December 8, 2016 - link

    Linux support, AMD?
  • negusp - Thursday, December 8, 2016 - link

    Yes, you dork.
  • BrokenCrayons - Thursday, December 8, 2016 - link

    I'm hopeful they can improve since I don't want to have my choice of Intel or Nvidia on Linux for my next graphics card upgrade.
  • coder111 - Thursday, December 8, 2016 - link

    Wait what? AMD is great on Linux. The most FPS you can get with open-source drivers. And it's getting better by the day.

    NVidia is still better if you are willing to run BLOBs. But I don't want to deal with that hassle.

    Read phoronix for more Linux benchmarks.
  • negusp - Thursday, December 8, 2016 - link

    AMD is horrible on Linux. The fglrx driver has no support and the open-source drivers aren't great. OpenGL performance is really quite bad as well.
  • Azurael - Thursday, December 8, 2016 - link

    I don't get it, have you guys actually used AMD under linux recently? On the 7870 I just pulled out of my machine (and presumably at least all the GCN1.x cores, I know the later models use amdgpu which I've not tried), the radeonhd driver is totally stable now and fully supports OpenGL 4.5 and so far as I could see matches or betters the performance of the Windows drivers (though it's difficult to compare cross-OS, I wasn't about to mess up my Gentoo install with the proprietaries)

    Since I stuck a GTX 970 in my machine, I've realised it's actually Nvidia who are the laughing stock with drivers these days. In a matter of months, I've had stability problems under Windows, performance regressions with new drivers, the open source 'nouveau' driver won't even boot on said 970 as of 4.8.x without a bunch of kernel patches that just about enable 2D acceleration (but not at 1440, only 1080)

    The proprietary Linux drivers are okay but it's a right pain in the backside having to remember to rebuild them every time I do a kernel update, plus they have no framebuffer console support so if something goes wrong before GDM starts successfully, I have to SSH into my machine to resolve it.
  • Azurael - Thursday, December 8, 2016 - link

    I should add that I can't use a VGA framebuffer because it's an EFI-booting system, and efifb conflicts with the proprietary Nvidia drivers. They are a joke. And that's before we get on to the DX12/Vulkan performance. I wouldn't be at all surprised if my old 7870 matched the performance of my 970 there...
  • Beany2013 - Friday, December 9, 2016 - link

    When AMD works on Linux, it works well.

    However, I have an Ubuntu 16.10 box, with an R280, and AMD have basically thrown me under the bus. I can't even play back HD video without stuttering. There is no info on whether they will ever actually support <GCN 1.2 on ubuntu, period.

    I'm going to have to revert back to Ubutnu 14.04.4 (not .5, as it has the Xorg that AMD can't be arsed working with) to get accelerated graphics back. Or install Debian instead (which would break the workflow I've had in Ubuntu for a few years).

    or keep my workflow and by nvidia.

    If anyone has an R280 on Ubuntu > 16.04 and has it working, let me know - because this, and AMDs attitude (IE *all* the development on Windows, fuck all on Linux) is really starting to get on my fucking tits.
  • artifex - Monday, December 12, 2016 - link

    You're blaming your gear manufacturer because your preferred distro that used to work with it dropped support in more recent spins?
  • JopV - Wednesday, December 21, 2016 - link

    Uhm, no. FGLRX stopped development and no longer supports newer Linux kernels. So only distro's with old kernels will work, it can impossibly work on any modern distro.

Log in

Don't have an account? Sign up now