CesiumGS / CesiumGS/cesium-native

Schedule the "main thread" part of tile loading more intentionally

Open
#507 1 comment 1 reaction 0 assignees View on GitHub
performance research
Dominant language
C++
Stars
623
Forks
277
PR merge metrics
No merged PRs in 30d

Description

Currently, the process of loading a tile is split into two parts:

# Future-based load pipeline

This happens almost entirely in a worker thread, and consists of:

1. A network request to get the tile content.
2. Parsing of the tile content.
3. Loading additional network resouces (e.g. textures external to the glTF).
4. Decoding images (JPG, KTX2, etc)
5. Decoding geometry (Draco, etc.)
6. Creating "load thread" renderer (e.g. Unreal) resources.

At the end of this process, the Tile is in the `ContentLoaded` state.

# Main thread update

This happens during tile selection in the main thread. Whenever we visit a tile in the `ContentLoaded` state, we do some additional processing and immediately (synchronously) move it to the `Done` state. The work done here consists of:

7. Updating the main-thread Tile data structure with new information loaded in the background (e.g. new child tiles, new bounding volume).
8. Creating "main thread" renderer (e.g. Unreal) resources.

#473 suggests separating step 1 from the rest, so that we can, say, have 20 network requests in flight at once but use a smaller number of threads for the CPU work in steps 2-6.

But this issue is about step 8. cesium-native basically assumes that `ContentLoaded` and `Done` are equivalent for selection purposes, because a `ContentLoaded` tile can and will be synchronously moved to `Done`. We should allow more flexibility in _when_ this happens. We don't need to do it for every tile we visit; only tiles that we're actually going to render. And conversely, too many tiles sometimes hit the `ContentLoaded` state all at once, causing noticeable rendering pauses as we create renderer resources (including uploading data to the GPU) all at once.

With more flexibility, we can avoid eagerly creating GPU resources for tiles we're unlikely to need. And we can also throttle and prioritize resource creation to avoid major frame rate drops.

Contributor guide

Open the contributing guide

Research direction

Start with the tile-selection path and the ContentLoaded-to-Done transition described in the issue. Trace how main-thread renderer resources are created, then determine how creation can be limited to tiles that will render and throttled or prioritized. Done means resource creation no longer happens eagerly for every visited tile and avoids large bursts that cause rendering pauses.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
computer-graphics, performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.