-
Notifications
You must be signed in to change notification settings - Fork 335
Clarify t2t copy same texture #823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify t2t copy same texture #823
Conversation
This patch intends to clarify the validation rules on the texture-to -texture copies when the source and destination textures are the same one. - when the source and destination textures are both 2D textures, we cannot allow the source base array layer being equal to the destination base array layer as D3D12 requires in the CopyTextureRegion() the source and destination resources must be different subresources. - the copy source and destination region must not overlap as is required in Vulkan SPEC.
The statements in D3D12 is here and the statements in Vulkan SPEC is "the union of all source regions, and the union of all destination regions, specified by the elements of pRegions, must not overlap in memory". Note that on D3D12 we implement multiple-layer texture-to-texture copy with a for-loop, so when we want to copy the top-left corner of layer 0, 1, 2 to the bottom-right corner of layer 1, 2, 3 within the same texture, on D3D12 we can implement this copy with 3 copies:
but when we want to copy from layer 0, 1, 2 to layer 0, 1, 2 within the same texture, D3D12 debug layer will report errors as the subresources in CopyTextureRegion() must be different. |
Imho it is weird to have a validation rules that disallow this copy (for a 2x2x3 2D array texture): encoder->copyTextureToTexture({
texture,
origin: [0, 0, 0]
}, {
texture,
origin: [1, 0, 0]
}, [1, 2, 2]) but not this one: encoder->copyTextureToTexture({
texture,
origin: [0, 0, 0]
}, {
texture,
origin: [1, 0, 1] // the only difference is the second 1
}, [1, 2, 2]) If I'm able to copy from the left side to the right side of multiple array layers, why am I able to do it for overlapping array layers, but only if they are staggered? Copying inside the same subresource can be useful when for example compacting a texture atlas, but I don't see a single usecase for copying array layers in a staggered manner like this. I think we should disallow it because the additional cases allowed don't seem to have much value, make the validation rules confusing and frustrating. |
- If |source|.{{GPUTextureCopyView/texture}} and |destination|.{{GPUTextureCopyView/texture}} are the same texture: | ||
- If the {{GPUTexture/[[dimension]]}} of |source|.{{GPUTextureCopyView/texture}} is {{GPUTextureDimension/2d}}: | ||
-|source|.{{GPUTextureCopyView/origin}}.[=Origin3D/z=] must not be equal to |destination|.{{GPUTextureCopyView/origin}}.[=Origin3D/z=]. | ||
- The region specified by |source|.{{GPUTextureCopyView/origin}} and |copySize|, and the region specified by |destination|.{{GPUTextureCopyView/origin}} and |copySize|, must not overlap. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the origin.z
is actually the array layer, it looks like this item totally covers the previous one. Should we just remove the previous 2 lines?
@Kangz I agree that it's not useful to copy Z-overlapping regions, even if we can do it by just iterating the layers. Let's disallow that for now. I.e. the PR says that the regions need to be disjoint, and that's the way to go. |
Actually this PR is to allow copying of Z-overlapping regions, as question that was raised while implementing more flexible T2T copies in Dawn. My understanding of the intent is that it makes the second example I gave pass validation. |
Resolved: Have more restrictions. Remove later if we find it's needed. |
I believe this needs revision (and need to figure out exactly what "More restrictions" is) |
Hi all the reviewers, now have we decided to keep the original statements in the SPEC instead of the changes in this PR? |
Ah, I think you're right. Thanks. |
WebGPU community has decided how to support color space conversion and update the spec. In that updating, it also add some new supported formats in copyExternalImageToTexture dst texture lists. This PR update the kValidTextureFormatsForCopyE2T to cover the new formats. And also update the compare logic to support 16-float comparation.
This patch intends to clarify the validation rules on the texture-to
-texture copies when the source and destination textures are the
same one.
cannot allow the source base array layer being equal to the
destination base array layer as D3D12 function CopyTextureRegion()
requires the source and destination resources must be different
subresources.
required in Vulkan SPEC.
💥 Error: 400 Bad Request 💥
PR Preview failed to build. (Last tried on Jun 1, 2020, 8:50 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 CSS Spec Preprocessor - CSS Spec Preprocessor is the web service used to build Bikeshed specs.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.