StagingBelt: check for free chunks in the receiver
as well as free_chunks
.
#2906
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.
Checklist
cargo clippy
.RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown
if applicable.Description
Previously, chunks would only be taken from the GPU callback receiver and put on
free_chunks
duringfinish()
. So, there might be chunks that are actually available for use but wouldn't be used.Now, we consult the receiver whenever we're about to consult the
free_chunks
, so the reuse of chunks will be as good as possible (given the application's uses of operations that triggermap_async
callbacks).Testing
StagingBelt has no automated tests, so I ran the
examples/skybox
and my own application that usesStagingBelt
, and confirmed that there were no errors or noticeable negative performance consequences.I don't have any proof that this is ever a performance improvement in practice; it just feels like low-hanging fruit.