Lift point cloud size limitations #5192
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
Wumpf
commented
Feb 14, 2024
Comment on lines
249
to
251
| // TODO(andreas/cmc): Use cached code path for this. | ||
| // This is right now a bit harder to do and requires knowing all queried components. | ||
| // The only thing we really want to pass here are the POV components. |
There was a problem hiding this comment.
cc @teh-cmc maybe this is easier than I thought? Had trouble using the cache here and figured it's not that important anyways for my usecases (profiler says it really isn't)
There was a problem hiding this comment.
If you're not deserializing nor joining anything you are much better off with a raw query anyway 👍
|
resolved |
emilk
requested changes
Feb 14, 2024
…exture sizes, mostly for clarity
Wumpf
commented
Feb 14, 2024
emilk
approved these changes
Feb 14, 2024
|
tested on Chrome & Firefox on Windows with a bunch of point containing scenes. seems all fine |
7 tasks
Wumpf
added a commit
that referenced
this pull request
Feb 19, 2024
### What * follow-up of #5192 * Fixes #3076 * Fixes #4844 * _technically_ there's still limits (see #5192 ) but they are machine dependent making this relatively hard to query. Overall I'd argue we removed the previous limits so there's no need for this in the original sense. <img width="1252" alt="image" src="https://github.com/rerun-io/rerun/assets/1220815/512be197-9817-4f5a-8054-e3661346d361"> (note that we haven't spend a lot of time optimizing the collection of lines, large amounts of lines don't perform all that well so far) Applies the same principles as on the previous PR that fixes the point cloud limits. The key difference here is that we use lines in *a lot* of places, making this a bigger refactor than originally assumed. --- ~The need to know both strip & vertex count for lines ahead of time is a bit problematic and isn't always as easy as it was with points. We err on the side of generating more draw data bundles, but to limit this (a single drawdata for a single line is extremely wasteful as we have to allocate a bunch of textures, buffers, bind groups, etc. etc.) I had to introduce `LineDrawableBuilderAllocator` which is a very simplistic Vec-like allocator (minus the increase in size) for `LineDrawableBuilder` (previously called `LineStripSeriesBuilder`). I'm not super happy with this construct overall, but it's the best I could come up with in the short-term and things seem to be fairly robust and at least not overly complicated.~ ~In the future it would be nice to reconcile `LineDrawableBuilderAllocator` and `LineDrawableBuilder` into a single construct, likely still with the limitations that the size of a batch (think named unit with a transform) needs to be known ahead of time, which is practically always the case!~ --- Second iteration: There's now `DataTextureSource` (ideas for better names?) which is essentially a thing where you can throw data in and get a data texture out! It handles all the copies and dynamic sizings for you. This makes everything awesome because now we can handle `reserve` call just as an optimization without requiring them and without being on a bad path if you don't! <3 ### 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/5207/index.html) * Using examples from latest `main` build: [app.rerun.io](https://app.rerun.io/pr/5207/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/5207/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)! * [x] Test misc examples on WebGL * [x] Test misc examples on WebGPU - [PR Build Summary](https://build.rerun.io/pr/5207) - [Docs preview](https://rerun.io/preview/012ab21d8acbf86f8d45bfdba3737f8ebe989784/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/012ab21d8acbf86f8d45bfdba3737f8ebe989784/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
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
Removes the old limitation of 4mio points caused by fixed "data texture" size.
We now allocate dynamically for the needed amount of points. This means that we use less memory when there's less points and support as many points in a single
DrawDataas the maximum texture size. This is at least 16.5mio points on mobile webgl (4096 is a common max texture size on Android) and about 265mio points on a typical desktop machine & WebGPU (common max texture size is 16k).With this change we share a single
DrawDataper visualizer execution, meaning the limit applies to the total of each 2D & 3D points in a single space view.Scene with 35 mio points. Renders on my desktop with a bit under 300ms per frame since we still re-upload data every frame.
Note that this change is also the first step towards secondary caching, i.e. not re-uploading (and preparing) all the data for the gpu every frame: we can now use as many independent point cloud draw data as we want at a relatively small allocation & bind group setting overhead without having to fear excessive memory use. (I haven't measured, but the overhead for new draw data shouldn't be entirely insignificant, which is why I still keep the number down in this PR, putting the results an entire visualizer a single one)
Line renderer limitations will be addressed in a follow-up PR.
Checklist
mainbuild: app.rerun.ionightlybuild: app.rerun.io