NVIDIA 435 driver looks exciting

can you post these for reference. if this works i'll have to give it another try :+1:

inxi -Gxxz

Why is that the 2 BusID lines are commented out? Do we only need the identifiers?

Those were initially introduced in order to fix issues that were observed by the author of the original config. As it turned out that I have no need it those, I just commented them, but left just for such cases when someone sees it is possible to set them explicitly if necessary.
So, some people may need them, some (like you and me) don't.

Also, what about glamor?

That's the thing I know nothing about.


╰─>$ inxi -Gxxz
Graphics:  Device-1: Intel UHD Graphics 620 vendor: Xiaomi driver: i915 v: kernel 
          bus ID: 00:02.0 chip ID: 8086:5917 
          Device-2: NVIDIA GP108M [GeForce MX150] vendor: Xiaomi Mi Notebook Pro driver: nvidia 
          v: 435.17 bus ID: 01:00.0 chip ID: 10de:1d12 
          Display: x11 server: X.Org 1.20.5 driver: intel,nvidia compositor: kwin_x11 
          resolution: 1920x1080~60Hz, 1920x1080~60Hz 
          OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) v: 4.5 Mesa 19.1.4 
          compat-v: 3.0 direct render: Yes 
╰─>$ nvidia-smi
Sun Aug 18 23:18:26 2019       
| NVIDIA-SMI 435.17       Driver Version: 435.17       CUDA Version: 10.1     |
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|   0  GeForce MX150       Off  | 00000000:01:00.0 Off |                  N/A |
| N/A   43C    P8    N/A /  N/A |     14MiB /  2002MiB |      0%      Default |
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|    0      1311      G   /usr/lib/Xorg                                 14MiB |
Graphics:  Device-1: Intel UHD Graphics 620 vendor: Xiaomi driver: i915 v: kernel 
          bus ID: 00:02.0 chip ID: 8086:5917 
          Device-2: NVIDIA GP108M [GeForce MX150] vendor: Xiaomi Mi Notebook Pro driver: nvidia 
          v: 435.17 bus ID: 01:00.0 chip ID: 10de:1d12 
          Display: x11 server: X.Org 1.20.5 driver: intel,nvidia compositor: kwin_x11 
          resolution: 1920x1080~60Hz, 1920x1080~60Hz 
          OpenGL: renderer: GeForce MX150/PCIe/SSE2 v: 4.6.0 NVIDIA 435.17 direct render: Yes
1 Like

well done :star_struck:

your config works perfectly with the intel driver, no more modesetting nightmare. i obviously wrote my config wrong when i tried it. no more tearing. :+1:

1 Like

Hey man, you are welcome :hugs:
I dropped it yesterday but you might have missed that (this thread is a mess).

By the way, "glamoregl" loads if using modesetting as Driver, and not if using intel:
$ cat /var/log/Xorg.0.log | grep -E "glamoregl"
[ 22.677] (II) Loading sub module "glamoregl"
[ 22.677] (II) LoadModule: "glamoregl"
[ 22.677] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[ 22.686] (II) Module glamoregl: vendor="X.Org Foundation"

But this fact has no impact on actual performance of offloading. Weird.

that not a good name command , think we need an alias

1 Like

Followed your procedure and everything seems to work fine here. KDE, intel/nvidia (obviously) and linux5.2.
Fans are a little noisy but it should be for the nvidia card always on, hoping that in future they will add the possibility to fully power off the card on non-turing too.

Thanks for sharing. I'll continue to testing and report if something change.

most definitly, i already added vkr for vulkan and nvr for opengl to my .zshrc .


vkr vkcube and nvr glxgears both working, running on render offload on the intel driver. no more tearing now that @openminded figured out using the intel driver instead of modesetting. which i previously forgot to say thank you btw.


What's with the intput lag?
I'm using nvidia-xrun right now.
For most games I use drm_modeset=1 but when it comes to shooters where every microsecond counts, I have to disable it, because it brings a noticeable input delay with it which makes shooters basically unplayable.
So modeset 1 means no input delay but tearing and without it means smooth frames without being able to play competitive.
On Windows I could offload and have zero delay and butter smooth frames.
If this new method doesn't bring this to the table but introduces new problems, I'll stick to nvidia-xrun.

1 Like

so far, any time i've even tried to use drm modeset i wasnt able to get xorg to start. i only tried loading 1 game so far on my install i have this setup on, borderlands 2 and it's performance on render offload was not so great, but to be fair i didnt put much effort into fixing it either, it was just a quick functionality test.

@openminded one thing i did notice was that offloading to the intel driver instead of modesetting, glxgears runs fine, but glxgears_pixmap shows it's usual thousands of FPS but the window is black, no image at all. can you confirm this when you get a chance.

Yeah, same here. Is it critical? I've tried only 2 games - a native one with Vulkan (Dota2) and Proton-powered OpenGL another one (old Warhammer 40K Dark Crusade). Both were working fine.

im not exactly sure what the difference is between glxgears and glxgears_pixmap but the only game i've tested (briefly) was native borderlands 2 and it was struggling on medium/low settings. on my prime setup it runs great on high settings. i'll have to try different intel driver options, "TearFree" comes at a cost on the intel driver, and prime uses modesetting but it's able to use prime sync so it fixes the tearing issues i have with the modesetting driver. i was not able to get prime sync to work with render offload, enabling it always ended in xorg failing to start.

if anyone is using these new drivers, could you try running a vulkan game with vsync enabled and see if it's working properly.

i'm using a PRIME setup, not this new "render offload" feature but i think it has something to do with the combination of the new 435.* drivers + vulkan + vsync. results in an unusable setup. further explanation

I got 435 + vulkan + vsync. Im on gnome and modesetting driver with nvidia offload. Everything is fine at here ^^

the problem happens with the combination of prime+vulkan+vsync on 435 drivers. render offload, while a good thing that nvidia is doing something for hybrid graphics on linux is also not very practical because even when your not using the nvidia gpu it has to remain powered on because the xorg process needs to be run on the nvidia for offload to work.

for everyday use you end up using the power cost of 2 gpu's while only getting the benefit of 1 unless you run the program using the launch variable.

i dont have concrete benchmarks but comparing the performance between prime and offload also didnt fare well for render offload.

red faction: remarstered on render offload and no vsync struggled to get 50+ fps while on prime with vsync disabled it easily hits 70+ fps. (identical settings, stock clock/mem)

offload also will not work with coolbits, so no fan or clocking capabilities. aside from the novelty of it being the latest shiny & new thing available, it's really nothing to get excited over and was more disappointing than anything else in it's current state so i'll be sticking to a prime setup and possibly add the functionality of a third mode to optimus-switch for this render offload so i can easily switch back and forth to check the progress on it if any.


I would also like to test how this works but my hardware is old (nvidia390xx).

I thought it was supposed to replace the "bumblebee" method, without the auto-select feature, like using optirun/primusrun. Similar... I think I've read some nvidia notes with Power Saving configuration on the new driver feature. Maybe the power consumption is better controlled? Wishes... I know... :disappointed_relieved:

1 Like

Turing cards are suppose to have better power management to use less power, but can never be powered off (using offload) because xorg needs to run on it.

dont worry, your not missing much. i'm hoping for a true on-demand optimus setup like on windows but this is definitely not it.

if the card remaining on was the only downside i wouldnt care, but losing performance, losing coolbits, on top of having the nvidia gpu powered on doing nothing but wasting power until launching with a parameter is silly. with prime both cards remain on, performance is better, no launch variables are needed.

on the upside with this new render offload it seems the black screen issues that come with fumblebee are a non issue so making it the default setup for 435.xx driver compatible installs makes perfect sense. even when removing any video .conf file from /etc/X11/xorg.conf.d i was still met with a desktop and thats much better than i can say for crumblebee :wink:


With all this situation of nvidia beta primus driver needing to run both GPUs all the time to get primus working because xorg, I have read than wayland is supposed to provide a better environment for switchable cards.
I wonder if nvidia is planning to do a primus implementation in linux that is comparable in power usage to the one done in windows, so they will probably have to do it in wayland. I wonder if they are even considering doing this work for wayland as well.

So seems to be that last testing update deleted any trace of nvidia drivers. Then I guess this is the chance I have to try this new functionality before I go find my USB driver to format manjaro.

Then, at this point, what do I have to do to try the new prime stuff in my optimus laptop? First thing I though was to search for the driver in MHWD, but there is nothing here


then what can I do?

i dont think nvidia is in there future plans. if the nvidia driver is loaded and you want to start sway you need to use the the flag sway --my-next-gpu-wont-be-nvidia :rofl: or it refuses to run.

remove any configurations left behind by your previous setup, install the 435 driver package
mhwd -i pci video-nvidia-435xx

then this
1 Like

Hey, thanks a lot, it worked surprisingly flawlessly.

1 Like

Black screen comes with Bumblebee sometimes but not because of Bumblebee. It happens due to current implementation. What mhwd Bumblewee options lack is adding i915 to the list of modules in mkinitcpio.conf and regenerating of initramfs when selecting video-hybrid-intel-nvidia-bumblebee (or whatever it's called). In fact, this should be a must for Intel driver if system is configured to use i915 as primary display driver since it also makes external monitors' early initialisation (not critical, but anyway). Inclusion of i915 to the list of modules does not prevent using of modesetting, nouveau or nvidia drivers. It is harmless (to the best of my knowledge) for any system with or without Intel graphics.


Forum kindly sponsored by