mpv-player / mpv-player/mpv

vo/gpu-next/opengl: frame timing statistics for compute shader passes are always zero

Open
#14,202 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

vo:gpu-next
Dominant language
C
Stars
37k
Forks
3.5k
Avg merge
1d 10h
Merged PRs (30d)
22

Description

mpv Information
mpv v0.38.0-77-g0318174273 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
libplacebo version: v7.349.0
FFmpeg version: 6.0.1
FFmpeg library versions:
   libavutil       58.2.100
   libavcodec      60.3.100
   libavformat     60.3.100
   libswscale      7.1.100
   libavfilter     9.3.100
   libswresample   4.10.100
Other Information
  • Linux version: Fedora Linux 40.20240519.0 (Silverblue)
  • Kernel Version: 6.8.9-300.fc40.x86_64
  • GPU Model: Intel Corporation DG2 [Arc A750] [8086:56a1]
  • Mesa/GPU Driver Version: 4.6 (Core Profile) Mesa 24.0.6 (git-c659c7e660)
  • Window Manager and Version: Mutter (GNOME 46.1)
  • Source mpv: Built from HEAD
  • Introduced in version: IDK
Reproduction Steps

Get a compute shader. Here I use ravu-zoom-ar-r3-yuv.hook as an example.

Run:

mpv test.mkv --no-config --msg-level=vo/gpu-next=trace --fs --vo=gpu-next --gpu-api=opengl --glsl-shader=ravu-zoom-ar-r3-yuv-compute.hook --log-file=mpv.log

Ensure the compute shader is hooked and takes effect.

See frame timing in Shift+I page 2.

Expected Behavior

The timing of the pass of compute shader should be correct. In my machine, compared with:

  • --vo=gpu
  • --vo=gpu-next --gpu-api=opengl
    the duration of this pass should be near 4000us.
Actual Behavior

The timing of this pass is always zero; I have confirmed it in the log file as well:

[vo/gpu-next/libplacebo] Spent 0.000 ms on shader: RAVU-Zoom-AR (yuv, r3, compute)

I tried adding a gl->MemoryBarrier immediately after gl->DispatchCompute in gl_pass_run() in libplacebo/src/opengl/gpu_pass.c, but the result did not change.

I've confirmed that the results got from gl->GetQueryObjectui64v for the pass are very small values like 0 and 52.

I've tried MESA_LOADER_DRIVER_OVERRIDE=zink and confirmed that it is unlikely a vendor-specific issue.

Log File

mpv.log

Sample Files

No response

I carefully read all instruction and confirm that I did the following:
  • I tested with the latest mpv version to validate that the issue is not already fixed.
  • I provided all required information including system and mpv version.
  • 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.
  • I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
  • I attached the full, untruncated log file.
  • I attached the backtrace in the case of a crash.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with libplacebo/src/opengl/gpu_pass.c and gl_pass_run(), then reproduce the compute-shader case with the provided mpv command and trace logging. Inspect the glGetQueryObjectui64v results alongside the gpu-next shader timing output; done means the compute pass reports its actual duration rather than zero.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
computer-graphics, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.