Bug 98604

Summary: [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.
Product: Mesa Reporter: Chris Rankin <rankincj>
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium CC: ckoenig.leichtzumerken, fdsfgs, mesa-dev
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: vdpauinfo

Description Chris Rankin 2016-11-05 21:03:21 UTC
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.
Comment 1 Chris Rankin 2016-11-05 23:08:53 UTC
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);
Comment 2 Chris Rankin 2016-11-06 17:27:35 UTC
Broadwells work OK with DRI3, but I have now reproduced this problem with both radeonsi and r600g.
Comment 3 smoki 2016-11-06 20:01:29 UTC
 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.
Comment 4 smoki 2016-11-06 20:15:50 UTC
 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 :)
Comment 5 Chris Rankin 2016-11-06 20:26:16 UTC
(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.
Comment 6 smoki 2016-11-06 21:48:44 UTC
 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.
Comment 7 Dieter Nützel 2016-11-07 04:09:04 UTC
(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.
Comment 8 smoki 2017-01-03 22:47:30 UTC
(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.
Comment 9 Chris Rankin 2017-01-03 22:54:22 UTC
(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 :-|
Comment 10 smoki 2017-01-03 23:04:24 UTC
(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.
Comment 11 Michel Dänzer 2017-01-05 01:13:52 UTC
Can you get a backtrace of a crash with gdb?
Comment 12 Dieter Nützel 2017-01-13 04:44:15 UTC
(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.bbc.com&ap=&ti=6cada3a9-2f5f-48b1-861f-31fc282cc43f&dt=8736481428691810142000") 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
Comment 13 Dieter Nützel 2017-01-18 07:58:56 UTC
Still there.

But patch works, even with latest DRI3 updates.
Comment 14 Dieter Nützel 2017-03-20 12:02:19 UTC
Any progress?
Michel?

DRI2 vs DRI3

Wouldn't it be nice to have this in 7.1?
Comment 15 Dieter Nützel 2017-04-13 15:49:25 UTC
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?
Comment 16 Michel Dänzer 2017-04-14 01:30:32 UTC
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.
Comment 17 Chris Rankin 2017-04-14 07:33:28 UTC
(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".
Comment 18 joeri.exelmans 2017-06-01 15:55:18 UTC
Created attachment 131644 [details]
vdpauinfo
Comment 19 joeri.exelmans 2017-06-01 15:58:33 UTC
Sorry, ignore the 'vdpau' attachment I just uploaded, this belongs to another bug (wrong browser tab!)
Comment 20 GitLab Migration User 2019-09-25 17:55:16 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.