Login: progress bar fills but reaching in-world takes 30-60 s #213

New issue

Closed

opened 2026-09-30 21:27:31 +00:00 by sky_line · 2 comments

sky_line commented

2026-09-30 21:27:31 +00:00

Owner

To investigate

Startup-state timing: log timestamps per LLStartUp state transition, especially the states after the bar fills: STATE_WORLD_WAIT, STATE_AGENT_SEND / AGENT_WAIT, STATE_INVENTORY_SEND, STATE_MISC, STATE_PRECACHE, STATE_WEARABLES_WAIT, STATE_CLEANUP. Find which one the time goes to.
Server or client: is the wait on a server reply (RegionHandshake, AgentMovementComplete, inventory skeleton / AIS, appearance / bake requests)? Or is it client work, such as Vulkan pipeline or shader compiles, texture/ingest startup, or the world sweep before first frame?
Comparison: check against Firestorm / LL viewer on the same account and region to see if it's server-side.
Precache: check whether STATE_PRECACHE / wearables wait is timing out (LL waits up to a fixed timeout for outfit/COF) rather than completing.
Progress bar: the bar filling long before the viewer is in-world is misleading on its own. Make its progress reflect the real remaining states.

Info

Reported on current main (post Beta 10).
Attach a Slipstream.log from a slow login for the state timeline.

After login the progress bar reaches full, but the viewer takes another 30-60 seconds to actually get in-world. This could be the server (region handshake, inventory or appearance fetch), but it needs tracking and attributing. ## To investigate - **Startup-state timing:** log timestamps per `LLStartUp` state transition, especially the states after the bar fills: STATE_WORLD_WAIT, STATE_AGENT_SEND / AGENT_WAIT, STATE_INVENTORY_SEND, STATE_MISC, STATE_PRECACHE, STATE_WEARABLES_WAIT, STATE_CLEANUP. Find which one the time goes to. - **Server or client:** is the wait on a server reply (RegionHandshake, AgentMovementComplete, inventory skeleton / AIS, appearance / bake requests)? Or is it client work, such as Vulkan pipeline or shader compiles, texture/ingest startup, or the world sweep before first frame? - **Comparison:** check against Firestorm / LL viewer on the same account and region to see if it's server-side. - **Precache:** check whether STATE_PRECACHE / wearables wait is timing out (LL waits up to a fixed timeout for outfit/COF) rather than completing. - **Progress bar:** the bar filling long before the viewer is in-world is misleading on its own. Make its progress reflect the real remaining states. ## Info - Reported on current main (post Beta 10). - Attach a Slipstream.log from a slow login for the state timeline.

sky_line referenced this issue

2026-09-30 21:58:11 +00:00

Kakadu (KDU) JPEG2000 decoder: request access from Linden Lab (TPV), measure OpenJPEG decode cost first #217

sky_line referenced this issue from a commit

2026-10-01 01:20:10 +00:00

Translucent coloured shadows, RT ray budget from Shadow quality, async parallel pipeline compile

sky_line commented

2026-10-01 01:20:17 +00:00

Author

Owner

Root cause found and mostly fixed in 4d377811f1: the bar-full wait was the Vulkan renderer compiling ~97 graphics pipelines serially on the main thread after login; on a cold driver cache (every new release) that was 25-40 s here and longer on fewer cores. Now: pipelines compile in parallel on background threads, the renderer is created at the LOGIN SCREEN so the compile overlaps login, and dynamic cull/depth state lets 40 of the 97 come from a pipeline cache (57 real compiles). Cold-cache test: renderer ready 2 s before login completed. Leaving open to confirm with testers on lower-core machines (an 8-thread CPU may still wait briefly if the user logs in very fast).

Root cause found and mostly fixed in 4d377811f1: the bar-full wait was the Vulkan renderer compiling ~97 graphics pipelines serially on the main thread after login; on a cold driver cache (every new release) that was 25-40 s here and longer on fewer cores. Now: pipelines compile in parallel on background threads, the renderer is created at the LOGIN SCREEN so the compile overlaps login, and dynamic cull/depth state lets 40 of the 97 come from a pipeline cache (57 real compiles). Cold-cache test: renderer ready 2 s before login completed. Leaving open to confirm with testers on lower-core machines (an 8-thread CPU may still wait briefly if the user logs in very fast).

sky_line commented

2026-10-04 03:39:02 +00:00

Author

Owner

Closing: not seen since world pipelines started compiling (and being cached on disk) while the login screen is up, so the post-login wait for pipeline compiles is gone. Commit 0ae81a7445 (persistent pipeline cache + progress-screen hold), shipped in v1.0.0-beta.1. Reopen if the 30-60 s post-login wait comes back.

Closing: not seen since world pipelines started compiling (and being cached on disk) while the login screen is up, so the post-login wait for pipeline compiles is gone. Commit 0ae81a7445 (persistent pipeline cache + progress-screen hold), shipped in v1.0.0-beta.1. Reopen if the 30-60 s post-login wait comes back.

sky_line closed this issue

2026-10-04 03:39:02 +00:00

sky_line referenced this issue from a commit

2026-10-05 21:02:03 +00:00

VK: cap parallel pipeline compiles by driver + free RAM; persist the cache while compiling (#462)

sky_line referenced this issue from a commit

2026-10-06 09:43:21 +00:00

VK: cap parallel pipeline compiles by driver + free RAM; persist the cache while compiling (#462)