profiles/graphic_drivers: Return workaround for RTD3

[ventureoo]

Since #148 has been merged, we can bring back some of problematic hooks in the past, such as RTD3 workaround, since they are still relevant. Moreover, I can now say that this workaround is needed not only for GNOME, but in general for all Wayland compositors.

The issue here is that every time some application using EGL is started, the loader starts loading all the drivers specified in /usr/share/glvnd/egl_vendor.d/ at once, which always causes the NVIDIA dGPU to wake up from its sleep state. This can be easily checked via watch -n 1 cat /sys/class/drm/card0/device/power_state (substitute your card number instead of card0 if it is different, in my case the dGPU always takes the number 0).

Running any application takes it from D3cold to D0 state. Using this environment variable, however, allows dGPU not to wake up when it shouldn't. This does not affect running an application with nvidia-offload / switcheroo-control, because then dGPU is activated anyway.

Another additional benefit is the slightly lower memory consumption and speeds up the launch of applications, as now any application does not load the NVIDIA EGL driver into its process. For example:

• Running alacritty without environment variable:

[N] vasily@cachyos ~> grep "nvidia" /proc/$(pidof alacritty)/maps
75:73d54ce00000-73d54cfa9000 r--p 00000000 00:1e 29216048                   /usr/lib/libnvidia-gpucomp.so.565.77
76:73d54cfa9000-73d54f3e1000 r-xp 001a9000 00:1e 29216048                   /usr/lib/libnvidia-gpucomp.so.565.77
77:73d54f3e1000-73d54fd02000 r--p 025e1000 00:1e 29216048                   /usr/lib/libnvidia-gpucomp.so.565.77
78:73d54fd02000-73d54fe08000 r--p 02f01000 00:1e 29216048                   /usr/lib/libnvidia-gpucomp.so.565.77
79:73d54fe08000-73d54fedd000 rw-p 03007000 00:1e 29216048                   /usr/lib/libnvidia-gpucomp.so.565.77
162:73d555c00000-73d555e39000 r--p 00000000 00:1e 29216034                   /usr/lib/libnvidia-eglcore.so.565.77
163:73d555e39000-73d556a84000 r-xp 00239000 00:1e 29216034                   /usr/lib/libnvidia-eglcore.so.565.77
164:73d556a84000-73d55790d000 r--p 00e84000 00:1e 29216034                   /usr/lib/libnvidia-eglcore.so.565.77
165:73d55790d000-73d55790e000 ---p 01d0d000 00:1e 29216034                   /usr/lib/libnvidia-eglcore.so.565.77
166:73d55790e000-73d557a7d000 r--p 01d0d000 00:1e 29216034                   /usr/lib/libnvidia-eglcore.so.565.77
167:73d557a7d000-73d557acf000 rw-p 01e7c000 00:1e 29216034                   /usr/lib/libnvidia-eglcore.so.565.77
...

• With environment variable:

[N] vasily@cachyos ~> grep "nvidia" /proc/$(pidof alacritty)/maps
[I] vasily@cachyos ~ [1]>

As for MUX configurations, they should not be broken because of validation with which the variable export is done. We have previously looked into this and found that when MUX mode is set to NVIDIA-only, the class id of the dGPU changes to 0300. When it is set to Offload-compatible mode it becomes 0302, so we should be protected against these situations.

References:

• https://bbs.archlinux.org/viewtopic.php?id=284426
• https://gitlab.gnome.org/GNOME/mutter/-/issues/2969
• [Bug]: Electron13+ always wakes up dGPU on hybrid setup (Intel + Nvidia PRIME) electron/electron#41389
• https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/240

[ventureoo]

I forgot to mention that the same issue occurs with GTK4 apps, but they use Vulkan instead of EGL by default since 4.16, so there isn't any cleaner solution here other than overriding the backend back to (E)GL for PRIME users, but I'm not sure if we should do something like that.

[vnepogodin]

not sure about it. AFAIR it was causing issues with MUX on Davinci being unable to pick cuda device

[vnepogodin]

let's try again

[ventureoo]

not sure about it. AFAIR it was causing issues with MUX on Davinci being unable to pick cuda device

Well, I don't have MUX, but for me Davinci works fine when using the environment variable.