Commit 10d652f
committed
fix(core): use
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`.BufferMapState::Active for any BufferUsages::MAP_* flags1 parent 73a1a40 commit 10d652f
2 files changed
+5
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
4 | 4 | | |
5 | 5 | | |
6 | 6 | | |
7 | | - | |
| 7 | + | |
8 | 8 | | |
9 | 9 | | |
10 | 10 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
990 | 990 | | |
991 | 991 | | |
992 | 992 | | |
993 | | - | |
| 993 | + | |
| 994 | + | |
| 995 | + | |
| 996 | + | |
994 | 997 | | |
995 | 998 | | |
996 | 999 | | |
| |||
0 commit comments