Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upImplement GPUBuffer.getMappedRange() #27126
Conversation
highfive
commented
Jun 30, 2020
|
Heads up! This PR modifies the following files:
|
highfive
commented
Jun 30, 2020
|
|
|
Looks reasonable overall! Noted a few small things |
|
Thank you, looks great! |
| (m_end - offset) as usize, | ||
| m_info.mapping.borrow_mut()[offset as usize..m_end as usize].as_mut_ptr() as _, | ||
| Some(free_func), | ||
| Rc::into_raw(m_info.mapping.clone()) as _, |
This comment has been minimized.
This comment has been minimized.
kvark
Jul 1, 2020
Member
I was looking at this piece a bit. So this would keep the memory for the ArrayBuffer around until it's GC-ed.
I think it's totally fine to land in this stage. Just wanted to note that for the end game, we probably want to "detach" the array buffer on unmap(), so that any access to its contents would be invalid and trigger an exception. Perhaps, we could leave a comment somewhere about this TODO
This comment has been minimized.
This comment has been minimized.
kunalmohan
Jul 1, 2020
•
Author
Collaborator
We already detach the actual array buffers(which are the only ones exposed to the user) on unmap. We also drop the Rc pointer for this array buffer in free_func and set the map_info to None (so we drop all Rc pointers on unmap). What else are we missing here? Should the contents be set to ptr::null() in free_func?
|
@bors-servo r+ |
|
|
Implement GPUBuffer.getMappedRange() <!-- Please describe your changes on the following line: --> The new fields added to `GPUBuffer` are- 1. `mapping`- This is the buffer data. This is not directly exposed to user and is refcounted to keep track of the number of `ArrayBuffer`s that point to the content in it. 2. `mapping_range`- The range of mapped portion of the GPUBuffer. 3. `mapped_ranges`- Ranges that the various `ArrayBuffer`s expose to the user. Used for validation of `getMappedRange()` 4. `js_buffers`- Actual `ArrayBuffer`s that expose the data to the user. They are detached on unmap. 5. `map_promise`- Promise that represents the pending mapping. This PR also changes the order of the exit of threads. WebGL thread is responsible for sending `Exit` message to WebRender and therefore should be exited after WebGPU threads. r?@kvark @jdm --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [ ] These changes fix #___ (GitHub issue number if applicable) <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
|
|
@bors-servo r+ |
|
|
|
|
kunalmohan commentedJun 30, 2020
The new fields added to
GPUBufferare-mapping- This is the buffer data. This is not directly exposed to user and is refcounted to keep track of the number ofArrayBuffers that point to the content in it.mapping_range- The range of mapped portion of the GPUBuffer.mapped_ranges- Ranges that the variousArrayBuffers expose to the user. Used for validation ofgetMappedRange()js_buffers- ActualArrayBuffers that expose the data to the user. They are detached on unmap.map_promise- Promise that represents the pending mapping.This PR also changes the order of the exit of threads. WebGL thread is responsible for sending
Exitmessage to WebRender and therefore should be exited after WebGPU threads.r?@kvark @jdm
./mach build -ddoes not report any errors./mach test-tidydoes not report any errors