AMD's Trinity : An HTPC Perspective

In the last few HTPC reviews, we have incorporated video decoding and rendering benchmarks. The Ivy Bridge review carried a table of values with the CPU and GPU usage. The Vision 3D 252B review made use of HWInfo's sensor graphs to provide a better perspective. In the latter review, it was easier to visualize the extent of stress that a particular video decode + render combination gave to the system. Unfortunately, HWInfo doesn't play well with the A10-5800K / Radeon HD 7660D yet. In particular, GPU loading and CPU package power aren't available for AMD-based systems yet.

The tables below present the results of running our HTPC rendering benchmark samples through various decoder and renderer combinations. Entries in bold with a single star indicate that there were dropped frames as per the renderer status reports in the quiescent state, while double stars indicate that the number of dropped frames made the video unwatchable. The recorded values include the GPU loading and power consumed by the system at the wall. An important point to note here is that the system was set to optimized defaults in the BIOS (GPU at 800 MHz, DRAM at 1600 MHz and CPU cores at 3800 MHz).

madVR :

madVR was configured with the settings mentioned in the software setup page. All the video post processing options in the Catalyst Control Center were disabled except for deinterlacing and pulldown detection. In our first pass, we used a pure software decoder (avcodec / wmv9 dmo, through LAV Video Decoder) to supply madVR with the decoded frames.

madVR takes up more than 80% of the resources when processing 60 fps interlaced material. The software decode penalty is reflected in the power consumed at the wall, with the 1080i60 VC-1 stream consuming more than 130W on an average. The good news is that all the streams played without any dropped frames with the optimized default settings.

The holy grail of HTPCs, in our opinion, is to obtain hardware accelerated decode for as many formats as possible. A year or so back, it wasn't possible to use any hardware decoders with the madVR renderer. Thanks to Hendrik Leppkes's LAV Filters, we now have a DXVA2 Copy-Back (DXVA2CB) decoder which enables usage of DXVA2 acceleration with madVR. The table below presents the results using DXVA2CB and madVR.

There is a slight improvement in power consumption for the first few streams. We still have a bit of power penalty compared to pure hardware decode because the decoded frames have to get back to the system memory and then go back into the GPU for madVR to process. An unfortunate point to note here is that none of the 1080i60 / 1080p60 streams could play properly with our optimized default settings (rendering their GPU usage and power consumption values meaningless). We did boost up the memory speeds to DDR3-2133 and saw some improvements with respect to the number of dropped frames. However, we were unable to make the four streams play perfectly even with non-default settings.

EVR-CP :

For non-madVR renderers, we set Catalyst 12.8 to the default settings. The table below presents the results obtained with LAV Video Decoder set to DXVA2 Native mode. All the streams played perfectly, but the power numbers left us puzzled.

For SD streams, the power consumed is almost as much as madVR with software decode. However, the HD streams pull back the numbers a little. This is something worth investigating, but outside the scope of this article. However, we wanted to dig a bit into this, and decided to repeat the tests with the EVR renderer.

EVR :

With Catalyst 12.8 in default settings and LAV Video Decoder set to DXVA2 Native mode, all the streams played perfectly with low power consumption. All post processing steps were also visible (as enabled in the drivers)

A look at the above table indicates that hardware decode with the right renderer can make for a really power efficient HTPC. In some cases, we have more than 20 W difference depending on the renderer used, and as much as 40 W difference between software and hardware decode with additional renderer steps.