encoder.WriteBuffer question

[Jean-Colas Prunier]

Hi everyone,

We have been using encoder.WriteBuffer in our code, which is convenient but noticed when we came to compiling the code for Esmcripten that WriteBuffer on the for CommandEncoders wasn't in the WebGPU spec. 

This is not an issue, we will revert back to using queues instead, but was wondering out of curiosity what was the motivation for adding this method (thought it seems really logical to me) and more generally, whether this is a suggestion you could make to the committee in charge of the specs. It would seem like a very reasonable thing to have in the specs?

Many thanks as usual for your input. -jc

[Corentin Wallez]

Hey Jean-Colas,

encoder.writeBuffer is a Dawn-specific API that was made specifically to implement the indirect draw validation in Dawn. It's exposed in the header so we can test it, but otherwise should probably not be used. Like you saw it is not in the WebGPU spec and unlikely to be standardized ever (because it ties GPU memory to a command buffer and has performance characteristics that are both unclear to developers, and not better than what devs could do themselves in most cases). So I'd really suggest using the queue.writeBuffer instead.

Cheers,

Corentin

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/3fdd2446-0163-4d85-884c-f0a59456bf65n%40googlegroups.com.

[Jean-Colas Pro]

Thank you Corentin.

Yes I got this was specific to Dawn’s API. I am not familiar enough with the issue you are alluring to, to appreciate why this wouldn’t be a good method (at least as valid as using the queue instead). I found it personally nice that you could just get into the flow of commands, as you had a clear picture that these things were going to be executed in the order in which the methods associated with the encoder were written. So I assume that if you use GetQueue() for instance, surely the WriteBuffer will be executed before you submit the commands and that pauses no problem whatsoever but then it’s not necessarily in order in which you have written the calls in the code any longer. It’s a detail I agree, but that’s why I found the method nice, though this is just a problem if you suffer from OCD ) like I do probably )).

Anyway we indeed reverted back to using the queue. Thanks again.

You received this message because you are subscribed to a topic in the Google Groups "Dawn Graphics" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dawn-graphics/bNsSq76ZzRs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CAGdfWNNz4J_0UTjwHyS3ZnLObNdNWrd6RcLo00RUdh%3DOva1BoQ%40mail.gmail.com.

[Jean-Colas Prunier]

Hello,

I wanted to add something to this thread. We have been adding some timestamps to look into the time it takes to render a single frame in if we go through queue.WriteBuffer() these operations can not be measured using queries (if I am not mistaken). One benefit of having something like encoder.WriteBuffer is that we could add a timestamp before and after and estimate the time it takes to copy the geometry data to the GPU in addition to rendering time.

Do you think it makes sense? Would there be another way to measure that time? 

Thank you.

[Kai Ninomiya]

Using timestamps to measure the time of an encoder.WriteBuffer would *only* measure the part of the code that actually happens inside of the encoder, which - not knowing the implementation - I think is probably just a CopyBufferToBuffer from Dawn's staging memory into your buffer. The rest of the work to upload the thing has already happened by that point.

-Kai (he/they)

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/07496141-9d92-4fbd-8b20-deab3745c59fn%40googlegroups.com.