Trying to debug some weird VDPAU issue

[rvdboom]

I'm running several AMD-based systems, including two with Kabini E-350 chips and one with a Kaveri A10-7700 one.
All runs a Slackware64 system, with custom built 3.16.3 kernel and libdrm, glamor, mesa and xf86-video-ati built from git pulls, dated on the 20th of september, with exact same options.
Libvdpau 0.8 is installed on all systems, compiled with the same options. vdpauinfo 0.1 is also installed, as well as x264, ffmpeg and vlc, all compiled from git pulls, dated from the same 20th of september, with the same options on all platforms.
The only differing options during compiles is that I use "-march=bdver3 -mtune=bdver3" on Kaveri while I use "-march=btver1 -mtune=btver1" on Kabini.

On Kaveri, vdpauinfo shows the following (only the begining):

**********
bash-4.3$ vdpauinfo -h
display: :0 screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name width height types
-------------------------------------------
420 16384 16384 NV12 YV12
422 16384 16384 UYVY YUYV
444 16384 16384 Y8U8V8A8 V8U8Y8A8

Decoder capabilities:

name level macbs width height
-------------------------------------------
MPEG1 0 9216 2048 1152
MPEG2_SIMPLE 3 9216 2048 1152
MPEG2_MAIN 3 9216 2048 1152
H264_BASELINE 41 9216 2048 1152
H264_MAIN 41 9216 2048 1152
H264_HIGH 41 9216 2048 1152
VC1_ADVANCED 4 9216 2048 1152
MPEG4_PART2_SP 3 9216 2048 1152
MPEG4_PART2_ASP 5 9216 2048 1152

(snip)
******************

On Kabini, I have the following output :

******************

bash-4.3$ vdpauinfo
display: :0 screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name width height types
-------------------------------------------
420 16384 16384 NV12 YV12
422 16384 16384 UYVY YUYV
444 16384 16384 Y8U8V8A8 V8U8Y8A8

Decoder capabilities:

name level macbs width height
-------------------------------------------
MPEG1 0 9216 2048 1152
MPEG2_SIMPLE 3 9216 2048 1152
MPEG2_MAIN 3 9216 2048 1152
H264_BASELINE 41 9216 2048 1152
H264_MAIN 41 9216 2048 1152
H264_HIGH 41 9216 2048 1152
VC1_ADVANCED 4 9216 2048 1152
MPEG4_PART2_SP 3 9216 2048 1152
MPEG4_PART2_ASP 5 9216 2048 1152

*****************

So far so good, the capabilities of both systems seem to be identical.

I have several H264 HD1080p videos with High Main profiles, and 41 levels.
They properly play on Kabini using VLC with VDPAU. The CPU usage is low for a HD file and the VLC logs show the usage of hardware decoding.
On Kaveri, this does not work. CPU usage is high and no hardware decoding seems to be used.

I tend to believe that this is a driver issue, since everything is compiled in much the same way, except for CPU optimizations, on both platforms.
But I don't know exactly where to start to find a clue.
Looking at the VLC logs, there's a subtle difference when opening the same file on the same network location between the two systems :

On Kabini, the avcodec codec is detected as such :

****************
[00007f5970d42768] avcodec decoder debug: CPU flags: 0x010010db
[00007f5970d42768] avcodec decoder debug: trying to use direct rendering
[00007f5970d42768] avcodec decoder debug: allowing 3 thread(s) for decoding
[00007f5970d42768] avcodec decoder debug: avcodec codec (H264 - MPEG-4 AVC (part 10)) started
[00007f5970d42768] avcodec decoder debug: using frame thread mode with 3 threads
[00007f5970d42768] core decoder debug: using decoder module "avcodec"
****************

while on Kaveri, it is as such :

****************
[00007fbb48d43d58] avcodec decoder debug: CPU flags: 0x01035fdb
[00007fbb48d43d58] avcodec decoder debug: trying to use direct rendering
[00007fbb48d43d58] avcodec decoder debug: allowing 4 thread(s) for decoding
[00007fbb48d43d58] avcodec decoder debug: codec (h264) started
[00007fbb48d43d58] avcodec decoder debug: using frame thread mode with 4 threads
[00007fbb48d43d58] core decoder debug: using decoder module "avcodec"
*****************

The codec string is different ("H264 - MPEG-4 AVC (part 10)" compared to "h264").
Why would that be?

[Rémi Denis-Courmont]

For the last question, that's because you have a different version of VLC on each system.

[rvdboom]

Indeed, the string is the same now that the git repository on the working system has been properly updated. It still works though, which is good news to me.

There's another difference I can't explain between the two logs, though :

On the working Kabini system, I get the following log :

********************
[00007f795cd42768] avcodec decoder debug: available hardware decoder output format 109 (vdpau)
[00007f795cd42768] avcodec decoder debug: available software decoder output format 0 (yuv420p)
[00007f7948044cd8] core generic debug: looking for hw decoder module matching "any": 1 candidates
********************

On the Kaveri system, I get the following at the same place:

********************
[00007ffb3cd43d58] avcodec decoder debug: available hardware decoder output format 109 (vdpau)
[00007ffb3cd43d58] avcodec decoder debug: available software decoder output format 0 (yuv420p)
[00007ffb34044cd8] core generic debug: looking for hw decoder module matching "none": 1 candidates
[00007ffb34044cd8] core generic debug: no hw decoder modules matched
********************

Why is it matching "any" on Kabini and "none" on Kaveri?
Did I misconfigure anything somewhere?
In the Preferences, Video output is definitely set to Automatic, so I don't think the culprit is there.

[Rémi Denis-Courmont]

On Kabini, you have the default VLC settings. On Kaveri, you changed the VLC settings.

[rvdboom]

I feel like a total jerk : reverting to default settings indeed solved the issue.
What I don't understand is what type of settings could have impaired the hardware decoding?