[viewer] [crash] Crash: high ram usage and no rendering

slipstream-reports commented

2026-10-05 19:00:14 +00:00

Collaborator

Source: in-viewer report (Help > Report Bug)

Reporter (avatar name as given; not verified):

Inari Demonpaws

Filed after a crash. Previous session ended with:

Previous session crashed (internal error)

System

Version: 1.0.0.11
Channel: Slipstream Release
OS: Microsoft Windows 11 64-bit (Build 26300.9457)
CPU: AMD Ryzen 9 5900X 12-Core Processor (3693.06 MHz)
Memory: 32685 MB
GPU: AMD Radeon RX 6800 XT
GPU driver: 32.0.21045.9003
Vulkan: 1.4.315; ray tracing: enabled
Window: 3840x2019
Settings:
  AlchemyRenderTonemapType = 1
  RenderDeferredSSAO = 1
  RenderDepthOfField = 0
  RenderFPSLimit = 0
  RenderFSAAType = 2
  RenderFarClip = 128
  RenderHiDPI = 0
  RenderMaxTextureResolution = 2048
  RenderMaxVideoMemoryMB = 0
  RenderMirrors = 0
  RenderQualityPerformance = 4
  RenderReflectionProbeCount = 128
  RenderReflectionProbeDetail = 1
  RenderReflectionProbeLevel = 2
  RenderReflectionProbeResolution = 128
  RenderScreenSpaceReflections = 0
  RenderShadowDetail = 1
  RenderTransparentWater = 1
  RenderVKAOStandard = 1
  RenderVKAlphaShadingRate = 0
  RenderVKGodRays = 0
  RenderVKOpaqueShadingRate = 0
  RenderVKProjectorShadows = 1
  RenderVKRayTracing = 1
  RenderVKRenderScale = 1
  RenderVKShadowResolution = 1024
  RenderVKSunShadows = 1
  RenderVKTAA = 0
  RenderVKTextureCompression = 1
  RenderVKUpscaler = 0
  RenderVSyncEnable = 1
  RenderVolumeLODFactor = 1.5
  UIScaleFactor = 1

Description

first time usage, having high ram usage and nothing renders graphics wise.

Steps to reproduce

not given

_{Filed by the Slipstream report relay. The reporter's identity is not verified; system details are as sent by the reporter.}

**Source:** in-viewer report (Help > Report Bug) **Reporter** (avatar name as given; not verified): ~~~text Inari Demonpaws ~~~ **Filed after a crash.** Previous session ended with: ~~~text Previous session crashed (internal error) ~~~ ### System ~~~text Version: 1.0.0.11 Channel: Slipstream Release OS: Microsoft Windows 11 64-bit (Build 26300.9457) CPU: AMD Ryzen 9 5900X 12-Core Processor (3693.06 MHz) Memory: 32685 MB GPU: AMD Radeon RX 6800 XT GPU driver: 32.0.21045.9003 Vulkan: 1.4.315; ray tracing: enabled Window: 3840x2019 Settings: AlchemyRenderTonemapType = 1 RenderDeferredSSAO = 1 RenderDepthOfField = 0 RenderFPSLimit = 0 RenderFSAAType = 2 RenderFarClip = 128 RenderHiDPI = 0 RenderMaxTextureResolution = 2048 RenderMaxVideoMemoryMB = 0 RenderMirrors = 0 RenderQualityPerformance = 4 RenderReflectionProbeCount = 128 RenderReflectionProbeDetail = 1 RenderReflectionProbeLevel = 2 RenderReflectionProbeResolution = 128 RenderScreenSpaceReflections = 0 RenderShadowDetail = 1 RenderTransparentWater = 1 RenderVKAOStandard = 1 RenderVKAlphaShadingRate = 0 RenderVKGodRays = 0 RenderVKOpaqueShadingRate = 0 RenderVKProjectorShadows = 1 RenderVKRayTracing = 1 RenderVKRenderScale = 1 RenderVKShadowResolution = 1024 RenderVKSunShadows = 1 RenderVKTAA = 0 RenderVKTextureCompression = 1 RenderVKUpscaler = 0 RenderVSyncEnable = 1 RenderVolumeLODFactor = 1.5 UIScaleFactor = 1 ~~~ ### Description ~~~text first time usage, having high ram usage and nothing renders graphics wise. ~~~ ### Steps to reproduce _not given_ --- <sub>Filed by the Slipstream report relay. The reporter's identity is not verified; system details are as sent by the reporter.</sub>

slipstream-reports added the

triage

from-viewer

labels

2026-10-05 19:00:14 +00:00

sky_line commented

2026-10-05 19:07:41 +00:00

Owner

Triage, 2026-10-05 (from the reporter's two logs):

Login screen: window 3840×2019. RSS goes from about 25 MB to 14–20 GB within seconds, before login. Our Linux baseline at the same point is about 0.7 GB.
In-world (crashed session):
- System commit stays pinned at the limit for about 7 minutes. Windows grew the page file from 52 GB to 85 GB of commit, and less than 1.5 GB of commit stayed available. RSS looks small only because the memory was paged out.
- About 16 FPS, with "Low system memory, emergency downrezzing".
Crash: vkCreateGraphicsPipelines = VK_ERROR_OUT_OF_HOST_MEMORY → fatal handler. "Nothing renders" fits the same cause: the world's render pipelines couldn't be created.

Root-cause candidates:

Login splash media: every media frame re-uploads the whole texture through a brand-new host-visible staging buffer, about 32 MB at this window size. That's allocate-and-free churn on every frame.
More broadly, VkDeviceContext::createBuffer does a raw vkAllocateMemory per buffer, with about 130 call sites. Transient host-visible allocations in-world would churn the same way. World texture uploads already use a ring.

A fix is in progress: a persistent staging ring plus dirty-rect media uploads, an audit of the transient createBuffer sites, and per-kind host-memory counters in the log and in bug reports.

Workaround until it ships: keep the window smaller or non-maximized at the login screen.

Possibly related: #402 and #403 (RX 7600, 16 GB, Windows: a crash or multi-second freezes with two viewers running).

**Triage, 2026-10-05 (from the reporter's two logs):** - **Login screen:** window 3840×2019. RSS goes from about 25 MB to 14–20 GB within seconds, before login. Our Linux baseline at the same point is about 0.7 GB. - **In-world (crashed session):** - System commit stays pinned at the limit for about 7 minutes. Windows grew the page file from 52 GB to 85 GB of commit, and less than 1.5 GB of commit stayed available. RSS looks small only because the memory was paged out. - About 16 FPS, with "Low system memory, emergency downrezzing". - **Crash:** `vkCreateGraphicsPipelines = VK_ERROR_OUT_OF_HOST_MEMORY` → fatal handler. "Nothing renders" fits the same cause: the world's render pipelines couldn't be created. **Root-cause candidates:** 1. **Login splash media:** every media frame re-uploads the whole texture through a brand-new host-visible staging buffer, about 32 MB at this window size. That's allocate-and-free churn on every frame. 2. **More broadly, `VkDeviceContext::createBuffer` does a raw `vkAllocateMemory` per buffer**, with about 130 call sites. Transient host-visible allocations in-world would churn the same way. World texture uploads already use a ring. A fix is in progress: a persistent staging ring plus dirty-rect media uploads, an audit of the transient `createBuffer` sites, and per-kind host-memory counters in the log and in bug reports. **Workaround until it ships:** keep the window smaller or non-maximized at the login screen. Possibly related: #402 and #403 (RX 7600, 16 GB, Windows: a crash or multi-second freezes with two viewers running).

sky_line referenced this issue

2026-10-05 19:07:41 +00:00

[viewer] [crash] Crash: sudden crash while running Firestorm simultaneously #402

sky_line referenced this issue

2026-10-05 19:07:41 +00:00

[viewer] Massive performance hitch when running two Slipstream viewers at the same time #403

sky_line referenced this issue from a commit

2026-10-05 19:39:02 +00:00

VK: extract the texture staging ring into vk_stagering.h

sky_line referenced this issue from a commit

2026-10-05 19:39:02 +00:00

VK UI: staging ring + dirty-rect uploads for media textures (login OOM)

sky_line referenced this issue from a commit

2026-10-05 19:39:02 +00:00

Media: cap UI media texture updates at 30 Hz before login

sky_line referenced this issue from a commit

2026-10-05 19:39:02 +00:00

VK: bound texture staging when frames are not recorded / the ring is full

sky_line referenced this issue from a commit

2026-10-05 19:39:02 +00:00

VK: host-visible memory + allocation traffic instrumentation (hostmem)

sky_line referenced this issue from a commit

2026-10-05 19:39:02 +00:00

VK RT: keep one empty acceleration-structure chunk as a spare

sky_line referenced this issue from a commit

2026-10-05 19:39:02 +00:00

VK UI: RAM-scaled upload ring cap; never cache an empty converted texture

sky_line referenced this issue from a commit

2026-10-05 19:47:58 +00:00

VK: extract the texture staging ring into vk_stagering.h

sky_line referenced this issue from a commit

2026-10-05 19:47:58 +00:00

VK UI: staging ring + dirty-rect uploads for media textures (login OOM)

sky_line referenced this issue from a commit

2026-10-05 19:47:58 +00:00

Media: cap UI media texture updates at 30 Hz before login

sky_line referenced this issue from a commit

2026-10-05 19:47:58 +00:00

VK: bound texture staging when frames are not recorded / the ring is full

sky_line referenced this issue from a commit

2026-10-05 19:47:58 +00:00

VK: host-visible memory + allocation traffic instrumentation (hostmem)

sky_line referenced this issue from a commit

2026-10-05 19:47:58 +00:00

VK RT: keep one empty acceleration-structure chunk as a spare

sky_line referenced this issue from a commit

2026-10-05 19:47:58 +00:00

VK UI: RAM-scaled upload ring cap; never cache an empty converted texture

sky_line commented

2026-10-05 20:32:55 +00:00

Owner

Fix released in 1.0.1 (stable) and 1.1.0 Beta 2. It adds a staging ring for UI and media uploads, dirty-rectangle media uploads, caps the login page at 30 Hz, waits for room in the texture staging ring instead of spilling into one-off buffers, and stops staging from piling up on skipped frames. Reports now include a hostmem line. Reporter: please update and tell us whether memory stays flat at the login screen and in-world.

Fix released in **1.0.1** (stable) and **1.1.0 Beta 2**. It adds a staging ring for UI and media uploads, dirty-rectangle media uploads, caps the login page at 30 Hz, waits for room in the texture staging ring instead of spilling into one-off buffers, and stops staging from piling up on skipped frames. Reports now include a `hostmem` line. Reporter: please update and tell us whether memory stays flat at the login screen and in-world.

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 commented

2026-10-05 21:48:21 +00:00

Owner

Fixed in 1.1.0 Beta 3, confirmed by the reporter: the login screen no longer fills RAM, and the world renders after login.

Cause: the world shaders compile in the background at the login screen. We compiled up to (CPU threads − 1) pipelines at once, and AMD's Windows driver uses a lot of memory per compile (driver-internal; our own Vulkan allocations stayed around 420 MB). Beta 3 limits how many compile at once based on the driver and free RAM, and saves the shader cache as it goes, so a crash keeps the progress.

Tuning for AMD on Windows continues; see the follow-up ticket. The stable release will get the fix in 1.0.2.

Fixed in **1.1.0 Beta 3**, confirmed by the reporter: the login screen no longer fills RAM, and the world renders after login. **Cause:** the world shaders compile in the background at the login screen. We compiled up to (CPU threads − 1) pipelines at once, and AMD's Windows driver uses a lot of memory per compile (driver-internal; our own Vulkan allocations stayed around 420 MB). Beta 3 limits how many compile at once based on the driver and free RAM, and saves the shader cache as it goes, so a crash keeps the progress. Tuning for AMD on Windows continues; see the follow-up ticket. The stable release will get the fix in 1.0.2.

sky_line closed this issue

2026-10-05 21:48:21 +00:00

sky_line referenced this issue

2026-10-05 23:08:05 +00:00

Memory-safe, fast shader/pipeline compilation: per-pipeline measurement + memory-aware compile scheduler #471

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)

sky_line referenced this issue

2026-10-06 11:24:14 +00:00

Advanced graphics: show when ray tracing is inactive (and why) + audit every control's enable/disable rules #483

sky_line referenced this issue