Mpv: Getting VK_ERROR_DEVICE_LOST upon resizing mpv's window

[guihkx]

Important Information

Provide following Information:

• mpv version: 0.33.0
• Linux Distribution and Version: Arch Linux
• Source of the mpv binary: Official repositories
• If known which version of mpv introduced the problem: I was getting this crash since v0.32.0, but searching through the issues in the mpv repository, I found a post by a developer who said the libplacebo version in the official Arch Linux repositories was too old (and it was indeed), so I waited until v0.33.0 was officially released (therefore with a newer version of libplacebo), but the issue persisted.
• Window Manager and version: mutter 3.38.2
• GPU driver and version: NVIDIA 455.45.01 (proprietary driver)
• Possible screenshot or video of visual glitches: https://www.youtube.com/watch?v=lG8X09lm6zE

Reproduction steps

First, let me say I'm not sure if I should've opened an issue here, or in the libplacebo repo, so feel free to close this if it's in the wrong place.

Anyway, I could only reproduce this when combining --profile=gpu-hq with --gpu-api=vulkan. To reproduce this, pick a random video (the download link for the one I used is at the end of this post), then run mpv in a terminal window, like this:

$ mpv --no-config --profile=gpu-hq --gpu-api=vulkan BigBuckBunny.mp4

After that, start resizing the mpv window diagonally (I couldn't reproduce it when resizing horizontally or vertically), as fast as you can: mpv will freeze (and sometimes your whole desktop will too, for a brief moment).

mpv will also spam this following message in the console:

[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] vk->QueueSubmit(cmd->queue, 1, &sinfo, cmd->fence): VK_ERROR_DEVICE_LOST
[vo/gpu/vulkan/libplacebo] Failed holding swapchain image for presentation
[vo/gpu] Failed presenting frame!

And If you have journalctl -f open (and if you have a NVIDIA GPU), this Xid error will show up:

dec 03 19:22:05 arch kernel: NVRM: Xid (PCI:0000:01:00): 31, pid=83961, Ch 00000022, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_PROP_0 faulted @ 0x1_016a1000. Fault is of type FAULT_PTE ACCESS_TYPE_WRITE

Expected behavior

mpv to not freeze and the NVIDIA driver to not throw a Xid error.

Actual behavior

mpv freezes and NVIDIA throws a Xid error.

Log file

https://gist.githubusercontent.com/guihkx/97e8437eb059868623564f18156d667b/raw/7d51f3bed46bc72661b8c1d81c30b4ff5c518427/log.txt

Sample files

http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4

[sfan5]

Can confirm the issue, there is no need to resize "as fast you can" the issue can appear on any resize kinda randomly.
Also, it's extremely likely that this is not mpv or libplacebo's fault but NVIDIA's bad drivers.

[guihkx]

there is no need to resize "as fast you can"

Indeed! Today I was watching a video with my second screen enabled, and as soon as I clicked and dragged just a little to start resizing the window, the crash happened. It just seemed easier to reproduce by resizing it quickly, though. >:)

Can you still reproduce a crash/freeze without using --profile=gpu-hq, though? What about using the OpenGL back-end? I couldn't in both cases...

[sfan5]

I use gpu-hq + OpenGL daily and I've never seen a similar thing happen with that.

[haasn]

Also, it's extremely likely that this is not mpv or libplacebo's fault but NVIDIA's bad drivers.

It's also extremely likely that mpv and/or libplacebo would benefit from having better code to recover from device loss, since that can happen for entirely legitimate reasons as well.

As far as that distinction is concerned, I'm convinced libplacebo is, essentially, doing the correct thing. It's forwarding the error to vo_gpu's draw_frame as the return value of pl_swapchain_submit_frame, which the documentation states indicates some sort of severe failure (e.g. device loss).

So in terms of an actual change that needs to be made, it's most likely on the mpv side. More specifically, mpv needs some mechanism of signalling that the entire gpu context needs to be recreated (possibly as a new VOCTRL of some sort)