RenderBundle support

[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:

• Render bundle support, use in msaa-line example wgpu-rs#357
• Update wgpu with bundle support wgpu-native#37
• figure out the lifetime solution

[cwfitzgerald]

I'm not knowledgeable on the content, but nothing stuck out to me in the code itself.

[kvark]

Faced a conceptual problem with life times here.

lifetime problem

A render bundle knows about its dependencies and carries a TrackerSet. A render pass, however, doesn't carry TrackersSet around, since it was built in an assumption that all the dependencies will live as long as the pass is recorded. We require the same for the render bundle as a dependency, so technically the requirement for bundle dependencies is fulfilled - they are guaranteed to be alive.

However, the problem comes from actual details. When the bundle is executed in a pass, we just merge in the stream of commands from the bundle. Suppose this stream uses resource A, held alive by the bundle. Suppose the resource got dropped by the user before using the bundle. When the render pass finishes, it goes through the raw commands and encounters that resources, and it sees that the resource is dead. So it panics, since from its perspective, the dependency wasn't held alive.

Proposed solution

I think we can get away here by carrying the TrackerSet in a render pass. For now, we are only going to use it for render bundles: by merging the tracked states in, or at least registering the resources that the bundle uses. This means that, when the pass is finishing, it will see the bundle dependencies as "known" resources.

Second part is to avoid the tracker panic in this borrow. Instead, a resource should produce Option<&RefCount>, which we'll only require if the resource was actually not registerd before, i.e. in the Vacant arm. This will still be correct, and allow bundles to propagate their dependencies smoothly.

[kvark]

@cwfitzgerald sorry about the size here, I had to take a different approach in light of the lifetime issues expressed in the previous comments. I believe, it's all for the better, as bundles are now truly visible in the API tracing, and faster to work with. Please see the description at the top of "bundle.rs" in this PR.

[cwfitzgerald]

A couple comments/concerns, but nothing major :)

[kvark]

Thank you!

[cwfitzgerald]

LGTM

[kvark]

bors r=cwfitzgerald

[bors]

Build succeeded:

• Ubuntu Stable
• iOS Stable
• Windows Nightly
• MacOS Nightly
• Windows Stable
• Android Stable
• MacOS Stable
• Ubuntu Nightly