Video Playback CPU Utilisation
With the HQV tests displaying a leap in detecting the various method employed by the source video when it was encoded, and being able to better cope with those scenarios the natural assumption may be that there's some CPU analysis and detection occurring here and there may be a leap in CPU utilisation for these later, higher playback quality drivers. We'll put this to the test by looking at the CPU utilisation over a 1m 40s clip of the HQV Cadence tests video (which has multiple cadence switching occurring), the "Subway Showdown" scene from the Matrix (representing a fairly early, NTSC, film to DVD transfer) and the "Battle Over Coruscant" scene from Star Wars III: Revenge of the Sith (representing a later, PAL, digital film to DVD transfer).

X1600 XT - % CPU Utilisation | Min | Max | Avg | |
HQV - Cadence Test | Catalyst 5.9 | 6.25 | 14.06 | 9.49 |
Catalyst 6.2 | 0.00 | 10.94 | 4.51 | |
The Matrix | Catalyst 5.9 | 0.00 | 17.19 | 8.28 |
Catalyst 6.2 | 0.00 | 10.94 | 4.05 | |
Star Wars III | Catalyst 5.9 | 6.25 | 15.63 | 10.45 |
Catalyst 6.2 | 0.00 | 9.38 | 4.77 |
The testing shows that rather than the CPU utilisation increasing with the newer drivers it has actually decreased - the newer drivers are giving a higher quality of output over a wider range of cases and at the same time the CPU utilisation is decreasing. In fact, in these cases here, with the newer drivers the average CPU load dropped to half the amount of the older drivers. The couple of standard DVD film scenarios was to check that this particular phenomena wasn't related specifically to the HQV benchmark tests.
With the Avivo video decoding engine ATI have taken many silicon blocks from their Xilleon DTV side of the business, which demands consumer level video decode quality, and either applied them directly to the X100's fixed function video hardware or re-written them as software to run over the graphics hardware's shaders. With the knowledge already in-house, ATI have applied this fairly quickly to the X1000 series, which is why they have been able to get such quality increases with their video decoding hardware.
What we see on the CPU utilisation is the video decoding hardware actually being utilised more effectively, and more to its actual capabilities. It's not, in fact, doing any analysis of the frames via the CPU to detect which interlacing method should best be used, or which cadencies are in place, nor is it looking for flags in the content (these are not entirely reliable in actually being present all the time), rather the hardware is doing the analysis and picking the the best method to use. For this reason, where there is a change in cadence there will actually be a small lag between the change and the actually applying the correct cadence detection in the hardware since the hardware actually has to analyse multiple frames to detect the correct pattern, before it can lock on.