OSD stats shows 0% for everything with gpu-api=vulkan

[lextra2]

mpv version and platform

Version:
mpv-x86_64-20190428-git-71ad1e2
OS:
Win10

Reproduction steps

Open any video, press Shift+I, press 2.

Expected behavior

The stats in that list show frame time numbers between 1-100%, equal to how much cpu load the different settings produce.

Actual behavior

The stats in that list all show 0% no matter the cpu load.

Log file

Use "gpu-api=vulkan" somewhere in your mpv.conf, and follow the reproduction steps.

Sample files

Any video is sufficient.
Edit: See example below

[Argon-]

Those percentages have nothing to do with CPU or GPU usage. They represent the percentage of a certain step based on the sum of all steps (that are considered here).

Use "gpu-api=vulkan" somewhere in your mpv.conf, and follow the reproduction steps.

My system doesn't support vulkan.

[Akemi]

on a side note, it doesn't show CPU load. first of all those stats show the frame timings of a fresh draw or redraw on the GPU, eg the absolute and relative amount of time it takes to draw a frame.

i guess VOCTRL_PERFORMANCE_DATA isn't properly implemented with the new libplacebo backend?

[edit]
actually the 4% are just rounding errors.

[Argon-]

i guess VOCTRL_PERFORMANCE_DATA isn't properly implemented with the new libplacebo backend?

According to the manual for vo-passes, this might be the case:

Not implemented by all VOs.

I feel like the manual once explicitly stated only the opengl backend implements vo-passes.

[lextra2]

on a side note, it doesn't show CPU load. first of all those stats show the frame timings of a fresh draw or redraw on the GPU, eg the absolute and relative amount of time it takes to draw a frame.

My bad. I meant what you said anyway.
Here is a screenshot of the bug.

[haasn]

The short answer is that libplacebo doesn't support timers at all.

The long answer is that adding timers is unnecessarily difficult due to the asynchronous internal design. At best we could perhaps have timers only for the "graphics queue" stuff, but that wouldn't be representative or accurate (since the graphics queue is time sliced with the compute queue), so I chose to simply omit them rather than have timers that are misleading.

It's possible we could revisit this in the future, perhaps with a modified internal design / queueing system. It's also possible we may re-add timers in a different form (i.e. getting execution stats on a per-shader basis rather than at "arbitrary points"), which would be more accurate and probably also more helpful in debugging shader performance.

[haasn]

These are implemented now, with some minor limitations. I decided to go with the second approach of making timers per-shader rather than starting/stopping them arbitrarily, since that fixes the queue type issues.

(Also, amdvlk supports timers on the transfer queues these days. Maybe it didn't in the past, I don't remember)