0

Basically title. There are support for timestamp queries, but that requires specific device feature support (my laptop for example does not support it when targeting web). There is also the function Queue::onSubmittedWorkDone(callback) that throws an unreachable code error when I use any callback on wasm. Finally, device.poll(Maintain::wait) is explicitly a no-op on web according to the docs (for me, it never returns true when I try it). Is there any way to see whats in the Queue or check if it is empty? In the WebGPU api spec, onSubmittedWorkDone is an async function that returns a Promise. If that were the case, we could simply await until completion. I included an example with my attempt at using Queue::onSubmittedWorkDone(callback) in case it is user error (likely).

let mut encoder = driver.device.create_command_encoder(&wgpu::CommandEncoderDescriptor { label: None });
self.calculate_summary(&mut encoder);
self.color_map(&mut encoder); 
driver.queue.on_submitted_work_done(Self::done);
driver.queue.submit(Some(encoder.finish()));

fn done(){
\\\Ive tried just print statements, incrementing dummy variables, and even empty functions, but it doesn't work
}
Pap113
  • 37
  • 1
  • 7

2 Answers2

1

You might be able to use timestamp queries. At this point in time they are in limbo because the spec for them is not done but, you can enable the current version in Chrome by going to about:flags and enabling "WebGPU Developer Features" and passing in --enable-dawn-features=allow_unsafe_apis on the command line. (Yes, that means this is not a user facing feature yet)

Maybe they're still disabled on your machine? This example uses them if they're enabled

It should be noted though that render pass timestamp queries (setup in the renderpass) are separate from the one in the encoder and writes to buffers (via writeBuffer and copyBufferToBuffer and copyTextureToBuffer) all all out of band (not included in the time).

This means it's hard to get good timing across varied usages. It's one of the reasons timestamp queries are disabled by default so that the spec can be revised to possibly deal with these issues.

gman
  • 100,619
  • 31
  • 269
  • 393
  • Thanks for the tip. I want to end up using this to create fixed frame-rates though, and I can't expect others to have this feature enabled. I'm surprised this task is so difficult to enable. It seems pretty fundamental to games programming. I'm using it for a physics simulation though, so maybe there is something I am missing. – Pap113 Jul 20 '23 at 01:10
  • Timestamp queries are currently work in-progress in `wgpu` (see [this PR](https://github.com/gfx-rs/wgpu/pull/3636)). – frankenapps Jul 26 '23 at 04:34
  • It's not fundamental to games. 100s of thousands of games have shipped without needing timing queries. That said, you can also just [use your frame rate](https://stackoverflow.com/questions/16432804/recording-fps-in-webgl/) if you want to know if you're going slow. And, like nearly every PC game in existence, you can give the user options to enabled/disable various graphics features so they can choose speed vs visual effects. – gman Jul 26 '23 at 14:30
  • I am using timestamp queries in my project through the wgpu-profiler crate and have found it plenty useful to know the relative performance of my different render passes. Yes, they don't work on the web so I do my profiling work on native. Besides this, there are currently some [heavy performance issues related to string garbage collection](https://github.com/rustwasm/wasm-bindgen/issues/3468) with wasm builds of wgpu projects so it's hard to properly measure performance on the web. I'd recommend going with native for now for profiling. – David Huculak Jul 26 '23 at 15:53
1

I had a similar situation for a complex render chain and came up with the solution of reading a 1-byte buffer. I can then block awaiting the result, and so then I know the queue is empty again.

Andrew P
  • 26
  • 2