`--hwdec=auto --gpu-context=wayland` keeps my dGPU awake.

morialo3 commented 3 weeks ago

mpv Information

mpv v0.39.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Sep 23 2024 17:46:22
libplacebo version: v7.349.0
FFmpeg version: n7.0.2
FFmpeg library versions:
   libavcodec      61.3.100
   libavdevice     61.1.100
   libavfilter     10.1.100
   libavformat     61.1.100
   libavutil       59.8.100
   libswresample   5.1.100
   libswscale      8.1.100

Other Information

- Linux version: "Arch Linux"
- Kernel Version: Linux Korialo-Arch 6.11.5-274-tkg-eevdf #1 SMP PREEMPT_DYNAMIC TKG Wed, 30 Oct 2024 21:58:24 +0000 x86_64 GNU/Linux
- GPU Model: 00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-H GT2 [UHD Graphics] [8086:9bc4] (rev 05)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104M [GeForce RTX 3080 Mobile / Max-Q 8GB/16GB] [10de:249c] (rev a1)
- Mesa/GPU Driver Version: OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.2.6-arch1.1
- Window Manager and Version: Hyprland, built from branch  at commit 4520b30d498daca8079365bdb909a8dea38e8d55  (version: bump to 0.44.1).
- Source mpv: pacman
- Introduced in version: na

Reproduction Steps

Just run:

  ~                                                                                                                                                                            took  23s at  20:40:04
❯ mpv --no-config --vo=gpu-next --hwdec=auto --gpu-context=wayland filename.mkv

in my case vaapi was shown as the decoder. But when I check the dGPU status through:

  ~                                                                                                                                                                            took  20s at  20:48:34
❯ watch cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time

the counter stops indicating that my dGPU is currently running. Now if I directly switch to --hwdec=vaapi, and ran the above command the dGPU is suspended.

Expected Behavior

If --hwdec=auto and vaapi is the decoding method, you expect the iGPU to be utilized, and dGPU is free to suspend/sleep.

Actual Behavior

Actually I don't fully understand how --hwdec=auto works, so I don't know if this an expected behavior or not, but the dGPU should not be running if not used.

Log File

output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

[X] I tested with the latest mpv version to validate that the issue is not already fixed.
[X] I provided all required information including system and mpv version.
[X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
[X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
[X] I attached the full, untruncated log file.
[X] I attached the backtrace in the case of a crash.

morialo3 commented 2 weeks ago

Closing. No response so I'll assume it ffmpeg issue.

kasper93 commented 2 weeks ago

I doubt it is ffmpeg issue. It is probably that we create hwcontext during hwdec probe and they are not removed and this for some reason keeps dGPU alive.

Could you try --hwdec=vaapi and --vaapi-device= if this behaves better?

llyyr commented 2 weeks ago

--vaapi-device=

this option only has any effect if you use vaapi-copy.

cuda is proved before vaapi, can you see if your issue reproduces with hwdec=cuda,vaapi?

morialo3 commented 2 weeks ago

cuda is proved before vaapi, can you see if your issue reproduces with hwdec=cuda,vaapi?

The issue doesn't occur with those settings, here some logs, and video evidence:

https://github.com/user-attachments/assets/6a804521-99b6-4286-9701-eb369aa1bed7

output-cuda.txt

morialo3 commented 2 weeks ago

I doubt it is ffmpeg issue. It is probably that we create hwcontext during hwdec probe and they are not removed and this >for some reason keeps dGPU alive.

Could you try --hwdec=vaapi and --vaapi-device= if this behaves better?

I don't usually touch this option; because of the ergonomic of -copy decoding, so I always avoid -copy decoding, also as per manual: "--vaapi-device=<device file|adapter name> Choose the DRM device for vaapi-copy. This should be the path to a DRM device file. (Default: /dev/dri/renderD128)"

Here from my setup:

  ~                                                                                                                                                                                       at  18:26:03
❯ ls -l /dev/dri/by-path                                                      
total 0
lrwxrwxrwx 1 root root  8 Nov  6 17:06 pci-0000:00:02.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Nov  6 17:06 pci-0000:00:02.0-render -> ../renderD128
lrwxrwxrwx 1 root root  8 Nov  6 17:07 pci-0000:01:00.0-card -> ../card1
lrwxrwxrwx 1 root root 13 Nov  6 17:07 pci-0000:01:00.0-render -> ../renderD129

also:

  ~                                                                                                                                                                                       at  18:41:15
❯ lspci | grep VGA 
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation GA104M [GeForce RTX 3080 Mobile / Max-Q 8GB/16GB] (rev a1)

If it worth the shot I'll gladly try it.

kasper93 commented 2 weeks ago

cuda is proved before vaapi, can you see if your issue reproduces with hwdec=cuda,vaapi?

Shouldn't it be hwdec=nvdec,vaapi? It is not called cuda. @morialo3 could you try that?

morialo3 commented 2 weeks ago

Shouldn't it be hwdec=nvdec,vaapi? It is not called cuda. @morialo3 could you try that?

Here:

https://github.com/user-attachments/assets/bea624dd-3c15-4048-b6e6-448478cd2caf

log file: output-nvdec.txt

mpv-player / mpv