TrueAudio

As part of the Kaveri package, AMD is also focusing on adding and updating their fixed function units / accelerators. Due to the jump on the GPU side to GCN we now have the TrueAudio DSP to allow developers to increase the audio capabilities in game, and both the Video Codec Engine (VCE) and Unified Video Decoder (UVD) have been updated.

All the major GPU manufacturers on the desktop side (AMD, NVIDIA, Intel) are pushing new technologies to help improve the experience of owning one of their products. There are clearly many ways to approach this – gaming, compute, content consumption, low power, high performance and so on. This is why we have seen feature like FreeSync, G-Sync, QuickSync, OpenCL adoption and the like become part of the fold in terms of these graphics solutions.

AMD’s new feature is TrueAudio - a fully programmable dedicated hardware element to offload audio tasks to.

The main problem with developing new tools comes down to whether they should be implemented in a general fashion or with a dedicated element. This comes down to the distinction of having a CPU or an ASIC do the work – if the type of work is specific and never changes, then an ASIC makes sense due to its small size, low power overhead and high throughput. A CPU wins out when the work is not clearly defined and it might change, so it opens up the realm of flexibility in exchange for performance per watt.

CPUs are now significantly powerful that a range of audio based techniques are available to them and the algorithms are optimized. The only limitation in this regard is the imagination of the developer or audio artist, which actually becomes part of the problem. When implementing an audio filter on the fly to a video game, the processing via the CPU can be overly taxing, especially when the effect is persistent over a long time. The example AMD gave in their press slide deck is one of adding reverb to an audio sample. The longer the reverb, the bigger the draw on CPU resources:

AMD cites this CPU usage as the effect of one filter on one audio sample. Imagine being in a firefight situation in a video game, whereby there are many people running around with multiple gunshots, splatter audio and explosions occurring. Implementing effects on all, and then transposing audio location to the position of the character is actually computationally expensive, all for the sake of realism. This is where the TrueAudio unit comes into play – the purpose is to offload all of this onto a dedicated bit of silicon that has the pathways built in for quicker calculations.

TrueAudio is also implemented on AMD's latest-generation R9 260 and R9 290 video cards – basically anything at least GCN 1.1 and up. Meanwhile we also know that the PS4’s audio DSP is based on TrueAudio, though given the insular nature of console development it's not clear whether the APIs are also the same on both platforms. AMD for their part is working with major audio middleware plugins (wwise, Bink) in order to help develop the TrueAudio ecosystem, so even in the case where the APIs are dissimilar, middleware developers can abstract that and focus on the similarities in the hardware underneath.

As is usually the case for these additional hardware features, games will need to specifically be coded to use TrueAudio, and as such the benefits of TrueAudio will be game specific. At the same time there are not any games currently on the market that can take advantage of the feature, so the hardware is arriving before there is software ready to use it. The first three games on AMD's list that will support TrueAudio are Murdered: Soul Suspect, Thief, and Lichdom. Much like FreeSync, I expect the proof is in the pudding and we will have to wait to see how it can affect the immersion factor of these titles.

Unified Video Decoder and Video Codec Engine

I wanted to include some talk about the UVD and VCE with Kaveri as both are updated – we get UVD 4, an update to error resiliency for H.264, and VCE 2, as shown below:

Of the two blocks, the improved VCE has the more interesting improvements to discuss. With the addition of support for B frames in H.264 encoding, the resulting ability to do backwards frame prediction should help improve the resulting image quality from VCE and/or reduce the required bitrates for any given quality level. Meanwhile the addition of support for the higher quality YUV444 color space in the H.264 encoder should help with the compression of primarily linear lineart/text, which in turn is important for the clarity of wireless displays.

Llano, Trinity and Kaveri Die: Compared A Deep Dive on HSA
Comments Locked

380 Comments

View All Comments

  • dbcoopernz - Tuesday, January 14, 2014 - link

    I'd like an APU with enough GPU power to run all the high quality options in MadVR. Would make a very nice HTPC chip.
  • thomascheng - Tuesday, January 14, 2014 - link

    I think Mantle can make that happen, but will see how much support they get.
  • MrSpadge - Tuesday, January 14, 2014 - link

    Mantle has nothing to do with GP-GPU, that's not using DirectX anyway.
  • JDG1980 - Tuesday, January 14, 2014 - link

    My discrete 7750 couldn't handle Jinc scaling in MadVR (at least not without dropping frames on some 1080i test clips), so this is going to be another generation or two in the future.

    The PS4 APU could probably do it, if that was available in a generic PC form factor.
  • MrSpadge - Tuesday, January 14, 2014 - link

    Add to that DDR4 and/or 4 memory channels, or at least a large on-package buffer like Crystal Well.
  • yankeeDDL - Wednesday, January 15, 2014 - link

    But the whole point of HSA is to get the GPU to do CPU work that it could do better (like FP).
    So you wouldn't need more CPU cores at all.
    Look at it this way: AMD's CPU is less efficient than Intel's, while the GPU is more efficient.
    Having a CPU-imbalanced APU, would put it in a tough(er) spot to compete against Intel. A GPU imbalanced, as Kaveri is, would improve the lead than it already has on the GPU side.
    Now imagine that HSA kicks in, and the GPU lead translates directly in CPU lead ...
  • mikato - Wednesday, January 15, 2014 - link

    This is true. I hope we see more articles as adoption of HSA starts to take hold.

    It is too bad they are far behind in CPU power, but AMD has the right strategy. Either way, some things are better done on the GPU. AMD just has more benefit than Intel to get things moving that way sooner with their GPU advantage and CPU disadvantage. Intel will have no choice but to follow that lead.
  • nissangtr786 - Tuesday, January 14, 2014 - link

    http://www.extremetech.com/computing/174632-amd-ka...

    hsa does well on amd main thing they marketed in libreoffice.
  • Ryan Smith - Tuesday, January 14, 2014 - link

    I'm normally not one to speak about other articles, but those are all OpenCL benchmarks. The OpenCL HSA driver won't be released for another quarter. And the HSA SDK is similarly far off.

    http://www.anandtech.com/show/7677/amd-kaveri-revi...
  • krumme - Tuesday, January 14, 2014 - link

    What a bencmark of a review. I learned a lot. Great. Thanx.

Log in

Don't have an account? Sign up now