more robust gpu image use #12606
Merged
more robust gpu image use #12606
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
robtfm
added
A-Rendering
JMS55
approved these changes
Apr 7, 2024
mockersf
approved these changes
Apr 7, 2024
mockersf
added
the
S-Ready-For-Final-Review
superdump
approved these changes
Apr 7, 2024
github-merge-queue bot
pushed a commit
that referenced
this pull request
Apr 26, 2024
# Objective allow throttling of gpu uploads to prevent choppy framerate when many textures/meshes are loaded in. ## Solution - `RenderAsset`s can implement `byte_len()` which reports their size. implemented this for `Mesh` and `Image` - users can add a `RenderAssetBytesPerFrame` which specifies max bytes to attempt to upload in a frame - `render_assets::<A>` checks how many bytes have been written before attempting to upload assets. the limit is a soft cap: assets will be written until the total has exceeded the cap, to ensure some forward progress every frame notes: - this is a stopgap until we have multiple wgpu queues for proper streaming of data - requires #12606 issues - ~~fonts sometimes only partially upload. i have no clue why, needs to be fixed~~ fixed now. - choosing the #bytes is tricky as it should be hardware / framerate dependent - many features are not tested (env maps, light probes, etc) - they won't break unless `RenderAssetBytesPerFrame` is explicitly used though --------- Co-authored-by: IceSentry <[email protected]> Co-authored-by: François Mockers <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
Objective
make morph targets and tonemapping more tolerant of delayed image loading.
neither of these actually fail currently unless using a bespoke loader (and even then it would be rare), but i am working on adding throttling for asset gpu uploads (as a stopgap until we can do proper asset streaming) and they break with that.
Solution
when a mesh with morph targets is uploaded to the gpu, the prepare function uploads the morph target texture if it's available, otherwise it uploads without morph targets. this is generally fine as long as morph targets are typically loaded from bytes (in gltf loader), but may fail for a custom loader if the asset server async-loads the target texture and the texture is not available yet. the mesh fails to render and doesn't update when the image is loaded
-> if morph targets are specified but not ready yet, retry mesh upload next frame
tonemapping
unwraps on the lookup table image. this is never a problem since the image is added viainclude_bytes!, but could be a problem in future with asset gpu throttling/streaming.-> if the lookup texture is not yet available, use a fallback
-> in the node, check if the fallback was used before caching the bind group