hyprwm / Hyprland

Hyprland is an independent, highly customizable, dynamic tiling Wayland compositor that doesn't sacrifice on its looks.
https://hyprland.org
BSD 3-Clause "New" or "Revised" License
19.55k stars 821 forks source link

Abnormally high VRAM usage on start #2945

Open OrderlyUnicode opened 1 year ago

OrderlyUnicode commented 1 year ago

Hyprland Version

appears on 3f7f4207a6dd8bd217c01514ea40e9e4b9b7874a , the hyprland package from the Arch repositories, and hyprland-git in the AUR

Bug or Regression?

Bug

Description

Hyprland is utilising ~256MB of VRAM on a cold boot with the only startup apps being hyprpaper and waybarin spite of any decorations that could possibly contribute to this, such as blur or animations, being disabled. Unlike in #809 , this does not appear to be influenced by the configuration file being reloaded or windows being closed, like in #357 .(although it did seem the issues were on in the same when I read up on those) This has lead to stability issues initially believed to be related to other software, but has since been found to be an issue with the system very quickly running out of video RAM.

In case it's at all relevant, I have an AMD CPU and Nvidia GPU. the Integrated GPU allocates 1GB by default. There is an option to allocate 2GB, but it cuts into the amount of system RAM I have available.

How to reproduce

Simply start hyprland and view the VRAM usage via nvtop

Crash reports, logs, images, videos

I have no crash reports to show, but here's the relevant portions of my hyprland.conf file

animations:enabled = no
decoration:blur:enabled = no
decoration:drop_shadow = no
misc:disable_hyprland_logo = true
Haudiel commented 1 year ago

How did you fix it?

OrderlyUnicode commented 1 year ago

I didn't, I just happened to have an option in the BIOS that increases the VRAM allotted to my iGPU to a point where I would run into performance issues before I ran out of VRAM, and I use that as a temporary workaround. It does have the downside that I'm only able utilise 13 of the 16GB of RAM I have, which will probably become an issue in and of itself eventually.

vaxerski commented 1 year ago

250MB of VRAM doesn't sound like too much...?

OrderlyUnicode commented 1 year ago

250MB of VRAM doesn't sound like too much...?

It's more than double what sway uses for me

And I would agree with you if I were running this from a desktop where I could ignore the integrated GPU alltogether. If I didn't have to worry about my battery lasting for more than two hours, I would just have it use the Nvidia card with 3-6 times the VRAM, depending on a BIOS setting I had to use as a workaround.

NerdySouth commented 1 year ago

I have a similar issue right now on my Arch desktop. I have a ryzen 7600 and RTX 3070, but with literally just one terminal and this single firefox tab open, Hyprland is using 2.2 GB (!) of VRAM according to nvtop, and an additional 2.1GB of system RAM. What is going on here?

vaxerski commented 1 year ago

no clue, for me it's 250MB on both.

NerdySouth commented 1 year ago

Any pointers on debugging? I've read the wiki, but I'm a bit confused how i can actually debug outside of just running a nested instance or just straight up run the debug build and read logs. I was wondering how to setup GDB or Valgrind to attach to the debug build, since those are the tools i have the most experience with. I would love to dig in and see what i can find and submit a PR if its something worthwhile

NerdySouth commented 1 year ago

As a follow up, a clean session starts with 585MB of VRAM use with another ~528MB of system RAM. Not insane, but still a lot higher than expected i think

NerdySouth commented 1 year ago

Okay, i figured out how i can step through with GDB. It seems the bug is not present on the debug build, at least for the git HEAD. Perhaps it is only present on the Arch repo package. Right now, the debug build is using 75MB of VRAM with 2 windows open, and only about 62MB of system RAM. I am going to try to just build this version from source and use that for a while. I will update this with my findings.

NerdySouth commented 1 year ago

Okay, seems even the debug build is having this issue when it is not running as a nested instance. Looking through the logs, this seems to be the common nonoccurence when closing a window:

[ERR] onWindowRemovedTiling node null? [LOG] Cleanup: destroyed a window [LOG] [wl res 55f233ef8410] destroyed (wl_resource_destroy not sent) [LOG] [wl res 55f233f2a240] destroyed (wl_resource_destroy not sent) [LOG] [wl res 55f233b8af90] destroyed (wl_resource_destroy not sent)

Does this mean anything to you?

OrderlyUnicode commented 1 year ago

It has been pointed out to me in private conversations about this issue, and confirmed in my own testing, that resolution effects VRAM usage quite a bit more than I thought it would. This is starting to seem like less of a software issue on my end and more a shortsided hardware decision on the part of the company behind my particular machine. I will not close this issue just yet, since @TristenSeth 's comments point to a more severe issue that I may have simply managed to avoid. However, if you feel that their issue is best left for a different issue alltogether, I will close this one.

ashbir commented 9 months ago

I have this issue too, on the startup the Hyprland use ~200MiB of vram. But after hibernate the vram usage is a lot less become ~50MiB after I use it several minutes.

Startup

swappy-20231129-062405

After Hibernate

swappy-20231129-064156

tchofy commented 9 months ago

Just woke up my laptop from a suspend with this, didn't check how much it was using before the suspend. image

tchofy commented 9 months ago

Now I'm unsure if my issue is different - Vram goes up by 10mb for every new notification from swaync, as long as one isn't currently being displayed on screen, but if I'm recording then vram stops increasing.

Edit: Happens with mako as well.

Edit 2: Ok, also happens on open/close window and layersurfaces, also 10mb up on every occurrence.

izmyname commented 1 month ago

Does it still happen? Can't confirm myself

DADA30000 commented 1 month ago

@vaxerski on my friend laptop hyprland consumes 1.1 gigs of vram on integrated graphics of ryzen 5 3500u, hyprland from git on NixOS

DADA30000 commented 1 month ago

On stable hyprland from nixpkgs it's only 250MB on his laptop, I haven't tested this on my machine because I'm currently using stable hyprland

vaxerski commented 1 month ago

"stable" means not much, I know -git "consumes" more vram, but it's actually just lazy freeing by the driver and will be freed if it's needed

DADA30000 commented 1 month ago

"stable" means not much, I know -git "consumes" more vram, but it's actually just lazy freeing by the driver and will be freed if it's needed

oh, ok then, and by stable I meant latest version from nixpkgs unstable repo, it's 0.41.2

SteavenGamerYT commented 1 month ago

image nvidia-smi says this for me

romanstingler commented 4 weeks ago

if you have Nvidia cards, update your egl-wayland package there have been a lot of changes between 1.13 and 1.15 https://github.com/NVIDIA/egl-wayland/compare/1.1.13...1.1.15

Avimitin commented 3 weeks ago

Is there a way to debug this issue? My hyprland boot up with ~200MB VRAM usage and after 8-9 hours it increase to to 3GB.

image

vaxerski commented 3 weeks ago

that looks like a leak. Maybe it's that one nvidia bug? is this bisectable within hl? or easily reproducible

Avimitin commented 3 weeks ago

Its hard and painful to get the root cause :(. I will try my best to try all my daily behavior and see which one will cause memory leak.

MCPO-Spartan-117 commented 2 weeks ago

Anyone happen to turn their monitors off and on(disconnect and reconnect)? Vram usages jumps up 150MBs everytime i turn my monitor off and on regardless if it is in or outside Hyprland.

I have a AMD card(6700xt) and a friend of mine also has this issue with a Nvidia card(3080) and it increases his by 300MBs, we both have a single monitor that turns completely off, i have a 3440x1440 and he has a 5120x1440, he runs a CUDA test that allocates all available Vram and barely any gets freed.

He has a suspicion that the DRM buffer doesn't get freed when the monitor turns off.

MCPO-Spartan-117 commented 2 weeks ago

I'm using git and i think he is too. We have patched Hyprlands but this happens on 'vanilla' too and without any Cflags on both hyprland and aquamarine.

I started Hyprland then turn the monitor off and on then quit. hyprland.log

gnusenpai commented 1 week ago

A simple way to reproduce this is to unplug your only monitor and plug it back in after a few seconds. Then, boom, vram leak.

gnusenpai commented 1 week ago

I built some old versions and found that this starts happening right after aquamarine was merged.

gnusenpai commented 1 week ago

I don't mean to spam this issue, but I did some additional testing and found that this affects multi-monitor users as well as single.

You just unplug any monitor and plug it back in. It results in unreclaimable* VRAM being allocated, with the amount seemingly dependent on monitor resolution. Apparently, a lot of modern monitors fully disconnect when turned off, put into standby, or DPMS'd, which also triggers this.

*(Confirmed to be unreclaimable on at least NVIDIA: VRAM usage stacks each time up until ~96%, CUDA programs can allocate less and less memory, programs eventually fail to start, existing ones have their buffer get stuck, etc. AMD/Intel testing welcome.)

vaxerski commented 1 week ago

hm, is this reproducible on aq-git and hl-git?

gnusenpai commented 1 week ago

hm, is this reproducible on aq-git and hl-git?

Yes, as well as far back as I could easily test (hyprland 016da234, aq v0.1.0).

A side note: on these earlier versions, I noticed resizing firefox doesn't bloat up the VRAM usage like it does on newer versions. Preliminary tests show this isn't reclaimable either, but I will do more testing.

EDIT: The firefox resizing "leak" does appear to be lazily-freed, but so lazily that it cannot be allocated upfront. You have to put the card under a lot of memory pressure, resize firefox a little, and it gets freed. Annoying, but at least there's a workaround without having to restart Hyprland every time. I'm still curious if this is technically a regression.