API tracing

[kvark]

API tracing is a feature that allows to serialize the workload that the library is processing over a period of time, so that it can be replayed later, potentially on a different machine and with a different GPU backend. It opens up a way to capture bugs (for investigating either the implementation or the application issues), share interesting workloads (as a form of art), or even do benchmarking.

At this point, it's clear that WebGPU as an API needs some tooling for workload capturing. There probably will appear some JS-based tools developed by the users and browser vendors. This issue is focuses on the native targets. Let's see what options we have to proceed:

A: Intercept in Rust, serialize with Serde.

This basically means transforming all the workload inputs (object descriptors, handles, etc), into pure Rust structs that implement Serde traits and recording them.

What this gives us:

• Convenience of Rust and its ecosystem (i.e can use RON format as destination).
• Can start the work today, not blocked by anything
• Can build an internal testing and benchmarking suite based on the captured format
• If used in conjunction with Capturing internal state for debug investigations #72, could support recording from a particular point (as opposed to the start of an application).

What's not clear is where this hookup should live. It could be a separate layer on top of wgpu-native, it could be a part of wgpu-remote, or be a part of wgpu-rs even.

B: develop a backend for RenderDoc and integrate with it

Given that RenderDoc became a central piece of the developer graphics tools, and it's open source, there is an opportunity here to start collaborating.

What this gives us:

• RenderDoc is not an afterthought, we get it from day 1
• convenience of the GUI

C: wait for the native tooling to emerge

We are not the only party interested in this technology. Obviously, Google is either already in process, or will attempt to build some tooling for tracing the API at the C level. Something like wgpuTrace as an analogy to vkTrace and apiTrace.

For us this plan means letting the things to advance by Google and assisting where time allows, focusing on interoperability with wgpu-native implementation (since clearly a hypothetical wgpuTrace will be catering to Dawn first and foremost).

What this gives us:

• path of least resistance

---

Now, I'm personally leaning towards (A) since I don't think this is going to be a huge amount of work, I think it could play well with #72, it will allow us to inspect and modify captures in RON by hands, and build some testing/benchmarking without relying on external suites.

My understanding is that when/if wgpuTrace becomes a thing, we'll just set up a tooling for bidirectional conversion to its binary format, effectively mimicking how ApiTrace trace is different from the dump.

This is a heavy RFC, please share your thoughts!

[m4b]

A seems really cool. I would be very interested in recording on my intel and playing back on another laptop with OpenGL to see what happens :)

B doesn’t help me; I use wayland on Linux and renderdoc only works for X11 last i checked.

C meh

[kvark]

I was thinking more about this feature in the context of Gecko integration. The further we are in with the implementation, the more the need to capture the workloads and debug independently of Gecko. For comparison, the moment WebRender got the capturing infrastructure ended up raising the developer productivity significantly, even though WR already had binary recordings mostly working. Contrary to this, wgpu doesn't have any kind of recording, so implementing this is the first and foremost priority once Gecko starts doing anything useful.

Now, as to how this should be done. I believe (C) is not an option for us because Gecko does not use the standard WebGPU C headers (i.e. wgpu-native) to talk to wgpu-core and instead does so via a different C API, which you can see in wgpu-remote. So Gecko wouldn't be able to take advantage of wgpuTrace if it was here today.

Further, having a text-based representation is extremely helpful, which is what (A) gives us. One can always write a converter from it into RenderDoc format as a follow up. So I feel strongly towards (A) now.