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

Skip to content

Merge GPUTextureCopyView.arrayLayer into .origin.z #730

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 4 commits into from
May 11, 2020
Merged

Merge GPUTextureCopyView.arrayLayer into .origin.z #730

merged 4 commits into from
May 11, 2020

Conversation

kainino0x
Copy link
Contributor

@kainino0x kainino0x commented Apr 28, 2020 •
edited by pr-preview bot
Loading

Similar to what was done for GPUTextureDescriptor in #613, I just missed it.

Preview | Diff

@kainino0x
Merge GPUTextureCopyView.arrayLayer into .origin.z
52476ea 
Similar to what was done for GPUTextureDescriptor in gpuweb#613, I just missed
it.
@Kangz
Copy link
Contributor

Kangz commented Apr 28, 2020

I'd like to discuss the GPUTextureDescriptor.arrayLayerCount removal again. While trying to implement the change in Dawn, things got fairly confusing, and I believe @kvark got feedback from users of wgpu that they were confused too. I think we should revert the arrayLayerCount removal because it makes semantic less clear for texture creation, and consistency requires other changes like this one or #299 that make semantic less explicit.

Also none of the native APIs do this and instead they have an explicit array layer count:

@kainino0x
Copy link
Contributor Author

Let's discuss it. If we revert then I'd like to do #520 instead.

@Kangz
Copy link
Contributor

Kangz commented Apr 28, 2020

After some offline discussion, looking copies available in all APIs, and remembering that 1D array textures exist (we should maybe have them in WebGPU), I'd like to retract my previous concern.

What we can do is better educate users and have nice representations of 2D array that looks like a cube and 1D array that looks like a plan.

@kainino0x
Copy link
Contributor Author

kainino0x commented Apr 28, 2020 •
edited
Loading

An example of spec complexity arising from separating arrayLayer from depth:

  • The number of slices of the extent (for 3D) or layers of the srcSubresource (for non-3D) must match the number of slices of the extent (for 3D) or layers of the dstSubresource (for non-3D)
  • If either of the calling command’s srcImage or dstImage parameters are of VkImageType VK_IMAGE_TYPE_3D, the baseArrayLayer and layerCount members of the corresponding subresource must be 0 and 1, respectively

from https://www.khronos.org/registry/vulkan/specs/1.1/html/vkspec.html#VUID-VkImageCopy-extent-00140

  • If both srcImage and dstImage are of type VK_IMAGE_TYPE_2D then extent.depth must be 1
  • If the calling command’s srcImage is of type VK_IMAGE_TYPE_2D, and the dstImage is of type VK_IMAGE_TYPE_3D, then extent.depth must equal to the layerCount member of srcSubresource
  • If the calling command’s dstImage is of type VK_IMAGE_TYPE_2D, and the srcImage is of type VK_IMAGE_TYPE_3D, then extent.depth must equal to the layerCount member of dstSubresource

from just below that, https://www.khronos.org/registry/vulkan/specs/1.1/html/vkspec.html#VUID-VkImageCopy-srcImage-01790

@kainino0x
Copy link
Contributor Author

[editors call] Since this change is conceptually part of #613, which was approved by the group, merging without rehashing the discussion.

@kainino0x
Copy link
Contributor Author

Actually, now that we have landed copyTextureToTexture, this change needs more complete edits. While I was at it I fixed the subresource range set issue and added Origin3D.

@kainino0x kainino0x requested a review from kvark May 4, 2020 23:01
@kainino0x kainino0x mentioned this pull request May 5, 2020
Merged
kvark
kvark requested changes May 5, 2020
View reviewed changes
Copy link
Contributor

@kvark kvark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few minor edits required, looks good in general!

spec/index.bs
is {{GPUTextureDimension/"2d"}}:
- For each |arrayLayer| of the |copySize|.[=Extent3D/depth=] [=array layers=]
starting at |textureCopyView|.{{GPUTextureCopyView/origin}}.[=Origin3D/z=]:
- The [=subresource=] of |textureCopyView|.{{GPUTextureCopyView/texture}} at
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it's going to be cleaner to define a subresource in a function manner, i.e. [$subresource$](texture, mipmapLevel, arrayLayer). This is just an idea, not something you have to fix here.

spec/index.bs

An <dfn dfn>Origin3D</dfn> is a {{GPUOrigin3D}}.
[=Origin3D=] is a spec namespace for the following definitions:
<!-- This is silly, but provides convenient syntax for the spec. -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's silly is that we allow both sequence and dictionary representation here, even though sequences are more heavy and can be trivially converted to a dictionary on the user side. This whole section wouldn't need to exist.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are sequences more heavy? On the syntax side they're much lighter at least.

As you know I still want to accept only sequence here, but if there's a strong preference we can change it back to dictionary-only. FWIW at some point I do want to consider making it so different users of this type have different defaults (e.g. some require all 3, some require only 2 or 1).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, because sequence is a separate object in JS. For this reason we wanted to avoid them in setVertexBuffers, for example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A dictionary is also a separate object though. We would avoid a dictionary in setVertexBuffers too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed! Would there be a difference when coming from WASM though?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes actually, I keep forgetting about this. sequence allows a typed array, and actually I think any iterable (I just tried it with a Float32Array, and a generator (function*() { ... })() and those worked. Set didn't work but maybe it's supposed to.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So would it be correct to say that sequence is heavier for WASM case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it's slightly lighter. For WASM you can do any of:

  • { x: HEAPF32[i], y: HEAPF32[i + 1], z: HEAPF32[i + 2] } copy and construct dict
  • [ HEAPF32[i], HEAPF32[i + 1], HEAPF32[i + 2] ] copy and construct array
  • HEAPF32.slice(i, i + 3) create new Float32Array + ArrayBuffer and memcpy
  • HEAPF32.subarray(i, i + 3) create new Float32Array pointing to same ArrayBuffer

@kainino0x kainino0x mentioned this pull request May 11, 2020
Closed
@JusSn JusSn merged commit 5b22c22 into gpuweb:master May 11, 2020
haoxli pushed a commit to haoxli/gpuweb that referenced this pull request May 12, 2020
@kainino0x @haoxli
Merge GPUTextureCopyView.arrayLayer into .origin.z (gpuweb#730)
d72ac60 
* Merge GPUTextureCopyView.arrayLayer into .origin.z

Similar to what was done for GPUTextureDescriptor in gpuweb#613, I just missed
it.

* update more text as needed

* address comments
@kainino0x kainino0x deleted the tcv-arraylayer branch May 13, 2020 17:10
JusSn pushed a commit to JusSn/gpuweb that referenced this pull request Jun 8, 2020
@kainino0x
Merge GPUTextureCopyView.arrayLayer into .origin.z (gpuweb#730)
533023f 
* Merge GPUTextureCopyView.arrayLayer into .origin.z

Similar to what was done for GPUTextureDescriptor in gpuweb#613, I just missed
it.

* update more text as needed

* address comments
JusSn pushed a commit to JusSn/gpuweb that referenced this pull request Jun 8, 2020
@kainino0x
Merge GPUTextureCopyView.arrayLayer into .origin.z (gpuweb#730)
5898d4c 
* Merge GPUTextureCopyView.arrayLayer into .origin.z

Similar to what was done for GPUTextureDescriptor in gpuweb#613, I just missed
it.

* update more text as needed

* address comments
ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this pull request Sep 6, 2022
@sarahM0
wgsl abs() built-in function execution test (gpuweb#730)
5434342
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kvark kvark kvark approved these changes

@JusSn JusSn JusSn approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@kainino0x @Kangz @kvark @JusSn