Buffer creation & GPU/CPU synchronization

[Jean-Colas Prunier]

HI everyone,

I have a situation in which the GPU is busy rendering a frame using data stored in buffers that have been sized to fit the data of say a scene called A. And while the GPU renders that frame (content of scene A), the CPU might need to resize the same buffers to fit the data of another scene (let's call it B). This invalidates the data in the buffers and causes an error. Ok fairly basic synchronization issue here but since I can't use fence or semaphore I was wondering if you had some ideas about to handle that type of situation.

- I can of course use double buffering but this can load out of memory issues (needing to fit 2 scenes for a short time).

- I wonder if I could use something like vertex_buffer.MapAsync() to figure out when we are done with using the vertex_buffer and perform the resize then.

I will try this approach but was wondering how you would approach this, best practice, your experience/solution with this type of issue.

Thanks a lot. -jc

PS: since the group has become terribly quite, do you prefer me to post this on Matrix now?

[Jean-Colas Prunier]

Update:

Using a someBuffer.MapAsync(MapMode::Read...) after submitting the commands to the queue seems to be working as a way of signaling the method that's responsible for resizing the buffers, that it's ok to do so. So well that solution would work.

I still wonder if that's a common way of doing it in WebGPU and if there's a better way you can think of / recommand. 

[Dominic Cerisano]

The Conformance Test Suite (CTS) is a comprehensive code resource for  WebGPU .

Although not perfectly clear from your question, this test seems to be in the general ballpark, as are some others.
The Matrix group is excellent if you post your code for spot review with specific info detailing the issue.

Dominic Cerisano

dcer...@gmail.com

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. 
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. 

--
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/ce8d7a54-e020-44e8-ada0-246ddd10eac2n%40googlegroups.com.

[Jean-Colas Prunier]

Thanks a lot Dominic. Our code is c++ but I will go through the ts code and try to figure something out) I will post the questions on Matrix then. Sad. this is was a nice group). But a group with 1 active member is not very useful... Well bye then.

[Gregg Tavares]

I'm a little confused

> the CPU might need to resize the same buffers to fit the data of another scene 

There's no such thing as resizing a buffer in WebGPU. Buffers are allocated in a single size and if you need a different size you have to make a new buffer

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/00f72a62-bb72-4438-adf0-27149edc614dn%40googlegroups.com.

[j...@jean-colas.com]

Sorry, I don’t resize I create a new one if you wish but it’s half by the same variable. I am using buffers of different size hence the term resizing but it’s misleading I agree.

I have a member variable called say vertex_buffer that’s being created then filled in with some data, that is being used in a render (commands submitted to the queue), then if attempt to destroy that buffer and recreate a new one while the commands are being processed (because I need a buffer of a different size to hold data for a different scene), the GPU will point to memory that’s either not there anymore or filled in with rubbish.

When that happens Dawn complains about the command being invalid the buffer size being incorrect with respect the offset used in DrawIndex. If I wait for the commands to be processed (I am using MapAsync right now - that’s the solution I found - and when the callback function is called with success, I know there’s no commands in the queue; the buffer can then be « re-created »  safely - the problem disappears). So it’s really a synchronization issue.

I hope that clarifies things. 

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/mrWoxYYf4Rc/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/CAKZ%2BBNpcts%3DfnmfdKpWAwdsqmYq14895ig-9icy4Af5Cp7YWoQ%40mail.gmail.com.

[j...@jean-colas.com]

Held by the same variable ...

On 26 Jul 2023, at 17:51, 'Gregg Tavares' via Dawn Graphics <dawn-g...@googlegroups.com> wrote:

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/mrWoxYYf4Rc/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/CAKZ%2BBNpcts%3DfnmfdKpWAwdsqmYq14895ig-9icy4Af5Cp7YWoQ%40mail.gmail.com.

[Dominic Cerisano]

This group is intended for development of Dawn itself, rather than Dawn applications.  I had to integrate Dawn with V8 directly a while back using NAPI to expose the WebGPU API, and I believe MS integrated Dawn into Babylon Native, again using NAPI to expose the WebGPU API there. Of course Chrome also has an integration of Dawn to expose the WebGPU-API as a micro service.

 AFAIK Dawn's C API was very much specifically  intended to support the WebGPU API, and is not intended to be used directly, so your approach may lack support unless you can find others who are using Dawn's C API outside of a WebGPU API integration. The amount of testing just to integrate Dawn with WebGPU API is quite exhaustive, but at least well defined. Without a clear definition of what your application of Dawn  is, it may be difficult to find support for it.

Dominic Cerisano

dcer...@gmail.com

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. 
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. 

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/00f72a62-bb72-4438-adf0-27149edc614dn%40googlegroups.com.

[Dominic Cerisano]

Of course other browsers are also integrating Dawn, but only to expose the WebGPU API. I can imagine that the Dawn C API might be attractive to applications other than browsers (javascript engines) such as game development and other cross platform applications, but again that might be an anti-pattern due to Dawn's codependence with WebGPU API. There could easily be breaking changes in any other application other than WebGPU API integrations.

Dominic Cerisano

dcer...@gmail.com

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. 
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. 

[j...@jean-colas.com]

Thanks Dominic.

- We find Dawn to be the best API for abstracting different real-time APIs out there which means that if you integrate it, you get an application that runs on Mac, Windows, Linux and the Web (as you already know). This is a big achievement. If you work for a large company with a lot of resources, you might find enough of these resources internally to have a port for Metal, Vulkan/ DirectX, … and maybe something for the web (if you find people of your experience). If you have a small group, you can leverage Dawn to achieve a similar result. So that’s one aspect of why Dawn is appealing (other projects that I know that tried to achieve the same result are not as solid as Dawn). And while I am speaking mostly about desktops here, I don’t even speak about tablets and phones … that’s another layer.

- It’s difficult to make a commercial product out of code that’s written in JS. Not impossible, but hard to protect since your code base is more easily exposed. And while I admire the work done to integrate WebGPU to JS, I am yet to see it used commercially (explaining this to investors in general, would be rather hard). While this will probably somehow happen, I don’t think there will be a big trend of that (I could be wrong). Which is somehow linked to the first point. If you develop a graphics app, users might be very interested in the prospect of using the web (no tool to download and install) but many users are still looking for native desktops apps. To my knowledge the C/C++ API offered by Dawn is the best option out there. And when porting to the Web you can got the WASM route, which also limits the exposure of your code to external users (hardly the case with JS). The other option I have seen to this is streaming the viewport to the web to by-pass the web architecture all together.

I go get my questions are generic and no so much about the Dawn code itself. I will try to redirect these questions to matrix and see if this is a more appropriate place. Though your answers seems to indicate that there is no support for people that would be using the Dawn C/C++ API (unless this community is willing to help each other - but limited supported from the Dawn devs themselves). 

So I hope eventually that there will be larger community out there of people that share our vision about why Dawn C API is interesting and relevant. The lack of support is a problem but the real danger would be if at some point your group decided to stop exposing the Dawn C API to the public as open source. Indeed if a group relies on it (for an app), and that somehow that effort is put on halt, that group would be in a difficult situation.

However if we have to get back to the board and rely on Vulkan directly, that’s rather sad. As imo no progress is being made to unify the approach to real-time graphics APIs which would be an opportunity for smaller dev groups to reach out a bigger audience. I wish I could stress more how important that work you are doing is. Now I understand your goal is to get WebGPU to Chrome primarily and by making the code open source to get others to integrate it to their own browser. Though I hope I can convince you that this effort could be really leveraged to offer a solution to develop efficient cross-platform real-graphics apps by teams that don’t have the resources to do it themselves and that you could support that work in that way too (assuming you have resources to do so of course).

Again thanks for your answer, your team effort and overall support.

Best -jc

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CA%2BgE_wi1hk_sEhVvH3eQ5Cnxsbygx0M8TpCbAMPNdDskGKZ4WQ%40mail.gmail.com.

[Dominic Cerisano]

It sounds like your approach is novel, and might even be innovative.  I hope you are least baselining Dawn and any other rolling project you are using, and not trying to use the nightly builds. It is hard enough to be independently innovative without the overhead of keeping up with everyone else's raw innovations in real time.

I am sure we all look forward to your results, it could be real "fire" (if I am using that term correctly)

Bon chance,

Dominic Cerisano

dcer...@gmail.com

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. 
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. 

[Austin Eng]

Asking questions here or on Matrix are both appropriate. Both are meant to be places where you can ask about using the API. It may take us some time to reply, so we appreciate your patience :)

We certainly do hope for Dawn to provide a good, stable C API. We're actively working on this, and it will eventually become stable, but we're not quite there yet. You can follow progress at https://github.com/webgpu-native/webgpu-headers. The goal is that you'll be able to write applications in C or in other high level languages like C++/Go/Kotlin/Rust made with bindings on top of the C API - and that you'll then be able easily port those native applications to the Web using a toolchain like Emscripten. We do intend for Dawn in native to be a use case, and we do intend to support it. The approach is not at all novel; there are many individuals (and companies!) who are using Dawn in C/C++ or wgpu in Rust to successfully build native apps that also can be ported to the web.

Regarding the original question:

My interpretation is that you're using a buffer in a command buffer, then dropping it and making a new one; repeat. This should be valid. It would be helpful if you could use SetLabel to label your objects, and share specifically the error messages you're seeing.

// You have some buffer

wgpu::Buffer vertex_buffer = ...;

void Frame(wgpu::Device device, wgpu::Buffer& vertex_buffer) {
  // You use the buffer in a command buffer that is submitted

  wgpu::CommandEncoder encoder = device.CreateCommandEncoder();
  wgpu::RenderPassEncoder pass = encoder.BeginRenderPass(...);
  pass.SetVertexBuffer(0, vertex_buffer, ...);
  ...
  pass.DrawIndexed(...);
  ...
  pass.End();
  wgpu::CommandBuffer commandBuffer = encoder.Finish();
  device.GetQueue().Submit(1, &commandBuffer);

  // You destroy the buffer, and make a new one.

  vertex_buffer.Destroy();

  vertex_buffer = device.CreateBuffer({ ... });

}

The ordering of what really matters are the parts in bold.

If you destroy the buffer before submit, then you will get a validation error.

If you destroy the buffer after submit, then the submission should be valid, and the buffer will be considered destroyed for all future uses on the queue.

I'm not sure about the part where you said "GPU will point to memory that’s either not there anymore or filled in with rubbish", and I'm not sure about how your comments about buffer mapping tie into your use case. Any clarification would be helpful, or if you could even share a reduced test case, we could help more.

Some guesses:

Dawn complains about the command being invalid the buffer size being incorrect with respect the offset used in DrawIndex

 

This sounds like you are reassigning vertex_buffer before you've actually called SetVertexBuffer. Could it be happening accidentally? Or perhaps you have multiple threads that race?

GPU will point to memory that’s either not there anymore or filled in with rubbish

Are you mapping the buffer, then writing/reading to the mapped addresses after the buffer has been destroyed?

Cheers,

Austin

  

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CA%2BgE_whJhzXYK%3DPzANsV1_LkVf13A-%2BKKmP8HKQ8sWHsie93Qg%40mail.gmail.com.

[Dominic Cerisano]

Given that the Dawn repo at googlesource is titled Dawn, A WebGPU Implementation using it directly, outside of a WebGPU API integration most certainly is novel at this time, all forward-looking statements notwithstanding.

The WebGPU API shall be driving priority changes to Dawn, so using Dawn's C API for any other application is going to remain novel (risky) until the dust has settled.

Certainly when it comes to successful innovations qui ne risque rien, n'a rien, so I appreciate and admire those who are willing to use Dawn directly at this time. Surely there will be some exciting results to look forward to.

Dominic Cerisano

dcer...@gmail.com

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. 
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. 

[Kai Ninomiya]

(Catching up on this thread all at once, apologies.)

About the usage of this list, the description: "development and use of the Dawn graphics library." Actually, almost all Dawn development discussions are on crbug.com/dawn rather than here, so it really is mostly "use of the Dawn graphics library".

About code references, if you're targeting Dawn, agreed it does still make sense to look at JavaScript samples (webgpu-samples, CTS, etc.), as the API is nearly the same. When it comes to native API details, the Dawn samples, tests, and implementation are good references.

About the use of Dawn, everything Austin said is correct. When the repo title says "a WebGPU implementation" it does not mean the JavaScript API in particular, but the API design generally, and in particular the C API that we're working on standardizing. It is and has always been intended to be used as a hardware abstraction library by general applications, not just those which bind it up to JavaScript.

The C API is indeed not stable yet, but that's only because we prioritized completing the JavaScript API first. I'd categorize risks:

• You'll have to deal with updating past breaking changes until the core C API is standardized (if you want Dawn updates).
• Dawn may not gain the features you want as quickly as you want, especially platform-specific features. (But we take contributions!)

And benefits:

• Dawn being a WebGPU implementation means it has especially strong portability and security goals.
• The API will be standardized so you can retarget to wgpu-native as well as WASM/Emscripten. (And wgpu-native is likely to have more non-standard features than Dawn.) The C++ bindings should be portable over other implementations too.

I'd call it "early adoption" as I think it's past the phase of "novel", but as long as people know what they're getting into with Dawn (and I think all of our adopters do), the term isn't really important.

-Kai (he/they)

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CA%2BgE_whypSKj2A5L5Ev9yUKY-HzVqn_bbrtM1g3F0-o1_B16fQ%40mail.gmail.com.