"Fill Viewport" Leaks in VRAM.

[yardengp]

Description

See the video as VRAM grows as viewport size changes while the "Fill Viewport" option is enabled. Eventually, isaac sim crashes when I keep following the loop.

There are no error logs

capture.mp4

Isaac Sim version

6 GA

Operating System (OS)

Fedora 44

GPU Name

RTX 5060TI 16GB

GPU Driver and CUDA versions

KMD Version: 610.43.02 CUDA UMD Version: 13.3

Logs

No response

Additional information

I know Fedora and R610 are not the officially supported platform, but this is currently the only blocker I have, for now I just disable the feature.

[vick-yu]

Thanks for the clear video -- it made the issue easy to trace.

What's Happening

This is a VRAM leak in Kit's viewport resize path. When "Fill Viewport" is enabled, every window resize triggers a full viewport destroy and recreate cycle internally. The old viewport's GPU resources (framebuffers, render targets) are deallocated asynchronously by the render thread, but during continuous resizing (like dragging a window edge), new viewports are created faster than old ones are cleaned up. The GPU allocations accumulate until VRAM is exhausted.

The underlying issue is that a resolution-only change is being treated as requiring a full viewport teardown/rebuild, when it could instead be handled as an in-place resolution update -- a much cheaper operation that doesn't allocate new GPU resources.

This is in Kit's rendering layer, not in Isaac Sim-specific code, so it's platform-independent -- it would reproduce on any OS/driver combination, not just Fedora + R610.

Workaround

You already found the best workaround -- disable "Fill Viewport" and use a fixed resolution.

If you want to keep Fill Viewport but reduce the leak rate, you can add these settings to your .kit config (or set them at runtime):

[settings.exts."omni.kit.widget.viewport".resize]
waitForMouseUp = true
textureFrameDelay = 10

waitForMouseUp = true delays the resolution update until you release the mouse button after resizing, which batches the entire drag into a single resize event instead of one per frame.

This won't completely eliminate the leak (a single resize still triggers the full teardown/rebuild), but it makes it unlikely to cause problems during normal use.

Note on Your Platform

Fedora 44 and the R610 NFB driver aren't officially supported, but this specific issue isn't related to that. However, the R610 driver could cause other problems -- if you encounter rendering artifacts or crashes unrelated to viewport resizing, switching to the R580 production driver would be the first thing to try.

Status

We've confirmed the root cause and are routing this to the Kit viewport team for a fix (internal ticket: 6308713). The proper solution is to decouple resolution changes from the full viewport recreate path so that resizing uses in-place resolution updates instead.