Cache store: async reads for J2C, mesh, asset and cluster (use the reader/decode pools and priorities) #867

New issue

Open

opened 2026-10-19 09:55:27 +00:00 by sky_line · 0 comments

sky_line commented

2026-10-19 09:55:27 +00:00

Owner

Follow-up to #715. Only GPU-ready textures use the store's async read() with priorities. J2C (lltexturecache.cpp), mesh (llmeshdiskcache.cpp), assets (llfilesystemstore.cpp) and cluster LOD (llcleanclustercachestore.cpp) call readSync on their own threads. They bypass the new reader/decode pools, the priority queues and the scheduling stats.

Data

J2C store reads, first 10 min of a fully migrated session: p50 0.54 ms for about 21 KB reads, against 0.08 ms on the legacy texture cache. GPU-ready async reads in the same session averaged 0.24 ms disk + 0.24 ms decode.

Plan

Move each consumer to async read() with a completion. Map priorities:
- J2C: visible/near textures HIGH, prefetch LOW.
- Mesh: LOD the camera needs now HIGH.
- Cluster pages: by screen error.
- Assets: NORMAL, user-initiated URGENT.
Keep each consumer's thread model where it must stay synchronous (e.g. LLFileSystem API callers). There, add a fast path for small records (no handoff) and find what makes the 21 KB J2C readSync cost 0.5 ms (lock contention, hash over the payload, page cache misses, a copy).
Aging for NORMAL/LOW under sustained HIGH load (priority is strict today).
Ability to raise the priority of a pending read (store API), for textures that become visible while queued.

Acceptance

Per-kind latency (p50/p95/p99) at or below legacy for J2C, asset, mesh and cluster at the same scene.
Store stats show each kind's reads going through the queues with priorities.
No starvation: LOW reads still complete under a sustained burst.

Follow-up to #715. Only GPU-ready textures use the store's async `read()` with priorities. J2C (`lltexturecache.cpp`), mesh (`llmeshdiskcache.cpp`), assets (`llfilesystemstore.cpp`) and cluster LOD (`llcleanclustercachestore.cpp`) call `readSync` on their own threads. They bypass the new reader/decode pools, the priority queues and the scheduling stats. ## Data J2C store reads, first 10 min of a fully migrated session: p50 **0.54 ms** for about 21 KB reads, against 0.08 ms on the legacy texture cache. GPU-ready async reads in the same session averaged 0.24 ms disk + 0.24 ms decode. ## Plan - Move each consumer to async `read()` with a completion. Map priorities: - J2C: visible/near textures HIGH, prefetch LOW. - Mesh: LOD the camera needs now HIGH. - Cluster pages: by screen error. - Assets: NORMAL, user-initiated URGENT. - Keep each consumer's thread model where it must stay synchronous (e.g. LLFileSystem API callers). There, add a fast path for small records (no handoff) and find what makes the 21 KB J2C `readSync` cost 0.5 ms (lock contention, hash over the payload, page cache misses, a copy). - Aging for NORMAL/LOW under sustained HIGH load (priority is strict today). - Ability to raise the priority of a pending read (store API), for textures that become visible while queued. ## Acceptance - Per-kind latency (p50/p95/p99) at or below legacy for J2C, asset, mesh and cluster at the same scene. - Store stats show each kind's reads going through the queues with priorities. - No starvation: LOW reads still complete under a sustained burst.

sky_line added the

perf

label

2026-10-19 09:55:27 +00:00

sky_line added this to the Slipstream project

2026-10-19 09:55:27 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sky_line/Slipstream#867

No description provided.

Rows
Columns