We’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.

AMD Delivers Crimson ReLive: Yearly Feature Update for Radeon Gamers and Professionals LiquidVR: Affinity Multi-GPU, MultiView, MultiRes, TrueAudio Next
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