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
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