My personal Nvidia repository has seen quite a few updates on versions, CUDA enablements, legacy drivers and Delta RPMS.
Table of Contents
Long Lived branch
Version 346.35 is now the new Long Lived branch release, this, plus the fact that is the newest made it to all supported distributions (CentOS/RHEL 6/7, Fedora 20/21/rawhide).
Here is the table that lists the current versions:
A complete packaged CUDA stack has been added for all supported distributions. This now includes all CUDA libraries and tools at version 6.5.19 (includes NVML / GPU deployment kit). You can easily install CUDA 6.5 on CentOS/RHEL 6/7 and Fedora 20/21/rawhide!
All the packages provide/require/obsolete the relevant driver packages in the RPMFusion repository and all the CUDA packages in the Nvidia repository; so you can enable this repository along with the official Nvidia CUDA one and RPMFusion at the same time. Packages will get upgraded accordingly.
Nvidia is slowly fading out 32 bit support from CUDA, and you can see it reflected in the various packages. The Unified Video Memory kernel module (nvidia-uvm.ko has been removed in version 346.16, CUDA graphical programs are 64 bit only, many libraries and compilers are available in 64 bit only, etc.
Feedback from users has been integrated, where possible.
A compatibility repository for drivers on 340.x, the new legacy release for cards up to 9xxx chipsets has been introduced. It’s in the same place, just follow the instructions by appending -340 to the repository file. This repository does not include the CUDA packages, just the enablement on the drivers.
The repository itself it’s not guaranteed to stay online forever; the GTX 9xxx series are from 2008 and I don’t guarantee I will maintain it for long.
Delta RPMS
Delta RPMS have been introduced, to reduce the time and data required for upgrades. Driver packages can reach 90 mb and CUDA packages can span even 650 mb. This would save you a lot of time into upgrading them. For now, delta RPMS have been generated for the new 346.35 drivers, and this reduced nearly 80% the download size on Fedora 21.
We’ll see some real gain when updating the CUDA packages.
Ending words
Along this, there is the usual assortment of packages refinement (syntax, RPMLint, optimizations, etc.). For additional details, please see the Nvidia driver page.
As time permits, new CUDA enabled packages will be added to the repository, namely Blender, ccMiner, NVENC enabled ffmpeg, etc.
I’ve created experimental CUDA packages that try to follow Fedora packaging guidelines as close as possible. Those have been updated to the Nvidia Fedora 20 repository, and are installable through normal yum commands.
To install them, you need to use my repository that contains the latest drivers.
Table of Contents
32 bit support
Nvidia is slowly fading out 32 bit support from CUDA, and you can see it reflected in the various packages. The Unified Video Memory kernel module (nvidia-uvm.ko has been removed in version 346.16, CUDA graphical programs are 64 bit only, many libraries and compilers are available in 64 bit only, etc.
Package testing
I’ve uploaded packages only to the Fedora 20 repository, as they are very big and this is what I’m using at the moment as my main desktop. To help test these, I’ve also added a package for ccminer, a CUDA cryptocurrency miner that links to the packages and requires them to be built. By installing it, all required CUDA runtime libraries should be installed as well.
If all goes well, my plan is to enable CUDA packages for all supported Fedora/CentOS/RHEL distributions and add also package software that in the current form do not use the Nvidia libraries.
As an example, the Blender package in Fedora does not (obviously) link to the CUDA libraries, so no CUDA rendering. On the contrary, the binary that you can download from the Blender website is linked statically to the CUDA libraries at compile time.
After some feedback I will enable them for all the other distributions. So if you need them, please test them.
Packages available
A brief recap on the packages, here we have the full list of drivers and CUDA packages that are available inside the repository folder:
From the above list, packages can be grouped as follows for an x86_64 system. For additional details, please see the repository page.
Kernel modules, in both akmod and dkms variants. Instantiated kernel modules are available as rebuild in both by enabling the appropriate configuration on your system.
akmod-nvidia
dkms-nvidia
kmod-nvidia
These are the basic driver packages, they are what is required along the kernel module packages to have accelerated drivers and full OpenGL support for a normal desktop. That is gaming, office use, etc. But no CUDA support.
Then there are extra tools and libraries, like Framebuffer Compression OpenGL libraries, GPU Deployment Kit (NVML, also called Nvidia Management Library), command line configuration for very specific X.org setups and a tool that leverages the NVML library to perform health checks on GPU clusters.
Please note that the Nvidia Management Library headers and tools do not follow the same versioning of the main driver set as they are provided by Nvidia in a separate bundle that is compatible across multiple releases of the drivers. For example, at the time of writing this, we have 340.58 (long lived), 343.22 (short lived) and 346.18 (beta) drivers available.
All works with version 340.29 of the NVML libraries.
Lastly, we have all the development files (unversioned library symlinks, headers and documentation) for compiling programs that link to the above driver libraries.
After those, that have been provided here for more than a year, I’ve now added CUDA packages. These can be splitted into multiple components as well; first group contains most runtime components for simply running CUDA enabled programs:
Then we have development files (headers, stub libraries, documentation, compilers, etc.) for compiling programs that link to the CUDA libraries:
cuda
cuda-cli-tools
cuda-devel.i686
cuda-devel
cuda-docs.noarch
And then finally, we have Java GUI programs (debuggers, etc.):
cuda-nsight
cuda-nvvp
Official Nvidia repositories
All the packages provide/require/obsolete the relevant driver packages in the RPMFusion repository and all the CUDA packages in the Nvidia repository; so you can enable this repository along with the official Nvidia CUDA one and RPMFusion at the same time. Packages will get upgraded accordingly.
Quite a few things have changed, the packages are going towards providing the complete packaged CUDA stack. So far, only the GPU deployment kit has been inclued; and the packages allow for parallel installation with the Nvidia CUDA repositories by osboleting/updating packages as required. Here is some details on the things that have been implemented.
Table of Contents
X.org configuration
Starting from Fedora 21, all driver X.org configuration can be managed by simply adding/removing X.org configuration snippets in /etc/X11/xorg.conf.d.
Use new OutputClass directive on Fedora 21 X.org server 1.16 (and later) to load the driver and do not rely on an edited /etc/X11/xorg.conf file. This also removes editing of the xorg.conf file from the package scriptlets.
Add the IgnoreABI directive by default on Fedora rawhide builds.
Kernel modules
Add a new UDev rule in nvidia-driver-cuda for the nvidia-uvm module and make X.org NVIDIA Files section to be loaded latest in case there are other packages providing a custom Files section (thanks Jan P. Springer for spotting these).
The binary nvidia-modprobe is now SETUID, but its package is no longer a mandatory requirement for the drivers, so it will not get installed by default.
Now that both Redhat Enterprise Linux 7 and CentOS 7 have been released, binary modules (kABI) are now provided for these distributions.
CUDA support
Added the GPU Deployment kit to the repository. This is constructed with NVML (NVIDIA Management Library) included with the drivers plus headers, docs and samples from a separate tarball. The separate tarball is using a different version number than the drivers. This is packaged in the nvidia-driver-NVML and nvidia-driver-NVML-devel packages. Installing these, the gpu-deployment-kit dependency provided by the CUDA repositories is preserved.
Along with NVML, the nvidia-healthmon package is provided to monitor TESLA GPU clusters.
Along this, there is the usual assortment of packages refinement (syntax, RPMLint, optimizations, etc.). For additional details, please see the Nvidia driver page.
If you would like to test the CUDA packages please contact me and I will point you to a repository hosting the CUDA packages.
Another batch of changes for the repositories. The HandBrake repository has seen some updates:
MakeMKV has been updated to version 1.8.11.
HandBrake has been updated to the current development version for Fedora 21. It contains additional/different bundled libraries, but the situation is not that bad.
libdvdnav is now based on a 5.0.0 snapshot that contains all the fixes required to avoid the HandBrake crash while opening a DVD for scanning with the default settings. Removal of the flag “Use dvdnav (instead of libdvdread)” in the preferences panel is no longer required.
Please test it, I found it much more stable than the previous version. If it works, I might build it also for current Fedora releases.
Regarding the other updates:
The Nvidia driver is now at version 340.24 for all CentOS/RHEL and Fedora variants.
Nvidia Fedora 21 packages have now aKMOD support
Nvidia CentOS/RHEL 7 packages have now binary kABI modules, so you can install the binaries directly without relying on DKMS.
The CDRtools suite has been updated to version 3.01a24.
The Steam package has been updated to version 1.0.0.48-2, the same build has been pushed to RPMFusion. The repository hosted here still contains other SteamOS packages.
The Flash plugin package has been updated to version 11.2.202.378 and Skype has been updated to version 4.3.0.37. Both versions have also been pushed to RPMFusion in the form of lpf packages.
Spotify it’s still at version 0.9.10; as the x86_64 and i386 builds share the same data package. Upstream has updated the x86_64 build to 0.9.11 but at the same time has reverted the i386 build to 0.9.4, so all Ubuntu users will not get the update anymore. Until this is sorted out, I’m going to leave the current package versions as 0.9.10 for systems that are both 32 and 64 bit. RHEL/CentOS 7 (which is 64 bit only) has the new 0.9.11 version.
This is a re-edit of my previous post about using and configuring an Optimus enabled laptop in Fedora 20/21. It should work on other distributions as well.
My laptop at work is a Dell Latitude E6430. Comes loaded with features and I really like it. Among the various features there’s the fact that this is an Nvidia Optimus enabled laptop, sporting both an Intel video card and an Nvidia one:
This one is a muxless laptop of the worst kind: video outputs are connected only to specific chips!
Update 23rd May 2014: UEFI console (using efifb) on external monitors has been fixed with bios update version “A14”. Now the UEFI console is also rendered on external monitors if the lid is closed; so I’ve updated the guide.
LVDS (Internal panel)
Intel
VGA (not usable along with the docking station one)
Intel
VGA (Docking station)
Intel
DVI
Nvidia
DVI (Docking station)
Nvidia
DisplayPort (Docking station)
Nvidia
HDMI
Nvidia
So to use an external HDMI connection at home you need to drive it through the Nvidia card, it doesn’t matter if Optimus is enabled or not. I regularly use it docked with the lid closed, external keyboard and mouse and 2 external monitors connected to the VGA and DVI outputs of the docking station. Basically while I’m at the office it looks like a normal desktop computer; but sometime I need to disconnect it to go on a meeting; and sometimes I use it at home to play games as well.
Guess what? Free drivers, proprietary drivers, UEFI, UEFI secure boot, multi monitor, outputs changing on the fly… all sorts of fun! I’m impressed by the fact that it all works together.
There are four modes on which I can operate the system:
Optimus enabled, free drivers for both Intel and Nvidia cards (implementation is called “Prime”)
Optimus enabled, free driver for Intel and proprietary driver for the Nvidia card
Optimus disabled, free driver for the Nvidia card
Optimus disabled, proprietary driver for the Nvidia card
Each one has its drawbacks, so let’s explain each setup a bit. At the end of the post I’ve made a table with all the pros and cons of each solution.
My current setup is:
Fedora 20 x86_64
Kernel 3.14.4 (stock Fedora)
Nouveau DDX 1.0.9 (stock Fedora)
Intel DDX 2.21.15 (stock Fedora)
Nvidia proprietary drivers 337.19 (from my repository)
If secure boot is enabled; there’s no way to use the proprietary Nvidia driver without fiddling with UEFI keys. The module is built separately from the kernel package; so there’s no way for it to have the same signature as the kernel.
When UEFI is enabled, the free drivers work fine and replace the efifb framebuffer driver with their own; thus giving proper modesetting at the correct resolution and a speedy and responsive terminal.
With the proprietary Nvidia driver, the efifb is not replaced; so the console still operates with it and the Nvidia driver only operates the X part. Unfortunately, using this method, the framebuffer console is really slow, the resolution is not optimal, and the EFI framebuffer is exposed onto external monitors only from bios version “A14”. Before the update, pressing CTRL+ALT+Fx jumped me to the console that is shown in the closed laptop lid on the docking station; making it pretty useless.
What UEFI could bring you is the Intel Rapid Start Technology which has been included in kernel 3.11; so make your choices depending on what you need.
Optimus disabled (Nouveau or Nvidia)
When Optimus is disabled, I can freely use the proprietary Nvidia driver or the free Nouveau driver.
Both solutions work; unfortunately performance and feature wise Nouveau cannot compete with the proprietary Nvidia driver.
My main issue is power management; with the Nvidia driver the battery lasts a lot more and the performance difference is abysmal. Nouveau performance is really poor with 3D games (especially Steam commercial ones, with Doom 3 it works fine) and there’s absolutely no power management; at least on my laptop. By playing with performance levels I was only able to overheat the card.
Another thing that does not work with Nouveau is the docking station removal. With the Nvidia proprietary driver I’m able to do the following:
– Disconnect from the docking station: output goes from the external VGA and DVI monitors to the internal LVDS display.
– Reconnect to the docking station: internal LVDS display gets shut off and output goes to VGA and DVI monitors as they were before; one next to the other. I can even close the lid and the computer doesn’t go in standby.
With Nouveau, I’m able to disconnect from the docking station but when reconnecting I need to reconfigure the monitors in their place; and after this, when closing the lid I need to wake up again the computer because it goes on standby.
With the recent Xrandr support to the proprietary drivers I don’t even need to edit che X.org configuration file. Whether I use nvidia-settings or Gnome Displays panel the result is reflected in both implementations and preserved across boots.
Optimus enabled (Nvidia)
To configure Optimus with proprietary drivers perform the following. First of all install the proprietary driver as normal. Now edit the /etc/grub2.cfg file and remove some parameters from the kernel command line. This is required because the Intel driver still need to operate with its KMS driver. So, from this:
After this, edit/recreate the /etc/X11/xorg.conf file with the following contents:
Section"Device"Identifier"nvidia"Driver"nvidia"Option"NoLogo""true"Option"DPI""96 x 96"# Specify Nvidia PCI deviceBusID"PCI:1:0:0"# Make sure X starts also when no outputs are connected to the Nvidia chipOption"AllowEmptyInitialConfiguration"EndSection# Slave deviceSection"Device"Identifier"intel"# Simple output, no full Intel driverDriver"modesetting"# BusID "PCI:0:2:0"EndSectionSection"Screen"Identifier"intel"Device"intel"EndSectionSection"Screen"Identifier"nvidia"Device"nvidia"EndSection# Make sure the Nvidia device is the first in the serverSection"ServerLayout"Identifier"layout"Screen0"nvidia"
Inactive "intel"EndSection
Section "Device"
Identifier "nvidia"
Driver "nvidia"
Option "NoLogo" "true"
Option "DPI" "96 x 96"
# Specify Nvidia PCI device
BusID "PCI:1:0:0"
# Make sure X starts also when no outputs are connected to the Nvidia chip
Option "AllowEmptyInitialConfiguration"
EndSection
# Slave device
Section "Device"
Identifier "intel"
# Simple output, no full Intel driver
Driver "modesetting"
# BusID "PCI:0:2:0"
EndSection
Section "Screen"
Identifier "intel"
Device "intel"
EndSection
Section "Screen"
Identifier "nvidia"
Device "nvidia"
EndSection
# Make sure the Nvidia device is the first in the server
Section "ServerLayout"
Identifier "layout"
Screen 0 "nvidia"
Inactive "intel"
EndSection
Make sure to set the correct bus ID for the Nvidia card; for instructions look in the Nvidia documentation. Make sure the integrated Intel card is using modesetting driver and not the native one.
The AllowEmptyInitialConfiguration directive in the Nvidia section is required to let X start with the Nvidia driver without any output attached to the chip, for example while using the internal LVDS monitor.
Upon reboot, you will see KMS running for the Intel card (Plymouth screen) and then the login manager appears on the Nvidia attached panels, while the Intel outputs shut off.
After logging in, you can also check that both drivers are running with the following commands:
Your Intel monitor should now have an extended desktop managed by the Nvidia card. Move windows around, and launch some commands to see that wherever you go you’re using the Nvidia accelerated driver:
$ glxinfo|grep"OpenGL version string"
OpenGL version string: 4.4.0 NVIDIA 337.19
$ vdpauinfo |grep-i string
Information string: NVIDIA VDPAU Driver Shared Library 337.19 Tue Apr 2919:51:41 PDT 2014
Everything seems to work, except output manipulation. Xrandr, Gnome and Nvidia drivers have a different view.
Xrandr view:
$ xrandr -q|grep conn
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 1680x1050+0+0(normal left inverted right x axis y axis) 474mm x 296mm panning 3360x1050+0+0
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
LVDS-1-0 connected (normal left inverted right x axis y axis)
VGA-1-0 connected 1680x1050+1680+0(normal left inverted right x axis y axis) 474mm x 296mm
$ xrandr -q | grep conn
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm panning 3360x1050+0+0
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
LVDS-1-0 connected (normal left inverted right x axis y axis)
VGA-1-0 connected 1680x1050+1680+0 (normal left inverted right x axis y axis) 474mm x 296mm
This is what I have in the Nvidia settings panel and in the Gnome Displays panel for the monitors; in one case I see only one of the external monitors, in the other one I have all monitors:
Primary monitor assignment does not work as well. I usally have the Gnome panel on the left monitor. If I try to move it from the Nvidia output I get this feedback:
$ xrandr --output VGA-1-0--primary
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139(RANDR)
Minor opcode of failed request: 30(RRSetOutputPrimary)
Serial number of failed request: 51
Current serial number in output stream: 53
$ xrandr --output VGA-1-0 --primary
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 30 (RRSetOutputPrimary)
Serial number of failed request: 51
Current serial number in output stream: 53
Putting monitor problems aside, running in this mode does not really give any benefit compared to running it with Optimus disabled and the proprietary Nvidia driver installed. Both cards are running with power management, but the Nvidia card is never shut off, so it doesn’t use less power than when running standalone.
There’s no way to turn off the card with vga_switcheroo, all libraries come from the Nvidia drivers and your desktop is being rendered by the Nvidia card.
GDM configuration for Optimus (Nvidia)
Let’s assume you want to create the above setup in GDM (Gnome Display Manager), making it run automatically the xrandr commands mentioned above.
You need to create a text file with the display name (usually “:0”) to start the commands upon Init time the appropriate GDM configuration directory:
$ cd/etc/gdm/Init/
$ cat \:0#!/bin/sh# Get the xrandr providersoutput="$(xrandr --listproviders)"src=$(echo"$output"|grep" Source"|head-n1|awk'{print $NF}'|cut -d: -f2)sink=$(echo-e"$output"|grep" Sink"|head-n1|awk'{print $NF}'|cut -d: -f2)# Pass provider or sink and source
xrandr --setprovideroutputsource"$sink""$src"# Make sure xrandr sees all the outputs# xrandr --auto# Do not move up. Only now xrandr shows the outputslvds=$(xrandr |grep-i"lvds"|head-n1|cut-d" "-f1)
xrandr --output"$lvds"--off
xrandr --output"$lvds"--auto
$ cd /etc/gdm/Init/
$ cat \:0
#!/bin/sh
# Get the xrandr providers
output="$(xrandr --listproviders)"
src=$(echo "$output" | grep " Source" | head -n1 | awk '{print $NF}' | cut -d: -f2)
sink=$(echo -e "$output" | grep " Sink" | head -n1 | awk '{print $NF}' | cut -d: -f2)
# Pass provider or sink and source
xrandr --setprovideroutputsource "$sink" "$src"
# Make sure xrandr sees all the outputs
# xrandr --auto
# Do not move up. Only now xrandr shows the outputs
lvds=$(xrandr | grep -i "lvds" | head -n1 |cut -d " " -f 1)
xrandr --output "$lvds" --off
xrandr --output "$lvds" --auto
The “–off” and then “–auto” is actually redundant, but it helped in a couple of cases.
Prime enabled (Nouveau)
The Open Source implementation of this is actually called “Prime” for obvious reasons.
Here comes the juicy part. With enough maturity on the Nouveau side this would be the perfect setup. To start with this implementation; nothing is required, just install Fedora and everything should be already set up by default. Booting it shows the Plymouth logo on both outputs.
Login in the system, and check that both drivers are running:
$ lsmod|egrep"i915|nouveau"
nouveau 9434451
i915 6518614
mxm_wmi 128651 nouveau
ttm 798651 nouveau
i2c_algo_bit 132572 i915,nouveau
drm_kms_helper 502392 i915,nouveau
drm 2744808 ttm,i915,drm_kms_helper,nouveau
i2c_core 342427 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau,videodev
wmi 186973 dell_wmi,mxm_wmi,nouveau
video 191042 i915,nouveau
Poking around with xrandr will give you totally different outputs from the Nvidia driver:
$ xrandr -q|grep conn
LVDS2 connected 1600x900+0+0(normal left inverted right x axis y axis) 309mm x 174mm
VGA2 connected 1680x1050+1600+0(normal left inverted right x axis y axis) 474mm x 296mm
LVDS-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-2 connected (normal left inverted right x axis y axis)
HDMI-1-1 disconnected (normal left inverted right x axis y axis)
VGA-1-1 disconnected (normal left inverted right x axis y axis)
$ xrandr -q | grep conn
LVDS2 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
VGA2 connected 1680x1050+1600+0 (normal left inverted right x axis y axis) 474mm x 296mm
LVDS-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-2 connected (normal left inverted right x axis y axis)
HDMI-1-1 disconnected (normal left inverted right x axis y axis)
VGA-1-1 disconnected (normal left inverted right x axis y axis)
But at least they’re consistent with the Gnome Displays panel:
For reasons I don’t understand the Nvidia card appears twice in 2 different but identical providers:
With the tests I made, there’s no apparent difference when using one or the other. Usage of one card or the other is driven by the DRI_PRIME environment variable. If it’s set to 0, commands run on the Intel card, if it’s set to 1 they will run on the Nvidia card. For example:
$ DRI_PRIME=1 vdpauinfo |grep-i string
Information string: G3DVL VDPAU Driver Shared Library version 1.0
$ DRI_PRIME=1 vdpauinfo | grep -i string
Information string: G3DVL VDPAU Driver Shared Library version 1.0
Or even better, to check OpenGL status:
$ glxinfo |grep-e'OpenGL.*string.*'
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.3(Core Profile) Mesa 10.1.3
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 10.1.3
OpenGL shading language version string: 1.30
$ glxinfo | grep -e 'OpenGL.*string.*'
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.3
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 10.1.3
OpenGL shading language version string: 1.30
$ DRI_PRIME=1 glxinfo |grep-e'OpenGL.*string.*'
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVC1
OpenGL core profile version string: 3.3(Core Profile) Mesa 10.1.3
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 10.1.3
OpenGL shading language version string: 1.30
$ DRI_PRIME=1 glxinfo | grep -e 'OpenGL.*string.*'
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVC1
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.3
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 10.1.3
OpenGL shading language version string: 1.30
Unfortunately the desktop is very slow, it’s rendered by the Intel driver and put on the Nvidia card for display. I’ve tried changing priority in vga_switcheroo prior to starting X, setting the DRI_PRIME=1 variable at boot, use xrandr to change the provider output source etc. to no avail; the desktop can run only on the first card or it doesn’t work. Usually I get a black screen upon GDM start.
There’s no power management as well, so the Intel card runs normally but the Nvidia one is always on and stuck in an intermediate performance level.
When docking it; I get cloned outputs on all external displays at a very low resolution. Same issue with the Optimus disabled Nouveau driver; the outputs need to be rearranged, the lid closed and the computer needs to be woken up from standby.
As you can see the second card is dynamically powered. Try to undock the system and check the status again: the second output is no longer needed so the second card shuts off:
You will notice a slight delay before the command output is returned, but the card is powered on again! This is awesome. Now, after 1 or 2 seconds look again at the card:
It’s shut off! Dock the laptop again and the monitor should come up again.
Keep in mind that powering up and down cards is a totally different things than power managing and adjusting clocks etc. for a running card. This make the Nvidia card shutdown automatically, not regulate its power levels during usage.
Dual cards can be shut down or powered up on demand through vga_switcheroo. For example, login in your system as root without X running and no outputs connected to the Nvidia chip. Look at the card status with the following command:
This will tell you that the Integrated Graphics Display (IGD) is powered up (Pwr) and that is the primary display (+), while Discrete one (DIS) is dynamically off. To turn on the secondary video card, a single command is required:
This will power on the Nvidia card. A look at the battery will tell you now that you have half the power because the Nvidia card sucks power along the integrated Intel one.
Turn off the integrated card (IGD), and switch the framebuffer console to the discrete one (DIS):
This will move the framebuffer and your shell to the other Nvidia driven monitor and shut down the Intel card. You will see the framebuffer console on the Nvidia output. Sweet, isn’t it?
Summary
A Prime enabled laptop with open source drivers does not have any configuration and does not require any manual configuration. The fact that the Nvidia card can power down itself is great and doubles my battery duration! On the screen I have KMS consoles without huge fonts and can have UEFI secure boot enabled! This is really awesome.
Unfortunately though, without proper Nouveau power management and performance improvements added to the fact that I need to reconfigure monitors everytime I move (sometime the output gets all black as well when docking); the experience is not that great. I don’t know why, but when I’m undocked and using only the LVDS internal panel, the Intel performance is fantastic. Problems arise only when it’s docked and Nouveau is enabled as well.
Optimus
Disabled
Disabled
Enabled
Enabled (Prime)
Driver
Nvidia
Nouveau
Intel/Nvidia
Intel/Nouveau
Configuration
Very easy.
Already set up.
Very complex
Already set up.
Card power
management
Perfect!
Poor performance, no power management.
Nvidia card always powered up, renders for all screens.
Dynamic video card switching works fine, Nouveau performance not.
Optimus card
power management
N.A.
N.A.
Nvidia card can't power down.
Perfect!
Docking / Undocking
Perfect!
Manual intervention required
Manual intervention required, unreliable
Manual intervention required
Performance
Perfect!
Pretty bad.
Very good, some tearing when moving windows.
Bad when using the Nvidia card for output, otherwise perfect!
Bios Console
VGA, no KMS.
Perfect (KMS)!
Perfect (KMS on Intel).
Perfect (KMS)!
UEFI Console
Uses efifb. Somewhat slow.
Perfect (KMS)!
Perfect (KMS on Intel).
Perfect (KMS)!
UEFI secure boot
Can't work.
Perfect!
Can't work.
Perfect!
Summing up, my current choice is for the Optimus disabled setup with Nvidia drivers. I can play games, dock, undock, power management works ok and I can drive all outputs easily. And if I need to go in a meeting I don’t need to be extra cautious in shutting down virtual machines, because the system might not go up again. It’s kinda retro style when booting with the text console and battery does not last more than 3 hours, but I can bear it.
If you’re not hunger for games or 3d stuff except the usual desktop compositing, just stick with the default OpenSource drivers and components, there is no setup required and everything works out of the box. My battery charge lasts usually 6 hours on a mixed usage case.
Nvidia has started contributing to the Nouveau driver with support for the GK20A (Nvidia K1) chip and it will be merged in kernel 3.16; let’s hope it will do the same for the other chips and components.
For details, please see the Nvidia driver page. Fedora 19 and 20 nvidia-settings package has been updated on par with the other channels to use the system provided jansson library instead of the bundled one.
MakeMKV has finally been updated to version 1.8.7-2, which contains a small tweak as suggested in MakeMKV‘s forums to re-enable internal SSL support. This should solve all SCSI errors when decrypting BluRay discs on recent Fedora OpenSSL releases that do not ship all EC curves.
The HandBrake build with some of the bundled libraries removed in favour of system libraries (~50% of them) has been pushed as the supported build.
The nvidia-settings package now builds the external libXNVCtrl.so library that can be used to control the graphic cards through the NV-CONTROL extension. This library updates the old and obsolete one in Fedora based on drivers version 165.
The CDRtools suite has been updated to version 3.01a21.
The Steam package now produces an additional steam-noruntime subpackage that contains all the library requirements for running Steam without using the Steam Runtime. More details on the Steam repository page. This build has also been pushed to RPMFusion and will become the next update; so users which have the Steam package installed from the RPMFusion repositories will still have a Valve supported configuration with the Runtime enabled.
I’ve updated the Nvidia driver repository to the latest 331.20 release. Since this release has been promoted by Nvidia to a long lived branch release; also the CentOS/RHEL 6 repository has been updated to this version. This means all currently supported Fedora releases have the same driver version as in CentOS/RHEL.
This driver release brings the usual assortment of fixes and features; but the most important things are the additions of the Unified Video Memory kernel module, the “private” Nvidia OpenGL Framebuffer Compression libraries and the packaging introduction of the multiple kernel modules as an alternative to the single module; as specified by the driver documentation.
Starting from the less important things, the Nvidia OpenGL Framebuffer Compression libraries have been packaged into a separate package as their usage is very specific and according to the documentation their usage is documented only with specific approved Nvidia partners. I’m pretty sure we will not miss these libraries on our systems.
Kernel module packages now contain/generate also the nvidia-uvm.ko kernel module and the multiple nvidia.ko modules that can be used to assign separate kernel module instances to separate GPU devices.
The resulting install of the kernel module packages ends up like this:
$ ls-laghs
total 127M
4.0K drwxr-xr-x. 2 root 4.0K Nov 720:20 .
4.0K drwxr-xr-x. 6 root 4.0K Nov 720:20 ..
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia0.ko
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia1.ko
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia2.ko
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia3.ko
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia4.ko
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia5.ko
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia6.ko
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia7.ko
12K -rw-r--r--. 1 root 11K Nov 720:20 nvidia-frontend.ko
15M -rw-r--r--. 1 root 15M Nov 720:20 nvidia.ko
48K -rw-r--r--. 1 root 48K Nov 720:20 nvidia-uvm.ko
$ du-hs .
127M .
$ ls -laghs
total 127M
4.0K drwxr-xr-x. 2 root 4.0K Nov 7 20:20 .
4.0K drwxr-xr-x. 6 root 4.0K Nov 7 20:20 ..
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia0.ko
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia1.ko
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia2.ko
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia3.ko
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia4.ko
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia5.ko
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia6.ko
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia7.ko
12K -rw-r--r--. 1 root 11K Nov 7 20:20 nvidia-frontend.ko
15M -rw-r--r--. 1 root 15M Nov 7 20:20 nvidia.ko
48K -rw-r--r--. 1 root 48K Nov 7 20:20 nvidia-uvm.ko
$ du -hs .
127M .
As you can see, the space used by these modules is huge; and they are only used in specific setups. I’m planning to make the multiple kernel modules in an optional package that can be installed separately from the main nvidia.ko and nvidia-uvm.ko modules.
Currently DKMS and AKMODs packages have these modules enabled; but the binary kMOD package for CentOS/RHEL 6 does not contain them. If I try to integrate them into the package, the kABI list of symbols is not exported correctly and I don’t know why. All the numbered modules are very similar (each one contains the 12 mb binary object that is included in the normal module) and for some reason this screws up the package assembly. In detail, this is the binary kMOD package that does not contain the numbered modules:
And this is the binary kMOD package that does contain them. As you can see the symbols are missing. This happens independently of the fact that the base module and / or the UVM module are included in the same package.
First of all I would like to say some thanks to the X.org community. Their work is awesome, and the fact I can make my setup work on entirely X.org components it’s something I never thought possible when XFree86 was still around. I personally think that looking at an Optimus laptop with Intel and Nouveau running is a tremendous achievement.
Now, back to the topic.
My laptop at work is a Dell Latitude E6430. Comes loaded with features and I really like it. Among the various features there’s the fact that this is an Nvidia Optimus enabled laptop, sporting both an Intel video card and an Nvidia one:
This one is a muxless laptop of the worst kind: video outputs are connected only to specific chips!
LVDS (Internal panel)
Intel
VGA (not usable along with the docking station one)
Intel
VGA (Docking station)
Intel
DVI
Nvidia
DVI (Docking station)
Nvidia
DisplayPort (Docking station)
Nvidia
HDMI
Nvidia
So to use an external HDMI connection at home you need to drive it through the Nvidia card, it doesn’t matter if Optimus is enabled or not. I regularly use it docked with the lid closed, external keyboard and mouse and 2 external monitors connected to the VGA and DVI outputs of the docking station. Basically while I’m at the office it looks like a normal desktop computer; but sometime I need to disconnect it to go on a meeting; and sometimes I use it at home to play games as well.
Guess what? Free drivers, proprietary drivers, UEFI, UEFI secure boot, multi monitor, outputs changing on the fly… all sorts of fun! I’m impressed by the fact that it all works together.
There are four modes on which I can operate the system:
Optimus enabled, free drivers for both Intel and Nvidia cards
Optimus enabled, free driver for Intel and proprietary driver for the Nvidia card
Optimus disabled, free driver for the Nvidia card
Optimus disabled, proprietary driver for the Nvidia card
Each one has its drawbacks, so let’s explain each setup a bit. At the end of the post I’ve made a table with all the pros and cons of each solution.
My current setup is:
Fedora 19 x86_64
Kernel 3.11.1 (stock Fedora)
Nouveau DDX 1.0.9 (stock Fedora)
Intel DDX 2.21.12 (stock Fedora)
Nvidia proprietary drivers 325.15 (from my repository)
If secure boot is enabled; there’s no way to use the proprietary Nvidia driver without fiddling with UEFI keys. The module is built separately from the kernel package; so there’s no way for it to have the same signature as the kernel.
When UEFI is enabled, the free drivers work fine and replace the efifb framebuffer driver with their own; thus giving proper modesetting at the correct resolution and a speedy and responsive terminal.
With the proprietary Nvidia driver, the efifb is not replaced; so the console still operates with it and the Nvidia driver only operates the X part. Unfortunately, using this method, the framebuffer console is slow as hell, the resolution is not optimal, and the EFI framebuffer is never exposed onto external monitors. In my case, pressing CTRL+ALT+Fx jumps me to the console that is shown in the closed laptop lid on the docking station; making it pretty useless.
So if you’re going to use the proprietary driver and you often use the console; make sure you’re using Bios mode and not UEFI. What UEFI could bring you is the Intel Rapid Start Technology which has been included in kernel 3.11; so make your choices depending on what you need.
Optimus disabled
When Optimus is disabled, I can freely use the proprietary Nvidia driver or the free Nouveau driver.
Both solution work; unfortunately performance and feature wise Nouveau cannot compete with the proprietary Nvidia driver.
My main issue is power management; with the Nvidia driver the battery lasts a lot more and the performance difference is abysmal. Nouveau performance is really poor with 3D games (especially Steam commercial ones, with Doom 3 it works fine) and there’s absolutely no power management; at least on my laptop. By playing with performance levels I was only able to overheat the card!
Another thing that does not work with Nouveau is the docking station removal. With the Nvidia proprietary driver I’m able to do the following:
– Disconnect from the docking station: output goes from the external VGA and DVI monitors to the internal LVDS display.
– Reconnect to the docking station: internal LVDS display gets shut off and output goes to VGA and DVI monitors as they were before; one next to the other. I can even close the lid and the computer doesn’t go in standby.
With Nouveau, I’m able to disconnect from the docking station but when reconnecting I need to reconfigure the monitors in their place; and after this, when closing the lid I need to wake up again the computer because it goes on standby.
With the recent Xrandr support to the proprietary drivers I don’t even need to edit che X.org configuration file. Whether I use nvidia-settings or Gnome Displays panel the result is reflected in both implementations and preserved across boots.
Optimus with proprietary Nvidia drivers
To configure Optimus with proprietary drivers perform the following. First of all install the proprietary driver as normal. Now edit the /etc/grub2.cfg file and remove some parameters from the kernel command line. This is required because the Intel driver still need to operate with its KMS driver. So, from this:
Make sure to set the correct bus ID for the Nvidia card; for instructions look in the Nvidia documentation. Contrary to what’s written in the Nvidia documentation I had to use the intel DDX driver for the Intel card instead of the modesetting one. With modesetting I’m not able to get any output on the Intel card.
Upon reboot, you will see KMS running for the Intel card (Plymouth screen) and then the login manager appears on the Nvidia attached panels, while the Intel outputs shut off.
After logging in, you can also check that both drivers are running with the following commands:
Your Intel monitor should now have an extended desktop managed by the Nvidia card. Move windows around, and launch some commands to see that wherever you go you’re using the Nvidia accelerated driver:
$ glxinfo|grep"OpenGL version string"
OpenGL version string: 4.3.0 NVIDIA 325.15
$ vdpauinfo |grep-i string
Information string: NVIDIA VDPAU Driver Shared Library 325.15 Wed Jul 3118:14:57 PDT 2013
Everything seems to work, except output manipulation. Xrandr, Gnome and Nvidia drivers have a different view.
Xrandr view:
$ xrandr -q|grep conn
VGA-0 connected primary 1680x1050+0+0(normal left inverted right x axis y axis) 474mm x 296mm
LVDS-0 connected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected 1680x1050+1680+0(normal left inverted right x axis y axis) 474mm x 296mm
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
$ xrandr -q | grep conn
VGA-0 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm
LVDS-0 connected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected 1680x1050+1680+0 (normal left inverted right x axis y axis) 474mm x 296mm
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
This is what I have in the Nvidia settings panel and in the Gnome Displays panel for the monitors; in one case I don’t see any monitor, in another one I have the internal LVDS display shown as enabled while in reality is not and with the button locked in the “On” position:
Primary monitor assignment does not work as well. I usally have the Gnome panel on the left monitor. If I try to move it from the Nvidia output I get this feedback:
$ xrandr --output VGA1 --primary
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139(RANDR)
Minor opcode of failed request: 30(RRSetOutputPrimary)
Serial number of failed request: 53
Current serial number in output stream: 55
$ xrandr --output VGA1 --primary
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 30 (RRSetOutputPrimary)
Serial number of failed request: 53
Current serial number in output stream: 55
Putting monitor problems aside, running in this mode does not really give any benefit compared to running it with Optimus disabled and the proprietary Nvidia driver installed. Both cards are running with power management, but the Nvidia card is never shut off, so it doesn’t use less power than when running standalone.
There’s no way to turn off the card with vga_switcheroo, all 3d libraries come from the Nvidia drivers and your desktop is being rendered by the Nvidia card.
Prime (Optimus) with free Nouveau drivers
Here comes the juicy part. With enough maturity on the Nouveau side this would be the perfect setup. To start with this implementation; nothing is required, just install Fedora and everything should be already set up. Booting it shows the Plymouth logo on both outputs.
Login in the system, and check that both drivers are running:
$ lsmod|egrep"i915|nouveau"
nouveau 9434451
i915 6518614
mxm_wmi 128651 nouveau
ttm 798651 nouveau
i2c_algo_bit 132572 i915,nouveau
drm_kms_helper 502392 i915,nouveau
drm 2744808 ttm,i915,drm_kms_helper,nouveau
i2c_core 342427 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau,videodev
wmi 186973 dell_wmi,mxm_wmi,nouveau
video 191042 i915,nouveau
$ dmesg|egrep"i915|nouveau"[3.155259] i915 0000:00:02.0: setting latency timer to 64[3.163318] nouveau 0000:01:00.0: enabling device (0004 -> 0007)[3.185671] i915 0000:00:02.0: irq 45for MSI/MSI-X
[3.517135] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[3.517136] i915 0000:00:02.0: registered panic notifier
[3.517156] i915: No ACPI video bus found
[3.774151][drm] Initialized i915 1.6.0 20080730for 0000:00:02.0 on minor 0[3.774654] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0c1e00a1
[3.774659] nouveau [ DEVICE][0000:01:00.0] Chipset: GF108 (NVC1)[3.774663] nouveau [ DEVICE][0000:01:00.0] Family : NVC0
[3.778240] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image...
[3.787999] nouveau [ VBIOS][0000:01:00.0] ... signature not found
[3.788002] nouveau [ VBIOS][0000:01:00.0] checking PROM for image...
[3.788086] nouveau [ VBIOS][0000:01:00.0] ... signature not found
[3.788087] nouveau [ VBIOS][0000:01:00.0] checking ACPI for image...
[4.624674] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid
[4.624679] nouveau [ VBIOS][0000:01:00.0] using image from ACPI
[4.624845] nouveau [ VBIOS][0000:01:00.0] BIT signature found
[4.624850] nouveau [ VBIOS][0000:01:00.0] version 70.08.a8.00.8d
[4.625140] nouveau [ DEVINIT][0000:01:00.0] adaptor not initialised
[4.625144] nouveau [ VBIOS][0000:01:00.0] running init tables
[4.753512] nouveau [ PFB][0000:01:00.0] RAM type: GDDR5
[4.753514] nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB
[4.753515] nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags
[4.779859] nouveau [ PTHERM][0000:01:00.0] FAN control: none / external
[4.779863] nouveau [ PTHERM][0000:01:00.0] fan management: disabled
[4.779867] nouveau [ PTHERM][0000:01:00.0] internal sensor: yes[4.783179] nouveau [ DRM] VRAM: 1024 MiB
[4.783180] nouveau [ DRM] GART: 1048576 MiB
[4.783184] nouveau [ DRM] TMDS table version 2.0[4.783185] nouveau [ DRM] DCB version 4.0[4.783199] nouveau [ DRM] DCB outp 00: 01000323 00010034
[4.783201] nouveau [ DRM] DCB outp 01: 020323a6 0f220010
[4.783202] nouveau [ DRM] DCB outp 02: 040433b6 0f220010
[4.783203] nouveau [ DRM] DCB outp 03: 08024382 00020010
[4.783204] nouveau [ DRM] DCB outp 04: 02032362 00020010
[4.783205] nouveau [ DRM] DCB outp 05: 04043372 00020010
[4.783206] nouveau [ DRM] DCB outp 06: 02011300 00000000
[4.783207] nouveau [ DRM] DCB conn 00: 00000041
[4.783209] nouveau [ DRM] DCB conn 01: 00000100
[4.783210] nouveau [ DRM] DCB conn 02: 00001246
[4.783211] nouveau [ DRM] DCB conn 03: 00002346
[4.783212] nouveau [ DRM] DCB conn 04: 00010461
[4.783213] nouveau [ DRM] DCB conn 05: 00000500
[4.783878] nouveau [ DRM] ACPI backlight interface available, not registering our own
[4.784072] nouveau [ DRM]3 available performance level(s)[4.784075] nouveau [ DRM]0: core 50MHz shader 101MHz memory 135MHz voltage 830mV
[4.784076] nouveau [ DRM]1: core 202MHz shader 405MHz memory 324MHz voltage 830mV
[4.784078] nouveau [ DRM]3: core 672MHz shader 1344MHz memory 1569MHz voltage 980mV
[4.784079] nouveau [ DRM] c: core 202MHz shader 405MHz memory 324MHz
[4.789392] nouveau [ DRM] MM: using COPY0 for buffer copies
[4.925967] nouveau [ DRM] allocated 1680x1050 fb: 0x60000, bo ffff88021fc21400
[4.926065] nouveau 0000:01:00.0: fb1: nouveaufb frame buffer device
[4.926068][drm] Initialized nouveau 1.1.1 20120801for 0000:01:00.0 on minor 1
$ dmesg | egrep "i915|nouveau"
[ 3.155259] i915 0000:00:02.0: setting latency timer to 64
[ 3.163318] nouveau 0000:01:00.0: enabling device (0004 -> 0007)
[ 3.185671] i915 0000:00:02.0: irq 45 for MSI/MSI-X
[ 3.517135] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 3.517136] i915 0000:00:02.0: registered panic notifier
[ 3.517156] i915: No ACPI video bus found
[ 3.774151] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[ 3.774654] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0c1e00a1
[ 3.774659] nouveau [ DEVICE][0000:01:00.0] Chipset: GF108 (NVC1)
[ 3.774663] nouveau [ DEVICE][0000:01:00.0] Family : NVC0
[ 3.778240] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image...
[ 3.787999] nouveau [ VBIOS][0000:01:00.0] ... signature not found
[ 3.788002] nouveau [ VBIOS][0000:01:00.0] checking PROM for image...
[ 3.788086] nouveau [ VBIOS][0000:01:00.0] ... signature not found
[ 3.788087] nouveau [ VBIOS][0000:01:00.0] checking ACPI for image...
[ 4.624674] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid
[ 4.624679] nouveau [ VBIOS][0000:01:00.0] using image from ACPI
[ 4.624845] nouveau [ VBIOS][0000:01:00.0] BIT signature found
[ 4.624850] nouveau [ VBIOS][0000:01:00.0] version 70.08.a8.00.8d
[ 4.625140] nouveau [ DEVINIT][0000:01:00.0] adaptor not initialised
[ 4.625144] nouveau [ VBIOS][0000:01:00.0] running init tables
[ 4.753512] nouveau [ PFB][0000:01:00.0] RAM type: GDDR5
[ 4.753514] nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB
[ 4.753515] nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags
[ 4.779859] nouveau [ PTHERM][0000:01:00.0] FAN control: none / external
[ 4.779863] nouveau [ PTHERM][0000:01:00.0] fan management: disabled
[ 4.779867] nouveau [ PTHERM][0000:01:00.0] internal sensor: yes
[ 4.783179] nouveau [ DRM] VRAM: 1024 MiB
[ 4.783180] nouveau [ DRM] GART: 1048576 MiB
[ 4.783184] nouveau [ DRM] TMDS table version 2.0
[ 4.783185] nouveau [ DRM] DCB version 4.0
[ 4.783199] nouveau [ DRM] DCB outp 00: 01000323 00010034
[ 4.783201] nouveau [ DRM] DCB outp 01: 020323a6 0f220010
[ 4.783202] nouveau [ DRM] DCB outp 02: 040433b6 0f220010
[ 4.783203] nouveau [ DRM] DCB outp 03: 08024382 00020010
[ 4.783204] nouveau [ DRM] DCB outp 04: 02032362 00020010
[ 4.783205] nouveau [ DRM] DCB outp 05: 04043372 00020010
[ 4.783206] nouveau [ DRM] DCB outp 06: 02011300 00000000
[ 4.783207] nouveau [ DRM] DCB conn 00: 00000041
[ 4.783209] nouveau [ DRM] DCB conn 01: 00000100
[ 4.783210] nouveau [ DRM] DCB conn 02: 00001246
[ 4.783211] nouveau [ DRM] DCB conn 03: 00002346
[ 4.783212] nouveau [ DRM] DCB conn 04: 00010461
[ 4.783213] nouveau [ DRM] DCB conn 05: 00000500
[ 4.783878] nouveau [ DRM] ACPI backlight interface available, not registering our own
[ 4.784072] nouveau [ DRM] 3 available performance level(s)
[ 4.784075] nouveau [ DRM] 0: core 50MHz shader 101MHz memory 135MHz voltage 830mV
[ 4.784076] nouveau [ DRM] 1: core 202MHz shader 405MHz memory 324MHz voltage 830mV
[ 4.784078] nouveau [ DRM] 3: core 672MHz shader 1344MHz memory 1569MHz voltage 980mV
[ 4.784079] nouveau [ DRM] c: core 202MHz shader 405MHz memory 324MHz
[ 4.789392] nouveau [ DRM] MM: using COPY0 for buffer copies
[ 4.925967] nouveau [ DRM] allocated 1680x1050 fb: 0x60000, bo ffff88021fc21400
[ 4.926065] nouveau 0000:01:00.0: fb1: nouveaufb frame buffer device
[ 4.926068] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 1
Poking around with xrandr will give you totally different outputs from the Nvidia driver:
$ xrandr -q|grep conn
LVDS1 connected (normal left inverted right x axis y axis)
VGA1 connected primary 1680x1050+0+0(normal left inverted right x axis y axis) 474mm x 296mm
LVDS-2 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected 1680x1050+1680+0(normal left inverted right x axis y axis) 474mm x 296mm
HDMI-1 disconnected (normal left inverted right x axis y axis)
VGA-2 disconnected (normal left inverted right x axis y axis)
$ xrandr -q | grep conn
LVDS1 connected (normal left inverted right x axis y axis)
VGA1 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm
LVDS-2 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected 1680x1050+1680+0 (normal left inverted right x axis y axis) 474mm x 296mm
HDMI-1 disconnected (normal left inverted right x axis y axis)
VGA-2 disconnected (normal left inverted right x axis y axis)
But at least they’re consistent with the Gnome Displays panel:
For reasons I don’t understand the Nvidia card appears twice in 2 different but identical providers:
With the tests I made, there’s no apparent difference when using one or the other. Usage of one card or the other is driven by the DRI_PRIME environment variable. If it’s set to 0, commands run on the Intel card, if it’s set to 1 they will run on the Nvidia card. For example:
$ DRI_PRIME=1 vdpauinfo |grep-i string
Information string: G3DVL VDPAU Driver Shared Library version 1.0
$ DRI_PRIME=1 vdpauinfo | grep -i string
Information string: G3DVL VDPAU Driver Shared Library version 1.0
Or even better, to check OpenGL status:
$ glxinfo |grep-e'OpenGL.*string.*'
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.1(Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.2.0
OpenGL shading language version string: 1.30
$ glxinfo | grep -e 'OpenGL.*string.*'
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.2.0
OpenGL shading language version string: 1.30
$ DRI_PRIME=1 glxinfo |grep-e'OpenGL.*string.*'
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVC1
OpenGL core profile version string: 3.1(Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.2.0
OpenGL shading language version string: 1.30
$ DRI_PRIME=1 glxinfo | grep -e 'OpenGL.*string.*'
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVC1
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.2.0
OpenGL shading language version string: 1.30
Unfortunately the desktop is very slow, it’s rendered by the Intel driver and put on the Nvidia card for display. I’ve tried changing priority in vga_switcheroo prior to starting X, setting the DRI_PRIME=1 variable at boot, use xrandr to change the provider output source etc. to no avail; the desktop can run only on the first card or it doesn’t work. Usually I get a black screen upon GDM start.
There’s no power management as well, so the Intel card runs normally but the Nvidia one is always on and stuck in an intermediate performance level.
When docking it; I get cloned outputs on all external displays at a very low resolution. Same issue with the Optimus disabled Nouveau driver; the outputs need to be rearranged, the lid closed and the computer needs to be woken up from standby.
Optimus cards power operation
Dual cards can be shut down on demand through vga_switcheroo. For example, login in your system as root without X running. Look at the card status with the following command:
This will tell you that the Integrated Graphics Display (IGD) is powered up (Pwr) and that is the primary display (+). To shut off the secondary video card, a single command is required:
# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch# cat /sys/kernel/debug/vgaswitcheroo/switch0:IGD:+:Pwr:0000:00:02.01:DIS: :Off:0000:01:00.0
This will shutdown the Nvidia card. A look at the battery will tell you now that you have twice the power because the Intel card sucks very little power compared to the Nvidia one.
Turn the card on again, and switch the framebuffer console to it:
# echo ON > /sys/kernel/debug/vgaswitcheroo/switch# cat /sys/kernel/debug/vgaswitcheroo/switch0:IGD:+:Pwr:0000:00:02.01:DIS: :Pwr:0000:01:00.0# echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch[879.436727] i915: switched off
# cat /sys/kernel/debug/vgaswitcheroo/switch0:IGD: :Off:0000:00:02.01:DIS:+:Pwr:0000:01:00.0
As you can see the second card is dynamically powered. Try to undock the system and check the status again: the second output is no longer needed so the second card shuts off:
You will notice a slight delay before the command output is returned, but the card is powered on again! This is awesome. Now, after 1 or 2 seconds look again at the card:
It’s shut off! Dock the laptop again and the monitor should come up again.
Keep in mind that powering up and down cards is a totally different things than power managing and adjusting clocks etc. for a running card. This make the Nvidia card shutdown automatically, not regulate its power levels during usage.
Summary
A Prime enabled laptop does not have any configuration and does not require any manual configuration. The fact that the Nvidia card can power down itself is great and doubles my battery duration! On the screen I have KMS consoles without huge fonts and can have UEFI secure boot enabled! This is really awesome.
Unfortunately though, without proper Nouveau power management and performance improvements added to the fact that I need to reconfigure monitors everytime I move (sometime the output gets all black as well when docking); the experience is not that great. I don’t know why, but when I’m undocked and using only the LVDS internal panel, the Intel performance is fantastic. Problems arise only when it’s docked and Nouveau is enabled as well.
My old laptop was working flawlessly with Nouveau. I didn’t play games on it, it was not Optimus based and the driver was generally working better.
Optimus
Disabled
Disabled
Enabled
Enabled (Prime)
Driver
Nvidia
Nouveau
Intel/Nvidia
Intel/Nouveau
Configuration
Very easy.
Already set up.
Very complex
Already set up.
Card power
management
Perfect!
Poor performance, no power management.
Nvidia card always powered up, renders for all screens.
Dynamic video card switching works fine, Nouveau performance not.
Optimus card
power management
N.A.
N.A.
Nvidia card can't power down.
Perfect!
Docking / Undocking
Perfect!
Manual intervention required
Manual intervention required, unreliable
Manual intervention required
Performance
Perfect!
Pretty bad.
Very good, some tearing when moving windows.
Bad when using the Nvidia card for output, otherwise perfect!
Bios Console
VGA, no KMS.
Perfect (KMS)!
Perfect (KMS on Intel).
Perfect (KMS)!
UEFI Console
Uses efifb. Somewhat slow.
Perfect (KMS)!
Perfect (KMS on Intel).
Perfect (KMS)!
UEFI secure boot
Can't work.
Perfect!
Can't work.
Perfect!
Summing up, my current choice is for the Optimus disabled setup with Nvidia drivers. I can play games, dock, undock, power management works ok and I can drive all outputs easily. And if I need to go in a meeting I don’t need to be extra cautious in shutting down virtual machines, because the system might not go up again. It’s kinda retro style when booting with the text console and battery does not last more than 3 hours, but I can bear it.
I’m impressed by the current X.org improvements of the last years and really looking forward to new developments. Sometimes just for fun I often switch back to the free drivers to check the status; like the new dynamic power management in kernel 3.12.
Let’s hope Nvidia collaboration becomes better and the new documentation does not simply stop to what has been announced.
Recent Comments