fix(core): use BufferMapState::Active for any BufferUsages::MAP_* flags
#8426
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ErichDonGubler
changed the title
BufferMapState::Active for any BufferUsages::MAP_* flagsBufferMapState::Active for any BufferUsages::MAP_* flags
|
Hmmm…I'm not immediately sure how to fix the CI errors, which all seem to be on GL backends (incl. WebGL). I'm not familiar with GL backends, so I'm sure I'm doing something wrong with bookkeeping there, but not what that might be. |
ErichDonGubler
force-pushed
the
erichdongubler-push-dazed-adept-horse
branch
from
984c1ea to
60bd075
Compare
… flags For cases where a buffer is `mapped_at_creation`, our current implementation of `Buffer::create` initializes the buffer's internal state with `BufferMapState::Init` (which contains a staging buffer underneath the hood) for a descriptor requesting `MAP_READ` that is copied to a host-backed buffer . `MAP_WRITE` works a little differently, starting from the beginning with a host-backed buffer. `Init` does a buffer copy between the staging buffer and the host-backed buffer in the device's queue when the buffer is `unmap`ped. However, `Buffer::map_async` (correctly) assumes that a host-backed buffer need not wait for anything in the queue. This results in a bug where `map_async` doesn't actually wait long enough for the device queue to complete its operations before resolving. Oops! Up to the point where a buffer is unmapped after being mapped at creation, `MAP_READ`, `MAP_WRITE`, and even _non_-`MAP_*` buffers' capabilities are the same. That is, we should be able to get mutable slices for mapped ranges, no matter what. So, make `MAP_READ` just initialize its internal state in the same way as with `MAP_WRITE`.
ErichDonGubler
force-pushed
the
erichdongubler-push-dazed-adept-horse
branch
from
60bd075 to
10d652f
Compare
|
Going to mark this as ready for review. I'm not sure how to resolve CI yet, but at least the approach can be validated, and maybe a reviewer will know more than I do about how to resolve this. 😖 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Connections
MAP_READbuffers that aremapped_at_creation.Description
For cases where a buffer is
mapped_at_creation, our current implementation ofBuffer::createinitializes the buffer's internal state withBufferMapState::Init(which contains a staging buffer underneath the hood) for a descriptor requestingMAP_READthat is copied to a host-backed buffer .MAP_WRITEworks a little differently, starting from the beginning with a host-backed buffer.Initdoes a buffer copy between the staging buffer and the host-backed buffer in the device's queue when the buffer isunmapped. However,Buffer::map_async(correctly) assumes that a host-backed buffer need not wait for anything in the queue. This results in a bug wheremap_asyncdoesn't actually wait long enough for the device queue to complete its operations before resolving. Oops!Up to the point where a buffer is unmapped after being mapped at creation,
MAP_READ,MAP_WRITE, and even non-MAP_*buffers' capabilities are the same. That is, we should be able to get mutable slices for mapped ranges, no matter what. So, makeMAP_READjust initialize its internal state in the same way as withMAP_WRITE.Testing
Added
webgpu:api,operation,buffers,map:mapAsync,read:*, which is expected to fail in the first commit, and is resolved with the second commit.Squash or Rebase?
Rebase.