LiquidVR

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

48 Comments

View All Comments

  • psychobriggsy - Friday, December 9, 2016 - link

    AMD has been shipping proprietary AMDPRO drivers on Linux for quite some time, and if you want open source then AMD is the only choice really given Nvidia won't provide Pascal firmware images for Nouveau, and even then the AMD open source drivers are faster (in fact they compete very well with AMD's blobs on Linux now, they just don't provide OpenCL and Vulkan yet).

    Sure, if you game on Linux the Nvidia blobs are a bit faster than AMD overall, but it certainly isn't like a few years ago.
  • BrokenCrayons - Thursday, December 8, 2016 - link

    Phrononix is my usual source for GPU benchmarks in Linux. I'm a regular reader over there and much of my current opinion was based on their performance analysis.
  • YukaKun - Friday, December 9, 2016 - link

    Benchmarks don't tell the day-to-day story. I have used both throughout the years and AMD has gotten ahead of the game now. People's complaints took some time, but they got their stuff together and they have zero things to have envy of nVidia's drivers.

    Performance not-withstanding, AMD is in a great shape now in the Linux world. In fact, I have to say it works wonders with SteamOS. Maybe I am a lucky one, but my 7970Ghz did not have a single issue playing all of the Linux ported titles and now the RX480 doesn't either. Outside of gaming, no issues either. It's been quiet sailing so far and I hope it remains that way.

    I can't say the same thing with nVidia in my laptop. I still, after 10 years aprox, still don't have switchable graphics and I am scared of upgrading the proprietary binary, since I've had issues with it, even using genkernel.

    Cheers!
  • BrokenCrayons - Friday, December 9, 2016 - link

    Thanks for the information. I've been running a few older Nvidia GPUs (NVS 160m and 8400m GS) in my laptops without problems, but I don't use open source drivers. They experience has been very "sane" for my usage. I've yet to move my desktop with its GT 730 off Windows 7 which is largely a laziness thing as I already have an unused drive sitting in the case that just needs to be plugged in.

    I haven't personally tinkered with AMD graphics under Linux since I retired a couple of older laptops, one with a C-70 and another with an E-450 and their integrated GPUs. They were a pain to get working under Arch and Mint. I'm glad to hear that a current gen RX480 is working out for you. I might grab a RX460 in the next month or three and at that point I'll probably be more interested in transitioning to Linux and moving the system into a smaller case (microATX board in a full tower case...kinda a waste of space).
  • mr_tawan - Friday, December 9, 2016 - link

    Bad news is, the latest AMD's RFC for DAL/DC get slammed today.
  • psychobriggsy - Friday, December 9, 2016 - link

    Yeah, I definitely sense that AMD's Linux devs were being held back by a higher up PHB regarding the HAL that was being imposed. Hopefully this major burn will allow them to do things properly at the kernel level even if it needs some linux-specific stuff in the drivers.
  • IntoGraphics - Tuesday, January 3, 2017 - link

    No.
    Read Phoronix for "It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel" :
    http://www.phoronix.com/scan.php?page=news_item&am...
  • VisS - Friday, December 9, 2016 - link

    What Crap ?
  • Colin1497 - Thursday, December 8, 2016 - link

    Out of the box this looks really impressive. Time to start the download.

    One question: Technical reason that rebadged r9-2xx series cards get HDR10 in their r9-3xx guise while the original r9-2xx's don't? BIOS or marketing?
  • Colin1497 - Thursday, December 8, 2016 - link

    Just realized how old I sound saying "start the download" like this was 1993 and it was going to take a week. It took a few seconds...

Log in

Don't have an account? Sign up now