NVIDIA/nvidia-drivers/it

è il driver grafico proprietario per schede grafiche nVidia. Una alternativa open source è nouveau.

I drivers vengono rilasciati da nVidia e sono costruiti per il kernel di Linux. Essi contengono una parte binaria che fa il lavoro pesante per dialogare con la scheda video. I driver sono costituiti da due parti, un modulo del kernel, e un driver X11. Entrambe le parti sono incluse in un singolo pacchetto. A causa del modo in cui nVidia ha creato i suoi drivers, è necessario fare delle scelte prima di installarli.

Il pacchetto contiene i driver più recenti di nVidia con supporto per tutte le schede video, con diverse versioni disponibili a seconda dell'età della scheda. Si avvale di un eclass per rilevare che tipo di scheda è in esecuzione sul sistema, in modo che installi la versione corretta.

Compatibilità hardware
Il pacchetto supporta una vasta gamma di schede nVidia disponibili. Versioni multiple sono disponibili per l'installazione, a seconda della scheda video che ha il sistema. Consultare la documentazione ufficiale di nVidia, What's a legacy driver?, per scoprire che versione di dovrebbe essere installata. Un modo abbastanza buono per scoprirlo è attraverso an interactive form. Inserire la scheda grafica che viene utilizzata dal sistema (ricordare l'opzione Legacy nel campo 'Tipo di prodotto') e il form dirà qual'è la versione più supportata.

Se la scheda è stata identificata come legacy, mascherare le più recenti releases di, cioè

If the card has been identified as a legacy card then mask the more recent releases of, e.g.:

Si noti che Gentoo non fornisce la versione 71.86.xx. Se il sistema dispone di una scheda che ha bisogno di queste versioni di drivers, allora è consigliabile utilizzare il driver nouveau.

Kernel
Come accennato in precedenza, il driver del kernel nVidia installa ed esegue in opposizione al kernel corrente. Se costruito come modulo, il kernel deve supportare il caricamento dei moduli (vedi sotto).

Il modulo del kernel è costituito da una parte proprietaria (comunemente nota come "binary blob") che pilota il chip grafico, e una parte open source (detta "glue") che durante il fuzionamento opera come intermediario tra la parte proprietaria e il kernel. Questi tutti hanno bisogno di lavorare bene insieme, altrimenti l'utente potrebbe trovarsi di fronte alla perdita di dati (attraverso kernel panic, X server crashing con i dati non salvati nelle applicazioni X) e anche guasti hardware (surriscaldamento e altre questioni di alimentazione relative che potrebbero venire in mente).

Compatibilità del kernel
Di tanto in tanto, una nuova release del kernel cambia l'ABI interno per i drivers, il che significa che tutti i drivers che utilizzano tali ABI devono essere modificati di conseguenza. Per i drivers open source, in particolare quelli distribuiti con il kernel, questi cambiamenti sono banali da risolvere dal momento che l'intera catena di chiamate tra i drivers e le altre parti del kernel possono essere riviste abbastanza facilmente. Per i drivers proprietari come nvidia.ko, non è proprio la stessa cosa. Quando l'ABI interno viene cambiato non è possibile sistemare semplicemente il "glue", perché nessuno sa come tale "glue" (collante) è utilizzato dalla parte proprietaria. Anche dopo essere riusciti a sistemare le cose e anche dopo che queste sembra funzionino bene, l'utente rischia ancora l'esecuzione di nvidia.ko nel nuovo kernel non supportato, e ciò porterà alla perdita di dati e guasti hardware.

Quando una nuova incompatibile versione del kernel viene rilasciata, è probabilmente meglio attaccarsi per un po' al nuovo kernel supportato. Nvidia richiede solitamente un paio di settimane per preparare una nuova release e in genere pensano che questa sia adatta per un uso generale. Sii paziente. Se assolutamente necessario è possibile utilizzare il comando epatch_user con gli ebuild nvidia-drivers: questo permette all'utente di adattare in qualche modo i drivers nvidia con l'ultima versione del kernel non supportata. Da notare che né i manutentori dei drivers nvidia né Nvidia stessa sosterranno questa situazione. La garanzia hardware molto probabilmente sarà nulla, i manutentori di Gentoo non potranno iniziare a risolvere i problemi in quanto si tratta di un driver proprietario che solo Nvidia può correttamente mettere a punto, e i manutentori del kernel certamente non supportano i driver proprietari o qualsiasi "sistema contaminato" che funziona in difficoltà.

Se per configurare il kernel è stato utilizzato, ogni cosa è impostata. Se non è stato utilizzato, invece, va fatto un doppio controllo nella configurazione del kernel, in modo che il seguente supporto sia abilitato:

Abilitare anche il "Memory Type Range Register" nel kernel:

With at least some if not all driver versions it may also be required to enable VGA Arbitration and the IPMI message handler:

Se il sistema ha una scheda grafica AGP, abilitare opzionalmente l'agpgart supportato dal kernel, sia compilato direttamente nel kernel sia come modulo. Se il modulo agpgart compilato direttamente nel kernel non viene utilizzato, i drivers utilizzeranno la propria implementazione agpgart, chiamata NvAGP. Su alcuni sistemi, questa si comporta meglio rispetto alla agpgart compilata direttamente sul kernel, e su altri, invece, si comporta peggio. Valutare la scelta sul proprio sistema per ottenere le migliori prestazioni. Quando incerti sul da farsi, utilizzare l'agpgart compilato nel kernel:

Un'alternativa al framebuffer è uvesafb, che può essere installato parallelamente al pacchetto.

Per i sistemi (U)EFI uvesafb non funzionerà. Sappiate che l'abilitazione del supporto "efifb" nel kernel causa problemi intermittenti con l'inizializzazione dei drivers nvidia. Non c'è alcun framebuffer alternativo conosciuto per i sistemi (U)EFI.

Gli ebuild nvidia-drivers rilevano automaticamente la versione del kernel basato sul link simbolico. Si prega di assicurarsi che tale link simbolico punti ai sorgenti corretti e che il kernel sia configurato correttamente. Si prega di consultare la sezione "Configuring the Kernel" del Gentoo Handbook per dettagli sulla configurazione del kernel.

Primo, scegliere la giusta sorgente del kernel utilizzando. Quando si utilizza la versione 3.7.10 del pacchetto per esempio, la lista dei kernel potrebbe essere simile a questa:

Nella schermata sopra, si noti che il kernel linux-3.7.10-gentoo è contrassegnato con un asterisco (*) per mostrare che è il kernel selezionato con un collegamento simbolico.

Se il link simbolico non punta ai sorgenti corretti, aggiornare il collegamento selezionando il numero della versione del kernel desiderata, come nell'esempio precedente.

Drivers
Ora è tempo di installare i drivers. Primo, segui la guida X Server Configuration Guide e imposta  su. Durante l'installazione del server X, verrà installata la versione corretta del pacchetto.

Una volta terminata l'installazione, eseguire il comando per caricare il modulo del kernel in memoria. Se si tratta di un aggiornamento, rimuovere il modulo precedente.

Per evitare di dover caricare manualmente il modulo ad ogni avvio, per far si che questo sia fatto automaticamente ogni volta che il sistema viene avviato, editare ed aggiungerci.

Firmare i moduli del kernel (opzionale)
Se si utilizza l'avvio sicuro del kernel con firma, allora si avrà bisogno di firmare i moduli del kernel Nvidia prima che possano essere caricati.

Questo si fa utilizzando lo script per il kernel fornito da, come segue.

Come per la versione del driver 358.09, è stato fatto un nuovo modulo per la gestione della modalità monitor e per questa versione del driver deve essere firmato tale modulo.

Una volta firmati questi moduli, il driver viene caricato all'avvio come previsto. Questo metodo di firma può essere utilizzato per firmare altri moduli non solo nvidia-drivers. Di conseguenza si dovrà modificare il percorso e il modulo corrispondente.

L'X server
Una volta che i driver appropriati sono installati, configurare il server X per utilizzare il driver  invece che quello di default.

Eseguire così che X server utilizzi le librerie GLX nVidia:

Abilitazione del supporto globale nvidia
Alcuni pacchetti, come ad esempio e, utilizzano una USE flag locale chiamata   la quale abilita il supporto XvMCNVIDIA, utile quando si guardano filmati ad alta risoluzione. Aggiungere  nella variabile USE sul file  o aggiungerla come USE flag su  e/o  su.

Le serie GeForce 8 e quelle successive sono dotate di supporto VDPAU che ha sostituito il supporto XvMCNVIDIA. Vedere l'articolo VDPAU per abilitare il supporto VDPAU.

Ci sono anche alcune applicazioni che utilizzano la USE flag, così che potrebbe essere una buona idea aggiungerla su.

Quindi, eseguire per ricompilare le applicazioni che beneficiano della variazione della USE flag.

Utilizzare lo strumento di impostazioni nVidia
nVidia fornisce anche uno strumento per le impostazioni. Tale strumento consente all'utente di monitorare e variare le impostazioni grafiche senza riavviare il server X ed è disponibile attraverso il Portage come. Come accennato in precedenza, lo strumento per le impostazioni verrà incluso automaticamente durante l'installazione dei driver con la USE flag  impostata su  o su.

Abilitazione OpenGL/OpenCL
Per abilitare OpenGL e OpenCL attraverso il dispositivo, eseguire:

Assicurarsi che il server Xorg non sia in esecuzione durante queste variazioni.

Testare la scheda
Per testare la scheda nVidia, avviare X ed eseguire il comando, il quale fa parte del pacchetto. Esso dovrebbe dire che il direct rendering è attivato:

Per monitorare gli FPS, eseguire.

FATAL: modpost: GPL-incompatible module *.ko uses GPL-only symbol
When the ebuild is complaining about the 'mutex_destroy' GPL-only symbol:

Be sure to disable CONFIG_DEBUG_MUTEXES in the kernel's file, as suggested by this forum thread.

Il driver non viene inizializzato quando gli interrupt MSI sono abilitati
Il driver Linux NVIDIA utilizza Message Signaled Interrupts (MSI) come impostazione predefinita. Questo offre vantaggi di compatibilità e scalabilità, dovuti principalmente alla prevenzione di condivisione IRQ. Alcuni sistemi hanno problemi di supporto MSI, mentre lavorano bene con i virtual wire interrupts. Questi problemi si manifestano come l'incapacità di lanciare X con il driver NVIDIA, o errori di inizializzazione CUDA.

MSI interrupts può essere disabilitato tramite il parametro del modulo del kernel NVIDIA. Questo può essere impostato nella linea di comando durante il caricamento del modulo, o più appropriatamente tramite i files di configurazione del modulo del kernel della distribuzione (come quelli sotto ).

Per esempio:

Ottenere l'accelerazione 2D su macchine con memoria da 4 GB in su
Quando l'accelerazione nVidia 2D da problemi, allora è probabile che il sistema è incapace di impostare una impostazione write-combining con MTRR. Per verificare, controllare il contenuto di :

Ogni riga dovrebbe contenere  o. Quando una linea contiene  è necessario variare l'impostazione del BIOS per risolvere.

Riavviare e accedere al BIOS, poi trovare le impostazioni MTRR (probabilmente sotto "Impostazioni della CPU"). Modificare l'impostazione da  a   e avviare Linux. A questo punto non c'è più  e l'accelerazione 2D ora funziona senza errori.

"no such device" appare quando si cerca di caricare il modulo del kernel
Questo in genere è causato da uno dei seguenti problemi:


 * 1) Il sistema non ha affatto una scheda nVidia. Controllare il messaggio che rilascia il comando  per vedere se il sistema ha una scheda video nVidia installata e rilevata.
 * 2) La corrente versione installata del pacchetto  non supporta il modello di scheda video montata. Controllare il file README in /usr/share/nvidia-drivers-*/ per vedere la lista dei dispositivi supportati, oppure ricercare il driver corretto su http://www.geforce.com/drivers.
 * 3) Un altro driver del kernel ha il controllo dell'hardware. Digitare  per vedere se un altro driver, tipo "nouveau", è legato alla scheda grafica. Se è così, disattivare o mettere in blacklist tale driver.

Xorg dice che non può trovare nessuno schermo
Quando l'avvio del sistema finisce con uno schermo nero o riga di comando invece dell'interfaccia grafica GUI, digitare ++ per spostarsi su una console virtuale. Successivamente eseguire:

per vedere il risultato di Xorg. Se uno dei primi errori è che Xorg non può trovare nessuno schermo, seguire i passi successivi per risolvere il problema.

Dovrebbe essere sufficiente eseguire il seguente comando prima dell'avvio:

Ma se non funziona, eseguire e notare che la scheda video inizia in questo modo:

Prendere il primo bit,  e metterlo nel file  con l'opzione  :

Direct rendering non è abilitato
Se direct rendering non funziona, questo può derivare dal fatto che il kernel ha Direct Rendering Manager attivato, il quale va in conflitto con il driver. Vedere lo stato di direct rendering seguendo le istruzioni nella sezione Testing the card.

Per prima cosa, disabilitare Direct Rendering Manager nel kernel:

Successivamente, ricostruire il pacchetto dal momento che il driver possa aver compilato il DRM del kernel. Questo dovrebbe risolvere il problema.

Riproduzione video a scatti o lenta
Ultimamente sembra che ci siano certi problemi con la riproduzione di alcuni tipi di video con i driver binari NVidia, causando la riproduzione dei video significativamente a scatti o lenta. Questo problema sembra si verifichi sulle CPU Intel anzichè sulle comuni CPU ACPI.

Disabilitare il metodo minimo della CPU intel utilizzando  nella linea di comando di avvio del kernel, il quale dovrebbe causare l'automatica caduta del kernel al normale o più vecchio metodo minimo della CPU ACPI. Disabilitare anche la caratteristica Powermizer di NVidia, o impostare Powermizer alla massima performance con può essere d'aiuto. Il metodo minimo della CPU Intel recentemente ha introdotto come predefinito il metodo minimo per i5 e i7 CPUs (rispetto all'utilizzo del minimo della CPU ACPI) ed è questa la causa principale. Questo metodo minimo risolve in maniera significativa il problema, tuttavia si incontra un pò di scattosità o lentezza nella riproduzione dei video se il deinterlacciamento è stato attivato; questo è quando il video è già deinterlacciato (per esempio alias  con qualcosa simile a   come un lavoro sparso.)

If you're using GRUB2 as your bootloader, you can add this kernel parameter to  like so:

Don't forget to run  after making the change, so that the new configuration is generated (see the GRUB2 page for further details).

After you have rebooted, you can verify that the change is active:

Nessuna sincronizzazione verticale (no VSync, lacerazione) nelle applicazioni OpenGL
Aggiungere la seguente opzione alla sezione screen, previene l'effetto lacerazione su GTX 660, 660 Ti, e probabilmente qualche altra GPUs (reference):

Documentazione
Anche il pacchetto viene fornito con una documentazione completa. Questo è installato dentro e può essere consultato con il seguente comando:

Parametri del modulo del kernel
Il modulo del kernel  accetta un numero di parametri (opzioni) che possono essere utilizzati per monitorare il comportamento del driver. Molti di questi sono menzionati nella documentazione. Per aggiungere o variare i valori di questi parametri, modificare il file. Ricordare di eseguire dopo la modifica di questo file, e tenere presente di ricaricare il modulo   prima che le nuove impostazioni abbiano effetto.

Modificare :

Scaricare il modulo ...

... e caricarlo nuovamente:

Configurazioni di X avanzate
Anche GLX ha una vastità di opzioni che possono essere configurate. Queste controllano la configurazione di uscita TV, dual displays, la rilevazione della frequenza del monitor, ecc... Anche in questo caso, tutte le opzioni disponibili sono descritte nella documentazione.

Per utilizzare ognuna di queste opzioni, elencarle nella relativa sezione Device del file di configurazione di X (in genere ). Per esempio, per disabilitare il logo splash:

Vedi anche

 * nouveau & nvidia-drivers switching - Modalità grafica ibrida utilizzando i driver open-source.
 * NVIDIA Optimus - Configurare un sistema per utilizzare i driver closed-source per la grafica ibrida (modesetting).