[ABANDONED] Bad performance under wayland plasma with nvidia gpu.

AngelBePro · 2024-12-08 15:44:31

I'm not sure if it is just me but I have way worse performance on wayland compared to x11. I am using the latest nvidia-dkms drivers as of posting this (565.57.01). I have done the following:

Early KMS for nvidia modules
Add "nvidia_drm.fbdev=1" to the kernel parameters
Add

GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia

to /etc/enviorment

I am also getting this error log from kwin_wayland https://0x0.st/Xhbo.txt

Last edited by AngelBePro (2024-12-14 12:45:59)

AngelBePro · 2024-12-08 16:02:48

This is the new log after updating my system and the nvidia drivers to 565.77 http://0x0.st/Xhbm.txt

AngelBePro · 2024-12-08 16:48:29

I found a "fix", and it is to remove the configs for kde plasma using this:

mv ~/.config/kwinrc ~/.config/kwinrc.bak
mv ~/.config/plasmashellrc ~/.config/plasmashellrc.bak

AngelBePro · 2024-12-12 12:01:04

(Hope I'm not bumping) I have been messing around since deleting this configs partially fixed my issues and here is what i found out. First disabling my second monitor fixes all my issues with the vsync, so either vsync is broken or how kwin handles a 60 hz and a 144hz monitor. But I also found out that gbm wasn't even used.

❯ journalctl -b 0 --grep "renderer for"
-- No entries --

So I need help with figuring out what is wrong. Full log as of my current boot http://0x0.st/XFiO.txt. A kscreen-doctor:

❯ kscreen-doctor -o
Output: 1 HDMI-A-1
        enabled
        connected
        priority 2
        HDMI
        Modes:  1:1920x1080@60*!  10:1280x720@60  11:1024x768@75  12:1024x768@60  13:800x600@75  14:800x600@60  15:720x480@60  16:720x480@60  17:640x480@75  18:640x480@60  2:1920x1080@60  3:1920x1080@60  4:1680x1050@60  5:1280x1024@75  6:1280x1024@60  7:1280x960@75  8:1152x864@75  9:1280x720@75 
        Geometry: 0,262 1920x1080
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: unknown
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none
        Color profile source: sRGB
        Brightness control: supported, set to 100%
Output: 2 DP-3
        enabled
        connected
        priority 1
        DisplayPort
        Modes:  19:2560x1440@144*!  20:2560x1440@120  21:2560x1440@60  22:1920x1080@144  23:1920x1080@120  24:1920x1080@60  25:1920x1080@60  26:1920x1080@50  27:1680x1050@60  28:1600x900@60  29:1280x1024@75  30:1280x1024@60  31:1440x900@60  32:1280x800@60  33:1152x864@75  34:1280x720@60  35:1280x720@60  36:1024x768@75  37:1024x768@70  38:1024x768@60  39:800x600@75  40:800x600@72  41:800x600@60  42:800x600@56  43:640x480@75  44:640x480@73  45:640x480@60 
        Geometry: 1920,0 2560x1440
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: Never
        RgbRange: unknown
        HDR: disabled
        Wide Color Gamut: disabled
        ICC profile: none
        Color profile source: sRGB
        Brightness control: supported, set to 50%

Hope that's all and I hope for a response

AngelBePro · 2024-12-12 17:25:45

I tested out the nouveau drivers and I did not find any issues there. So it is probably a issue with the nvidia driver of some sort. eglinfo also segfaults https://0x0.st/XFX8.txt, where with nouveau it worked with no issues.

AngelBePro · 2024-12-12 20:44:32

Here is my main issue, when I use both of my screen https://imgur.com/8UjRPdX. And that is how it looks like when I disable the second monitor https://imgur.com/a/hbN7yOg.

seth · 2024-12-13 10:20:45

So the "bad performce" is merely that kwin_wayland averages out the two outputs to ~100fps w/ vsync enabled? Or is there more (things moving considerably slower than 60fps or even 30fps)
Is the browser the only testcase? Is seems to indicate a double-sync (ie. both compositor and browser wait for a vblank signal, maybe the browser runs on xwayland?)

What happens if you "export __GL_SYNC_TO_VBLANK=0" to the entire session/the browser?

AngelBePro · 2024-12-13 12:26:32

I decided to use eglgears with mangohud to test this out, and when running without __GL_SYNC_TO_VBLANK=0 the vsync is applied and is running bad at around 95 fps. With __GL_SYNC_TO_VBLANK=0 it still runs bad, but whenever I move my mouse cursor vsync is not applied and the fps is around 1500.

seth · 2024-12-13 16:13:23

nomodeset nvidia-drm.modeset=1 nvidia_drm.fbdev=1 NVreg_PreserveVideoMemoryAllocations=1

Don't use nomodeset, NVreg_PreserveVideoMemoryAllocations is a parameter of the nvidia module and try w/o fbdev=1:

nvidia-drm.modeset=1 nvidia_drm.fbdev=0 nvidia.NVreg_PreserveVideoMemoryAllocations=1

(NVreg_PreserveVideoMemoryAllocations might cause errors/warnings w/o the userspace services when trying to suspend/hibernate the system - otherwise you'd have gotten warnings when trying to use those w/o the parameter)

AngelBePro · 2024-12-13 17:08:17

Using these kernel parameters, the only difference in eglgears is that the fps stabilizes around 150 instead of slowly just stopping rendering, and something else the higher the polling rate is of the mouse the higher fps - with 125 hz its around 500, with 500 around 1000, and with 1000 hz at peak I reach 1500 fps.

Last edited by AngelBePro (2024-12-13 17:09:22)

seth · 2024-12-13 17:32:03

Stabilized at 150Hz w/ or w/o __GL_SYNC_TO_VBLANK=0 ?
Your outputs run at 144Hz max, so that'd be expectable for a sync'd run.

Do you currently export WLR_NO_HARDWARE_CURSORS=1 ?

AngelBePro · 2024-12-13 17:40:10

seth wrote:

Stabilized at 150Hz w/ or w/o __GL_SYNC_TO_VBLANK=0 ?
Your outputs run at 144Hz max, so that'd be expectable for a sync'd run.
Do you currently export WLR_NO_HARDWARE_CURSORS=1 ?

With __GL_SYNC_TO_VBLANK=0 without WLR_NO_HARDWARE_CURSORS=1

After running WLR_NO_HARDWARE_CURSORS=1 __GL_SYNC_TO_VBLANK=0 mangohud eglgears_wayland I get the same result.

AngelBePro · 2024-12-13 17:52:43

AngelBePro wrote:

I tested out the nouveau drivers and I did not find any issues there. So it is probably a issue with the nvidia driver of some sort. eglinfo also segfaults https://0x0.st/XFX8.txt, where with nouveau it worked with no issues.

After using gdb to backtrace the segfault, it turned out that it was a mesa bug, which I reported to mesa already.

Last edited by AngelBePro (2024-12-13 18:35:37)

AngelBePro · 2024-12-14 12:45:35

I am abandoning this as I am planning on purchasing a rx 7700 xt.

Arch Linux

#1 2024-12-08 15:44:31

[ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#2 2024-12-08 16:02:48

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#3 2024-12-08 16:48:29

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#4 2024-12-12 12:01:04

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#5 2024-12-12 17:25:45

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#6 2024-12-12 20:44:32

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#7 2024-12-13 10:20:45

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#8 2024-12-13 12:26:32

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#9 2024-12-13 16:13:23

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#10 2024-12-13 17:08:17

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#11 2024-12-13 17:32:03

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#12 2024-12-13 17:40:10

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#13 2024-12-13 17:52:43

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

#14 2024-12-14 12:45:35

Re: [ABANDONED] Bad performance under wayland plasma with nvidia gpu.

Board footer