Investigate copying between textures with different formats.

[Kangz]

Currently the spec requires texture to texture copies to be between textures with the same format:

source.texture.[[format]] must be equal to destination. texture.[[format]].

However Vulkan allows copying between texture that have "size-compatible" formats (except depth-stencil formats) and I suspect other APIs allow that too. We should investigate if WebGPU can gain that additional flexibility too.

[kvark]

In Metal:

The source and destination textures must have the same pixel format and sample count.

However, one can create a texture view of a different format, and use it for copy. The problem here is the hit on #744, i.e. either source or destination need to have MTLTextureUsagePixelFormatView bit.

Another alternative on Metal is copying through an intermediate buffer. This is what Vulkan Portability does in the absense of better options. Since we have an option to shape the API, we shouldn't make this path mandatory (i.e. the user can always do this themselves).

[kainino0x]

However, one can create a texture view of a different format, and use it for copy. The problem here is the hit on #744, i.e. either source or destination need to have MTLTextureUsagePixelFormatView bit.

Only if the source and destination have "different component layouts".

[shaoboyan]

I did some explore about this before. And in vulkan and d3d12, there are compatible rules for texture copy(The final result is that if the texture format has the same component layout, vulkan and d3d12 support them copy to each other). But as @kvark said, Metal has a very strict rules on texture copy. And the only way to bypass this rule is adding MTLTextureUsagePixelFormatView flag, which may hurt perf by disabling compression(But with @kainino0x 's comment, it seems that this will hurt performance in "different component layouts" case). So my explore strength my agreement on the strict copy rules in current WebGPU spec.

And another thing is that the compatible rules need to be 'valid', which means developer can get the correct result with the different dest texture format. From my view, I think the 'valid' pairs to copy to each other is the format that has same component layout but are unorm<-->uint<-->unorm-srgb. Because they have the same contents but different interpreter in shader. But I'm not sure something like copy from rgba16uint to rgba16float is 'valid' or copy from one compress format to another different compress format is 'valid'.

[kainino0x]

If we are adding viewFormats in #811 anyway, can we just say you can copy between two textures if they have any overlap in their viewFormats?

[kainino0x]

#2322 investigated what we can do without any flags and resulted in #2329 which allows copies between formats differing only in srgb-ness (compressed or uncompressed)

[kainino0x]

I'm leaving this open for copies between different formats with a view-reinterpretation flag or viewFormats list.
This partial investigation from #2322 will be helpful here though:
#2322 (comment)
Things not covered by that investigation:

• Details of copyability in D3D12
• Does adding a flag change anything about copyability in D3D12/Vulkan?