Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

Jiawei-Shao
Copy link
Contributor

@Jiawei-Shao Jiawei-Shao commented Jun 1, 2020

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 function CopyTextureRegion()
    requires the source and destination resources must be different
    subresources.
  • the copy source and destination region must not overlap as is
    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.

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.
@Jiawei-Shao
Copy link
Contributor Author

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:

  • from layer 0 to layer 1
  • from layer 1 to layer 2
  • from layer 2 to layer 3

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.

@Kangz
Copy link
Contributor

Kangz commented Jun 1, 2020

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.
Copy link
Contributor

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?

@kvark
Copy link
Contributor

kvark commented Jun 1, 2020

@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.

@Kangz
Copy link
Contributor

Kangz commented Jun 1, 2020

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.

@kainino0x
Copy link
Contributor

Resolved: Have more restrictions. Remove later if we find it's needed.

@kainino0x
Copy link
Contributor

I believe this needs revision (and need to figure out exactly what "More restrictions" is)

@Jiawei-Shao
Copy link
Contributor Author

Hi all the reviewers, now have we decided to keep the original statements in the SPEC instead of the changes in this PR?

@kainino0x
Copy link
Contributor

Ah, I think you're right. Thanks.

@kainino0x kainino0x closed this Jun 9, 2020
ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this pull request Sep 6, 2022
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.
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.

4 participants