Repository navigation
VRAM usage grows until dedicated memory is full (12 GB) and spills into shared memory, with Sodium only (RTX 5070, Windows 11 Insider) #3971
Description
Bug Description
With Sodium 0.8.13 installed, dedicated GPU memory used by javaw.exe grows continuously until it reaches the card's limit (about 10.8 of 12 GB in Task Manager). Shared GPU memory then starts growing too, system RAM usage grows along with it, and FPS drops. Without Sodium, VRAM usage stays flat in the same situation, so I believe this is a bug in the interaction between Sodium and the graphics stack, not normal caching.
Opening File Explorer is a reliable trigger. Without File Explorer open, the memory does not overflow: system RAM stays stable and VRAM grows slower, if at all. As soon as File Explorer is opened, both VRAM and system RAM start to overflow (RAM after VRAM), and this keeps going while the game is open, even after Explorer is closed.
The memory is released when chunks get rebuilt (for example, moving a couple of chunks away), then it fills up again in a regular cycle. It grows even when I stand still, and also in the main menu. I expected VRAM usage to stabilize and not keep growing while the game is idle.
Setup:
- Only Sodium 0.8.13+mc1.21.1 is installed (C2ME is present but disabled), new empty world
- Minecraft 1.21.1, NeoForge 21.1.265, LWJGL 3.3.3, Prism Launcher 11.1.1
- Behaves the same on other Sodium versions I tried
- GPU: NVIDIA GeForce RTX 5070 (12 GB), driver 621.01 (Game Ready, released Oct 21, 2026; Windows reports it as 32.0.16.2101)
- CPU: Ryzen 9 7950X (integrated AMD Radeon is also present)
- OS: Windows 11 Pro Insider Preview, build 26220.9757
- Two monitors
Other notes:
- Toggling "Use Persistent Mapping" made no noticeable difference.
- With Sodium removed, VRAM stays flat regardless of window layout and whether Explorer is open.
Screenshots: Task Manager with javaw.exe at 10.8 GB dedicated GPU memory (only Sodium enabled), and the GPU graph showing dedicated and shared memory growing over time.
Reproduction Steps
- Start the game on monitor 1 and keep the Prism Launcher console window (the "Minecraft Log" window that opens with the game) on the same monitor. Memory is stable at this point.
- Open File Explorer (two windows) on the same monitor as the game and the console.
- VRAM and system RAM start to overflow. This continues while the game is open, even after the Explorer windows are closed.
- Without File Explorer open, the overflow does not happen. Memory can sometimes start growing without it, but Explorer triggers it every time.
- Moving windows between monitors changes the speed of the growth. With the console on the second monitor, or minimized, the memory grows more slowly.
- Memory drops when chunks are rebuilt (moving a couple of chunks away), then fills up again.
Activity
douira commentedon Oct 31, 2026
This sounds like a severe bug of the graphics driver, given that you're the first person to report this to my knowledge.
just661 commentedon Oct 31, 2026
Update with all the requested tests:
The Fabric and 26.3 results looked the same, so I attached only one screenshot (stable VRAM).
Note: on 26.3 I used a different Sodium line (mc26.3-0.9.3-beta.1-neoforge) than on 1.21.1 (0.8.13), so that test does not separate the Minecraft version from the Sodium version.
In all cases I used the same steps: game on monitor 1 with the launcher window on the same monitor, then opening File Explorer (two windows) on that monitor. So far it only happens on NeoForge with Minecraft 1.21.1 and Sodium 0.8.13, regardless of launcher.
just661 commentedon Oct 31, 2026
Update:
After recent system changes (updating Windows to Insider Preview 26220.9836, performing a clean reinstall of the GPU driver 621.01, and updating PowerToys to 0.102.3001), the issue has become slightly harder to reproduce, but the core behavior remains.
Refined Reproduction Steps:
Opening File Explorer alone is no longer sufficient. The reliable trigger now requires a specific combination on the same monitor (Discord can be anywhere, but repeatability is better if it's on one screen):
-Minecraft running with Sodium.
-Discord is fully open with its main window visible (though it has also triggered occasionally when minimized to the system tray), with Hardware Acceleration enabled or disabled. (interact with Discord, scroll or do something in the app, a few seconds is enough)
-Opening File Explorer
-The Minecraft console (log window) is open.
-Moving across chunks (even just once is enough to trigger it).
Note: If it doesn't work, interact with each one app from the list.
Observed Behavior:
VRAM usage begins to spike immediately upon triggering this state. It may "autoclear" a couple of times even if the player is standing still (0-3 times was the maximum I observed), but if the player remains stationary the rest of the time, it will eventually max out the dedicated VRAM and begin overflowing into shared system RAM (the memory filling speed is identical)
Important Note:
Completely closing only Discord (others from the list have no effect) immediately resolves the issue, and the VRAM leak does not reoccur until the application is launched again. (I am specifying Discord as it is the most consistent trigger I have found in this updated environment, to avoid adding unnecessary speculation about other software).
P.S Fabric and 26.3 remain stable