https://bugs.freedesktop.org/show_bug.cgi?id=98604
Bug ID: 98604 Summary: [VDPAU, radeonsi] Fullscreen flash video fails when hardware acceleration is enabled. Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: rankincj@googlemail.com QA Contact: dri-devel@lists.freedesktop.org
Hardware: R7 360, Linux x86_64 Screen: 1680x1050
To reproduce this bug, play the "Weather" video at http://www.bbc.co.uk/weather using Firefox and Adobe's flash-plugin-11.2.202.643-release.x86_64. Ensure that "Hardware acceleration" is enabled, and then enter "Full screen" mode.
On my PC, this results in a black screen with a small, blank rectangle in the top left corner. And then the flash plugin will crash a few minutes later.
This does not happen with either i965 (Broadwell) or r600 (HD6450) hardware. Nor does it happen with Chromium and chromium-pepper-flash-23.0.0.162-1.fc24.x86_64 with my R7 360, although chromium-pepper-flash doesn't appear to use libvdpau_radeonsi.so either.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
Chris Rankin rankincj@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS|All |Linux (All) Hardware|Other |x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #1 from Chris Rankin rankincj@googlemail.com --- I think this bug is related to DRI3, because this change "fixes" the problem:
diff --git a/src/gallium/state_trackers/vdpau/device.c b/src/gallium/state_trackers/vdpau/device.c index 81b7582..cd5afe2 100644 --- a/src/gallium/state_trackers/vdpau/device.c +++ b/src/gallium/state_trackers/vdpau/device.c @@ -64,7 +64,7 @@ vdp_imp_device_create_x11(Display *display, int screen, VdpDevice *device, pipe_reference_init(&dev->reference, 1);
#if defined(HAVE_DRI3) - dev->vscreen = vl_dri3_screen_create(display, screen); + //dev->vscreen = vl_dri3_screen_create(display, screen); #endif if (!dev->vscreen) dev->vscreen = vl_dri2_screen_create(display, screen);
https://bugs.freedesktop.org/show_bug.cgi?id=98604
Chris Rankin rankincj@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[VDPAU, radeonsi] |[VDPAU, DRI3] Fullscreen |Fullscreen flash video |flash video fails when |fails when hardware |hardware acceleration is |acceleration is enabled. |enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #2 from Chris Rankin rankincj@googlemail.com --- Broadwells work OK with DRI3, but I have now reproduced this problem with both radeonsi and r600g.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #3 from smoki smoki00790@gmail.com ---
Reproducable on Kabini APU too. DRI3 issue yes, it works only in DRI2 session, but LIBGL_DRI3_DISABLE=1 does not help in this case.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #4 from smoki smoki00790@gmail.com ---
But yeah newer does not have VDPAU support, neither this 24 beta it seems:
http://labs.adobe.com/downloads/flashplayer.html
In couple months 11.2.x seems will cease to be supported anymore, so this might be time fixable... well in case they did not decide to enable VDPAU again :)
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #5 from Chris Rankin rankincj@googlemail.com --- (In reply to smoki from comment #4)
In couple months 11.2.x seems will cease to be supported anymore, so this might be time fixable... well in case they did not decide to enable VDPAU again :)
I don't see your point here. AFAIK the Flash plugin knows nothing about either DRI2 or DRI3, and it works fine with DRI2. So why shouldn't it work with DRI3 too? Especially since Broadwell + DRI3 is unaffected.
To my mind, the Flash plugin has probably revealed a bug in Gallium's DRI3 layer. In which case, hoping that Adobe will "shoot the messenger" soon is just silly.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #6 from smoki smoki00790@gmail.com ---
That was pure information :), as i tried to reproduce it with that old affected one and newest which does not have an issue since it does not have decode... so no offense, bug is there.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #7 from Dieter Nützel Dieter@nuetzel-hh.de --- (In reply to Chris Rankin from comment #1)
I think this bug is related to DRI3, because this change "fixes" the problem:
diff --git a/src/gallium/state_trackers/vdpau/device.c b/src/gallium/state_trackers/vdpau/device.c index 81b7582..cd5afe2 100644 --- a/src/gallium/state_trackers/vdpau/device.c +++ b/src/gallium/state_trackers/vdpau/device.c @@ -64,7 +64,7 @@ vdp_imp_device_create_x11(Display *display, int screen, VdpDevice *device, pipe_reference_init(&dev->reference, 1);
#if defined(HAVE_DRI3)
- dev->vscreen = vl_dri3_screen_create(display, screen);
- //dev->vscreen = vl_dri3_screen_create(display, screen);
#endif if (!dev->vscreen) dev->vscreen = vl_dri2_screen_create(display, screen);
This works on r600g - NI/Turks XT with Firefox 49.0.2 and Konqueror 4.14.8 (KDE 4.14.9) plus flash-player-11.2.202.643-2.115.1.x86_64, too.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #8 from smoki smoki00790@gmail.com --- (In reply to Chris Rankin from comment #5)
I don't see your point here. AFAIK the Flash plugin knows nothing about either DRI2 or DRI3, and it works fine with DRI2...
Does this still work for you with DRI2? Asking becuase DRI2 seems now affected also.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #9 from Chris Rankin rankincj@googlemail.com --- (In reply to smoki from comment #8)
Does this still work for you with DRI2? Asking becuase DRI2 seems now affected also.
I can't say, because Adobe has now "upgraded" its Flash plugin to v24 and removed the hardware-accelerated v11 plugin from the Yum repository :-|
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #10 from smoki smoki00790@gmail.com --- (In reply to Chris Rankin from comment #9)
(In reply to smoki from comment #8)
Does this still work for you with DRI2? Asking becuase DRI2 seems now affected also.
I can't say, because Adobe has now "upgraded" its Flash plugin to v24 and removed the hardware-accelerated v11 plugin from the Yum repository :-|
Yeah it is not have decode accel anymore, but issue is still there... it actually does not need to be VDPAU used just that hardware accel enabled.
Asking as i just tried it now and now happens with DRI2 too, basically flash whatever default with our driver crashing browser... one just need to wait enough :D
Interesting is that it works fine with AMD proprietary driver, so it is our bug likely... mesa probably.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #11 from Michel Dänzer michel@daenzer.net --- Can you get a backtrace of a crash with gdb?
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #12 from Dieter Nützel Dieter@nuetzel-hh.de --- (In reply to Michel Dänzer from comment #11)
Can you get a backtrace of a crash with gdb?
Hello Michel,
no backtrace of a crash, but I could attach gdb on running konqueror process. BBC weather side need JAVA. Hope this help, too.
/opt/mesa> konqueror & [2] 10181 /opt/mesa> Vector smash protection is enabled. openjdk version "1.8.0_111" OpenJDK Runtime Environment (IcedTea 3.2.0) (suse-33.1-x86_64) OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode) konqueror(10181)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data!; job URL = KUrl("http://s.update.rubiconproject.com/2/873648/analytics.js?si=52926&di=www...") data size = 0 konqueror(10181)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data!; job URL = KUrl("http://ps.eyeota.net/match/bounce/?bid=i0r4o4v&uid=LAuIY6Hs") data size = 0
(gdb) bt full #0 0x00007faaa40fe2bd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007faa9f4a5402 in _xcb_conn_wait () at /usr/lib64/libxcb.so.1 #2 0x00007faa9f4a7209 in xcb_wait_for_special_event () at /usr/lib64/libxcb.so.1 #3 0x00007fa9e961e4a6 in dri3_wait_present_events (scrn=scrn@entry=0x2e2f090) at vl/vl_winsys_dri3.c:183 ev = <optimized out> #4 0x00007fa9e961f3bc in vl_dri3_screen_texture_from_drawable (vscreen=0x2e2f090, drawable=<optimized out>) at vl/vl_winsys_dri3.c:558 scrn = 0x2e2f090 buffer = <optimized out> #5 0x00007fa9e961b119 in vlVdpPresentationQueueDisplay (presentation_queue=<optimized out>, surface=5, clip_width=0, clip_height=0, earliest_presentation_time=0) at presentation.c:234 dump_window = 0 pq = 0x2f0ab60 surf = 0x4198340 pipe = 0x2ef3fe0 tex = <optimized out> surf_templ = {reference = {count = 0}, texture = 0x400000000, context = 0x100000000, format = PIPE_FORMAT_NONE, width = 0, height = 0, writable = 0, u = {tex = {level = 3, first_layer = 0, last_layer = 0}, buf = {first_element = 3, last_element = 0}}} surf_draw = <optimized out> src_rect = {x0 = 1, x1 = 16809983, y0 = 68781024, y1 = 0} dst_clip = {x0 = 68780956, x1 = 0, y0 = 68780992, y1 = 0} dirty_area = <optimized out> compositor = 0x2e2ef48 cstate = 0x2f0ab70 vscreen = 0x2e2f090 #6 0x00007faa2efc37f3 in () at /usr/lib64/browser-plugins/libflashplayer.so #7 0x00007faa2ed522e9 in () at /usr/lib64/browser-plugins/libflashplayer.so #8 0x00007faa2ed524ed in () at /usr/lib64/browser-plugins/libflashplayer.so #9 0x00007faa2ed4fc5c in () at /usr/lib64/browser-plugins/libflashplayer.so #10 0x00007faa2eca69a9 in () at /usr/lib64/browser-plugins/libflashplayer.so #11 0x00007faa2ec2c390 in () at /usr/lib64/browser-plugins/libflashplayer.so #12 0x00007faa2f1c472f in () at /usr/lib64/browser-plugins/libflashplayer.so #13 0x00007faa2f1c57ec in () at /usr/lib64/browser-plugins/libflashplayer.so #14 0x00007faa2f12b191 in () at /usr/lib64/browser-plugins/libflashplayer.so #15 0x000015aebcff63f6 in () #16 0x00000dd1873ddb78 in () #17 0x00000dd1873ddae0 in () #18 0x00001be706c23128 in () #19 0x00001be706c23061 in () #20 0x0000000000000000 in ()
(gdb) info registers all rax 0xfffffffffffffdfc -516 rbx 0x2f00bb0 49286064 rcx 0x7faaa40fe2bd 140370873672381 rdx 0xffffffff 4294967295 rsi 0x1 1 rdi 0x7fffb0fac080 140736162611328 rbp 0x29b7e60 0x29b7e60 rsp 0x7fffb0fac070 0x7fffb0fac070 r8 0x0 0 r9 0x94 148 r10 0x0 0 r11 0x293 659 r12 0x29b7e78 43744888 r13 0x0 0 r14 0x0 0 r15 0x7fffb0fac080 140736162611328 rip 0x7faaa40fe2bd 0x7faaa40fe2bd <poll+45> eflags 0x293 [ CF AF SF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 st0 -nan(0x0fe2b2b2b) (raw 0xffff00000000fe2b2b2b) st1 -nan(0x2c002b002b002b) (raw 0xffff002c002b002b002b) st2 -nan(0xd300d300d300d30) (raw 0xffff0d300d300d300d30) st3 -inf (raw 0xffff0000000000000000) st4 -nan(0x10000ff00ff00ff0) (raw 0xffff10000ff00ff00ff0) st5 -inf (raw 0xffff0000000000000000) st6 0 (raw 0x00000000000000000000) st7 0 (raw 0x00000000000000000000) fctrl 0x37f 895 fstat 0x20 32 ftag 0xffff 65535 fiseg 0x7faa 32682 fioff 0x29bf75ed 700413421 foseg 0x7fff 32767 fooff 0xb0fabb38 -1325745352 fop 0x55c 1372 xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x18, 0x0, 0x1, 0x0, 0x3, 0x43, 0xed, 0x8, 0x48, 0x76, 0x64, 0x2, 0xb1, 0x4, 0x0, 0x0}, v8_int16 = {0x18, 0x1, 0x4303, 0x8ed, 0x7648, 0x264, 0x4b1, 0x0}, v4_int32 = {0x10018, 0x8ed4303, 0x2647648, 0x4b1}, v2_int64 = {0x8ed430300010018, 0x4b102647648}, uint128 = 0x000004b10264764808ed430300010018} xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x77, 0x0, 0xe0, 0x5, 0x0, 0x0, 0x0, 0x0, 0xf6, 0x1, 0xc4, 0x2, 0xf6, 0x1, 0xc4, 0x2}, v8_int16 = {0x77, 0x5e0, 0x0, 0x0, 0x1f6, 0x2c4, 0x1f6, 0x2c4}, v4_int32 = {0x5e00077, 0x0, 0x2c401f6, 0x2c401f6}, v2_int64 = {0x5e00077, 0x2c401f602c401f6}, uint128 = 0x02c401f602c401f60000000005e00077} xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x10, 0x0, 0x1, 0x0, 0x1c, 0x0, 0xed, 0x8, 0xb1, 0x4, 0x0, 0x0, 0x72, 0x0, 0x0, 0x0}, v8_int16 = {0x10, 0x1, 0x1c, 0x8ed, 0x4b1, 0x0, 0x72, 0x0}, v4_int32 = {0x10010, 0x8ed001c, 0x4b1, 0x72}, v2_int64 = {0x8ed001c00010010, 0x72000004b1}, uint128 = 0x00000072000004b108ed001c00010010} xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm7 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm8 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm9 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm10 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm11 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm12 {v4_float = {0x1, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x0, 0x80, 0x3f, 0x0 <repeats 12 times>}, v8_int16 = {0x0, 0x3f80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x3f800000, 0x0, 0x0, 0x0}, v2_int64 = {0x3f800000, 0x0}, uint128 = 0x0000000000000000000000003f800000} xmm13 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm14 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm15 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} mxcsr 0x1fa7 [ IE DE ZE PE IM DM ZM OM UM PM ]
After this I have SysRq running KDE desktop: [40631.027856] sysrq: SysRq : SAK [40631.027895] tty tty7: SAK: killed process 24471 (Xorg): by session [40631.028084] tty tty7: SAK: killed process 24471 (Xorg): by controlling tty [40631.028088] tty tty7: SAK: killed process 24472 (radeon_cs:0): by controlling tty [40631.028090] tty tty7: SAK: killed process 24475 (InputThread): by controlling tty
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #13 from Dieter Nützel Dieter@nuetzel-hh.de --- Still there.
But patch works, even with latest DRI3 updates.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #14 from Dieter Nützel Dieter@nuetzel-hh.de --- Any progress? Michel?
DRI2 vs DRI3
Wouldn't it be nice to have this in 7.1?
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #15 from Dieter Nützel Dieter@nuetzel-hh.de --- Michel and Christian,
can we have this patch in 17.1 (final)? I have to apply it by hand on every build.
Any further logs/debug needed?
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #16 from Michel Dänzer michel@daenzer.net --- The patch just disables DRI3 for VDPAU, so it cannot be applied anywhere as is. It would have to be guarded by an environment variable.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #17 from Chris Rankin rankincj@googlemail.com --- (In reply to Michel Dänzer from comment #16)
The patch just disables DRI3 for VDPAU, so it cannot be applied anywhere as is. It would have to be guarded by an environment variable.
I only intended that patch as a "proof of concept" anyway, i.e. that the problem really was being caused by DRI3. I'd be mortified if it were actually *applied* to Mesa, even if it were "guarded by an environment variable".
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #18 from joeri.exelmans@gmail.com --- Created attachment 131644 --> https://bugs.freedesktop.org/attachment.cgi?id=131644&action=edit vdpauinfo
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #19 from joeri.exelmans@gmail.com --- Sorry, ignore the 'vdpau' attachment I just uploaded, this belongs to another bug (wrong browser tab!)
https://bugs.freedesktop.org/show_bug.cgi?id=98604
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED
--- Comment #20 from GitLab Migration User gitlab-migration@fdo.invalid --- -- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1239.
dri-devel@lists.freedesktop.org