secondlife / secondlife/viewer

Extremely excessive (25GB+) VRAM usage in PBR viewer

Open
#3,575 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

backlog bug team:viewer triage
Dominant language
C++
Stars
299
Forks
146
Avg merge
1d 9h
Merged PRs (30d)
88

Description

Viewer VRAM usage spikes dramatically, exceeding physical memory capacity, and does not seem to drop as expected as objects go out of view, or for any reason except teleporting to another sim. Memory use far exceeds what makes sense.

I have seen up to 25GB of VRAM allocated on a 16GB GPU. The viewer continues to run without issues, suggesting it is not actively using most of this memory and causing swap thrashing between physical and shared video memory.

Other games and tools that use video memory in meaningful amounts are incapable of running at the same time due to all physical memory being taken up; the viewer seems to have priority of some kind.

I have also seen this happen on the latest alchemy viewer release, presumably it happens in all PBR viewers. Some users with similar hardware have reported it not happening.

The viewer does not crash at any point.

Current video driver is AMD 24.7.1, OS is Windows 10 Enterprise LTS 2021. No unusual software that would interfere with video memory behavior in any way is running.

https://secondlife.canny.io/admin/board/bug-reports/p/extremely-excessive-25gb-vram-usage-in-pbr-viewer

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source file, test, or entry point is identified in the report. Start by reproducing the VRAM growth on Windows 10 with the AMD 24.7.1 driver while objects leave view, and compare memory behavior before and after teleporting to another sim. Done means identifying the cause and preventing excessive VRAM allocation or confirming that it is released appropriately.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
computer-graphics, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.