How do I install (nvidia/suse) Prime using the Nouveau driver on my Asus Optimus laptop?

My readings show:

“The open-source nouveau driver (xf86-video-nouveau) can dynamically switch with the Intel driver (xf86-video-intel) using a technology called PRIME.”

“If you don’t choose to the use the proprietary NVIDIA driver, however, the open-source Nouveau driver does actually provide most of the Optimus functionality out of the box through a technology called PRIME. You may have to still execute a line or two of commands in a terminal, but it is arguably the easiest and most out of the box solution. See this Arch Linux wiki entry on PRIME for more information. The downside is obvious though - Nouveau will suffer dramatically in terms of performance compared to the proprietary NVIDIA driver and has no power-saving features either.”

Situation:

To install openSUSE Leap, Tumbleweed or run a liveDVD/CD on my Asus laptop, I have to use “nouveau.modeset=0” as a kernel parameter which is then written to the kernel boot code. So, by default, I am booting to the Intel driver and I my Nvidia card is turned off.

I do have xf86-video-nouveau, xf86-video-intel and Mesa-dri-nouveau - Mesa DRI plug-in for 3D acceleration via Nouveau installed.

(This package contains nouveau_dri.so, which is necessary for Nouveau’s 3D acceleration to work. It is packaged separately since it is still experimental.)

Questions:

How do I go about activating Nouveau Prime in Leap 42.2 and Tumbleweed?

Do I need both xf86-video-nouveau and Mesa-dri-nouveau?

Is it as simple as issuing:
$ xrandr --setprovideroffloadsink nouveau Intel

Thoughts?

Hi, before going any further please check that the current nouveau driver supports your Nvidia GPU.
I am sure that the current nouveau in Leap 42.2 DOESN’T SUPPORT Maxwell chips like the GTX960M you should have on your laptop.
Not sure about current TW though, but the last time I checked it didn’t support those chips yet.

Roger that! I never thought to check; many thanks!

These are worth a read:

 	 	 	   https://nouveau.freedesktop.org/wiki/CodeNames/

This page contains a list of some NVIDIA chip code names and their corresponding official GeForce number. If you’re running a recent version nouveau, you can find your chipset by doing dmesg | grep -i chipset. This will always be correct, whereas the lists below are approximate.
Be aware that this list may be outdated and incomplete. Nouveau aims to support all NVIDIA cards, but no effort is made to document which cards (and BIOSes) actually work, as this is deemed infeasible. Just try it and submit bug reports if it doesn’t work.
NV110 family (Maxwell) | NV124 (GM204)
|
| GeForce GTX (970, 980)
|
| NV126 (GM206)
| GeForce GTX (950, 960)
|

http://www.phoronix.com/scan.php?page=news_item&px=MTg1MjU

  • Initial GM204 GPU support. The GM204 is the new Maxwell GPU found with the GeForce GTX 970 / GeForce GTX 980. However, this initial GeForce GTX 900 series support is limited to just mode-setting. Nouveau developers are still waiting on NVIDIA to provide the necessary signed firmware images for being able to properly initialize the hardware for GPU acceleration.

http://www.phoronix.com/scan.php?page=news_item&px=MTg4NTg

While the Linux 3.19 support for the GTX 970/980 support just comes down to mode-setting, I decided to try it anyways to verify it worked for both of my graphics cards given I’ve ran into plenty of Nouveau mode-setting troubles with other hardware in the past. Fortunately, everything worked out fine for the eVGA GeForce GTX 970 and the GeForce GTX 980 reference samples I was testing with – using HDMI and dual-link DVI displays. The Ubuntu 14.10 box that was running Linux 3.19 Git had no troubles with getting mode-setting done right for these new graphics processors while falling back to using the LLVMpipe Gallium3D driver.

This support in Linux 3.19 though is just limited to kernel mode-setting with no hardware acceleration being in place for this release.
From a hardware perspective, these new NVIDIA products are terrific and yield great performance, big improvements in power efficiency, etc.

The next rainy day that I am not working I’ll give it a confidence try – without frying my memory/registers.

Now to find out the best way to do do it!

That’s exactly the point: no acceleration yet. So, while you should be able to render something on the Nvidia+nouveau, the last time I checked with a kernel 4.8 nouveau rendered openGL benchmarks 2 to 4 times slower than integrated graphics with artifacts and occasional glitches.
If you still want to see for yourself, with a recent kernel and Mesa (DRI3) you should be able to do that by just prepending “DRI_PRIME=1” to a command, like in:


DRI_PRIME=1 glxgears

Please be aware that NO bumblebee NOR suse-prime (nor Nvidia drivers, of course) must be installed for the above to work.
AFAIK, Nvidia have already released the blobs needed to drive Maxwell chips with nouveau, so this situation is going to change sooner or later.

I tried “DRI_PRIME=1 glxgears” With a Tumbleweed release 20170119, and it threw 3 error initializing; I was able to reboot and continue. Also, I had no external monitors connected.

I did a clean install with 20170121 and a zypper dup to sync; I got all new Mesa RPMs including a new mesa-nouveru.

Here is my NVIDIA GM107M [GeForce GTX 960M] on Nouveau with no errors:

DRI_PRIME=1 glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
439 frames in 5.0 seconds = 87.718 FPS
301 frames in 5.0 seconds = 60.007 FPS
301 frames in 5.0 seconds = 60.003 FPS
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"  -- think that is when I closed the window.

Here is my Intel HD Graphics 530 card results:

glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
351 frames in 5.0 seconds = 69.996 FPS
301 frames in 5.0 seconds = 60.002 FPS
301 frames in 5.0 seconds = 60.003 FPS
301 frames in 5.0 seconds = 60.001 FPS
301 frames in 5.0 seconds = 60.004 FPS
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"

So, obviously as of now, there is no reason to run an app with nouveau with the current system-- as OrsoBruno tried to tell me earlier.

I did read that with an earlier release that one could copy over the firmware and some code from the popietary driver and get accell; but, that is beyond my skill set & probably illegal.

Have fun & press on!

Hi, you are seeing the video refresh rate of your screen… try:


DRI_PRIME=1 vblank_mode=0 glxgears

to see what the maximum speed is, or even better with glxspheres… but the conclusion remains the same.

Wow:

 DRI_PRIME=1 vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
41419 frames in 5.0 seconds = 8283.692 FPS
44064 frames in 5.0 seconds = 8812.776 FPS
43649 frames in 5.0 seconds = 8729.594 FPS
43130 frames in 5.0 seconds = 8625.914 FPS
40030 frames in 5.0 seconds = 8005.829 FPS
37926 frames in 5.0 seconds = 7585.124 FPS
42755 frames in 5.0 seconds = 8550.884 FPS
42049 frames in 5.0 seconds = 8409.728 FPS
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 354608 requests (38 known processed) with 0 events remaining. -- from when I closed the window!

DRI_PRIME=1 vblank_mode=0 glxspheres
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
Visual ID of window: 0xb4
Context is Direct
OpenGL Renderer: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) 
349.886591 frames/sec - 390.473436 Mpixels/sec
268.320621 frames/sec - 299.445813 Mpixels/sec
272.383528 frames/sec - 303.980017 Mpixels/sec
272.488501 frames/sec - 304.097167 Mpixels/sec
264.387546 frames/sec - 295.056501 Mpixels/sec
265.266375 frames/sec - 296.037275 Mpixels/sec
268.582268 frames/sec - 299.737811 Mpixels/sec
256.790737 frames/sec - 286.578463 Mpixels/sec
250.692425 frames/sec - 279.772746 Mpixels/sec
252.405260 frames/sec - 281.684270 Mpixels/sec
253.714879 frames/sec - 283.145805 Mpixels/sec
252.554118 frames/sec - 281.850396 Mpixels/sec
250.905304 frames/sec - 280.010319 Mpixels/sec

Compared to a late proprietary driver using suse-prime-alt on an earlier install{

: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0xa1
Context is Direct
OpenGL Renderer: GeForce GTX 960M/PCIe/SSE2
1980.588234 frames/sec - 2210.336469 Mpixels/sec
2018.783649 frames/sec - 2252.962552 Mpixels/sec
2022.322083 frames/sec - 2256.911445 Mpixels/sec
2023.751754 frames/sec - 2258.506957 Mpixels/sec
1988.688490 frames/sec - 2219.376355 Mpixels/sec
1865.613027 frames/sec - 2082.024138 Mpixels/sec
1869.932240 frames/sec - 2086.844380 Mpixels/sec
jim@localhost:~> 

And compared to the sole Intel HD Graphics 530 & driver:

glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
332 frames in 5.0 seconds = 66.255 FPS
301 frames in 5.0 seconds = 60.006 FPS
301 frames in 5.0 seconds = 60.003 FPS
301 frames in 5.0 seconds = 60.003 FPS
301 frames in 5.0 seconds = 60.004 FPS
301 frames in 5.0 seconds = 60.004 FPS

Well pleased-- looking great too! This is from a clean Tumbleweed install and “zypper dup” – I did add virtualgl & a few utulities; basically a clean install.

for reference:

inxi -G
Graphics:  Card-1: Intel HD Graphics 530
           Card-2: NVIDIA GM107M [GeForce GTX 960M]
           Display Server: X.Org 1.19.1 drivers: modesetting (unloaded: fbdev,vesa,intel)
           Resolution: 1920x1080@60.00hz
           GLX Renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2) GLX Version: 3.0 Mesa 13.0.3

No, there is acceleration* … performance is just not good on the devices** because they’re stuck at default boot clocks.

  • NVC0 supports Maxwell. Pascal has no signed firmwares, so no support.
    ** Maxwell 750 series have (manual/static) clock support, and hence are performant. The later 900 series do not, and hence they (to use some highly technical terminology) “blow goats”

don’t use gears as a benchmark across drivers, OSes, etc. etc.

And compared to the sole Intel HD Graphics 530 & driver:

glxgears
Running synchronized to the vertical refresh. 

Does making two wrongs make a right? rotfl! – first wrong is comparing nvidia vs intel, second was running the nvidia without synch and intel with synch

Thanks for that clue. However I see no gm10x folder here, apparently needed to drive a GTX960M (AKA GM107M):


bruno@LT_B:~> ls /lib/firmware/nvidia
gk20a  gm200  gm204  gm206  gm20b  tegra124  tegra210
bruno@LT_B:~>

So I guess I see little if any effective acceleration on my GPU; or am I missing something?

it doesn’t need a signed blob. They (nvidia) intoduced the requirement after the first generation/class of Maxwells.

OK, clear now. The GTX960M is just crawling at 135MHZ instead of the maximum 1202MHz.
In the end, no use for bumblebee or prime with nouveau: integrated graphics will always beat that.

(Software rendering via) llvmpipe would likely also be quicker.

But your device should support manual reclocking!

cat /sys/kernel/debug/dri/N/pstate

N = adapter number, from 0 to …

echo pstate_value > /sys/kernel/debug/dri/N/pstate

pstate_value is one of the available states you found above.

Also see if your device can make use of NvBoost boot option

Good news for snakedriver: nouveau is no dead wood on the GTX960M! Indeed it supports manual reclocking, with 3 options:
07 405 MHz clock, 810 MHz memory; default, don’t try to set that as your first option, or the power switch will be your friend;
0a 270-1202 MHz clock, 1600 MHz memory;
0f 270-1202 MHz clock, 5010 MHz memory.
That chip doesn’t seem to take advantage ov NvBoost, but I didn’t check with a 4.10 kernel yet.
I checked with a liveCD sporting a 4.8.15 kernel and got the following results with the three settings, respectively.


~ $ DRI_PRIME=1 vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
30134 frames in 5.0 seconds = 6026.634 FPS
...
63228 frames in 5.0 seconds = 12645.484 FPS
...
81998 frames in 5.0 seconds = 16399.582 FPS
~ $

As a benchmark, the Haswell Mobile on the same laptop gave:


~ $ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
67285 frames in 5.0 seconds = 13456.995 FPS
~ $

More meaningful OpenGL tests like GpuTest 0.7.0 ( http://www.geeks3d.com ) gave mixed results.
PRIME-nouveau smoked integrated on wireframe tests like plot3d @ 1920x1080:


Haswell 5392 points  89 fps
nv@07   8506 points 141 fps
nv@0a  14072 points 234 fps
nv@0f  15707 points 262 fps

but lagged behind no-matter-what on other shader tests, e.g. furmark @ 1920x1080:


Haswell 382 points  6 fps
nv@07   184 points  3 fps
nv@0a   252 points  4 fps
nv@0f   253 points  4 fps

Now I think that our friend snakedriver has something to spend next weekend on :wink:
Have Fun.

Since Tyler_K’s & OrsoBruno’s posts,I have not been idle; but with little success.

If I look in /sys/kernel/debug/dri I have the following:

/sys/kernel/debug/dri # dir
total 0
drwxr-xr-x 6 root root 0 Jan 29 20:36 0
drwxr-xr-x 2 root root 0 Jan 29 20:36 128
drwxr-xr-x 2 root root 0 Jan 29 20:36 64

And, when I “cat /sys/kernel/debug/dri/N/pstate”, I get:

cat: /sys/kernel/debug/dri/0/pstate: No such file or directory
localhost:~ # cat /sys/kernel/debug/dri/128/pstate
cat: /sys/kernel/debug/dri/128/pstate: No such file or directory
localhost:~ # cat /sys/kernel/debug/dri/64/pstate
cat: /sys/kernel/debug/dri/64/pstate: No such file or directory

/sys/kernel/debug/dri/0/pstate is densely populated, but, no pstate

But, in dmesg – find pstate


     2.027160] intel_pstate: Intel P-state driver initializing
    2.027643] intel_pstate: HWP enabled

and, I,m scratching my head – as I was wondering if my DSDT was providing it!

I have found the following readings:

https://nouveau.freedesktop.org/wiki/Nouveau: Accelerated Open Source driver for nVidia cards

Experimental support for manual performance level selection (also known as “reclocking”) on GM10x Maxwell, Kepler and Tesla G94-GT218 GPUs. Starting Linux 4.5, available in /sys/kernel/debug/dri/0/pstate, previously boot with nouveau.pstate=1 and use /sys/class/drm/card0/device/pstate.

(But again, I get:

# echo 0f > /sys/class/drm/card0/device/pstate
-bash: /sys/class/drm/card0/device/pstate: Permission denied

)

https://www.phoronix.com/scan.php?page=news_item&px=linux-4.5-nouveu-pstate-howtoHow To Enable Nouveau GPU Re-Clocking For Linux 4.5+ Kernels

With being over on debugfs, you no longer need to set nouveau.pstate=1 as a kernel command-line parameter to access this interface.

Rather than the pstate interface being within /sys/class/drm/card0, you can now access it from /sys/kernel/debug/dri/0/pstate (assuming it’s your first GPU on the system). The rest of the layout of pstate on debugfs is the same as its prior sysfs implementation.

http://www.phoronix.com/scan.php?page=article&item=nouveau-410-nvboost&num=1Testing Nouveau’s Open-Source NVIDIA Support On Linux 4.10 With NvBoost

With Linux 4.10, NvBoost can be turned on by setting nouveau.config=NvBoost=2 when booting the kernel.

I tried all of those hints…

I fiind that http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/provides kernel-4.10.rc5-2.1*
I will give that a try as time permitslol!

Lastly, I see that kernel 4.10 is due for release mid-Feb unless they have to have an rc8 – only getting better!

And, thanks for all the help!

Those are all copies of the Intel GPU; your Nvidia GPU seems switched off for whatever reason. Here is what I get from a TW 2016-10-31 live DVD:


nohostname:/home/linux # ls -l /sys/kernel/debug/dri
total 0
drwxr-xr-x 2 root root 0 Jan 30 15:52 0
drwxr-xr-x 6 root root 0 Jan 30 15:52 1
drwxr-xr-x 2 root root 0 Jan 30 15:52 128
drwxr-xr-x 2 root root 0 Jan 30 15:52 129
drwxr-xr-x 2 root root 0 Jan 30 15:52 64
drwxr-xr-x 2 root root 0 Jan 30 15:52 65
nohostname:/home/linux # cat /sys/kernel/debug/dri/0/pstate
07: core 405 MHz memory 810 MHz
0a: core 270-1202 MHz memory 1600 MHz
0f: core 270-1202 MHz memory 5010 MHz
AC: core 0 MHz memory 0 MHz
nohostname:/home/linux # cat /sys/kernel/debug/dri/64/pstate
07: core 405 MHz memory 810 MHz
0a: core 270-1202 MHz memory 1600 MHz
0f: core 270-1202 MHz memory 5010 MHz
AC: core 0 MHz memory 0 MHz
nohostname:/home/linux # cat /sys/kernel/debug/dri/128/pstate
07: core 405 MHz memory 810 MHz
0a: core 270-1202 MHz memory 1600 MHz
0f: core 270-1202 MHz memory 5010 MHz
AC: core 0 MHz memory 0 MHz
nohostname:/home/linux # 

I finally got it turned onrotfl!

cd /sys/kernel/debug/dri
localhost:/sys/kernel/debug/dri # dir
total 0
drwxr-xr-x 6 root root 0 Jan 30 22:20 0
drwxr-xr-x 2 root root 0 Jan 30 22:20 1
drwxr-xr-x 2 root root 0 Jan 30 22:20 128
drwxr-xr-x 2 root root 0 Jan 30 22:20 129
drwxr-xr-x 2 root root 0 Jan 30 22:20 64
drwxr-xr-x 2 root root 0 Jan 30 22:20 65

and only found pstate in the following:

# cat /sys/kernel/debug/dri/1/pstate
07: core 405 MHz memory 810 MHz
0a: core 270-1202 MHz memory 1600 MHz
0f: core 270-1202 MHz memory 5010 MHz
AC: core 0 MHz memory 0 MHz

# cat /sys/kernel/debug/dri/65/pstate
07: core 405 MHz memory 810 MHz
0a: core 270-1202 MHz memory 1600 MHz
0f: core 270-1202 MHz memory 5010 MHz
AC: core 0 MHz memory 0 MHz

# cat /sys/kernel/debug/dri/128/pstate
cat: /sys/kernel/debug/dri/128/pstate: No such file or directory
localhost:/sys/kernel/debug/dri # cat /sys/kernel/debug/dri/129/pstate
07: core 405 MHz memory 810 MHz
0a: core 270-1202 MHz memory 1600 MHz
0f: core 270-1202 MHz memory 5010 MHz
AC: core 0 MHz memory 0 MHz

# xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x76 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 4 associated providers: 0 name:modesetting
Provider 1: id: 0x3f cap: 0x5, Source Output, Source Offload crtcs: 0 outputs: 0 associated providers: 0 name:modesetting

I also tried kernel 4.10-rc5, but found that it was not uefi signed.

now to have fun…Many thanks to the pro’s!