WebGPU "Queries" implementation (for profiling purposes)

[z2oh]

I am strictly a hobbyist when it comes to graphics programming, so please forgive any misinformed assumptions that I make :)

I am trying to benchmark individual render passes in an application built on wgpu-rs. In my research to resolve this, I stumbled upon the "timestamp" GPUQueryType. This API seems like it exposes data which could be used to benchmark any particular command, render passes among them (a very useful feature indeed!).

However, I could not find any APIs for interfacing with these Queries in wgpu-rs. I followed the trail and it seems that gfx-hal does provide this interface, which (in theory) means it can be propagated to my application code with the only necessary changes being contained within wgpu-rs and wgpu-core. I have two theories as to why this feature is not already implemented:

1. Software projects must allocate their limited resources judiciously; profiling isn't very useful if there is nothing to profile!
2. This open issue on gfx-hal precludes it from being spec-compliant with WebGPU, namely this restriction:

Timestamp query requires timestamp-query is available on the device.

I am willing to put in some legwork to make this happen, but I want to make sure my understanding of the situation is correct before I invest too much time. Any guidance would also be appreciated. Thanks for working on wgpu-rs!

[cwfitzgerald]

I believe your theory 1 is the most accurate :) Queries just recently got added to the upstream spec, so no one has gotten around to implementing them yet. (@kvark please correct me if any of this is wrong)

I don't know of anything at the moment that would predicate that they are unable to be implemented.

Hop on our matrix (https://matrix.to/#/#wgpu:matrix.org) and lets chat!

[kvark]

Thank you for the initiative, @z2oh ! I'm looking forward to use the GPU time queries in https://github.com/kvark/wgpu-bench/ .

[z2oh]

I have added the necessary interfacing to query for timestamp information in the hello-compute example. There is still some more implementation work to do, as well as a healthy amount of cleanup, but the steel thread implementation is there :)

Unfortunately, applications driven by an event loop will still need to manually poll the future that maps the buffer with timestamp information into host memory (and I couldn't find an easy way to do this). I'm also not sure how this will work with the buffer being overwritten every frame, but these are problems that can be solved after the initial implementation.

[kvark]

Great progress here!
The questions you are asking about async polling and overwriting the buffer are not specific to queries, they equally apply to buffer mapping and buffer copies, so it's nothing that you should be worried about in scope of the PR.

Minor nit: let's keep hello-compute as simple as possible. Could you pick a different example to add the queries in it?

[z2oh]

The questions you are asking about async polling and overwriting the buffer are not specific to queries, they equally apply to buffer mapping and buffer copies, so it's nothing that you should be worried about in scope of the PR.

Yep yep, I was just making a note for posterity that while the upcoming PR will add the ability to query for timestamps, it is not very useful without additional async integrations.

Minor nit: let's keep hello-compute as simple as possible. Could you pick a different example to add the queries in it?

I was planning on adding an explicit query example; I just put it in hello-compute locally to for my own testing :)

[kvark]

@z2oh please don't rush into making a new example. If we end up having an example per feature, there is going to be too much redundancy between them, and more code to maintain. Instead, pick an existing example for which it would make sense.

We'll need to make a table showing which features are present in which examples.

[rukai]

"We'll need to make a table showing which features are present in which examples."
Oooh that's a great idea

[cwfitzgerald]

Any progress on this? This would be a very useful feature to have.

[z2oh]

@cwfitzgerald,
I have made some additional progress since my last update, but I had shelved this PR temporarily after being distracted by some other things. Your comment has re-motivated me though :)

Pipeline statistics queries are wired through, but every time I read the buffer it's all 0s so I clearly have done something wrong! I'll rebase and continue the PR this week, and hopefully I can submit a draft PR this weekend. I may ping you on matrix if I can't figure out this last remaining issue. Cheers!

[cwfitzgerald]

Glad to hear it! Please do!

[cwfitzgerald]

hey! I know it's been.... over two months, but if you still are interested in helping with this, I can help out. If you don't have enough time or don't want to, no worries, I can continue where you left off. :)

[cwfitzgerald]

Bump :)