Multi-GPU Support, Power Design
Polaris Display Technology Support
The big story around display technology with Polaris is the move to support DisplayPort 1.3/1.4, HDMI 2.0b and the on-coming HDR screens.
By adding in support for the not yet finalized DP1.3 and DP1.4-HDR standards, the new Polaris display pipe can support more than 30 Gbps of data throughput which is 80% higher than HDMI 2.0b. The result is support for massive resolutions or massive refresh rates – going from 1080p at 240Hz in HDR to 5K at 60Hz over a single cable in SDR.
We have talked about the advantages that HDR displays will give gamers and content viewers in the near future, and while none of that technology is specifically AMD-based, the Polaris and future AMD architectures look to be prepared for it.
For gamers, AMD is hoping to accelerate the move to HDR content with the Radeon Photo SDK. By encouraging game developers to add HDR tonemapping in the game engine by passing back data from the display specifications, the move to HDR should be painless. Having seen HDR content in person many times I can tell you that it is a dramatic shift for image quality and with HDR TVs coming in at incredibly low price points already, this should be a push for holiday 2016.
New Polaris Power Design Considerations
AMD has been open about the changes that a move to 14nm process technology offers for GPUs, and I have written about this many times in the past, so I don’t feel the need to rehash that content here today. What is new, is how AMD is utilizing that shift in technology to improve the power design of Polaris.
What AMD calls adaptive clocking is similar in theory to what NVIDIA calls GPU Boost – the goals of both technologies are to raise the effective frequency of the GPU without sacrificing performance due to voltage and power issues from specific workloads or from specific components. In previous AMD architectures, in order to cover the variation and quality of voltages from package and power supplies, the average voltage had to be raised to ensure lifetime functionality and stability of the product. This wastes power, and in effect, wastes potential performance.
This slide shows an example of the differences between the “old” ways of doing things on Hawaii and Fiji and the “new” way of Polaris. Along the top there is a line showing voltage input supply with some frequent droops/spike down. The diagram below zooms in on one of the drops.
The yellow line represents the voltage threshold that Polaris is able to run at (and determine average clocks based on) thanks to the addition of adaptive clocking while the red line shows what has happened in previous architectures: the clock speed had to be lowered in order to account for the voltage drops. On Polaris, the clock speed drops only temporarily to secure stability of the system, then reverts to the higher clock state once voltage normalizes.
By utilizing this new capability, the Radeon RX 480 and other Polaris GPUs will be able to run with a targeted performance level and optimal energy efficiency.
AMD has implemented some other interesting changes on the power design for Polaris including one called boot time power supply calibration (BTC).
BTC uses analysis code run at the time of testing and binning at production to log and then re-test voltages through the integrated power supply monitors. Based on the results at each boot time, the card can dial in board voltage regulators to the deliver the same voltage as observed on the first day of testing at the factory. This gives the GPU the ability to adapt to changes in board design from partners, for example.
Polaris also has the ability to adjust voltages to compensate for aging. (I wish I had this capability…) As with BTC tech above, the GPU has the ability to self-calibrate over time, changing voltages to accommodate for aging transistors or even other components on the PCB. Interestingly, this does mean that RX 480 cards might use more power as they get older, but if the alternative is to fail instead, I think most users would gladly make the efficiency trade.
AMD’s LiquidVR is an API and set of tools targeted at developers building VR games and experiences. Along with the Polaris launch, the company is adding a few capabilities to this package.
First up is TrueAudio Next, an updated audio engine targeted at VR and using ray traced audio. This sound very similar to what NVIDIA announced with Pascal and hopefully there is some overlap in the implementation methods so that we might actually see wide-scale adoption. AMD claims that its version of spacial audio will utilize asynchronous compute to improve performance and lower any latency for the developer.
Interesting side note: the old TrueAudio DSP is completely removed from Polaris. TrueAudio code built into any game or application you have today will not run on the RX 480.
Compute Unit Reservation is the ability for a developer to specifically dedicate a subset of the CUs for a single task queue. This gives the developer a deterministic amount of performance for secondary functions and workloads.
Also coming to LiquidVR is Variable Rate Shading, similar to what NVIDIA announced with the GeForce GTX 980 Ti then called multi-res shading. This allows a collection of viewports to be created at different resolutions for VR gaming, putting priority on the center or eye-tracked focal point of the display. This can lower the workload for the GPU in games that implement it with potentially no noticeable change in quality for the gamer. NVIDIA has deprecated multi-res shading to some degree in favor of Simultaneous Multi-Projection.
Though AMD admits that working with multiple GPUs inside DX12 titles will continue to be an uphill battle, they did not take the same road NVIDIA did and cut off more than 2 GPU support for Polaris. The Radeon RX 480 will still support up to 4-GPUs running in CrossFire, while the RX 470 and RX 460 will be limited to 2-way CrossFire. How this CrossFire gets implemented with DX12, and how much work falls back to AMD versus the game developer, will continue to be a topic of discussion. I plan to do a follow up on this topic shortly after RX 480s hit online shelves.
AMD is implementing a new pacing feature for CrossFire in AFR (alternate frame rendering) mode. The idea is to insert a delay between the time a frame is done rendering until the time of the next present interval sent from the game engine. The goal is to even space out the frames on the display as well as the times being sent back to the game engine itself, improving smoothness of both game time and display time. Obviously this is a technology that needs to be implemented and tested before we can make any claims to its usefulness, but I am glad to see AMD at least walking down the right path.
Microsoft’s Chas Boyd was on-hand at AMD’s editor’s day for Polaris and previewed ideas that MS is implementing to help improve multi-GPU scaling. The best news surrounded a new abstraction layer for game developers to utilize for multiple GPU support that MS would be releasing on GitHub very shortly. According to Microsoft, with only “very little” code adjustment, DX12 titles should be able to implement basic multi-GPU support.