-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More robust handling of maximum texture size for non-color data, slight perf improvements for large point clouds #5229
Merged
Conversation
This file contains 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
…riteGpuReadBuffer` directly
Measuring about 0.3ms speedup compared to 0.13. A bit hard to measure though given that overhead moved the point cloud draw data creation to `point_cloud_builder`
Wumpf
added
🔺 re_renderer
affects re_renderer itself
🚀 performance
Optimization, memory use, etc
🚜 refactor
Change the code, not the functionality
include in changelog
labels
Feb 19, 2024
Wumpf
changed the title
More robust handling of maximum texture size for non-color data, slight perf improvements for point clouds
More robust handling of maximum texture size for non-color data, slight perf improvements for large point clouds
Feb 19, 2024
(tested on firefox webgl, chrome webgpu and ofc native) |
emilk
approved these changes
Feb 20, 2024
Wumpf
added a commit
that referenced
this pull request
Feb 20, 2024
### What * Fixes #1398 * Follow-up of #5229 * same changelog applies which is why I left it out: again this makes handling of I tried a scene with a very large number of line strips and the performance is about the same before after, hard to judge though since before perf was not very stable and both before/after we have a huge profiler overhead - there's some low hanging fruit in better batching how we add batches of line strips, but I left this intentionally out of this pr. Similar to the previous PR I also artificially lowered the data size texture limit to check that the error messages and truncating of lines works gracefully. ### Checklist * [x] I have read and agree to [Contributor Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md) * [x] I've included a screenshot or gif (if applicable) * [x] I have tested the web demo (if applicable): * Using newly built examples: [app.rerun.io](https://app.rerun.io/pr/5240/index.html) * Using examples from latest `main` build: [app.rerun.io](https://app.rerun.io/pr/5240/index.html?manifest_url=https://app.rerun.io/version/main/examples_manifest.json) * Using full set of examples from `nightly` build: [app.rerun.io](https://app.rerun.io/pr/5240/index.html?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json) * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG * [x] If applicable, add a new check to the [release checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)! - [PR Build Summary](https://build.rerun.io/pr/5240) - [Docs preview](https://rerun.io/preview/6d57ed6f6cfce86d82218a33994437fd4fdb637e/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/6d57ed6f6cfce86d82218a33994437fd4fdb637e/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
include in changelog
🚀 performance
Optimization, memory use, etc
🔺 re_renderer
affects re_renderer itself
🚜 refactor
Change the code, not the functionality
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.
What
Point cloud builder uses now
DataTextureSource
for all its data.DataTextureSource
is now better at dealing with the max texture size: data writes are clamped ahead of time, meaning we no longer reserve memory for data that we can't write into the texture uponDataTexturesSource::finish
.This bubbled up now since
PointCloudBuilder
so far used a vec for positions and checked that against the maximum. The changes here leave the check in place, but makeDataTextureSource
reserving & writing clamp to the maximum and deal with this robustly even if high level data structures (likePointCloudBuilder
) fail to handle this.Artificially limiting the data texture size to 256 * 256 looks like this:
I tested performance before/after on these changes on two opf scenes on my mac to check for changes in perf and found the switch to using
DataTextureSource
for position/radius improved performance slightly:(numbers via performance metrics, release build)
Checklist
main
build: app.rerun.ionightly
build: app.rerun.io