| Bug ID | 91308 |
|---|---|
| Summary | Tonga UVD not working with GL_NV_vdpau_interop |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | adf.lists@gmail.com |
UVD seems OK generally on Tonga (barring apparently being in low power) but not with GL_NV_vdpau_interop. Tested with kodi and mpv. kodi says - ERROR: VDPAU::COutput error mapping surface DEBUG: CLinuxRendererGL::GetPlaneTextureSize - invalid size 0x0 - 0 mpv - [vo/opengl] after rendering: OpenGL error INVALID_OPERATION. glxinfo shows GL_NV_vdpau_interop present. mesa is of course agd5f, with some llvm build fixes plus a minor modification I made to advertise level 52 (as ffmpeg cli at least does check). I'll attach my diff against agd5f mesa just in case I obviously messed up!
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=C3=B6nig from comment #2) > Created attachment 11= 7336 [details] [review] [review] > Possible fix >=20 > 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 fai= ls 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 set= ting 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=C3=B6nig 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 p= erf with > > cpufreq. >=20 > Sounds like some kind of race condition to me, e.g. something isn't pr= operly > protected and multi thread save. >=20 > That's probably pretty hard to find. Turns out I can also provoke this with kodi if I try enough, and cpufreq pe= rf doesn't always help mpv (but usually does).
(In reply to Andy Furniss from comment #5) > (In reply to Christian K=C3=B6nig 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. > >=20 > > Sounds like some kind of race condition to me, e.g. something isn= 't properly > > protected and multi thread save. > >=20 > > That's probably pretty hard to find. >=20 > Turns out I can also provoke this with kodi if I try enough, and cpufr= eq > perf doesn't always help mpv (but usually does). Please try the following: Start mpv with gdb, set a break point on _mesa_er= ror 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.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
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.
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | CLOSED |