NVIDIA/nvidia-drivers/es

es el controlador propietario para tarjetas de vídeo nVidia. Una alternativa de código abierto es nouveau.

El paquete del árbol lo mantiene nVidia y se construye con el núcleo Linux. Contienen un gran fichero binario (blob) que realiza el trabajo pesado para comunicarse con la tarjeta de vídeo. Los controladores están compuestos por dos partes, un módulo para el núcleo y un controlador X11. Ambas partes se incluyen en un solo paquete. Debido a la forma en que nVidia empaqueta sus controladores, es necesario tomar algunas decisiones antes de instalar los controladores.

El paquete contiene los controladores más recientes de nVidia con soporte para todas las tarjetas, con varias versiones disponibles, dependiendo de la antigüedad de tenga su tarjeta. Utiliza un «eclass» para detectar qué tipo de tarjeta está funcionando en el sistema para que se instale la versión correcta.

Compatibilidad del hardware
El paquete es compatible con una amplia gama de tarjetas nVidia disponibles. Están disponibles múltiples versiones para su instalación, dependiendo de la tarjeta(s) que tenga el sistema. Consulte la documentación oficial de nVidia, ¿Qué es un controlador antiguo?, para averiguar qué versión de debe ser utilizada. Una manera bastante decente para encontrar esta versión es a través de un formulario interactivo. Introduzca la tarjeta gráfica que es utilizada por el sistema (no olvide la opción de Legacy en el campo «Product Type») y el formulario debe terminar con la versión más compatible.

Si la tarjeta ha sido identificada como una tarjeta antigua entonces se enmascara con los lanzamientos más recientes de, esto es:

Observe que Gentoo no proporciona las versiones 71.86.xx. Si el sistema tiene una tarjeta que necesita estos controladores, entonces se recomienda utilizar el controlador nouveau.

El núcleo de línux
Como se mencionó anteriormente, el controlador nVidia del núcleo se instala y ejecuta al margen del núcleo actual. Se construye como módulo, por lo que el núcleo debe soportar la carga de los módulos del núcleo (ver más abajo).

The kernel module (nvidia.ko) consists of a proprietary part (commonly known as the "binary blob") which drives the graphics chip(s), and an open source part (the "glue") which at runtime acts as intermediary between the proprietary part and the kernel. These all need to work nicely together as otherwise the user might be faced with data loss (through kernel panics, X servers crashing with unsaved data in X applications) and even hardware failure (overheating and other power management related issues should spring to mind).

Compatibilidad del núcleo
De vez en cuando, una nueva versión del núcleo cambia la ABI (siglas en inglés de application binary interface —interfaz binaria de aplicación—) interna para los controladores, lo que significa que todos los controladores que utilizan esas ABI deben cambiar en consecuencia. Para controladores de código abierto, especialmente los distribuidos con el núcleo, estos cambios son casi triviales de arreglar, ya que toda la cadena de llamadas entre los controladores y otras partes del núcleo pueden ser revisadas con bastante facilidad. Para los controladores propietarios, como nvidia.ko, esto no funciona exactamente igual. Cuando cambia la ABI interna, entonces no es posible simplemente ajustar el «glue», porque nadie sabe cómo el glue se utiliza por la parte propietaria. Incluso después de arreglar las cosas de manera que parezcan funcionar bien, el usuario corre el riesgo de que la ejecución de nvidia.ko en el nuevo núcleo no esté soportada, dando lugar a la pérdida de datos y fallos del hardware.

Cuando se libera una nueva versión del núcleo incompatible, probablemente sea mejor quedarse, por un tiempo, con el núcleo con soporte más reciente. nVidia suele tardar un par de semanas en preparar una nueva versión patentada que considere apta para su uso general. Sea paciente. Si es absolutamente necesario, entonces es posible utilizar la orden epatch_user con los ebuilds de nvidia-drivers: esto permite al usuario parchear nvidia-drivers para adaptarse, de alguna manera, con lo último, es decir, la liberación del núcleo no compatible. Tenga en cuenta que ni los mantenedores de nvidia-drivers ni de nVidia dan soporte a esta situación. No habrá ninguna garantía para el hardware, los mantenedores de Gentoo no pueden comenzar a solucionar los problemas, ya que es un driver propietario que solo nVidia puede depurar adecuadamente, y los mantenedores del núcleo (tanto de Gentoo como los de desarrollo) no darán, sin duda, soporte a los controladores propietarios, o, de hecho, a cualquier sistema «viciado por estos» que pase a tener problemas.

Opciones obligatorias del núcleo
Si se utiliza genkernel all para configurar el núcleo, entonces todo estará listo. En caso contrario, vuelva a comprobar la configuración del núcleo para que este soporte (cargas los módulos) esté activado:

Active también Memory Type Range Register en el núcleo:

Si el sistema tiene una tarjeta gráfica AGP, entonces, active opcionalmente el soporte agpgart para el núcleo, ya sea compilado (en el núcleo) o como módulo. Si (la opción) del módulo agpgart (compilado) en el núcleo no se utiliza, entonces, los controladores usarán su propia implementación de agpgart, llamada NvAGP. En algunos sistemas, esto produce un mejor comportamiento que el módulo agpgart en el núcleo, y en otros, se comporta peor. Evalúe una u otra opción en el sistema para obtener el mejor rendimiento. Cuando no sepa qué hacer, utilice agpgart en el núcleo:

Una alternativa a framebuffer es uvesafb, que se puede instalar en paralelo a.

Para sistemas (U)EFI, uvesafb no funcionará. Advierta que activar el soporte para efifb en el núcleo provocará problemas intermitentes con la inicialización de los controladores de nVidia. No hay alternativa conocida para framebuffer en los sistemas (U)EFI.

Los ebuild de nvidia-drivers detectan automáticamente la versión del núcleo basándose en el enlace simbólico. Asegúrese de que este enlace simbólico apunta a las fuentes correctas y que el núcleo está configurado correctamente. Por favor, consulte la sección «Configurar el núcleo» del Gentoo Handbook para obtener más detalles sobre la configuración del núcleo.

En primer lugar, elija la fuente del núcleo adecuada con eselect. Cuando utilizamos gentoo-sources-3.7.10</tt>, el núcleo listado podría ser algo como esto:

En la salida anterior, notará que el núcleo linux-3.7.10-gentoo</tt> está marcado con un asterisco para mostrar que es el núcleo vinculado.

Si el enlace simbólico no apunta a las fuentes correctas, actualice el enlace, seleccionando el número de la fuente del núcleo deseada, como en el ejemplo anterior.

Controladores
Ahora es el momento de instalar los controladores. En primer lugar, siga la X Server Configuration Guide y ajuste la variable  en. Durante la instalación del servidor X, esto hará que se instale la versión correcta de.

Una vez finalizada la instalación, ejecute modprobe nvidia</tt> para cargar el módulo del núcleo en la memoria. Si se trata de una actualización, retire primero el módulo anterior.

Para evitar tener que cargar manualmente el módulo en cada arranque, puede hacer que este se cargue de forma automática cada vez que se arranca el sistema, editando el fichero y añadiendo   al mismo.

El servidor X
Una vez instalados los controladores adecuados, hay que configurar el servidor X para utilizar el controlador nvidia</tt>, en lugar del controlador predeterminado nv</tt>.

Ejecute eselect</tt> para que el servidor X utilice las bibliotecas GLX de nVidia:

Permisos
Tendrá que añadir el usuario al que desea dar capacidad de acceder a la tarjeta de vídeo al grupo «video»:

Observe que todavía será capaz de ejecutar X sin permiso para el subsistema DRI, pero, por lo general, no con la aceleración activada.

Probar la tarjeta gráfica
Para probar la tarjeta nVidia, encienda X y ejecute glxinfo</tt>, que es parte del paquete. Este debería decir que el renderizado directo está activado:

Para los FPS (siglas en inglés frames per second —fotogramas por segundo—) del monitor, ejecute glxgears</tt>.

Enabling nvidia support
Some tools, such as and, use a local USE flag called   which enables XvMCNVIDIA support, useful when watching high resolution movies. Add in  in the USE variable in  or add it as USE flag to   and/or   in.

GeForce 8 series and later GPUs do come with VDPAU support which superseded XvMCNVIDIA support. See the VDPAU article for enabling VDPAU support.

There are also some applications that use the  USE flag, so it might be a good idea to add it to.

Then, run emerge -uD --newuse @world</tt> to rebuild the applications that benefit from the USE flag change.

Using the nVidia settings tool
nVidia also provides a settings tool. This tool allows the user to monitor and change graphical settings without restarting the X server and is available through Portage as. As mentioned earlier, it will be pulled in automatically when installing the drivers with the  USE flag set in  or in.

Enable OpenGL/OpenCL
To enable OpenGL and OpenCL.

Asegúrese de que el servidor Xorg no se está ejecutando mientras se realizan estos cambios.

Driver fails to initialize when MSI interrupts are enabled
The Linux NVIDIA driver uses Message Signaled Interrupts (MSI) by default. This provides compatibility and scalability benefits, mainly due to the avoidance of IRQ sharing. Some systems have been seen to have problems supporting MSI, while working fine with virtual wire interrupts. These problems manifest as an inability to start X with the NVIDIA driver, or CUDA initialization failures.

MSI interrupts can be disabled via the NVIDIA kernel module parameter. This can be set on the command line when loading the module, or more appropriately via the distribution's kernel module configuration files (such as those under ).

For instance:

Getting 2D acceleration to work on machines with 4GB memory or more
When nVidia 2D acceleration is giving problems, then it is likely that the system is unable to set up a write-combining range with MTRR. To verify, check the contents of :

Every line should contain write-back</tt> or write-combining</tt>. When a line shows up with uncachable</tt> in it then it is necessary to change a BIOS setting to fix this.

Reboot and enter the BIOS, then find the MTRR settings (probably under "CPU Settings"). Change the setting from continuous</tt> to discrete</tt> and boot back into Linux. There is now no uncachable</tt> entry anymore and 2D acceleration now works without any glitches.

"no such device" appears when trying to load the kernel module
This is usually caused by one of the following issues:


 * 1) The system does not have a nVidia card at all.  Check lspci</tt> output to confirm that the system has a nVidia graphics card installed and detected.
 * 2) The currently installed version of  does not support the installed graphics card model.  Check the README file in /usr/share/nvidia-drivers-*/ for a list of supported devices, or use the driver search at http://www.geforce.com/drivers.
 * 3) Another kernel driver has control of the hardware.  Check <tt>lspci -k</tt> to see if another driver like "nouveau" is bound to the graphics card.  If so, disable or blacklist this driver.

Xorg says it can't find any screens
When after booting the system, it ends up with a black screen or a console prompt instead of the GUI; then press ++ to bring up a virtual console. Next, run:

to see the output of Xorg. If one of the first errors is that Xorg can't find any screens, then follow the following steps to resolve the issue.

It should be enough to run the following command before rebooting:

But if that doesn't work, run <tt>lspci</tt> and notice that the video card starts off like this:

Take the first bit,  and put it in the  file with the   option:

Direct rendering is not enabled
If direct rendering does not work, it may be because the kernel has Direct Rendering Manager enabled, which conflicts with the driver. See the direct rendering status by following instructions in the section Testing the card.

First, disable Direct Rendering Manager in the kernel :

Next, rebuild since the driver may have built against the kernel DRM symbols. It should fix the problem.

Video playback stuttering or slow
Lately there seems to be some breaking with playback of some types of video with the NVidia binary drivers, causing slow video playback or significant stuttering. This problem seems to be occurring within the Intel CPU Idle replacement instead of the common ACPI CPU idling method for certain CPU's.

Disable the Intel CPU idling method using  on the kernel command line boot method, which should cause the kernel to automatically fall back to the normal or older ACPI CPU idling method. Also, disabling the NVidia Powermizer feature, or setting Powermizer to maximum performance within <tt>nvidia-settings</tt> has been said to help. Although the Intel CPU idling method recently was introduced as the default CPU idling method for i5 and i7 CPUs (versus using ACPI CPU idling) is the root cause here. This idling method significantly solves the problem, however some minimal stuttering or slow video is encountered if deinterlacing was enabled; this is when the video is likely already deinterlaced (ie. alias <tt>mplayer-nodeint</tt> with something similar to <tt>mplayer -vo vdpau:deint=0:denoise=0:nochroma-deint:colorspace=0:hqscaling=1, video.mpg</tt> as a work around.)

Documentation
The package also comes with comprehensive documentation. This is installed into and can be viewed with the following command:

Kernel module parameters
The <tt>nvidia</tt> kernel module accepts a number of parameters (options) which can be used to tweak the behaviour of the driver. Most of these are mentioned in the documentation. To add or change the values of these parameters, edit the file. Remember to run <tt>update-modules</tt> after modifying this file, and bear in mind to reload the  module before the new settings take effect.

Edit :

Update module information:

Unload the <tt>nvidia</tt> module...

...and load it once again:

Advanced X configuration
The GLX layer also has a plethora of options which can be configured. These control the configuration of TV out, dual displays, monitor frequency detection, etc. Again, all of the available options are detailed in the documentation.

To use any of these options, list them in the relevant Device section of the X config file (usually ). For example, to disable the splash logo: