NVIDIA 435 driver looks exciting

Are you using the correct driver?

Also keep in mind that this is still in the experimental stage so you'll need to do a little experimentation yourself.

Well we have to see on how we make this a default by not breaking systems

anyone able to get prime sync functional to fix the tearing issues?

Make it separate in mhwd and the such, just like you do/did with bumblebee and old-prime?

With a warning popup maybe.

I've never experienced tearing on my hardware, so I might sound noobish, but have you tried setting options nvidia-drm modeset=1 in /etc/modprobe.d/nvidia.conf (for instance) and adding that file to /etc/mkinitcpio.conf? By the way, it would be nice if you'd shared your mkinitcpio.conf. Mine has these strings btw:

MODULES=(intel_agp i915 tpm vfat crc32c_intel)
FILES=(/etc/modprobe.d/hid_apple.conf /etc/modprobe.d/i915.conf /etc/modprobe.d/nvidia.conf)
HOOKS=(base udev keyboard consolefont plymouth autodetect modconf block tpm2 plymouth-encrypt resume filesystems)

[the third line has no relation to what we discuss here though]

Interesting outcome of some fiddling around new Xorg / Nvidia driver:
I've installed xf86-video-intel and set it to xorg.conf this way:

xorg.cong
Section "OutputClass"
  Identifier "intel"
  MatchDriver "i915"
  Driver "intel"
  Option "TearFree" "true"
  Option "AccelMethod" "sna"
EndSection

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

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

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

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

Here is how it looks:

inxi -G
┬─[openm@reiwa:~]─[12:58:20]
╰─>$ env __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia inxi -G
Graphics:  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel 
           Device-2: NVIDIA GP108M [GeForce MX150] driver: nvidia v: 435.17 
           Display: x11 server: X.Org 1.20.5 driver: intel,nvidia 
           resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: renderer: GeForce MX150/PCIe/SSE2 v: 4.6.0 NVIDIA 435.17 
┬─[openm@reiwa:~]─[12:58:23]
╰─>$ inxi -G
Graphics:  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel 
           Device-2: NVIDIA GP108M [GeForce MX150] driver: nvidia v: 435.17 
           Display: x11 server: X.Org 1.20.5 driver: intel,nvidia 
           resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) v: 4.5 Mesa 19.1.4

PS: However, it turns out that disabling modeset with i915.modeset=0 results in SDDM's failure to start (even though I've set intel as shown above):

$ journalctl --no-pager --no-hostname -xb -1 -p3
-- Subject: Process 1586 (sddm) dumped core
-- Defined-By: systemd
-- Support: https://forum.manjaro.org/c/technical-issues-and-assistance
-- Documentation: man:core(5)
-- 
-- Process 1586 (sddm) crashed and dumped core.
-- 
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.
Aug 17 15:19:34 sddm[1601]: Failed to read display number from pipe
Aug 17 15:19:34 sddm[1601]: Display server failed to start. Exiting
Aug 17 15:19:34 systemd-coredump[1612]: Process 1601 (sddm) of user 0 dumped core.
                                        
                                        Stack trace of thread 1601:
                                        #0  0x00007f5883095755 raise (libc.so.6)
                                        #1  0x00007f5883080851 abort (libc.so.6)
                                        #2  0x00007f58834a98b6 _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5)
                                        #3  0x00005559a67b90f5 n/a (sddm)
                                        #4  0x00005559a67fdebe _ZN4SDDM4Seat13createDisplayEi (sddm)
                                        #5  0x00005559a67fe102 _ZN4SDDM4SeatC2ERK7QStringP7QObject (sddm)
                                        #6  0x00005559a68000c1 _ZN4SDDM11SeatManager10createSeatERK7QString (sddm)
                                        #7  0x00005559a6800ee2 n/a (sddm)
                                        #8  0x00007f58836ddb70 _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
                                        #9  0x00005559a67ff130 _ZN4SDDM10LogindSeat19canGraphicalChangedEb (sddm)
                                        #10 0x00005559a67ff443 n/a (sddm)
                                        #11 0x00007f58836ddb70 _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
                                        #12 0x00007f58840dfd00 _ZN23QDBusPendingCallWatcher8finishedEPS_ (libQt5DBus.so.5)
                                        #13 0x00007f58840dfe01 n/a (libQt5DBus.so.5)
                                        #14 0x00007f58836de44a _ZN7QObject5eventEP6QEvent (libQt5Core.so.5)
                                        #15 0x00007f58836b19a0 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5)
                                        #16 0x00007f58836b4739 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5)
                                        #17 0x00007f588370a3a4 n/a (libQt5Core.so.5)
                                        #18 0x00007f5881eeccf4 g_main_context_dispatch (libglib-2.0.so.0)
                                        #19 0x00007f5881eeeb11 n/a (libglib-2.0.so.0)
                                        #20 0x00007f5881eeeb51 g_main_context_iteration (libglib-2.0.so.0)
                                        #21 0x00007f58837099a3 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                        #22 0x00007f58836b05ec _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                        #23 0x00007f58836b8326 _ZN16QCoreApplication4execEv (libQt5Core.so.5)
                                        #24 0x00005559a67bc8da main (sddm)
                                        #25 0x00007f5883081ee3 __libc_start_main (libc.so.6)
                                        #26 0x00005559a67bcbde _start (sddm)
                                        
                                        Stack trace of thread 1602:
                                        #0  0x00007f588314c667 __poll (libc.so.6)
                                        #1  0x00007f5881eeea80 n/a (libglib-2.0.so.0)
                                        #2  0x00007f5881eeeb51 g_main_context_iteration (libglib-2.0.so.0)
                                        #3  0x00007f58837099a3 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                        #4  0x00007f58836b05ec _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                        #5  0x00007f58834e32f5 _ZN7QThread4execEv (libQt5Core.so.5)
                                        #6  0x00007f588407bb37 n/a (libQt5DBus.so.5)
                                        #7  0x00007f58834e4520 n/a (libQt5Core.so.5)
                                        #8  0x00007f588304357f start_thread (libpthread.so.0)
                                        #9  0x00007f58831570e3 __clone (libc.so.6)

Also modesetting prevents GuC from loading even if I set intel as Driver (above):

$ journalctl --no-pager --no-hostname -xb -g GuC
-- Logs begin at Mon 2019-08-12 22:26:38 +10, end at Sat 2019-08-17 15:21:22 +10. --
Aug 17 15:20:24 kernel: [drm] Incompatible option detected: enable_guc=3, GuC submission not support
ed!
Aug 17 15:20:24 kernel: [drm] Switching to non-GuC submission mode!
Aug 17 15:20:24 kernel: [drm] GuC: Loaded firmware i915/kbl_guc_32.0.3.bin (version 32.0)
Aug 17 15:20:24 kernel: i915 0000:00:02.0: GuC firmware version 32.0
Aug 17 15:20:24 kernel: i915 0000:00:02.0: GuC submission disabled

And again, I have no tearing neither with intel nor with modesetting. As well as with or without nvidia-drm modeset=1.

Frankly, all these is such a mess. My head is overfilled with these random things, methods, workarounds,etc. Just because Nvidia has added one more way to torture the community instead of implementing Windows-like Optimus mechanism. This is why I like Bumblebee. This is how Nvidia approach should look like. Windows doesn't need relogins or killing graphics in order to launch something on Nvidia card. And yeah, this is why I will never buy Nvidia again anyway.

Can this be confirmed? I am on NVIDIA PRIME.

1 Like

I think yes. I am using linux419-nvidia version 1:435.17-1

Edit: I fixed the problem by moving xorg.conf from /usr/share/X11 to /etc/X11 and moving 10-nvidia-drm-outputclass.conf from /usr/share/X11/xorg.conf.d to /etc/X11/xorg.conf.d

PRIME synchronization still doesn't work for me on this beta driver.
I've tried every kind of configuration and tweaks I could think of but nothing can fix the tearing issue.
I'm tired of seeing the screen tearing and this message on the Xorg log.

randr: falling back to unsynchronized pixmap sharing

Thankfully, this new PRIME offload works just fine and a lot easier to setup. The most important thing is there is no noticable screen tearing at all.
The only thing I wish Nvidia did for now is the ability to turn off their GPU on my system. The "hacky" ways like bbswitch and acpi_call are not working on my machine.

I've updated the config file for Intel. Can this been checked? Also it would be great to know if installing the AMD config on a Intel-System without AMD hardware might break things. Please also test the other way around.

This is exactly what I use since yesterday. No issues.

As for AMD config, I'm kinda puzzled. What is it? /etc/X11/xorg.cong.d/somefile.conf? Or /usr/share/X11/xorg.cong.d/10-nvidia-drm-outputclass.conf?

@philm Ah OK. Will try now and see.

currently the author named it 99-amd-nvidia-prime-offload.conf. Should be placed in /usr/share/X11/xorg.conf.d/. I'll check now why we have now two config files ...

Absolutely no impact on Intel/Nvidia system. I mean that AMD-related file. Tried with both modesetting and intel set as drivers in xorg.conf. But. I have no xf86-video-amdgpu installed (for obvious reasons). From the other side, it is a kernel driver, right, so anyway.
Of course proper xorg.conf is needed to have everything working fine.

OK, so I'll try to add it somehow by default so we see how people will react.

As I already wrote in the announcement thread, 435.17 is noticeably slower here (dedicated single graphics card) with KDE.
Investigating...

Graphics:  Device-1: NVIDIA GP104 [GeForce GTX 1070] driver: nvidia v: 435.17 
           Display: x11 server: X.Org 1.20.5 driver: nvidia resolution: 1920x1200~60Hz, 2560x1440~60Hz 
           OpenGL: renderer: GeForce GTX 1070/PCIe/SSE2 v: 4.6.0 NVIDIA 435.17

I've been in contact with the author of that AMD-specific Xorg configuration and he said that this seems to be the best way to support both AMD and Intel integrated GPU.

Section "ServerLayout"
    Identifier "layout"
    Option "AllowNVIDIAGPUScreens"
EndSection

# You can remove this section if you don't have AMD iGPU
Section "Device"
  Identifier "AMDGPU"
  Driver "amdgpu"
  Option "TearFree" "true"
EndSection

Section "OutputClass"
    Identifier "iGPU"
    MatchDriver "i915|amdgpu"
    Driver "modesetting"
EndSection

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

But still, we need someone who can verify that this configuration works since we don't have access to Manjaro system with Intel processor right now.

Please give me guide how to safety manually moving from

video-hybrid-intel-nvidia-bumblebee

to PRIME (and yes - I know about guide from @jonathon, but I don't have IDEA if this is actually or not :heart_decoration:

Thanks. I have an Intel + NVIDIA here - so I can TEST.

this , see with @dglt

add tutorial Jonathon

Hm...
The conf you posted is supposed to be the content of 10-nvidia-drm-outputclass.conf, right? I can check it.

@dglt said this is OUT OF DATE for current 435.17 :wink:

# You can remove this section if you don't have AMD iGPU
Section "Device"
  Identifier "AMDGPU"
  Driver "amdgpu"
  Option "TearFree" "true"
EndSection

Should this not been optional? Default config should be as generic as possible and don't break things.

Forum kindly sponsored by Bytemark