xubuntu@xubuntu:~$ glxinfo | grep NVIDIA
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation OpenGL core profile version string: 4.6.0 NVIDIA 390.48 OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 390.48
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.48
xubuntu@xubuntu:~$ glxgears
Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate.
69297 frames in 5.0 seconds = 13859.334 FPS
68090 frames in 5.0 seconds = 13617.823 FPS
xubuntu@xubuntu:~$ glxspheres64 Polygons in scene: 62464 (61 spheres * 1024 polys/spheres) Visual ID of window: 0xa8 Context is Direct OpenGL Renderer: GeForce GTX 860M/PCIe/SSE2
1914.953887 frames/sec - 2137.088538 Mpixels/sec
1964.035952 frames/sec - 2191.864122 Mpixels/sec
The Tim Richardson’s GitHub project is awesome and it works well for me on Linux Mint 19 Cinnamon. I use prime-indicator-plus to switch video cards. And the beautiful part is now the system remembers the chosen VGA between reboots. I also use .service to start the Nvidia card just before shutdown or reboot in order to get proper reboot command which otherwise is broken. Thank you!!! Now everything works just as I want!
How does the prime-indicator applet know to use the modified prime-select script and not the standard one? The standard one is still there, the modified one goes in /usr/local/bin which has precedence in the path, perhaps the applet looks at the user path; did you do anything?
mozo, I think Mint 19 uses an older version of nvidia-prime, which doesn’t require a restart to begin with, so prime-indicator-plus might be using the provided prime-select and working fine right out of the box regardless of Tim’s solution.
What does
dpkg -l nvidia-prime
say?
The problems were introduced after version 0.8.5, according to their github they’re using version 0.8.2.
No, I tried it right after the upgrade and switching GPU’s was really slow. Switching off the Nvidia discrete GPU doesn’t worked at all even with manual bbswitch via terminal. After I followed the steps from Tim Richardson’s GitHub page, it now working great - I can switch GPUs fast, without restart (only with logout), I can switch off the Nvidia card via prime-indicator-plus menu and this choise is remembered between restarts. dpkg -l nvidia-prime says:
mozo@mozo ~ $ dpkg -l nvidia-prime
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii nvidia-prime 0.8.8 all Tools to enable NVIDIA's Prime
I’d be surprised if Mint 19 is different to ubuntu 18.04, since the entire packaging of Nvidia drivers changed too (in a good way), so Mint would be committing itself to a big chunk of non-18.04 Ubuntu if the devs stayed with the 16.04 approach. It’s possible, of course, but it seems unlikely.
The upside is that the ‘MathieuGras-TimRichardson’ approach will work the same for Mint 19 as in Ubuntu 18.04
In Ubuntu 18.04, I experimented with symlinking /usr/bin/prime-select to my modified version (/usr/local/bin/prime-select) and after that the intel/nvidia profile switching in the nvidia control panel uses the new method (for non-ubuntu users: Ubuntu’s Optimus support includes the addition of mode switching in the Nvidia GUI control panel, the Ubuntu equivalent to the Mint indicator applet). I updated the readme, but I called it experimental.
Probably the Mint applet is using the user’s path since the behaviour mozo observes is only possible if the applet finds the /usr/local/bin version first
Reminder: see here for the MathieuGras-TimRichardson solution:
But I use “prime-indicator-plus”, not “prime-indicator”. prime-indicator-plus isn’t related to Mint and I installed it manually when I installed Mint 18 and it’s there since than. Now I just upgraded the system to Mint 19 :)
Tim Richardson’s version for Optimus does work to an extent. The switching was slow as noted earlier. Once I downloaded and used https://github.com/timrichardson/Prime-Ubuntu-18.04 as my OS install, it installed only leaving initramfs-tools half-installed. I had to manually remove initramfs-tools from the terminal as no other software installs would complete citing exit error 127 from initramfs-tools.
After that was accomplished, I could install software normally. Initially the command prime-select seemed to work fine showing what GPU was currently selected. The switching times however took some time and did bork the whole installation on a switch to intel. So far the system seems to be fine and working well left with nvidia enabled. I could personally care less if the intel side is ever used as battery consumption is not a concern for me. I am however concerned that if I do any updates to the system, whether it will break with say a kernal upgrade. Yes I did unix programming ages ago in the green screen era, but I now work with industrial controls. I will report back in the next few days to see if updates break it. I hope Mr. Richardson keeps up the work! I have fought this machine from day one two years ago as graphics, video, multimedia it was horrid. Overall I love how snappy and responsive the whole machine is!
System specifics: -Version-
Kernel : Linux 4.15.0-24-generic (x86_64)
Version : #26-Ubuntu SMP Wed Jun 13 08:44:47 UTC 2018
C Library : GNU C Library / (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
Distribution : Ubuntu 18.04 LTS
-Current Session-
Computer Name : bill-Aspire-F5-573G
User Name : bill (William Smith)
Language : en_US.UTF-8 (en_US)
Home Directory : /home/bill
-Misc-
Uptime : 1 hour 3 minutes
Load Average : 0.31, 0.61, 0.94
Available entropy in /dev/random : 3767 bits (healthy)
I can’t think why this code would have anything to do with initramfs…It’s doesn’t install anything except a couple of scripts and doesn’t touch anything to do with the kernel
Unixman39, if prime-select takes a long time and afterwards the system is broken, this sounds like you’re still using the (bad9 prime-select that comes with 18.04. Tim’s prime-select is installed in /usr/local/bin i think. It should only take a fraction of a second to switch.
Taking the broken initramfs-tools into account, did you check dmesg for a harddisk failure?
This is a very crude, handheld phone video of how it looks:
It switches in seconds rather than fractions of a section. Fraction of minute, could settle for that.
The machine is a Thinkpad P50, ubuntu 18.04.1 with the standard nvidia driver for 18.04, stock kernel.
Tim Richardson My reference to slow was prior to this install, I confused the issue mentioning what was before your changes. Switching nearly instantaneous on my laptop. I was quite pleased with how things were going. The initramfs-tools was something with the install of the packaged install with your changes on the 18.04 as listed in the link earlier. For some reason the system did not completely remove it.
I have been pouring thru the logs and files sniffing about. The boot log reports:
"[e[0;32m OK e[0m] Started Snappy daemon. Starting Wait until snapd is fully seeded…
Seems to just sit there waiting forever for this to occur. Apparently this has something to do with 18.04 as reported in numerous other places. At this point I believe it to be a coincidence rather than a result of your changes. If I find out otherwise, I will advise. Thanks for your speedy reply!
generix I have poured thru everything else and have done repeated checks on hd0 and all seems well. So at this point between my misstatement of slow switching and the initramfs-tools issue on OS install are unrelated to this Nvidia solution.
I will report back if this is a fubar on my part, something with 18.04, or who knows? I am beginning to believe this would have happened without switching at this point. Thanks all for the help! Most appreciated by this crusty old programmer (think assembly level, green screens, punched cards, eeproms… lol
The long startup time comes from a change in the kernel, it’s collecting entropy for randomness. Previously, due to a bug, too much static values were collected which was fast but bad in terms of cryptography. Move your mouse to speed up things. So not connected to graphics.
Thanks for all the excellent work and effort all. I did get it somewhat operational but for the 18.04 bugs. Glad to see you had success @DarkAether. I found 18.04 too buggy for my tastes. I do appreciate all the great efforts on here that found workarounds to get this running.
I ended up switching to Opensuse Leap 15 and Bumblebee for now. Totally stable and works fast. Low battery consumption unless running with Nvidia Gpu on of course. Yes I have only 32 bit support for the Nvidia however it works for all but one of my games. But I do much more than gaming and found 18.04 too buggy and unstable. I may re-visit this later but for now I will stick with Opensuse. Thanks all!
My System:
Machine : Acer F5-573G-78R2
CPU : i7-6500U CPU 3100MHz
GPU : GTX 940MX 4GB
openSUSE Leap 15.0
Linux 4.12.14-lp150.12.16-default x86_64
Mem: 3466/7845MB
Disk: 69/465GB
Gfx: NVIDIA Corporation Device 179c @ 1920x1080
OpenGL version 4.6.0 NVIDIA 390.77
Thanks for the “worked for me” post. Installing it is sometimes a bit tricky, and it helps people persevere if they know someone with the same hardware has succeeded.
For different display managers, you will see the display manager is hardcoded in the rust script, however, all it does is call the shell, so it is easy to change to sddm.
I think you could even try ‘display-manager’ instead of ‘lightdm’, systemctl seems to understand ‘display-manager’.
lightdm does not have any special properties, it’s just that gdm3 doesn’t work with nvidia in modeset, and you need nvidia in modeset if you want no tearing on the laptop panel. gdm3 seems to think that nvidia in modeset means you want wayland. Or maybe it’s some other problem.
lightdm is just something which works.
Please let me know you go, either via pull request or an email.
Good news. In Ubuntu 18.10 (still pre-release), the new version of nvidia-prime works fine. The official prime-select moves between intel and nvidia requiring only a logout. No more initramfs rebuilding, no more rebooting. I have not looked at the code, but based on earlier hints from the developer, I think this means the bbswitch approach has been used (without it being a dependency).
Also, gdm3 works with mode-setting, which I have never seen before in Ubuntu.
At the moment, lightdm is not working but that’s not very relevant when gdm3 works fine.
This is a bit amazing compared to 18.04 so I hope more people test it.
