Bug 84140 - mplayer crashes playing some files using vdpau output
Summary: mplayer crashes playing some files using vdpau output
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-21 17:06 UTC by demon
Modified: 2014-10-22 09:04 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
gdb debugging log (4.23 KB, text/plain)
2014-09-21 17:06 UTC, demon
Details
vdpauinfo (2.56 KB, text/plain)
2014-09-21 17:08 UTC, demon
Details
with --enable-debug (4.40 KB, text/plain)
2014-09-22 12:07 UTC, demon
Details
Modified Arch Linux's PKGBUILD for latest mesa code (6.67 KB, text/plain)
2014-09-22 12:51 UTC, demon
Details
Debug log with symbols (5.85 KB, text/plain)
2014-09-22 14:23 UTC, demon
Details
MPlayer-vdpau-RV730-AGP-Mesa-crash.log (8.58 KB, text/plain)
2014-09-22 21:24 UTC, Dieter Nützel
Details
Possible fix (1.39 KB, patch)
2014-10-07 14:14 UTC, Christian König
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description demon 2014-09-21 17:06:47 UTC
Created attachment 106609 [details]
gdb debugging log

Driver: r600, using vdpau kernel patch.
Mesa version: commit 4eb2bbefd2bf0359aff7ebbb8e931a1c7833606f.

mplayer crashes playing »some« x264 files using vdpau. `ffmpeg -i` for those files reports:

 > Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x800 [SAR 1:1 DAR 12:5], 1769 kb/s, 23.98 fps, 23.98 tbr, 96k tbn, 47.95 tbc (default)

The same command for files which don't cause crash looks like this:

 > Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x800, 1979 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)

(the difference is this "SAR DAR" thing).

Mplayer config ($HOME/.mplayer/config) is

 > vo = vdpau
 > [vo.vdpau]
 > vc=ffh264vdpau,ffmpeg12vdpau,

Debug log attached. vdpauinfo log attached.

Note: I think I could play all x264 encoded files few days ago (same setup, older mesa drivers), so this might be a some kind of regression.
Comment 1 demon 2014-09-21 17:08:12 UTC
Created attachment 106610 [details]
vdpauinfo
Comment 2 demon 2014-09-21 17:12:32 UTC
To correct myself: kernel is 3.16.3, using uvd patch and uvd firmware.
Comment 3 Michel Dänzer 2014-09-22 06:15:16 UTC
Can you get another backtrace with debugging symbols for /usr/lib/vdpau/libvdpau_r600.so.1?

Can you bisect?
Comment 4 Christian König 2014-09-22 08:15:43 UTC
Sounds like a problem already reported by mail to me, thanks for creating a tracker for it.

Please provide a backtrace with debugging symbols by either installing the approprita packages or compiling mesa with --enable-debug.

Thanks,
Christian.
Comment 5 Christian König 2014-09-22 08:34:44 UTC
(In reply to comment #3)
> Can you bisect?

It's most likely "4dfdcdb radeon/video: use the hw to initial clear the buffers", but I can't see how that could lead to such problems.
Comment 6 demon 2014-09-22 11:16:31 UTC
Sorry for late response, notifications were sent to my old e-mail address.

First I'm gonna try a commit before 4dfdcdb, then I'll compile the latest commit with debugging. Will report back soon.
Comment 7 demon 2014-09-22 11:38:19 UTC
The commit which triggers the issue is 4dfdcdb4b394df72da769806a0b64025e475f8b3. I can't reproduce the issue with 4bc0059229f212e91ca266ef3f80b652b1cdcb86 but I can with 4dfdcdb4b394df72da769806a0b64025e475f8b3.
Comment 8 demon 2014-09-22 12:07:16 UTC
Created attachment 106673 [details]
with --enable-debug
Comment 9 Christian König 2014-09-22 12:21:07 UTC
(In reply to comment #8)
> Created attachment 106673 [details]
> with --enable-debug

This log still doesn't contains symbol informations, but the line: "r600_pipe.h:470:r600_emit_command_buffer: Assertion `cs->cdw + cb->num_dw <= (16 * 1024)' failed." is rather interesting. Looks like the is a flush missing somewhere.
Comment 10 demon 2014-09-22 12:45:11 UTC
 > This log still doesn't contains symbol informations

I'm not sure why is that, I'm using Arch Linux's PKGBUILD, modified to use latest mesa code from git. Build log clearly stated -DDEBUG flag.
Comment 11 demon 2014-09-22 12:51:16 UTC
Here's the Arch's PKGBUILD:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa

Modified PKGBUILD I use is attached. As you can see, I'm building only r600 driver, and I don't build opencl stuff (so I don't have mesa-opencl package installed which contains `gallium-pipe/pipe_r600.so`).
Comment 12 demon 2014-09-22 12:51:59 UTC
Created attachment 106676 [details]
Modified Arch Linux's PKGBUILD for latest mesa code
Comment 13 Laurent carlier 2014-09-22 13:52:38 UTC
(In reply to comment #12)
> Created attachment 106676 [details]
> Modified Arch Linux's PKGBUILD for latest mesa code

Please check pkgbuild manpage, ther is an options() array where you disable stripping:

options=('!strip' 'debug')
Comment 14 demon 2014-09-22 14:23:05 UTC
Created attachment 106682 [details]
Debug log with symbols

Sorry, I totaly forgot about that. Is it OK now?
Comment 15 Christian König 2014-09-22 15:53:36 UTC
(In reply to comment #14)
> Created attachment 106682 [details]
> Debug log with symbols
> 
> Sorry, I totaly forgot about that. Is it OK now?

Yeah, that's much better thanks a lot.

@Marek: Can you take a look? I of hand can't see what's going wrong here.
Comment 16 Marek Olšák 2014-09-22 19:26:48 UTC
Sorry, I cannot reproduce this. I forced the u_blitter path for clearing and it just works here. It was on Evergreen.
Comment 17 Dieter Nützel 2014-09-22 21:24:43 UTC
Created attachment 106695 [details]
MPlayer-vdpau-RV730-AGP-Mesa-crash.log
Comment 18 Dieter Nützel 2014-09-22 21:34:20 UTC
OK, ok, Christian here I am and thanks for the tracker. I was off over the weekend and lost my email back to Friday e.g. the one's from my providers server...8-(

Above you find my crash log with --enable-debug.
Bisected and works for me (on RV730 AGP) with

git revert 4dfdcdb

commit 4dfdcdb4b394df72da769806a0b64025e475f8b3
Author: Christian König <christian.koenig@amd.com>
Date:   Thu Sep 11 09:38:50 2014 +0200

    radeon/video: use the hw to initial clear the buffers
    
    Less CPU overhead and avoids contention over CPU accessible memory on startup.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

That's the 'email information' Christian is referencing ;-)
Comment 19 Ilia Mirkin 2014-09-22 21:38:30 UTC
(In reply to comment #17)
> Created attachment 106695 [details]
> MPlayer-vdpau-RV730-AGP-Mesa-crash.log

#1  0xb2adc40a in r600_emit_command_buffer (cs=0xa00f, cs=0xa00f, cb=0xb9dc6490, cb=0xb9dc6490)
    at r600_pipe.h:471
#2  r600_emit_cso_state (rctx=0xb9dc30f8, atom=0xb9dc35f0) at r600_state_common.c:66


This seems a little suspect -- cs == 0xa00f... that's an awfully small pointer value. Which is just rctx->b.rings.gfx.cs [sorry, don't know more, just pointing out an observation]
Comment 20 Alex Deucher 2014-09-22 21:54:05 UTC
I seem to recall adding an auxilary context for doing buffer clears on the GPU in the 3D driver, maybe this needs something similar?
Comment 21 Marek Olšák 2014-09-22 23:16:30 UTC
The context should be fully initialized to do anything no matter what the user API is, is that right, Christian?

The auxiliary context is for cases when you don't have any context around and need to submit some commands. It saves the context_create/destroy overhead but not much else. If the context created by VDPAU isn't initialized properly, the aux context can be used (if it works).
Comment 22 Dieter Nützel 2014-10-05 23:31:28 UTC
Mesa git-ca824e6
drm-next-3.18-wip

Now it is NOT crashing, but hangs.
CTRL+'c' show this:

MPlayer -4.8 (C) 2000-2014 MPlayer Team
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Loading extension-related profile 'vo.vdpau'

Playing /data/Filme/test.mkv.
libavformat version 55.48.100 (internal)
libavformat file format detected.
[lavf] stream 0: video (h264), -vid 0, OceanWorld.2D.2009.BluRay.1080p.AC3.x264-CHD
[lavf] stream 1: audio (ac3), -aid 0, -alang eng, AC3 5.1 channels, 640kbps
VIDEO:  [H264]  1920x1080  0bpp  24.000 fps    0.0 kbps ( 0.0 kbyte/s)
Clip info:
 title: 深海探奇 2D
 encoder: libebml v1.2.2 + libmatroska v1.3.0
 creation_time: 2011-10-08 18:03:44
Load subtitles in /data/Filme/
==========================================================================
Forced video codec: ffmpeg12vdpau
Forced video codec: ffwmv3vdpau
Forced video codec: ffvc1vdpau
Forced video codec: ffh264vdpau
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 55.69.100 (internal)
Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU))
==========================================================================
==========================================================================
Trying to force audio codec driver family libmad...
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
[ac3 @ 0xb751fb60]Channel layout '5.1(side)' with 6 channels does not match specified number of channels 2: ignoring specified channel layout
AUDIO: 48000 Hz, 2 ch, floatle, 640.0 kbit/20.83% (ratio: 80000->384000)
Selected audio codec: [ffac3] afm: ffmpeg (FFmpeg AC-3)
==========================================================================
AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1920x1080 => 1920x1080 H.264 VDPAU acceleration  [zoom]
radeon: Failed to allocate a buffer:
radeon:    size      : 80163840 bytes
radeon:    alignment : 4096 bytes
radeon:    domains   : 4
radeon:    flags     : 4
radeon: Failed to allocate a buffer:
radeon:    size      : 80163840 bytes
radeon:    alignment : 4096 bytes
radeon:    domains   : 4
radeon:    flags     : 4
EE radeon_uvd.c:838 ruvd_create_decoder UVD - Can't allocated dpb.
[vdpau] Failed creating VDPAU decoder: A catch-all error, used when no other error code applies.
FATAL: Cannot initialize video driver.
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1920x1080 => 1920x1080 H.264 VDPAU acceleration  [zoom]
[vdpau] Unexpected reinit, query_format called too often?
radeon: Failed to allocate a buffer:
radeon:    size      : 80163840 bytes
radeon:    alignment : 4096 bytes
radeon:    domains   : 4
radeon:    flags     : 4
radeon: Failed to allocate a buffer:
radeon:    size      : 80163840 bytes
radeon:    alignment : 4096 bytes
radeon:    domains   : 4
radeon:    flags     : 4
EE radeon_uvd.c:838 ruvd_create_decoder UVD - Can't allocated dpb.
[vdpau] Failed creating VDPAU decoder: A catch-all error, used when no other error code applies.
FATAL: Cannot initialize video driver.
Too many buffered pts

[snip]

Too many buffered pts

MPlayer interrupted by signal 2 in module: decode video
Too many buffered pts
Comment 23 Dieter Nützel 2014-10-06 01:47:15 UTC
(In reply to Dieter Nützel from comment #22)
> Mesa git-ca824e6
> drm-next-3.18-wip
> 
> Now it is NOT crashing, but hangs.
> CTRL+'c' show this:

OK, sorry, forget this one.

I've lost the NVRAM info over the weekend, maybe due to low mobo buffer battery, so I had only default 64 MB AGP aperture memory, to few for this MPlayer test.

After fixing BIOS, I'm back to crash or running vdpau with
git revert 4dfdcdb
Comment 24 Christian König 2014-10-07 14:14:57 UTC
Created attachment 107497 [details] [review]
Possible fix

(In reply to Marek Olšák from comment #21)
> The context should be fully initialized to do anything no matter what the
> user API is, is that right, Christian?

Correct, yes. The context is the same we do CC conversion with and there it works perfectly fine. We also hold a lock to make sure that the context isn't used by more than one theread at the same time.

> The auxiliary context is for cases when you don't have any context around
> and need to submit some commands. It saves the context_create/destroy
> overhead but not much else. If the context created by VDPAU isn't
> initialized properly, the aux context can be used (if it works).

Well, using the auxiliary context migth work around the problem but won't really solve it. Anyway a patch going this approach is attached, please test.
Comment 25 Marek Olšák 2014-10-07 22:56:44 UTC
Christian, you can use r600_screen_clear_buffer, which does exactly what you want.
Comment 26 Dieter Nützel 2014-10-09 01:58:48 UTC
(In reply to Christian König from comment #24)
> Created attachment 107497 [details] [review] [review]
> Possible fix

First quik test do NOT work on RV730 AGP.
Linux 3.16.3 32 bit
Mesa git-67909f2

Tomorrow I'll do some debug runs.
Comment 27 Dieter Nützel 2014-10-21 17:15:07 UTC
Fixed by this patch:

https://bugs.freedesktop.org/attachment.cgi?id=108144
[Mesa-dev] [PATCH] r600g: Drop references to destroyed blend state
Comment 28 Michel Dänzer 2014-10-22 09:04:34 UTC
Module: Mesa
Branch: master
Commit: ae879718c4086fc5905070e7f26dfa2757df0c86
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae879718c4086fc5905070e7f26dfa2757df0c86

Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Oct 21 12:40:15 2014 +0900

r600g: Drop references to destroyed blend state


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.