Multi-second delay opening nearly any new window (new app/process?) in cosmic

[colemickens]

1. Launch helvum, three second delay before it appears.
2. Launch cosmic-term (even with other instances open), three second delay before it appears.
3. "Ctrl+n" in firefox -> opens reasonably snappily, as I'd expect.

so, no idea what's going on but this dmesg spew accompanies the slow openings:

[103789.899524] [drm] PCIE GART of 512M enabled (table at 0x00000081FEB00000).
[103789.899551] amdgpu 0000:03:00.0: amdgpu: PSP is resuming...
[103789.982212] amdgpu 0000:03:00.0: amdgpu: reserve 0xa00000 from 0x81fd000000 for PSP TMR
[103790.086437] amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available
[103790.103436] amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
[103790.103445] amdgpu 0000:03:00.0: amdgpu: SMU is resuming...
[103790.103450] amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x0000000f, smu fw if version = 0x00000013, smu fw program = 0, version = 0x003b3100 (59.49.0)
[103790.103455] amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched
[103790.153626] amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully!
[103790.155483] [drm] kiq ring mec 2 pipe 1 q 0
[103790.161042] [drm] DMUB hardware initialized: version=0x02020020
[103791.350617] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[103791.350624] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.1.0 uses VM inv eng 1 on hub 0
[103791.350627] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 4 on hub 0
[103791.350629] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 5 on hub 0
[103791.350631] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[103791.350633] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[103791.350636] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[103791.350638] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[103791.350640] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[103791.350642] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[103791.350644] amdgpu 0000:03:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 12 on hub 0
[103791.350647] amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 13 on hub 0
[103791.350649] amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 14 on hub 0
[103791.350651] amdgpu 0000:03:00.0: amdgpu: ring vcn_dec_0 uses VM inv eng 0 on hub 8
[103791.350653] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc_0.0 uses VM inv eng 1 on hub 8
[103791.350656] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc_0.1 uses VM inv eng 4 on hub 8
[103791.350658] amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 8
[103791.361061] amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes

[colemickens]

Probably relevant information, this is an ASUS G14 2022.

It's running in "Hybrid" mux mode, not "Discrete".

It's an AMD/AMD system:

• AMD 680M (I think, lol, why is it so hard to find this)
• AMD 6700S

[ids1024]

Some delay in opening windows is a known issue (#827), but this sounds a bit worse. And that issue won't cause dmesg errors.

You get those lines every time a window is opened? And nothing else? Seems rather verbose given only the last line "Cannot find any crtc or sizes" reports something error-like, unless DRM debugging is explicitly enabled (https://github.com/swaywm/wlroots/wiki/DRM-Debugging).

[colemickens]

Those drm debug instructions look non-persistent. While I have used them before, it has been ages, and I definitely didn't permanently enable it. I can't explain it, other than it seems like sometimes Cosmic does something that triggers my dGPU to become active. (well, I can't fully substantiate that, so let's ignore that for now)

Per the description, that dmesg spew and delay happens every time I launch a new instance of cosmic-term, or something like helvum. Or probably even the first instance of Firefox.

If I open a second Firefox window when it's already open, the spew and lag does not occur.

I got my phone out and timed it, it's at least 2.5 seconds. Seemingly closer to 3secs.

[colemickens]

See, something weird is going on. If I open windows in rapid-succession, it's fine.

If I wait like 5-10 seconds and then open another COSMIC Terminal instance, I get the spew+delay.

I'm like 90% if I put the MUX Switch into Discrete mode (aka, keep the dGPU on and engaged), this issue goes away.

[colemickens]

Note to self/others, when I brought this up previously, this is what @Drakulix suggested. https://chat.pop-os.org/pop-os/pl/wutekoaetbfpmcyqa9t1d7ddna

I will try to do this tomorrow. Thanks all! <3.

[colemickens]

Yeah... comp is definitely activating my dGPU. I get a notification from rog-control-center. Then after a while it suspends, and then the lag comes back for the next launch.

It very much seems like comp is forcibly using my dGPU to do compositing animations.

[Drakulix]

I think it is the other way around. We deactivate the dGPU. So any vulkan app launching and enumerating devices probably has to wait until the gpu is turned on again, select the internal one, and then it gets powered off again in the background.

Since this is an amdgpu+amdgpu system, our nvidia hack we applied for this reason can't fix it. I would consider this a mesa bug. (And if you want to see this fixed, I would recommend opening a bug with them.)

[colemickens]

@Drakulix thanks for looking at this again and advising again. Can you help me with one last bit of confusion? This was not an issue in Sway, even with WLR_RENDERER=vulkan. Why is this only an issue in Cosmic?

[Drakulix]

@Drakulix thanks for looking at this again and advising again. Can you help me with one last bit of confusion? This was not an issue in Sway, even with WLR_RENDERER=vulkan. Why is this only an issue in Cosmic?

Because something (most likely sway?) is keeping the gpu active. Not necessarily using it, so it might still be in a very low power state, but any open handle (which cosmic carefully avoid to keep) should keep it active enough for quick enumeration.

[colemickens]

How can I prove this to myself further?

This just doesn't really match with my experience as far as I can tell. I ran sway for years, and have always used rog-control-center to know when the dGPU is engaged. I can say that it does NOT stay engaged under Sway, and doesn't have this issue.

Furthermore, when my dGPU is fired up in Cosmic, the battery widget tells me it's cosmic-comp responsible.

[Drakulix]

How can I prove this to myself further?

Well, if you want to debug this, attach a debugger and benchmark which function call is taking the majority of the time. I bet it is either vkEnumeratePhysicalDevices or vkCreateInstance in which case this is a driver bug.