dmabuf-wayland wakes up discrete NVIDIA GPU #13668
Comments
|
Use |
|
Thanks for your help~ I've tried (And as I recall NVIDIA doesn't support VAAPI by default?) |
|
I can also reproduce the issue on 2 different laptops with Intel + NVIDIA GPU. |
|
I can also reproduce the issue with Intel + NVIDIA GPU, on Arch Linux, kde wayland |
|
had a similar issue of mpv always taking 3sec+ to launch while it was waking up suspended GPUs even when just listing --help, it also took 3sec to quit if the other GPU got suspended again. I wasn't actually using dmabuf-wayland so my specific issue was different but perhaps there's a connection. with with then I tested switching gpu-api=opengl which still woke up the other GPUs but now it only when playing a video and not when listing --help etc (with that change the slowest syscall was a futex). then noticed that setting |
|
Hi,
It should be another issue, since vo=gpu-next paired with gpu-api=vulkan or opengl does not wake up my discrete GPU.
I've introduced some environment variables to workaround similar issues, see https://github.com/Kimiblock/moeOS.config/tree/master/usr/share/moeOS-Docs/Environments.d and https://github.com/Kimiblock/moeOS-Package/blob/b514baf818cb07c56580588f4b4b582471f3f29c/PKGBUILD#L321.
…--
Sincerely,
Kimiblock
|
|
Btw, it won't happen when using nouveau. log is little different: https://fars.ee/VtIr |
|
I can replicate this issue. I believe I've narrowed down exactly when mpv wakes up the nvidia dgpu. The wake up happens when mpv is ran with the
One of the decoders it tries to load is The There's two possible fixes here:
This is also why @heddxh could not replicate the issue with Nouveau. CUDA isn't supported by Nouveau, so whatever things the cuda hwdec driver is calling never wake up the dgpu. |
|
The gpu is awoken when cuda_hwdec calls |
|
I've made a patch which fixes this. Submitting soon. |
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process is blocking and takes a few seconds. It also needlessly increases power consumption. Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls `cuInit` before running all interop inits. However, the first checks in the interops do not require cuda initialization, so we only need to call `cuInit` after those checks. `cuInit` is handled by the new `cuda_priv_init` function. It ensures `cuInit` is only called once. With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents `dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily, making them start faster and decreasing power consumption on laptops. Fixes: mpv-player#13668 Signed-off-by: Jrelvas <[email protected]>
|
I've done a little testing and this appears to fix the issue. #14028 |
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process is blocking and takes a few seconds. It also needlessly increases power consumption. Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls `cuInit` before running all interop inits. However, the first checks in the interops do not require cuda initialization, so we only need to call `cuInit` after those checks. `cuInit` is handled by the new `cuda_priv_init` function. It ensures `cuInit` is only called once. With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents `dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily, making them start faster and decreasing power consumption on laptops. Fixes: mpv-player#13668 Signed-off-by: Jrelvas <[email protected]>
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process is blocking and takes a few seconds. It also needlessly increases power consumption. Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls `cuInit` before running all interop inits. However, the first checks in the interops do not require cuda initialization, so we only need to call `cuInit` after those checks. This commit splits the interop `init` function into `check` and `init`. `check` can be called without initializing the Cuda backend, so cuInit is only called *after* the first interop check. With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents `dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily, making them start faster and decreasing power consumption on laptops. Fixes: mpv-player#13668
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process is blocking and takes a few seconds. It also needlessly increases power consumption. Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls `cuInit` before running all interop inits. However, the first checks in the interops do not require cuda initialization, so we only need to call `cuInit` after those checks. This commit splits the interop `init` function into `check` and `init`. `check` can be called without initializing the Cuda backend, so cuInit is only called *after* the first interop check. With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents `dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily, making them start faster and decreasing power consumption on laptops. Fixes: mpv-player#13668
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process is blocking and takes a few seconds. It also needlessly increases power consumption. Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls `cuInit` before running all interop inits. However, the first checks in the interops do not require cuda initialization, so we only need to call `cuInit` after those checks. This commit splits the interop `init` function into `check` and `init`. `check` can be called without initializing the Cuda backend, so cuInit is only called *after* the first interop check. With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents `dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily, making them start faster and decreasing power consumption on laptops. Fixes: mpv-player#13668
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process is blocking and takes a few seconds. It also needlessly increases power consumption. Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls `cuInit` before running all interop inits. However, the first checks in the interops do not require cuda initialization, so we only need to call `cuInit` after those checks. This commit splits the interop `init` function into `check` and `init`. `check` can be called without initializing the Cuda backend, so cuInit is only called *after* the first interop check. With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents `dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily, making them start faster and decreasing power consumption on laptops. Fixes: mpv-player#13668
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process is blocking and takes a few seconds. It also needlessly increases power consumption. Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls `cuInit` before running all interop inits. However, the first checks in the interops do not require cuda initialization, so we only need to call `cuInit` after those checks. This commit splits the interop `init` function into `check` and `init`. `check` can be called without initializing the Cuda backend, so cuInit is only called *after* the first interop check. With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents `dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily, making them start faster and decreasing power consumption on laptops. Fixes: mpv-player#13668
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process is blocking and takes a few seconds. It also needlessly increases power consumption. Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls `cuInit` before running all interop inits. However, the first checks in the interops do not require cuda initialization, so we only need to call `cuInit` after those checks. This commit splits the interop `init` function into `check` and `init`. `check` can be called without initializing the Cuda backend, so cuInit is only called *after* the first interop check. With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents `dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily, making them start faster and decreasing power consumption on laptops. Fixes: #13668
Important Information
Provide following Information:
If you're not using git master or the latest release, update.
Releases are listed here: https://github.com/mpv-player/mpv/releases
Reproduction steps
On an hybrid GPU system, run
and run
to monitor GPU power state.
Expected behavior
mpv does not wake up the discrete GPU:
watchcommand will return a lineD3coldActual behavior
mpv wakes up discrete GPU, watch shows all GPUs at
D0,sudo lsof /dev/nvidia*shows that mpv is using discrete GPU.Also tried
--drm-device=/dev/dri/renderD129to point drm device to iGPU but it doesn't work.Log file
output.txt
Sample files
Any VP9 / AV1 / HEVC / AVC video
The text was updated successfully, but these errors were encountered: