Conversation
|
Sorry y'all. :) |
|
Title says GPUQueue.mapBuffer but the PR has GPUBuffer.map? |
|
Haha, I got bit by |
kvark
left a comment
There was a problem hiding this comment.
Left some notes here. What's also critically missing is a description of differences with #605 in the PR (not the spec).
One important difference that I noticed so far is that there are no limitations on what buffers can be mappable at all, while #605 requires them to basically be staging buffers. This changes the semantics or the API and implementation complexity quite a bit.
|
|
||
| If size is zero, {{GPUBuffer/map}} treats it as an effective size of buffer-length-starting-at-offset. | ||
| Effective size of a mapping must not be zero. | ||
| {{GPUBuffer/map}} fails (and rejects) if the range overlaps with already-mapped ranges in GPUBuffer. |
| If |getMappedRange| succeeds, the subrange is set to the "visible" state. | ||
|
|
||
| It is an error if |unmapRange| specifies range that: | ||
| * Is not "mapped" or "visible". |
There was a problem hiding this comment.
does a range even have a single "state" in this approach? If I map 0..10 but then 0..4 become "visible", then the whole 0..10 doesn't have a single state that we can talk about
| If size is zero, {{GPUBuffer/map}} treats it as an effective size of buffer-length-starting-at-offset. | ||
| Effective size of a mapping must not be zero. | ||
| {{GPUBuffer/map}} fails (and rejects) if the range overlaps with already-mapped ranges in GPUBuffer. | ||
| {{GPUBuffer/map}}'s Promise resolves before {{GPUFence/onCompletion}}'s Promise for any |
There was a problem hiding this comment.
Let's consider this scenario:
- user submits work X on part A of a buffer
- user requests to map part B of the buffer, B doesn't intersect with A
- user submits work Y on part A of the buffer
The rules you specify basically guarantee that the mapping resolves while part A is still being used by the GPU. So this proposal requires the implementation to track buffer sub-ranges independently. I think it's essential to write it down clearly (i.e. what the implementations are supposed to do) instead of implying.
|
Closing since we agreed on a mapAsync similar to #605 |
order of conditions was flipped in WGSL
Preview | Diff