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

  • ABR - Thursday, January 16, 2014 - link

    Kind of funny to hear "Iris" mentioned here given that the SGI O2 was an early example of a workstation with HUMA back in the mid-90's. :) There was no such thing as GPGPU back then (it might have helped save SGI if there was), but it provided a big help for memory-intensive things like texture-mapping.
  • vinayshivakumar - Thursday, January 16, 2014 - link

    Why are the iGPU codenames mentioned in the CPU benchmark and the CPU is in brackets ?? What is the reason to mention the GPU at all in a CPU test ? To the untrained eye , it might look as is HD3000 is faster than the AMD R7... Which is obviously not true...
  • vinayshivakumar - Thursday, January 16, 2014 - link

    Am I missing something here , apart from a bias ?
  • Th-z - Thursday, January 16, 2014 - link

    I agree the labels can be misleading, in CPU benchmarks other than the second table "Agisoft PS v1.0 Mapping IGP" on page 10, all other are done with CPU only. Some tables got it right while some have iGPU names leading the labels and model names in the brackets. What should be in the brackets are iGPUs. Consistency in labelling is needed. It's probably not intentional, just a result of messing up the labels and get the review out ASAP.
  • ryrynz - Thursday, January 16, 2014 - link

    You should be listing the GPU first in the Winrar results. The GPU is obviously not important in this benchmark and really shouldn't be specified at all.
  • sonofsanta - Thursday, January 16, 2014 - link

    "...the benchmark follows Jenson Button in the McLaren who starts on the grid in 22nd place, with the field made up of 11 Williams cars, 5 Marussia and 5 Caterham in that order."

    You sure a 2013 McLaren could make it through that field? I reckon it'd still fail to make the podium.
  • HaryHr - Thursday, January 16, 2014 - link

    What's the story with Iris Pro and huge difference between average FPS and minimum FPS?

    In BI performance test: 78 average and 6 minimum, quality test: 20 average and 1 minimum.
    If this is happening during gameplay this makes game almost unplayable. AMDs lineup has much smaller variance.

    It would be nice to see time frame tests.
  • synce - Thursday, January 16, 2014 - link

    What a disappointment... I thought the 7850K would be the first rig I've built in years but it's barely an improvement over the 6800 and still no match for an i5 :(
  • Rogatti - Thursday, January 16, 2014 - link

    Drivers still immature ... I will wait to form an opinion
  • SolMiester - Thursday, January 16, 2014 - link

    WOW, looks to me that the A10 6800k is the better bang. I saw only 1 game where the R7 bettered the 6800K where any of them were playable....

Log in

Don't have an account? Sign up now