这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@Kangz
Copy link
Contributor

@Kangz Kangz commented May 14, 2019

edited: Fixes #286


Preview | Diff

Copy link
Contributor

@kvark kvark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approach is good in general, it's in line with what we've been discussing.
Got some concerns about the details

@Kangz
Copy link
Contributor Author

Kangz commented Jun 4, 2019

Thanks @RafaelCintron for all the explanation on D3D12 optimizations.

In the call yesterday you said you wanted to think more about bundles. I'd like to clarify again what the different uses for bundles are:

  • Parallel recording of the inside of a render pass. D3D12 can do this using command lists because (until recently) there was no constraints on commands for being inside or outside a render pass. In WebGPU we need to have different types because you can either record something "at the top level" or "inside a render pass". Recording the inside of render pass in parallel is important because for many application they will have "main" render pass that contains thousands of objects and will dwarf the rest of the encoding work.
  • Reordering inside a render pass. I don't have an example at hand for render bundles, but Babylon.js found it very useful to be able to record two command buffers in a single traversal of their scenegraph. They encode both upload commands to update uniforms, and the actual draw commands, then at submission time they just need to order uploads before draws. With reordering they'd need to do two passes over their scenegraph. Bundle doing the same type of thing with the inside of a render pass.
  • Reuse of parts of the commands inside a render pass. Many applications will have part of their scene stay similar across frames. Reusing bundles allows saving the CPU cost of walking through the scenegraph subtree, encoding the commands and validating them.

My understanding is you have concerns that WebGPU implementation using bundles will have to use the DESCRIPTORS_VOLATILE flag. That's likely necessary in all cases because we can't guarantee that the content of uniform buffers will not change so we don't want the D3D driver to inline part of it in the root signature.

However, the D3D team's experience so far suggests they are rarely a performance win, and in many cases a pessimisation. Their programming model is too restricted to map well to typical app usage patterns, and they inhibit optimizations that drivers would otherwise perform.

Dawn made an implementation choice to always replay commands from software command buffer, but some other implementation can choose to back WebGPU bundles with D3D12 bundles, at which point there is the same performance tradeoff that you mentioned in your comment.

WDYT? Does it make you more comfortable with this PR?

Copy link
Contributor

@beaufortfrancois beaufortfrancois left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Kangz Bikeshed raises some errors.
Please make sure documentation is up to date as well.

Nit: Why executeBundles instead of setBundles?

@Kangz
Copy link
Contributor Author

Kangz commented Jun 27, 2019

@beaufortfrancois executeBundles isn't like setPipeline or setBindGroup because it essentially inlines all the commands in the bundles in particular draw or dispatch.

@grorg
Copy link
Contributor

grorg commented Jul 8, 2019

Discussed at 8 July 2019 teleconference

@Kangz
Copy link
Contributor Author

Kangz commented Jul 9, 2019

Merging as discussed in yesterday's call.

@Kangz Kangz merged commit b357e42 into gpuweb:master Jul 9, 2019
@Kangz Kangz deleted the bundle branch July 9, 2019 08:21
@kvark kvark mentioned this pull request Jun 10, 2020
3 tasks
bors bot added a commit to gfx-rs/wgpu that referenced this pull request Jun 11, 2020
286: RenderBundle support r=cwfitzgerald a=kvark

Implements the API of gpuweb/gpuweb#301

The general concept here is having re-usable command streams, which seems much desired given that our command buffers are not reusable.

Currently, only "software" render bundles are supported. That means, they are just smaller chunks of render pass commands, not backed by any driver object.

TODO:
- [x] gfx-rs/wgpu-rs#357
- [x] gfx-rs/wgpu-native#37
- [x] figure out the lifetime solution

Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this pull request Sep 6, 2022
* Add validation tests for mapAsync, getMappedRange and unmap.

* Address comments

* Make createBufferWithState not modify the incoming object

Co-authored-by: Kai Ninomiya <kainino@chromium.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Encoder results reuse

6 participants