AMD Delivers Crimson ReLive Drivers: Yearly Feature Update for Radeon Gamers and Professionals
by Ian Cutress on December 8, 2016 9:00 AM ESTWe’ve covered AMD’s progress into open source software development, with most efforts coming through GPUOpen. AMD is keen to point out that over 2016 GPUOpen now provides 70+ SDKs/Samples/Libraries/Tools that are used in common software packages such as VLC, Firefox, Ubuntu, WordPress, Blender and so on. As part of today’s announcement, a few more tools are coming to the box.
Radeon Loom
Radeon Loom was demonstrated earlier this year, and the beta preview is now available through GPUOpen. Loom is AMD’s answer to the current problem of 3D camera content: how to stitch together a sufficient number of flat images to remain seemless in a 360º environment or playback.
With the new preview, using AMD’s open source implementation of OpenVX, developers should be able to use the toolset to create a combined 4K 360º video using 24 images in real time. This becomes important when live video is streamed into a 360º experience, such as sitting on the touchline of a sports game or getting ring-side seats. For non-live content that is pre-processed to consumption, Radeon Loom will support 31 image input for an 8K equivalent display.
OCAT (Open Capture and Analysis Tool)
In the world of benchmarking, two main issues have probed up in recent years. Firstly was the issue regarding multi-GPU frame pacing and runt frames, which exposed not only hardware failure but the failure for software to accurately record what is shown compared to what is computed. To detect runt frames, the FCAT tool was developed involving on-screen overlay, capture, and frame-by-frame processing. This requires a second PC with fast storage, capture cards, and compute resources.
If runt frames aren’t an issue, such as in single GPU environments or with configured multi-GPU profiles, then the most commonly used software for live benchmarking is FRAPS. But due to the way FRAPS takes data, it cannot be used for DX12 or Vulkan due to the different way in which the frame pipeline is managed. AMD’s is promiting a new OCAT tool that is designed to be an all-encompassing frame rate benchmarking tool for modern APIs that is purely software based.
OCAT will support DX11, DX12 and Vulkan with a simple interface and log outputs. Rather than FRAPS that captures any screen that requires a 3D engine, OCAT will operate on software run through itself in order to put in the appropriate hooks required.
OCAT is third-party but also more importantly is open source. Thus despite AMD promoting it, analysis of the code can be performed to make sure there are no hidden tricks to frame calculations. We will be experimenting with the tool for our benchmarking over the course of the next few months.
Increased Game Developer Integration in DX12
One of the key talking points for 2016 has been the move towards DirectX 12, and here at AnandTech we’ve closely followed the sorts of improvements possible from creating content using the latest API as well as extensive testing as the technology was being enabled. As one of the lead partners in the DirectX 12 specifications, we would expect AMD to be promoting its use, and with today’s announcement AMD has stated that they are working with 50+ titles expected to come to market that will use DX12 features, up from the ~15 currently available.
Depth of Field, TressFX 4.0, H.265
As game engines are becoming the go-to tool for certain types of non-game content generation such as storytelling (or even story telling in games), then increased fidelity and realism, along with cinematic effects, are being integrated into these tools. For today’s announcement, AMD has added new tools to GPUOpen for Depth of Field (DoF) and updates to TressFX and H.265.
The DoF update is simple – it applies a relevant set of filters to the parts of the scene that are not meant to be in focus, basically a bokeh for game engines. AMD states this has a low-performance impact.
TressFX 4.0 expands the hair modeling tools initially released with AMD and used heavily in Tomb Raider. Version 4.0 gives increased developer control, and scalable rendering to ensure peak performance with hardware at hand. Version 4.0 is also DX12 supported.
H.265 encoding has been a part of GPUOpen, but with the new launch the tools are being expanded for in-game DX12 frame processing. AMD was light on the details, except to say that more of the H.265 feature set is now available.
48 Comments
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.