-
Notifications
You must be signed in to change notification settings - Fork 335
Add Queue/writeTexture method #761
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
Conversation
This would be nice ergonomics and like you pointed out, it would mostly reuse the implementation of 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. |
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.
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.
@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 |
|
Provide some feedbacks #700 (comment) may be related to this. |
Resolution: accepted writeTexture() |
Thank you for the quick reviews! |
Committed my suggestions plus added |
Looks good, thank you! |
* 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]>
* 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]>
…b#761) * Add WGSL auto-generated documentation and how to contribute steps. * Add builtin.ts to docs/helper_index.txt
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
orwriteBuffer
, and manage their staging buffers, or we could expose thisGPUQueue.writeBuffer
function.The convenience benefit has two sides:
writeBuffer
.bytesPerRow
alignment of 256, which I'm sure many users will hit otherwiseBasically, 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 aGPUTexture
, and then initialize it viaQueue.writeTexture
.How to implement it
The implementation very light when based on
writeBuffer
, with only 2 small differences:bytesPerRow
to 256vkCmdCopyBufferToImage
.Preview | Diff