ReLive New Features (2)

Display Diagnostics

One of the most frustrating things to diagnose with a display that will not turn on is the cable. I’ve been there, in an overclocking content, having changed CPU/GPU/Motherboard/Monitor/DRAM over the course of two hours only to find that the cable between my machine and the monitor had died. There’s no indication that the cable was ever failing, and no light to say it was/wasn’t working.

I’m not the only one to have had this issue, apparently. AMD told a story of how their CEO of the Radeon Technology Group (RTG), Raja Koduri, had a similar issue trying to connect an HTPC to his TV. After many emails around the company, troubleshooting fresh OS installs and BIOS updates, the culprit was the HDMI cable, and despite the fact it had been used before was fine, but it had gone the way of the dodo.

With this in mind, AMD has created a set of display diagnostics in Crimson ReLive for HDMI. On all AMD APUs from Kabini and all GCN discrete GPUs, the software can detect a bad HDMI cable and realign the signal for both resolution and frequency to get to a point where the signal is stable.

This can help in most situations (short of a severed cable) by widening the window for bad data to be accepted at a loss of frame rate or resolution. At present this feature is only for HDMI ports on relevant cards, but when a bad cable is detected and a display has to change to work, the software notifies the user that a new cable is needed.

VP9 Decode and HDR10/HBR3 Support

One of the issues with last year’s launch of Crimson is that most of the video display settings seemed to not work with streamed video, particularly VP9 video coming from YouTube. This is in part due to VP9 decode not being supported on AMD products, but with the ReLive driver this changes. ReLive will allow for 4K60 decode of a VP9 stream for all GCN enabled discrete graphics cards and Stoney Ridge APUs. This is ultimately a software solution using the GPU, so it isn’t as power efficient as a dedicated hardware solution, but does offer a lot more performance than a CPU.

On the HDR front, AMD has been promoting that high end R9-300 series and RX-400 series graphics cards can support HDR10, however this has not been enabled in the drivers until Crimson ReLive. All the demos seen at AMD shows up to this point on compatible HDR10 displays have been beta driver versions specifically not released to the public, however with ReLive this changes. This also pairs with DisplayPort HBR3 support being enabled with ReLive allowing for 4K120, 5K60 and 8K30 over a single cable (HBR3 is on RX-series only).

FreeSync: Borderless Fullscreen Mode and Refresh Ramping

One of the most requested features for AMD has been bringing FreeSync into other modes than just single-focus full-screen mode. This is particularly important for users that use multiple monitors and end up requiring other content on a second monitor while the first is running, or for other applications to take focus quickly. With ReLive, AMD has put the tools in place to enable Borderless Fullscreen mode for software that can use it. One of the issues moving away from a fullscreen fixed mode is the click-to-response time latency, which AMD claims to have reduced by up to 24%.

Refresh Ramping will be another feature in ReLive and is designed to stop harsh changes in panel refresh rate depending on the content. When the onscreen display can run at a lower refresh rate, rather than slamming down immediately to that rate, the driver will pull the refresh rate down over a few seconds in order to give a smoother transition, and similarly to a higher refresh rate. AMD states that this saves power, which without data might be correlated to the actual switching of refresh rate rather than the low refresh rate itself.

ReLive New Features (1): Clean Install, Feedback/ Requests, Upgrade Advisor ReLive New Features (3): Radeon Chill, WattMan Extended, XConnect Support
POST A COMMENT

48 Comments

View All Comments

  • negusp - Thursday, December 08, 2016 - link

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

    Yes, you dork. Reply
  • BrokenCrayons - Thursday, December 08, 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. Reply
  • coder111 - Thursday, December 08, 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.
    Reply
  • negusp - Thursday, December 08, 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. Reply
  • Azurael - Thursday, December 08, 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.
    Reply
  • Azurael - Thursday, December 08, 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... Reply
  • Beany2013 - Friday, December 09, 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.
    Reply
  • 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?
    Reply
  • 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. Reply

Log in

Don't have an account? Sign up now