Created attachment 117060 [details]
my diff against agd5f/mesa

Created attachment 117336 [details] [review]
Possible fix

This should fix the issue.

(In reply to Christian König from comment #2)
> Created attachment 117336 [details] [review] [review]
> Possible fix
> 
> This should fix the issue.

Sort of - kodi seems OK with it but mpv is strange.

With mpv if I test something small/low bitrate there's a fair chance it fails with -

[vo/opengl] after rendering: OpenGL error INVALID_OPERATION

It seems that I can make it work reliably by setting my cpus to perf with cpufreq.

I wonder if there is some timing/threading issue here - on my phenom II x4 cpufreq is quite extreme in that low is 800MHz next is 2.2 GHz.

I will soon be filing another UVD issue I found - but after messing around with it quite extensively I now need to put cpufreq into the testing and do it again!

(In reply to Andy Furniss from comment #3)
> It seems that I can make it work reliably by setting my cpus to perf with
> cpufreq.

Sounds like some kind of race condition to me, e.g. something isn't properly protected and multi thread save.

That's probably pretty hard to find.

(In reply to Christian König from comment #4)
> (In reply to Andy Furniss from comment #3)
> > It seems that I can make it work reliably by setting my cpus to perf with
> > cpufreq.
> 
> Sounds like some kind of race condition to me, e.g. something isn't properly
> protected and multi thread save.
> 
> That's probably pretty hard to find.

Turns out I can also provoke this with kodi if I try enough, and cpufreq perf doesn't always help mpv (but usually does).

(In reply to Andy Furniss from comment #5)
> (In reply to Christian König from comment #4)
> > (In reply to Andy Furniss from comment #3)
> > > It seems that I can make it work reliably by setting my cpus to perf with
> > > cpufreq.
> > 
> > Sounds like some kind of race condition to me, e.g. something isn't properly
> > protected and multi thread save.
> > 
> > That's probably pretty hard to find.
> 
> Turns out I can also provoke this with kodi if I try enough, and cpufreq
> perf doesn't always help mpv (but usually does).

Please try the following: Start mpv with gdb, set a break point on _mesa_error and get me a backtrace where this error message is coming from.

Going to be on IRC for the next hour or so for questions.

Here's bt after hitting breakpoint -

Breakpoint 1, _mesa_error (ctx=0x7fffe45b73c0, error=3829288608, fmtString=0x7fffe43e51d0 " O>\344\377\177") at main/errors.c:1451
1451    {
(gdb) bt
#0  _mesa_error (ctx=0x7fffe45b73c0, error=3829288608, fmtString=0x7fffe43e51d0 " O>\344\377\177") at main/errors.c:1451
#1  0x00000000005191bf in destroy_objects (hw=hw@entry=0x7fffe43e4ea0) at ../video/out/gl_hwdec_vdpau.c:81
#2  0x000000000051925f in reinit (hw=0x7fffe43e4ea0, params=0x7fffe43a4de8) at ../video/out/gl_hwdec_vdpau.c:135
#3  0x0000000000523d7a in init_video (p=0x7fffe43a4bd0) at ../video/out/gl_video.c:701
#4  gl_video_config (p=0x7fffe43a4bd0, params=params@entry=0x7fffe4302f60) at ../video/out/gl_video.c:2728
#5  0x0000000000529809 in reconfig (vo=<optimized out>, params=0x7fffe4302f60, flags=<optimized out>) at ../video/out/vo_opengl.c:204
#6  0x0000000000525303 in run_reconfig (p=<optimized out>) at ../video/out/vo.c:367
#7  0x00000000004b686f in mp_dispatch_queue_process (queue=0x1c936a0, timeout=timeout@entry=0) at ../misc/dispatch.c:197
#8  0x0000000000525ffd in vo_thread (ptr=0x1c93460) at ../video/out/vo.c:793
#9  0x00007ffff79b3d7a in start_thread (arg=0x7fffdffff700) at pthread_create.c:308
#10 0x00007ffff20d9a9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Created attachment 117361 [details]
dmesg with ring 9 stall

Further to IRC chat with current agd5f libdrm and mesa I can easily with cpufreq set to perf get a ring 9 stall with a small number of player starts.

(In reply to Andy Furniss from comment #8)
> Created attachment 117361 [details]
> dmesg with ring 9 stall
> 
> Further to IRC chat with current agd5f libdrm and mesa I can easily with
> cpufreq set to perf get a ring 9 stall with a small number of player starts.

Should add this is really nothing to do with interop per say as I was using vdpau for vo.

I tried reproducing these with agd5f drm/mesa amd-staging and I can reproduce but I have to try a lot harder, were I not using scripts I would probably call working.

The vdpau interop fail took about 30 tries with mpv.

After about 60 runs of mpv --vo=vdpau with cpufreq both on_demand and perf I failed to get a ring 9 lock.

With mplayer I did about 60 with cpufreq perf without a lock, but did get one after about 50 starts with cpufreq on_demand.

On amdgpu branches I can lock with both in < 10 starts sometimes as low as 3.

Historically I've had uvd issues that I can provoke with mplayer but not mpv - looking at vdpau traces, I see that mplayer at start up, twice creates and instantly destroys a decoder with w/h 48 before creating one with the correct w/h (which depending on content it may then destroy if it needs more ref frames).

mpv just does one create and uses it, perhaps this is why mplayer can trigger some issues better.

vdpau interop is working for me now with the patch in this bug which is in mesa now + a fix in libdrm which makes it reliable.

5c42b5e drm: fix the usage after free

http://cgit.freedesktop.org/mesa/drm/commit/?id=5c42b5e36a4a02e579ec5dcdc3a95ce58538224c

Other uvd issues mentioned may or may not still exist, but should have their own bug.

Great, thanks for all the help.