NVIDIA 435 driver looks exciting

I documented what I did to make it work here: Nvidia render offloading
Look at the logs of Xorg, it should give you an idea of what went wrong.

1 Like

This is killer.

Finally, no need for bumblebee or hacky workarounds (no matter how nicely coded the tools may be, switching configuration files and restarting X is hacky).

2 Likes

That will still be needed for 340 and 390 cards.

Also, rumor is the cards are never completely powered down (in generations before Turing). This might change in the future though.

2 Likes

that should easy enough to make work with pre turing cards, even if it's using a script to load/unload modules when running/stopping nvidia specified tasks.

nice, looking it over now. :+1:

This happens because (allegedly, again) you run the Xserver on the nvidia driver.

They finally managed to allow it to accept more than a single vendor per screen.
They finally managed to allow it to accept more than a single vendor per server.
But I believe that you still cannot "pass the bucket" back and forth between the intel and nvidia driver. And you can't unload the modules gracefully if the server's fixed on them.

It's all still super new though, and for as much as I know, yes, it may even be that a stupid script could do the magic.
After all the folks over at bumblebee-project and optimus-manager have certainly seen worse ■■■■■

I pushed the needed packages to our unstable branch.


For render offload, I think there are a few pieces are needed:

  • Install xorg-server 1.20.5-2.1
  • Update to nvidia 435.17 packages
  • Don't put Option "PrimaryGPU" in the nvidia-drm OutputClass rule in /usr/share/X11/xorg.conf.d

That last one might be a bit controversial: what that flag does is force the X server to use a traditional display offload configuration when an NVIDIA GPU is present, but having that flag set gets in the way of using the NVIDIA GPU as a secondary GPU for render offload.

For render offload to actually work in the beta drivers, users need to set the "AllowNVIDIAGPUScreens" option. Nvidia recommends against setting that by default, but will enable it by default after some soak time in public drivers. See also here.

11 Likes

Very goodjob Manjaro! So glad you listen to the community!

Right now its like this by default:

Section "OutputClass"
Identifier "nvidia"
MatchDriver "nvidia-drm"
Driver "nvidia"
Option "PrimaryGPU" "yes"
Option "AllowEmptyInitialConfiguration"
ModulePath "/usr/lib/nvidia/xorg"
ModulePath "/usr/lib/xorg/modules"
EndSection

So all I have to do is change PrimaryGPU to

Option "PrimaryGPU" "no"

and it will work?

Edit: I think adding this is also needed

Option "AllowNVIDIAGPUScreens"

it's early days but so far it functions ok with some caveats.

so far, due to reasons in that post the only way im able to power down the gpu is by killing xorg running on the nvidia and unload the nvidia modules and start xorg again only on the intel gpu and the nvidia will power down.

i'll do some more playing around, can anyone else confirm or not confirm this behavior?

i'll say this though, this setup seems very forgiving. i've been throwing silly configurations at it that would certainly end up at a black screen with previous versions. even when using no xorg configuration at all it still gets to the desktop.

This is really exciting. I didn't think this would actually happen. Will this be an easy transition if Prime is already installed?

1 Like

Today's nvidia and xorg updates, but I will just wait for NEW GUIDE SWITCH FROM BUMBLEBEE TO PRIME.

1 Like

I think that's because they want Linus to hold his middle finger back.:metal:

3 Likes

so far, from what i can tell you would just remove the prime xrandr script and xorg configuration you created and it just works so at the very least is easier for newcomers to install proprietary drivers and boot and not need to deal with the bumblebee/bbswitch nonsense.

im currently focused on a way of making it so the nvidia gpu can be powered down when not used which is easily done as long as the nvidia modules can be unloaded so right now im only able to do that with kill xorg --> unload modules --> start xorg. with the modules unloaded and power management set to "Auto" the nvidia card shuts off.
the turing cards are suppose to do this for you if i understand correctly. pre-turing cards like mine may need some more intervention.

1 Like

can somebody share how /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf looks like after making this work? Specially in an intel + nvidia configuration

i guess with this setup, the best possible outcome is that the nvidia gpu can go into a low power state but never powered off completely. :disappointed:
https://devtalk.nvidia.com/default/topic/1061158/linux/render-offload-power-management-on-435-17-linux-drivers/post/5373881/?offset=3#5373936

heres where i see this as not so great.

  • only turing cards and newer will have built in power management, the documentation says as much so no surprise there.
  • the xorg process runs on the nvidia card and the modesetting driver does all the rendering unless an app is launched with the variable to specify using the nvidia card. regardless, there is no way to power off the gpu without exiting xorg unloading modules and starting xorg exclusively on the intel gpu.
  • modesetting is good for carrying the art, not creating it and it shows quite a bit. :nauseated_face:
  • with PRIME (as in the old way) the nvidia did all the rendering and modesetting/intel only displayed it so it wasnt relying on the crap iGPU to do any of the work and make a mess of it.
  • having the gpu powered on all the time regardless of what power state it's in will use a fair amount of power all the while the modesetting is doing most of the work. so for everyday tasks that are not graphics intensive your paying the extra cost of battery life while getting the graphical performance of an etch-a-sketch. apps that are run on the nvidia though do seem to work perfectly fine.

it's early days though, i guess i'll focus more on getting the nvidia card to use as little power as possible rather than powering it of, at least on this install anyway. i'll be sticking to prime/optimus-switch on my primary for now.

2 Likes
10-nvidia-drm-outputclass.conf
/usr/.../X11/xorg.conf.d >>> cat 10-nvidia-drm-outputclass.conf                                       
Section "OutputClass"
    Identifier "intel"
    MatchDriver "i915"
    Driver "modesetting"
EndSection

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowNVIDIAGPUScreens"
    Option "AllowEmptyInitialConfiguration"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

This is how we ship it stock now

https://gitlab.manjaro.org/packages/extra/nvidia-utils/raw/df4904709b2ed29775a645982d2734dfb64a48bd/nvidia-drm-outputclass.conf

AFAIK the Option "AllowNVIDIAGPUScreens" should be on a ServerLayout section or PRIME offload won't run and a warning like below will appear on Xorg log

(WW) NVIDIA(G0): Option "AllowNVIDIAGPUScreens" is not used

Also I've managed to make PRIME offload work on AMD iGPU that uses amdgpu using this xorg configuration: https://gist.github.com/rockyprabowo/46550399affbbdd39b48cd5efea9fe84

I think you should consider AMD iGPU support in the future instead of hardcoding Intel specific configuration on that file.

1 Like

Does a more generic way work too?

Section "ServerLayout"
    Identifier "layout"
    Screen 0 "iGPU"
    Option "AllowNVIDIAGPUScreens"
EndSection

Section "Device"
    Identifier "iGPU"
    Driver "modesetting"
EndSection

Section "Screen"
    Identifier "iGPU"
    Device "iGPU"
EndSection

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

No, it won't, at least on my side.
The minimal xorg conf which is working for me is as follows:

Section "ServerLayout"
  Identifier "layout"
  Option "AllowNVIDIAGPUScreens"
  Screen 0 "iGPU"
EndSection

Section "Device"
  Identifier "iGPU"
  Driver "modesetting"
#  BusID "PCI:0:2:0"
EndSection

Section "Screen"
  Identifier "iGPU"
  Device "iGPU"
EndSection

Section "Device"
  Identifier "nvidia"
  Driver "nvidia"
#  BusID "PCI:1:0:0"
#  Option "Coolbits" "28"
EndSection

Some info:

  • Section Device with nvidia identifier and driver is a must, there's no way to avoid setting it.
  • Setting Coolbits has no impact on nvidia-settings.
  • There's no need to set BusID explicitly (but some users may need that).
  • No xf86-video-...-like packages needed, no mhwd configs necessary.
  • Nouveau should be blacklisted, or otherwise it will take over nvidia device acting as modesetting and prevent nvidia or nvidia-drm from loading. It is also possible (and less restrictive) to set nouveau.modeset=0 instead of full blacklisting like modprobe.blacklist=nouveau`.
  • Yet to understand is what does this mean:
    $ cat /var/log/Xorg.0.log | grep -E "WW"
...
[    14.195] (WW) NVIDIA(G0): Option "AllowNVIDIAGPUScreens" is not used
...

Because removing this setting from xorg conf breaks the work of this offload solution.

$ lsmod | grep -E "i9|nv|nou"
nvidia_drm             57344  2
nvidia_modeset       1126400  2 nvidia_drm
nvidia              19554304  78 nvidia_modeset
ipmi_msghandler        65536  2 ipmi_devintf,nvidia
nouveau              2306048  0
mxm_wmi                16384  1 nouveau
ttm                   118784  2 drm_vram_helper,nouveau
wmi                    36864  5 intel_wmi_thunderbolt,wmi_bmof,mxm_wmi,xiaomi_wmi,nouveau
i915                 2322432  42
i2c_algo_bit           16384  2 i915,nouveau
drm_kms_helper        217088  4 vboxvideo,nvidia_drm,i915,nouveau
drm                   520192  23 drm_kms_helper,drm_vram_helper,vboxvideo,nvidia_drm,i915,ttm,nouveau
intel_gtt              24576  2 intel_agp,i915
agpgart                53248  5 intel_agp,intel_gtt,ttm,nouveau,drm

Forum kindly sponsored by Bytemark