[nvidia] le nouveaux choix du libre

Message

jetboo · Post by **jetboo** » Thu Sep 02, 2010 11:08 am

Ben en faite ca m'a surpris aussi, je suis resté avec mesa 7.8.2 car hier l'overlay de x11 ne marchait pas (timeout à chaque connection,et meme le site était down)
Je vais reéssayer voir

xaviermiller · Post by **xaviermiller** » Thu Sep 02, 2010 11:18 am

Les overlays Gentoo étaient inacessibles hier soir. C'est rétabli.

jetboo · Post by **jetboo** » Thu Sep 02, 2010 11:49 am

Par ailleurs on peut maintenant régler la luminosité directement via X, alors qu'avant les drivers nvidia empêchaient ça et le temps de rétablissement d'un suspend/resume est + rapide.
Par contre il y'a un bug, au retour du suspend (au resume donc ^^) on peut plus régler la luminosité ni sur X, si sur les terminaux tyy [1-12]
edit : en faite si on peut en tapant

Code: Select all

echo 400 >> /sys/class/backlight/nv_backlight/brigthness

mais pommed ne prends plus les commandes à moins d'un reboot

Code: Select all

/etc/init.d/pommed restart

ny fait rien..

Edit 2 : corrigé avec pommed-1.34 de l'overlay keruspe

a tte

razer · Post by **razer** » Fri Sep 03, 2010 12:05 pm

jetboo wrote:Par ailleurs on peut maintenant régler la luminosité directement via X, alors qu'avant les drivers nvidia empêchaient ça et le temps de rétablissement d'un suspend/resume est + rapide.

J'ajouterais aussi que nouveau est globalement meilleur que le driver proprio en 2D et composite via xrender. Ainsi, un WM tel que metacity est plus rapide qu'avec les drivers proprios, avec comme sans composite d'activé.
En sus de KMS, de l'installation plus simple, il me parait meilleur pour tout usage hors 3D.
Libre et performant en somme, du tout bon. Reste juste à régler mon petit problème avec la synchro verticale, mais à priori cela ne dépend même pas de nouveau...

El_Goretto · Post by **El_Goretto** » Sat Sep 04, 2010 10:42 am

razer wrote:Je n'ai pas de problèmes de lenteur, mais de tearing (synchronisation verticale)

http://nouveau.freedesktop.org/wiki/XVideoStatus wrote:A note about overlays:
The overlay support status written below refers to non-KMS setup. In KMS, overlays are disabled until the proper support is added to the DRM. Since Nouveau now requires the use of KMS, overlays are not supported for now. Blitters and texture adapters still work.

Mais ensuite:

Overlay: No overlay engine. Xv has to be done via the 3D engine (i.e. provide a texture adapter), and we're not quite ready for this yet.

Xv should be fully functional.

Je ne comprends pas tout. Moi qui croyait que Xv était un overlay, erf. (passé trop de temps à bidouiller fglrx sans comprendre les fondamentaux on dirait).
Bref, pour éviter le tearing de video, il faudrait activer la synchronisation verticale côté rendu 3D (et activer un mode de rendu opengl sous mplayer j'imagine. quoique, mais alors Xv là dedans?).

--
edit:
migration sous nouveau faite avec succès, DRI ok, vidéo via Xv sans tearing, KDE 4 avec transparence et tout.
Bonheur!

guilc · Post by **guilc** » Sat Sep 04, 2010 1:57 pm

El_Goretto wrote:Je ne comprends pas tout. Moi qui croyait que Xv était un overlay, erf. (passé trop de temps à bidouiller fglrx sans comprendre les fondamentaux on dirait).
Bref, pour éviter le tearing de video, il faudrait activer la synchronisation verticale côté rendu 3D (et activer un mode de rendu opengl sous mplayer j'imagine. quoique, mais alors Xv là dedans?)

Ce que j'en ai compris :
xv est une extension vidéo qui permet de déléguer le redimensionnement et la conversion d'espace colorimétrique (YUV, YUYV et compagnie) à la carte graphique, pour éviter que ce soit le CPU qui fasse le boulot.
C'est la différence entre les sorties "xv" et "x11"

Par contre, ce que j'ai compris aussi c'est que quand le compositing est activé, xv n'est plus accessible. La manip se fait maintenant via des appels opengl sur la fenêtre de compositing (un backbuffer dans lequel est calculé ce qui va être affiché à l'écran). Bref, une "autre" manière de déléguer le boulot à la carte graphique.
Par contre, visiblement, c'est le driver qui fait le boulot de conversion, niveau mplayer ça change pas, tu utilises toujours "xv".

Enfin, c'est ce que j'ai compris de ce bazard

migration sous nouveau faite avec succès, DRI ok, vidéo via Xv sans tearing, KDE 4 avec transparence et tout.
Bonheur!

Bienvenue au club

)

geekounet · Post by **geekounet** » Sat Sep 04, 2010 2:39 pm

guilc wrote:Par contre, ce que j'ai compris aussi c'est que quand le compositing est activé, xv n'est plus accessible. La manip se fait maintenant via des appels opengl sur la fenêtre de compositing (un backbuffer dans lequel est calculé ce qui va être affiché à l'écran). Bref, une "autre" manière de déléguer le boulot à la carte graphique.
Par contre, visiblement, c'est le driver qui fait le boulot de conversion, niveau mplayer ça change pas, tu utilises toujours "xv".

C'était le cas avec l'ancienne accelération 2D XAA, mais avec EXA il n'y a plus ce soucis avec XV et le compositing (du moins c'est le cas avec mon Intel et ma Radeon), et nouveau ne gère que l'EXA donc normalement c'est tout bon.

razer · Post by **razer** » Sun Sep 05, 2010 2:33 pm

El_Goretto wrote: Bref, pour éviter le tearing de video, il faudrait activer la synchronisation verticale côté rendu 3D (et activer un mode de rendu opengl sous mplayer j'imagine. quoique, mais alors Xv là dedans?).

Là est bien le problème, car il ne semble pas possible de réaliser une synchro certicale correcte. Les drivers proprio souffrent d'ailleurs du même mal.
Perso, j'ai du tearing partout, composite ou pas : je bouge rapidement une grande fenêtre, et elle part en lamelles...
Le seul cas de figure ou je ne l'ai pas, c'est avec compiz et les drivers proprio sauf... dans les videos (je suis obligé de faire du undirect)

Fenril · Post by **Fenril** » Sat Sep 11, 2010 9:24 am

Salut à tous,

Ça y est, moi aussi, j'ai franchi le pas.

Par contre j'aimerai apporter des précisions.

* Il y a une autre option du kernel que j'ai été obligé d'activer, sinon nouveau refusait de compiler, c'est le Virtual Frame Buffer support :

Code: Select all

FB_VIRTUAL=y

Apparemment, de ce que j'ai compris, nouveau ne gère pas certaines fonctions d'accélération 2D qui doivent être émulées en utilisant des modules comme CFB_COPYAREA. Une idée ?

* Après, je n'ai pas compris pourquoi, mais même après désinstallation de nvidia-drivers, le module était encore présent, donc obligé de blacklister le module pour faire marcher nouveau.

* Ensuite, côté test : ça paraît effectivement plus fluide que sur les proprios. Cependant, j'ai fait des comparos de tests avec gtkperf entre les 2, les drivers proprios sont près de 2 fois plus rapide. Peut-être à cause de mon thème GTK qui utilise abondamment les pixmaps ? Ça me dérange pas de savoir ça puisque niveau ressenti j'ai l'impression que c'est plus fluide, je voulais juste relever la contradiction.

* En revanche, zéro problème niveau fonctionnement, vidéo, changement de résolution, réglages...
A noter, le lissage des polices est carrément meilleur, maintenant je me dis comment j'ai fait pour ne pas me plaindre avec les proprios tellement c'est horrible

* Côté 3D, j'ai bien pensé à activer gallium, mais comment être sûr qu'il y a accélération des fonctionnalités supportées ? J'aimerai contribuer à l'avancée du support 3D pour nouveau. J'ai testé avec des jeux, quelques-uns marche sans souci, mais c'est lent. Comment être sûr que ce n'est pas le CPU qui se tape tout le boulot ?

Voili voilà.

guilc · Post by **guilc** » Sat Sep 11, 2010 10:44 am

Fenril wrote:* Il y a une autre option du kernel que j'ai été obligé d'activer, sinon nouveau refusait de compiler, c'est le Virtual Frame Buffer support :
Code: Select all
FB_VIRTUAL=y
Apparemment, de ce que j'ai compris, nouveau ne gère pas certaines fonctions d'accélération 2D qui doivent être émulées en utilisant des modules comme CFB_COPYAREA. Une idée ?

Heu...

Code: Select all

# grep FB_VIRTUAL /usr/src/linux/.config
# CONFIG_FB_VIRTUAL is not set

* Après, je n'ai pas compris pourquoi, mais même après désinstallation de nvidia-drivers, le module était encore présent, donc obligé de blacklister le module pour faire marcher nouveau.

Ménage dans /lib/modules puis depmod -a

Fenril · Post by **Fenril** » Sat Sep 11, 2010 12:17 pm

Bin c'est pour ça que je demande des explications du FB_VIRTUAL...

Je suis le seul à en avoir besoin ? J'ai loupé quelque chose ?

Edit : Bon peut-être parce que je n'utilisais pas les drivers de l'overlay x11... je viens d'y passer (avec llvm d'activé), y a du mieux, principalement en 3D.

xaviermiller · Post by **xaviermiller** » Sat Sep 11, 2010 7:55 pm

J'utilise les drivers du kernel, présents dans la partie "staging drivers". Pas vous ?
Tout marche impec avec portage "pur", avec les dernières versions "testing" de Portage.

guilc · Post by **guilc** » Sat Sep 11, 2010 8:52 pm

XavierMiller wrote:J'utilise les drivers du kernel, présents dans la partie "staging drivers". Pas vous ?

Ouaip, ici aussi, mais ça ça concerne que la 2D, pas la 3D

Tout marche impec avec portage "pur", avec les dernières versions "testing" de Portage.

Heu, la 3D marche, avec mesa 7.8.2 ?
Ici (NV86) la 3D ne marche pas avec cette version (crash de X), il faut passer sur mesa 7.9, et sur gallium/llvm pour améliorer les perfs. Donc overlay X11

Fenril · Post by **Fenril** » Sun Sep 12, 2010 9:15 am

C'était effectivement ça, avec les derniers nouveau, pas besoin du FB_VIRTUAL dans mon cas, et un passage sur gtkperf montre que j'ai maintenant des performances 2D supérieures aux drivers propriétaires, héhé. Merci guilc.
Dernières infos, avec mesa 7.9/gallium et llvm, je fais tourner ut2004 avec tous les effets graphiques, c'est juste plus lent (mais jouable). Je dis ça surtout pour ceux qui ne veulent pas franchir le pas à cause de la 3D, si comme moi vous en avez besoin occasionnellement et vous jouez peu, aucun problème. Moi c'est décidé, j'abandonne les drivers nvidia (sauf si problèmes de bug avec les prochains drivers nouveau).

razer · Post by **razer** » Sun Sep 12, 2010 2:01 pm

Nouveau problème dont je viens de me rendre compte : openoffice devient d'une lenteur désespérante dès qu'on insère des images.
Testé avec openoffice-bin, et une compil mano. J'ignore vraiment la raison, étant donné que c'est le seul programme qui pose problème...

guilc · Post by **guilc** » Fri Oct 22, 2010 9:27 pm

razer wrote:Je n'ai pas de problèmes de lenteur, mais de tearing (synchronisation verticale)

Je sais pas si tu as vu : http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/
Les derniers commits devraient t'intéresser. En particulier http://cgit.freedesktop.org/nouveau/xf8 ... 8e8f757a92
le sync to vblank, qui devrait régler tes soucis de tearing

Poussin · Post by **Poussin** » Tue Nov 23, 2010 12:45 pm

Salut,

Je me décide enfin à essayer.

Juste une petite question (parce que pour l'instant j'ai du faire une connerie ^^), je ne suis pas en ~arch et donc toujours en xorg-server 1.7, c'est censé fonctionner?

merci :$

Poussin · Post by **Poussin** » Tue Nov 23, 2010 1:36 pm

Je me réponds, ça marche

En fait j'avais laissé nvidia dans la config opengl (vous savez, avec eselect ^^) Shame on me...

Je suis vrai ravi de ce changement! Fini monpetit problème avec mplayer et compiz. De plus, la prise de controle à distance de gnome fonctionne maintenant meme si le serveur a activé compiz (chose qui foirait totalement avant)

Aucun idée des réelles performances de la choses pour de la 3D, et je pense bien que je m'en balance quand je vois le reste :]

Ravi ravi ravi

netfab · Post by **netfab** » Sun Jan 23, 2011 9:19 am

Je déterre ce sujet. Je voudrais tester nouveau, mais ayant tout de même besoin régulièrement de la 3D, je me demande si il est possible de préconfigurer le système de façon à ce qu'un simple reboot puisse permettre de passer des drivers nouveau à nvidia et inversement ? Je pense au blacklistage du module nvidia, au choix de la configuration xorg, etc... tout ceci doit se faire en root.

Fenril · Post by **Fenril** » Sun Jan 23, 2011 9:33 am

J'y ai pensé aussi. Une idée comme ça : en ayant deux noyaux et/ou en gérant par script de démarrage 2 versions du modules.conf ?

netfab · Post by **netfab** » Sun Jan 23, 2011 10:07 am

Oui, 2 noyaux c'est ce que je comptais faire. Je crois que je vais gérer çà en créant d'autres runlevels, le choix se fera donc avec un paramètre passé au noyau sélectionné. Je pense que çà sera la façon la plus propre d'y arriver.

guilc · Post by **guilc** » Sun Jan 23, 2011 10:12 am

why not.
Le seul truc à changer en plus du kernel c'est le fichier de conf de X. pas besoin de toucher aux modules : il suffit de ne PAS placer le module nvidia dedans : il se charge totu seul automatiquement au lancement de X si X est configuré pour utiliser le driver nvidia (enfin, c'était comme ça à l'époque ou j'utilisais encore le driver propriétaire, ce qui remonte à quelques mois maintenant (début du fil))

Fenril · Post by **Fenril** » Sun Jan 23, 2011 11:38 am

Et en installant le paquet xf86-video-nouveau à la place de son activation en dur dans le kernel, ça ne faciliterait-il pas les choses ?
guilc > en conservant le module nvidia au début j'étais obligé de le blacklister sinon X ne voulait pas démarrer avec nouveau.

guilc · Post by **guilc** » Sun Jan 23, 2011 12:25 pm

Fenril wrote:Et en installant le paquet xf86-video-nouveau à la place de son activation en dur dans le kernel, ça ne faciliterait-il pas les choses ?

Ca n'a rien à voir : xf86-video-nouveau est le driver X. Ce driver a besoin de configuration dans *dans* le kernel (KMS, DRM). Et ce sont ces options là qui ne sont pas compatible avec le driver propriétaire.
D'où le besoin de 2 noyaux avec des configurations différentes

netfab · Post by **netfab** » Wed Jan 26, 2011 12:44 am

Bon, çà fonctionne, enfin tout du moins avec openrc et baselayout2, pas testé avec l'ancien système d'init.

Le script d'initialisation et la méthode [topic=861821]ont évolué[/topic]. Je laisse ce post uniquement pour référence.

Je blackliste le module nvidia, je le charge manuellement si besoin par la suite.

$ grep nvidia /etc/modprobe.d/blacklist.conf
blacklist nvidia

J'ai donc compilé 2 noyaux différents, un avec le framebuffer et l'autre avec KMS et nouveau.

Code: Select all

$ ls -l /boot/ | grep kernel
-rw-r--r-- 1 root root 3312320 18 déc.  17:59 kernel-2.6.36-gentoo-r5-FB_NVIDIA
-rw-r--r-- 1 root root 3551968 23 janv. 14:09 kernel-2.6.36-gentoo-r5-KMS_NOUVEAU

Pour xorg je créé 2 fichiers de configuration indépendants. Je vais utiliser par la suite le répertoire xorg.conf.d :

Code: Select all

$ ls -l /etc/X11 | grep xorg
-rw-r--r-- 1 root root  235 23 janv. 14:53 xorg-nouveau.conf
-rw-r--r-- 1 root root  322 25 janv. 18:51 xorg-nvidia.conf
drwxr-xr-x 2 root root 4096 25 janv. 23:52 xorg.conf.d

Dans le fichier xorg-nvidia.conf, en plus de ma configuration habituelle pour le driver propriétaire, j'ai ceci, afin d'éviter le chargement automatique du driver nouveau :

Code: Select all

Section "Module"
        Disable     "nouveau"
EndSection

Le script d'initialisation qui va permettre d'effectuer les modifications necessaires à chaque boot ...

Code: Select all

#!/sbin/runscript
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

depend() {
	need localmount
	before xdm
}

start() {
	local DRV=${RC_SVCNAME}
	local impl= modules=

	case "${DRV}" in
		nvidia)
			impl="nvidia"
			modules="nvidia"
		;;
		nouveau)
			impl="xorg-x11"
		;;
		*)
			eerror "wrong video card driver provided on kernel command line"
		;;
	esac

	dosym /etc/X11/xorg-${DRV}.conf /etc/X11/xorg.conf.d/videocard.conf || return 1

	for x in $modules; do
		ebegin "Loading module $x"
		eval modprobe -q "$x"
		eend $? "Failed to load $x" || return 1
	done

	ebegin "Switching to ${impl} OpenGL implementation"
	eval eselect opengl set "${impl}" >/dev/null 2>&1
	eend $? "Failed to switch to the correct OpenGL interface" || return 1

	einfo "Setted up environment for $DRV X driver"
	return 0
}

dosym() {
	ebegin "Symlinking $1"
	if [ ! -f "$1" ]; then
		eend 1 "Missing file $1" || return 1
	else
		eval ln -snf "$1" "$2"
		eend $? "Failed to symlink $1" || return 1
	fi
}

... que je sauvegarde sous le nom nvidia-nouveau-switch dans /etc/init.d, et je créé 2 liens symboliques vers ce fichier.

Code: Select all

$ ls -l /etc/init.d/ | grep nvidia
lrwxrwxrwx 1 root root    21 23 janv. 17:15 nouveau -> nvidia-nouveau-switch
lrwxrwxrwx 1 root root    21 23 janv. 17:15 nvidia -> nvidia-nouveau-switch
-rwxr-xr-x 1 root root  1030 25 janv. 23:18 nvidia-nouveau-switch

Comme expliqué dans le handbook, je créé donc 2 runlevels supplémentaires, qui contiennent exactement les même services que le runlevel default.
J'ajoute le service nvidia au runlevel nvidia, et le service nouveau au runlevel nouveau.

Code: Select all

# rc-update show default nvidia nouveau
           vixie-cron | nvidia nouveau default
               nvidia | nvidia                
            syslog-ng | nvidia nouveau default
                  nfs | nvidia nouveau default
                 dbus | nvidia nouveau default
       udev-postmount | nvidia nouveau default
                local | nvidia nouveau default
                acpid | nvidia nouveau default
           consolekit | nvidia nouveau default
             net.eth0 | nvidia nouveau default
              nouveau |        nouveau        
                  xdm | nvidia nouveau default

Dans ma configuration de grub je n'oublie pas d'ajouter les options softlevel correspondantes aux noyaux :

$ grep -B 3 softlevel /boot/grub/grub.conf

title Gentoo Linux 2.6.36-r5 - Framebuffer et Nvidia
root (hd0,0)
kernel /boot/kernel-2.6.36-gentoo-r5-FB_NVIDIA root=/dev/sda1 video=vesafb:mtrr:3,ywrap vga=792 softlevel=nvidia

title Gentoo Linux 2.6.36-r5 - KMS et Nouveau
root (hd0,0)
kernel /boot/kernel-2.6.36-gentoo-r5-KMS_NOUVEAU root=/dev/sda1 softlevel=nouveau

Le boot avec le driver nvidia propriétaire :

Code: Select all

 * Symlinking /etc/X11/xorg-nvidia.conf ...                 [ ok ]
 * Loading module nvidia ...                                [ ok ]
 * Switching to nvidia OpenGL implementation ...            [ ok ]
 * Setted up environment for nvidia X driver
 * Setting up gdm ...                                       [ ok ]


$ ls -l /etc/X11/xorg.conf.d/ | grep videocard
lrwxrwxrwx 1 root root  25 26 janv. 00:35 videocard.conf -> /etc/X11/xorg-nvidia.conf

$ eselect opengl list
Available OpenGL implementations:
  [1]   nvidia *
  [2]   xorg-x11

Le boot avec le driver nouveau :

Code: Select all

 * Symlinking /etc/X11/xorg-nouveau.conf ...                [ ok ]
 * Switching to xorg-x11 OpenGL implementation ...          [ ok ]
 * Setted up environment for nouveau X driver
 * Setting up gdm ...                                       [ ok ]


$ ls -l /etc/X11/xorg.conf.d/ | grep videocard
lrwxrwxrwx 1 root root  26 25 janv. 23:52 videocard.conf -> /etc/X11/xorg-nouveau.conf

$ eselect opengl list
Available OpenGL implementations:
  [1]   nvidia
  [2]   xorg-x11 *