|Summary:||mplayer crashes playing some files using vdpau output|
|Component:||Drivers/Gallium/r600||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED FIXED||QA Contact:|
|Priority:||medium||CC:||ckoenig.leichtzumerken, demon, maraeo, yashax|
|i915 platform:||i915 features:|
gdb debugging log
Modified Arch Linux's PKGBUILD for latest mesa code
Debug log with symbols
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 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 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 <email@example.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 <firstname.lastname@example.org> Reviewed-by: Michel Dänzer <email@example.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 <firstname.lastname@example.org> Date: Tue Oct 21 12:40:15 2014 +0900 r600g: Drop references to destroyed blend state