vo/gpu-next/opengl: frame timing statistics for compute shader passes are always zero
Nobody has claimed this yet.
- 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
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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