Time control is now behind a RwLock, making recording config access non-mutable everywhere #4389
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
added
🚜 refactor
abey79
approved these changes
Nov 29, 2023
crates/re_time_panel/src/lib.rs
Outdated
Comment on lines
69
to
71
| // Naturally, many parts of the time panel need the time control. | ||
| // Copy it once, read/edit, and then write back at the end. | ||
| let mut time_ctrl = ctx.rec_cfg.time_ctrl.read().clone(); |
There was a problem hiding this comment.
I've tried very hard to figure out if this could lead to a race, e.g. some other place could write the current time that would the be overwritten (timeseries space view or play feature comes to mind), but I can't think of one really 🤷🏻♂️
There was a problem hiding this comment.
Yeah you're right, this is technically a very racy strategy 🤔
There was a problem hiding this comment.
Hmm I'm a bit torn now actually. If we have several parts of the viewer run in parallel and one of them is making any modifications to the time ctrl we would loose them.
There was a problem hiding this comment.
Too worried now that at some point someone does a secondary time affecting panel and gets ugly surprises. Pushed stuff to make it better, please have a look.
There was a problem hiding this comment.
Yeah, any kind of viewer-wide state behind a mutex is going to inevitably end up with nasty race conditions imo/ime.
We shouldn't ever modify anything beyond a system's local/private state while in the middle of a frame: we need a way to schedule these kinds of modifications so they run at the start of next frame imo.
There was a problem hiding this comment.
Yeah I fear your right, but I don't want to go through all of the necessary steps to go there for the time panel right now. Also double buffering like we do on selection/hover now is a good alternative, that's still very well behaved in all situations IF you're ok with reading potentially outdated data at all callsites
edit: okay yes double buffering is one of two strategies that does exactly what you promote, the other being to send messages that are queued up for the end of the frame
Wumpf
force-pushed
the
andreas/non-mut-rec_cfg
branch
from
af6636b
to
357b024
Compare
visible_history_highlight is now part of TimeControl
Wumpf
force-pushed
the
andreas/non-mut-rec_cfg
branch
from
357b024
to
0f103c9
Compare
abey79
approved these changes
Nov 29, 2023
emilk
reviewed
Nov 30, 2023
There was a problem hiding this comment.
An alternative to making it a lock is to do all mutations with commands sent over CommandSender, i.e. postponing them to the end of the frame.
It has some advantages: no need for .read() everywhere, no chance of deadlock, and the state of the world won't change during a frame.
Yes, this was already pointed out :). I'm leaning towards keeping the PR as is though in the interest of moving quickly |
Wumpf
added a commit
that referenced
this pull request
Dec 5, 2023
…peline/Shader/Layouts/etc.) (#4421) ### What * Prerequisite for #1325 * Followed by #4422 The dynamic resource pool (textures, buffers, bindgroups) was already interior mutable. The static resource pool (mostly append only pool) however, still required mutable access. This PR addresses this. The actual tricky part is the implications this has on the draw step: `wgpu::RenderPass<'a>` expects all passed in references to live for `'a`. This isn't much of a problem we have with resources from the dynamic resource pool since there the handles are actually Arcs to the underlying wgpu resources. However we can't do this with RenderPipelines (the only relevant static resource for this case) though since we want to be able to swap out what the handle points to for shader reloading. This means we need to hold the lock read lock on render pipelines for the entirety of the pass recording. This is quite nice and easy for our ViewBuilder draws (== individual space views), but hard for the "compositing step" where we draw into egui's render pass. This is solved by taking out all render pipelines of the lock and putting them back in at the start of the frame. Once wgpu lifts this restrictions we can simplify things a bit! (to be continued with follow-up PRs!) ### 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): * Full build: [app.rerun.io](https://app.rerun.io/pr/4421/index.html) * Partial build: [app.rerun.io](https://app.rerun.io/pr/4421/index.html?manifest_url=https://app.rerun.io/version) * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG - [PR Build Summary](https://build.rerun.io/pr/4421) - [Docs preview](https://rerun.io/preview/8e4b0d88d9d01df8121a84850b251c1840494695/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/8e4b0d88d9d01df8121a84850b251c1840494695/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html) --- Part of series towards more multithreading in the viewer! * #4387 * #4404 * #4389 * You are here ➡️ #4421 * #4422 * #4430
Wumpf
added a commit
that referenced
this pull request
Dec 5, 2023
…xt (#4422) ### What * Prerequisite for #1325 * Follow-up of #4421 * Followed by #4430 Make draw data (this is in essence resource submission to GPU! e.g. make pointcloud ready to render) an operation that doesn't require a mutable renderer context. Two pieces to this: * `FileResolver` resolve needs to be non-mut, this turned out to be trivial * `Renderer::get_or_create` had to be streamlined. Renderer creation is now done directly on the context and holding a renderer implies holding a read lock. Since Renderers are added **very** rarely, this isn't much of a limitation! This causes a large trickle of removing `&mut` and gets us _almost_ to having a non-mutable render context reference on the Viewer context! ### 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): * Full build: [app.rerun.io](https://app.rerun.io/pr/4422/index.html) * Partial build: [app.rerun.io](https://app.rerun.io/pr/4422/index.html?manifest_url=https://app.rerun.io/version * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG - [PR Build Summary](https://build.rerun.io/pr/4422) - [Docs preview](https://rerun.io/preview/5a1ad48f35f4cd28bb4dc4cd56f56ac289a50ab3/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/5a1ad48f35f4cd28bb4dc4cd56f56ac289a50ab3/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html) --- Part of series towards more multithreading in the viewer! * #4387 * #4404 * #4389 * #4421 * You are here ➡️ #4422 * #4430
Wumpf
added a commit
that referenced
this pull request
Dec 5, 2023
### What * Prerequisite for #1325 * Follow-up of #4422 Makes `ViewBuilder`'s draw method no longer require a mutable render context, thus no longer requiring a mutable frame state on the render context (which previously held the mutable viewbuilder!), thus finally lifting the need to store mutable references to the render context from the viewer context! Having a non-mut draw method on ViewBuilder is _mostly_ straight forward at this point. The main hurdle are render phases that so far consumed themselves on drawing because of readback textures (which are still self-consuming for good reasons). ### 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): * Full build: [app.rerun.io](https://app.rerun.io/pr/4430/index.html) * Partial build: [app.rerun.io](https://app.rerun.io/pr/4430/index.html?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json) - Useful for quick testing when changes do not affect examples in any way * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG - [PR Build Summary](https://build.rerun.io/pr/4430) - [Docs preview](https://rerun.io/preview/965d71c3723e74947e2d063372d51d9ae89cc9dd/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/965d71c3723e74947e2d063372d51d9ae89cc9dd/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html) --- Part of series towards more multithreading in the viewer! * #4387 * #4404 * #4389 * #4421 * #4422 * You are here ➡️ #4430
4 tasks
Wumpf
added a commit
that referenced
this pull request
Dec 5, 2023
### What * Prerequisite for #1325 * Follow-up of #4430 What it says on the tin! No additional review required, just waiting for rust ci to be sure :) ### 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): * Full build: [app.rerun.io](https://app.rerun.io/pr/4430/index.html) * Partial build: [app.rerun.io](https://app.rerun.io/pr/4430/index.html?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json) - Useful for quick testing when changes do not affect examples in any way * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG - [PR Build Summary](https://build.rerun.io/pr/4430) - [Docs preview](https://rerun.io/preview/cc13e9becf363d9f611cfc59c61b41d1135ef411/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/cc13e9becf363d9f611cfc59c61b41d1135ef411/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html) --- Part of series towards more multithreading in the viewer! * #4387 * #4404 * #4389 * #4421 * #4422 * #4430 * You are here ➡️ #4438
4 tasks
Wumpf
added a commit
that referenced
this pull request
Dec 11, 2023
### What * Fixes #1325 Two levels of parallism actually: * All context & part systems for a single space view each run in parallel * All space views now in parallel first setup their query and then kick of their (parallized!) system execution This gives us major speedups whenever: * There is several heavy systems in a scene (e.g. a lot of points and a lot of arrows) * There is several space views As such this is a very fundamental & widely applicable parallelization!  (a rather silly "points with arrows" scene duplicated a bunch of times. Note that we still don't have any caching, so all these space views might as well be animated individually!) <img width="1421" alt="image" src="https://github.com/rerun-io/rerun/assets/1220815/57e13e15-9d8f-4a30-bf74-d8174676986d"> (busy rayon worker threads!) Related things that are not parallel yet: * ui methods per space view (run one by one) * draw call recording (done as part of the ui method, but we could likely do this in parallel, only joining on these tasks when egui wants to queue up the command buffers) * processing _within_ a system depends on the system at hand. Today, only point cloud has some parallization ### 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): * Full build: [app.rerun.io](https://app.rerun.io/pr/4460/index.html) * Partial build: [app.rerun.io](https://app.rerun.io/pr/4460/index.html?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json) - Useful for quick testing when changes do not affect examples in any way * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG - [PR Build Summary](https://build.rerun.io/pr/4460) - [Docs preview](https://rerun.io/preview/cb7e9a9902bb9923ade41271ccc43ed01a2a4d33/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/cb7e9a9902bb9923ade41271ccc43ed01a2a4d33/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html) --- End of a series on refactors leading to this parallization: * #4387 * #4404 * #4389 * #4421 * #4422 * #4430 * #4438 * #4460 --------- Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
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
Checklist