Maybe not exactly what this FR about, but from "regular user" perspective we could have something debugfs/sysfs/procfs like and then read whatever metrics in RT using standard tools like cat/watch/...conky.
I know many people playing games in fullscreen, but for good old fun: in windowed mode one can slap two customized "gauges" to the game window sides and get all required metrics (cpu/gpu/temp/...) from "system" in creative, not covering way. It should not have high precision, just to give user overall picture what currently happening.
Well, same from CI or whatever -- just cat /path/to/metric_file ...
My old PoC: https://github.com/pchome/dxvk-ipc
EDIT: another use-case is sshfs. Mount it on secondary device and get poor-man's "companion app" with minimal effort. Can be useful if fullscreen on main device.
@pchome: Are you advocating for dxvk to have its own performance overlay? What would be the benefit over mangohud? If there are some internal metrics dxvk would like to expose, can't we use some extensions to expose them?
On the topic of who should be dumping the metrics, I must admit that I have a slight preference for the tracing side to responsible as it would have the highest chance of generating consistent output across GPUs, drivers (even layered ones like DXVK), and graphics API.
The drawback of adding support in the tracing tool is mostly that landing code in apitrace isn't a fast process... but we can run our own fork until the code gets upstreamed! We need to do that for dx12 anyway.
But since I probably will not have time to work on that for a long time, I'll take anything anyone makes! Beggars can't be choosers ;)
@mupuf
@pchome: Are you advocating for dxvk to have its own performance overlay? What would be the benefit over mangohud? If there are some internal metrics dxvk would like to expose, can't we use some extensions to expose them?
Not performance overlay but the cat /sys/class/drm/card0/device/vendor way to access some metrics.
If you confused by the screenshot on my PoCs readme page there are two separate windows side by side. The green one (my poor attempt to theme conky in frog colors) represent what it gets from dxvk. Also can be simple watch command in terminal.
Maybe not that useful from tracing/profiling tools, but can be useful in other ways.
@pchome: Oh, I see, sorry, I definitely misunderstood you!
Not sure how one would do that efficiently in userspace though, since you don't want to generate the metrics unless you have a client for it. The solution you went with (writing each file after every update) is a bit wasteful... Maybe a socket would have been more appropriate?
Or having dxvk just dump all metrics to a single file, which could be a named pipe in your case which would then split the fields into separate files.
Yes, but the point to make as simple accessible as possible. Also doing this in /dev/shm or /tmp(usually tmpfs, in memory).
This is something "good to have" level, I'm not insist it should be like this. But if devs found this useful for them then users will be able use this for their needs too.
On the topic of who should be dumping the metrics, I must admit that I have a slight preference for the tracing side to responsible as it would have the highest chance of generating consistent output across GPUs, drivers (even layered ones like DXVK), and graphics API.
The problem with this is that it's not possible to measure GPU execution time with older graphics APIs (including D3D11). Timestamp queries exist, but since you have no control over GPU submissions from the application side in these APIs, they are not meaningful and you will end up measuring idle time as well. And since apitrace replay is generally CPU-bound, there's going to be a lot of idle time.
I feel like per-draw measurements aren't useful anyway since execution can overlap on a hardware level, which also greatly affects the results. RenderDoc's timing feature suffers from this as well. If we want to measure GPU time on a frame-by-frame basis, I think the correct solution is to accumulate and log this kind of data on the DXVK side.
D3D12 is a different story since the app actually controls submissions there, which means that timestamp queries actually produce meaningful results.
Thanks a lot for taking the time to answer, @doitsujin!
The problem with this is that it's not possible to measure GPU execution time with older graphics APIs (including D3D11).
Oh, right, lovely! Well, that settles it then :)
I feel like per-draw measurements aren't useful anyway since execution can overlap on a hardware level, which also greatly affects the results.
Sure, but it also happens between frames. Anyway, the point of per-draw measurements was to detect big changes... but if we can't tie these measurements to drawcall ids or something, they would not be useful as a performance trend.
If we want to measure GPU time on a frame-by-frame basis, I think the correct solution is to accumulate and log this kind of data on the DXVK side.
Works for me! As long as dxvk generates as many frames as what the trace contains (and will keep on doing so), we should have a 1:1 mapping so frames :)
I think the correct solution is to accumulate and log this kind of data on the DXVK side.
Hi, so I was wondering if we could us the DXVkGpuTimeStamps to collect different stats using timestamp queries over different draws/pipelien binds API calls (kinda like using Tracy like macros etc) and collect them into a DXVKGpuProfiler class and show them alongside the HUD? is that possible? I would like to work on it if that's actually doable, we can accumulate results per pass and and have a crude frame-to-frame GPU execution when we do submission alongside vkQueueSubmit?
@doitsujin (sorry for the tag on this old issue) any advice/opinion from you?
What do you actually want to achieve and why is it worth spending significant development resources on it?
Graphics profilers already exist (think RGP, Nsight), and they tend to work with DXVK quite nicely as-is, I don't see why we need any of this inside dxvk, not to mention that it's going to be substantially less reliable than vendor tools.
Nothing extracted yet.
We already have a way to look for rendering changes in DXVK CI, but performance tracking is limited to checking the execution time of the entire trace execution.
While this shows the overall trend in the average execution time, this is not representative of the user experience where stable frame pacing is more important than average FPS.
We could add support for dumping these metrics in Apitrace/GFX Reconstruct, but these performance metrics may also be of use to DXVK users when running actual games.
Performance instrumentation could be done on the vulkan side or the directX side, but since we care about the long term stability of the metrics, we would prefer to instrument the directX side to allow for architectural changes in DXVK without having to throw away our metrics history.
We would like to use this issue to discuss what would be the appropriate metrics to collect, and how/where it would be best to implement them. As a starter, we believe that using GPU timestamps to dump frame times and drawcall times would be of great help as a research experiment into what would be the most appropriate metrics.
cc @mupuf