Default resource usage semantics

[kvark]

Is your feature request related to a problem? Please describe.
#1413 exposed the cost of tracking resources. This issue is a concrete proposal to help it.

Describe the solution you'd like
Given a set of usages for a resource, we can determine default_usage: Option<Usage>. For example, if it's a texture with COPY_DST | SAMPLED (which is what most textures should have), we can assume that copying is only going to be done at start. So we want to make it so using it as SAMPLED doesn't require tracking the usage of the resource. It doesn't free us from tracking the lifetime of the resource, though.

When such resource is added to a bind group, and the usage matches the bind group usage, we'd add it to a separate list on the bind group. This list would not be scanned on SetBindGroup, it would only be scanned on submit() when the device updates the submission indices of all used resources.

When a resource is used for a different usage (from the default one, if present), then it's added to the trackers, like the usual. However, after submission, the resource is transitioned back to the default state.

The logic of determining the default usage can be very conservative. We can start with COPY_DST | SAMPLED on textures.

For buffers the situation is less obvious. Even if it's just COPY_DST | UNIFORM, it may be constantly updated. However, it may still be OK to let it follow the logic of default usage, it's probably going to produce the same set of transitions anyway.
The other problem with buffers is that a lot of them don't naturally come in any container (bind group): vertex, index, indirect buffers are all provided directly. So we'd have to register each of these buffers somewhere. At least, we can do it in a list on CommandBuffer itself, instead of first adding it to a pass/scope, and then merging into the command buffer.

Describe alternatives you've considered
Previously, in WebGPU there were talks about "dropping usage" semantics. The suggested use case was: having COPY_DST on a resource just to initialize it, then dropping this usage, therefore leaving the resource truly immutable.
This proposal is an evolution of the idea, but to be implemented without any API changes.

Additional context

[cwfitzgerald]

This is now basically obsoleted by #2662. There are theoretical benefits there, but tracking is no longer our number one bottleneck in renderpass recording, so we should focus elsewhere and only come back to this if we must.