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

Skip to content

Conversation

kvark
Copy link
Contributor

@kvark kvark commented May 7, 2020

This is the second half of #509 (which is now closed), improved and cleaned up, following #749.

I also left a few "Issue" entries in the spec as well as filed #760 in spots that I noticed to require improvement, but not directly related to this PR.

Why I think this is needed

Textures internal representation is not portable, or even open, so the only way to get data there from the CPU is via a copy operation. This is something the majority of our applications will be doing. When doing this copy, the users don't generally care about the contents in the staging buffer, since it's only used temporarily. We could either advise them to use mapAsync or writeBuffer, and manage their staging buffers, or we could expose this GPUQueue.writeBuffer function.

The convenience benefit has two sides:

  • no need to have staging buffers, unless the users want to opt into that specifically, just like with writeBuffer.
  • no need to worry about the bytesPerRow alignment of 256, which I'm sure many users will hit otherwise

Basically, this change makes the use case of rendering a textured quad (a sprite) extremely smooth in terms of data transfers (edit: but not the only this use case!). Users just load the image data into an ArrayBuffer (i.e. directly from a PNG, not worrying about the alignment), create a GPUTexture, and then initialize it via Queue.writeTexture.

How to implement it

The implementation very light when based on writeBuffer, with only 2 small differences:

  1. when copying data into the staging area, as well as calculating its size, the implementation needs to align bytesPerRow to 256
  2. when copy from the staging into the resource, the implementation would use the appropriate copy command, such as vkCmdCopyBufferToImage.

Preview | Diff

@Kangz
Copy link
Contributor

Kangz commented May 11, 2020

This would be nice ergonomics and like you pointed out, it would mostly reuse the implementation of writeBuffer. However I'm not sure the use case is as crucial as writeBuffer because developers can use copyImageBitmapToTexture to put data in textures easily (especially for PNGs that would be decoded by the browser).

The spec text looks good but I don't have an opinion on whether we should include this or not, and if we include it, if it should be pre or post-MVP.

Copy link
Contributor

@kainino0x kainino0x left a comment

Choose a reason for hiding this comment

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

IIUC, the bytesPerRow issue is resolved by memcpying each row separately from sourceData into staging area?

Perf-wise that seems ok, but just want to make sure.

Spec LGTM, approval pending on having a discussion about this at the meeting.

@kvark
Copy link
Contributor Author

kvark commented May 12, 2020

@Kangz that's a totally fair point. I haven't considered the image bitmap as a solution to this, since I'm coming from the native land where such API doesn't exist. We got multiple requests to make texture uploads/updates easier.

Do you think copyImageBitmapToTexture effectively shadows writeTexture? Roughly, it seems to me that not everybody would want to go through image bitmaps to load their textures.

@Kangz
Copy link
Contributor

Kangz commented May 13, 2020

copyImageBitmapToTexture doesn't shadow all the usecases for writeTexture but it covers a lot of the cases where developers need convenience to get started using WebGPU. The easiest way to get a decoded texture is to create an ImageBitmap from an HTMLImageElement. More advanced developers will be using packed textures, or things like Basis, but if they do I think, it's likely they can deal with having staging buffers and bytesPerRow alignment constraints.

@shaoboyan
Copy link
Contributor

Provide some feedbacks #700 (comment) may be related to this.

@kainino0x
Copy link
Contributor

Resolution: accepted writeTexture()

@kvark
Copy link
Contributor Author

kvark commented May 19, 2020

Thank you for the quick reviews!
Rebased, resolved conversations, and did some more improvement on the copy view valid usage (see the last commit). Let me know if there is anything else missing! Otherwise, should be good to land, and then iterate further in follow-ups.

@kainino0x
Copy link
Contributor

Committed my suggestions plus added <div algorithm> to make var highlighting work. PTAL and feel free to merge.

@kvark
Copy link
Contributor Author

kvark commented May 19, 2020

Looks good, thank you!

@kvark kvark merged commit cc74459 into gpuweb:master May 19, 2020
@kvark kvark deleted the write-texture branch May 19, 2020 22:58
JusSn pushed a commit to JusSn/gpuweb that referenced this pull request Jun 8, 2020
* Add writeTexture

* Refactor writeXxx parameters

* Turn copy view validations into proper algorithms

* Apply suggestions from code review

* wrap writeBuffer and writeTexture in <div algorithm>

Co-authored-by: Kai Ninomiya <[email protected]>
Co-authored-by: Kai Ninomiya <[email protected]>
JusSn pushed a commit to JusSn/gpuweb that referenced this pull request Jun 8, 2020
* Add writeTexture

* Refactor writeXxx parameters

* Turn copy view validations into proper algorithms

* Apply suggestions from code review

* wrap writeBuffer and writeTexture in <div algorithm>

Co-authored-by: Kai Ninomiya <[email protected]>
Co-authored-by: Kai Ninomiya <[email protected]>
ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this pull request Sep 6, 2022
…b#761)

* Add WGSL auto-generated documentation and how to contribute steps.
* Add builtin.ts to docs/helper_index.txt
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.

5 participants