Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ensure framebuffer textures are detached and deleted, avoid leaving framebuffers bound when not needed #9188

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

gulafaran
Copy link
Contributor

without detaching textures before deleting them they become dangling in vram if my google skills are correct. so ensure we call glFramebufferTexture2D on the framebuffer before deleting it. and in good practice try to unbind the framebuffers where framebuffers have been bound after its usage. and dont call glDeleteProgram on a zero program, its safe to do so but fills apitrace up with unnecessery lines.

its safe to do so but it adds a bunch of unnecessery lines in apitrace
when tracing. if guard it and return early.
ensure bound buffers are unbound after use, also detach textures from
framebuffer before deleting it otherwise it will become dangling and
essentially leak.
@UjinT34
Copy link
Contributor

UjinT34 commented Jan 27, 2025

Will be hard to test on nvidia. Some vram might stay reserved for HL with nvidia drivers if it is not needed. Starting some vram heavy app should take that memory from HL. nvidia-smi isn't suitable to debug vram issues. Without any vram stress HL will "eat" about 1gb vram. Should go down to 400-500mb under heavy load. Running apps will ask HL to allocate some vram for their buffers. Loaded wallpapers can take a good chunk of this vram. So it is hard to tell how many vram is really used by HL itself.

@gulafaran
Copy link
Contributor Author

Will be hard to test on nvidia. Some vram might stay reserved for HL with nvidia drivers if it is not needed. Starting some vram heavy app should take that memory from HL. nvidia-smi isn't suitable to debug vram issues. Without any vram stress HL will "eat" about 1gb vram. Should go down to 400-500mb under heavy load. Running apps will ask HL to allocate some vram for their buffers. Loaded wallpapers can take a good chunk of this vram. So it is hard to tell how many vram is really used by HL itself.

Perhaps, was apitrace reporting leaks and i found post similar to these https://stackoverflow.com/a/19422828 even tho opengl manpages seems to suck explaining things like this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants