Home IT Hardware Assets AMD Delivers Crimson ReLive Drivers: Yearly Feature Update…

AMD Delivers Crimson ReLive Drivers: Yearly Feature Update…

266

This time last year we saw the launch of Radeon Crimson. This was AMD’s big attempt to state that a yearly cadence for software features was a good thing, and helped streamline the process for the number of initiatives that AMD participates in when it comes to GPUs. This year the update is called ‘Crimson ReLive’, and features a number of updates such as integrating the professional aspect of Radeon Pro into the cadence, a push towards VR features, and additional elements to gamers/streamers and even screen recording for professional software.

Then vs. Now

As was made clear during various presentations during 2016, AMD’s driver and software teams have been shaken up and put on a quest to improve the user experience. This has been explicitly stated as more quality assurance, no fixed update schedule (fixes are published when they are ready) and a new push to ensure game-ready drivers are good-to-go when the game is launched. As a result we were promised more beta driver releases and a half-dozen WHQL releases during the year to ensure that steady stream. (The WHQL process takes time and doesn’t take into account game-specific issues, but offers a certified set of collected updates which can be required in certain environments.)

Users were promised six WHQL updates in 2016, and so far there have been eight. There have been a total of 29 driver releases (which makes 21 betas / hotfixes) with 28 new games supported and optimized, most of which were supported on day one. AMD has stated that this resulted in a user satisfaction rating (as rated through their metrics) of 9/10, and have been key to promote that the newer Crimson style of doing things is a stark contrast to the perception of AMD driver tools and software of generations past.

Back at the launch of Radeon Crimson in 2015, we saw the launch of a streamlined interface taking over from Catalyst Control Center, the introduction of Frame Pacing, Liquid VR integration (which was expected given the launch of VIVE/Oculus in 2016), shader caching, custom resolution support, FreeSync improvements, FrameRate Target Control  (FRTC), Game Profiles, improved Eyefinity support and a new driver branch for performance. Ryan and Daniel wrote about this last year, and it’s still worth a read for users that do not recognize any of the terms in that list (some of which will be used in this piece).

For the 2016 update, Crimson ReLive, AMD has focused the updates into three key areas: Consumer, Developer and Professional. These are not hard-and-fast divisions, given that features for one market may also be used for another. However package-level updates typically fall into two areas: bug fixes and new tools.

AMD is keen to promote that for 2016, due to the immediate driver release methodology, the driver program can be on top of more bug-fixes and they’re released as required. Part of this comes through the additional level of automated quality assurance but also an increased level of real-world/end-user test procedures as well as rigorous VR testing. AMD is aiming that the increased testing and focus on launch-day drivers that are right first time will give optimum performance. If there are updates to come, this way of testing also allows performance updates to be rolled out quicker, which AMD has tested compared to the RX 480 launch drivers. It was stated that the days of 40%+ performance increases due to drivers is set to disappear in part due to this refocused effort to get it right on day one.

Crimson ReLive on Linux

Before we get into the meat of the launch, a side note about Linux. The new launch will extend driver support to all AMD discrete graphics cards that are based on GCN architecture (so from AMD HD 7000-series and newer) but also gives Linux official FreeSync 1.0 support.

Supported operating systems for this are Ubuntu 14.04 / 16.04, RHEL 6.8 / 7.2 / 7.3, and SLED/SLES 12 SP2.

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

Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here