Skip to content
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

Primary & secondary generalized caching #1331

Open
teh-cmc opened this issue Feb 16, 2023 · 1 comment
Open

Primary & secondary generalized caching #1331

teh-cmc opened this issue Feb 16, 2023 · 1 comment
Labels
💬 discussion 📉 performance Optimization, memory use, etc 🔺 re_renderer affects re_renderer itself

Comments

@teh-cmc
Copy link
Member

teh-cmc commented Feb 16, 2023

Today, most of the compute power to render a frame goes into instantiating re_renderer primitives: deserializing all of the raw Arrow data that the store returns, and effectively turning it into actual GPU buffers that we can upload and render.

Querying the store and uploading the data to the GPU are actually fairly cheap: what's slow is to deserialize the raw component data, join everything together and finally build a set of primitives that the renderer can actually work with.

Since our datastore is an append-only and otherwise immutable datastructure (ignoring GC), it should be possible to maintain an LRU cache that maps a list of (Component, RowIndex) tuples to the resulting GPU buffer data.
This cache could then be re-used not only across frames, but also across views within a single frame:

  1. Query datastore, get list of (Component, RowIndex) tuples
  2. Check LRU cache using this list as key (and probably EntityPath etc)
  3. If it's a hit, feed that back to the renderer
  4. Otherwise, do the same as we do today and insert the result back into the LRU

This naturally handles out-of-order insertions as well as multi-threading due to everything being append-only.
The race condition when reading/writing to the cache across different views should be irrelevant since the mapping is deterministic.

This also fits nicely with the ideas expressed in #426.

Questions:

  • What about hover/picking and such? Prob need to cache some stuff for that too.
@teh-cmc teh-cmc added 💬 discussion 🔺 re_renderer affects re_renderer itself 📉 performance Optimization, memory use, etc labels Feb 16, 2023
@Wumpf
Copy link
Member

Wumpf commented Feb 16, 2023

What about hover/picking and such? Prob need to cache some stuff for that too.

Once we move to a model where we re-query hovered/selected objects in order to render them again for outlines instead of checking the selected-ness while processing, this might be less of a concern

@teh-cmc teh-cmc changed the title Caching GPU resources using their unique store indices as keys Generalized 1-frame caching Oct 12, 2023
@teh-cmc teh-cmc changed the title Generalized 1-frame caching Primary & secondary generalized caching Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💬 discussion 📉 performance Optimization, memory use, etc 🔺 re_renderer affects re_renderer itself
Projects
None yet
Development

No branches or pull requests

2 participants