fix(core): use BufferMapState::Active for any BufferUsages::MAP_* flags
#8426
+9
−7
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
2 times, most recently
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. 😖 |
teoxoy
reviewed
Oct 27, 2025
| let buffer = Buffer { | ||
| raw: Snatchable::new(buffer), | ||
| device: self.clone(), | ||
| usage: desc.usage, |
There was a problem hiding this comment.
To address the GL error: I don't think we are passing the right usage to HAL, when we create the buffer its usage should include MAP_WRITE if mapped_at_creation == true.
There was a problem hiding this comment.
I think this'll do it: ac38c82
WDYT?
There was a problem hiding this comment.
Actually we need to set the MAP_WRITE flag only when MAP_READ and mapped_at_creation are present. So that we don't set it on GPU-backed buffers.
ErichDonGubler
force-pushed
the
erichdongubler-push-dazed-adept-horse
branch
from
10d652f to
146f37e
Compare
ErichDonGubler
commented
Oct 27, 2025
This comment was marked as resolved.
This comment was marked as resolved.
|
Hmm, some WebGL tests failed with ac38c82 with recursive snatch log errors, but I'm not sure that they're related to this PR. Dump of the error log:I guess we'll see if they reproduce with 34a3316, which should be the same repository state. EDIT: It does. Ugh. 😩 |
… 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
34a3316 to
684859e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.