Le compagnon irrégulier du développement de Nouveau (TiNDC)
Édition du 30 janvier 2008
1. Introduction
Et voilà, pour votre plus grand plaisir, l'édition 34. Merci beaucoup de l'intérêt sans faille que vous portez à notre pilote et au TiNDC.
Pour vous donnez un exemple de l'importance pour nous de vos tests : durant les 15 derniers jours, rindolf et AndrewR ont tous les deux constatés des régressions. Rindolf obtenait des saccades après de longues périodes d'utilisation de X tandis que AndrewR obtenait un kernel panic. Les deux problèmes avaient été introduits dans la semaine précédente rendant beaucoup plus simple l'identification du patch coupable.
Ainsi, même s'il n'y a pas de corrections ou de nouvelles fonction pour votre carte, il est important d'effectuer des tests au moins une fois par semaine pour être sur que tout continue à fonctionner.
Durant les dernières semaines, une discussion s'est tenu pour savoir si nous devions aller vers une première version officielle uniquement 2D rapidement. Des arguments en faveur ou contre ont été échangés et la décision finalement reportée :).
Arguments Pour :
- Les distributions pourraient commencer à proposer Nouveau avec moins de difficultés
- Cela nous amènerait plus de testeurs et d'utilisateurs
- Cela montrerait que nous progressons à un bon rythme et que nous sommes un succès (du point de vue des utilisateurs)
- Il vaudrait mieux une sortie avant d'avoir une 3D fonctionnelle. Celle-ci va nous amener une énorme quantité d'utilisateurs et de testeurs qui pourraient bien nous dépasser
- sortir tôt, sortir vite
Arguments Contre :
- Le support des NV5x n'est pas très bon
- Nous ne voulons pas avoir à suivre une interface DRM stable pour le moment (ce qui serait obligatoire pour l'intégration dans une distribution) et au moins 2 changements sont à venir (pour le TTM et pour le modesetting noyau)
- RandR1.2 n'est pas encore assez bon
- Nous n'avons pas besoin de beaucoup de nouveaux testeurs/utilisateurs, nous avons surtout besoins de testeurs qui sont interessés par la résolution de problèmes spécifiques, comme ceux que nous avons.
Les deux côtés ayant des arguments valides, aucune décision finale n'a été prise. Nous allons attendre encore quelques semaines de plus et en discuter au FOSDEM le mois prochain.
Et pour vos tablettes : Non, nous n'avons pas été approchés par Nvidia pour des spécifications (et honnêtement, nous n'espérons pas qu'il nous contacterons).
2. État actuel
Il semble que MMioTrace va rester inutilisable avec un noyau 2.6.24, le kernel hacker responsable ne voulant pas réinsérer les points d'entrées nécessaires. La bonne nouvelle est que pq a commencé à travailler sur l'intégration de MMioTrace directement dans le noyau, aidé en cela par le susdit kernel hacker pour trouver comment remplacer les fonctions supprimées. Il y a un consensus sur l'intérêt d'un outil comme MMioTrace dans le noyau.
Si tout va bien, MMioTrace devrait être inclus dans à partir du noyau 2.6.25 ou 2.6.26.
Stillunknown a développé un système expérimental de restauration des modes (NDT : pour le passage console/X) qui peut être activé avec l'option NewRestore placé à la valeur True. AndrewR n'a pas hésité une seconde avant de tester et de rapporter le résultat à stillunknown. Résultat mitigé, pour certains ça marche, pour d'autres ça ne marche pas. Stillunknown a par la suite corrigé deux problèmes sur cette partie.
fr/eld_ko.png "eld_ko.png")
- Artéfacts avec l'adaptateur de textures
Toujours pas fatigué d'ajouter des fonctions à Nouveau, Stillunknown a également fait quelques tests avec l'adaptateur de textures et remarqué des artefacts ainsi que des trainées floues sur certaines cartes. Après en avoir discuté avec Marcheu, Ahuillet et avoir réalisé quelques tests, il découvrit que le blob réalisait le rendu des gros quadrilatère 2D (supérieurs à 512x512 pixels) en créant un triangle de taille suffisante pour contenir le quadrilatère et en découpant le tout par la suite à la taille désirée. Ceci a pour effet de réaliser un rendu de haut en bas qui supprime le flou (au contraire du pavage par 2 triangles, méthode utilisé par la carte lorsqu'on demande directement un quadrilatère). Il a implémenté ça pour l'adaptateur de textures des NV40 et ainsi corrigé le rendu (http://gitweb.freedesktop.org/?p=nouveau/xf86-video-nouveau.git;a=commit;h=d9149bddc758cc0644630b26fe10fc563ba38ce9).
fr/eld_ok.png "eld_ok.png")
Rendu corrigé
Réfléchissant au problème, il eut l'idée d'appliquer le même raisonnement à EXA sur NV40. Ce qui fonctionne très bien et devrait éliminer le même problème bien que je n'ai jamais vu quelqu'un s'en plaindre(http://gitweb.freedesktop.org/?p=nouveau/xf86-video-nouveau.git;a=commit;h=71435dde5b2fd1c197ef5dc31b22ba40abcbca7e).
Après la pause des vacances, quelques uns de nos testeurs sont revenus et ont mis à jour leur statut : tout fonctionne parfaitement chez chownmeined, normal et RandR1.2 ; une régression chez seventhguardian : l'écran reste noir au démarrage de X. Bug trouvé et corrigé par Stillunknown. Darktama a toujours des problèmes avec son portable et Nouveau : l'écran reste noir. Quelques corrections de malc0 permettent au moins d'avoir le rétro-éclairage, mais l'écran reste noir tout de même. Une session de débogage a été réalisé et a donné des informations à malc0 mais la solution est toujours à venir.
Malc0 a également amélioré la lecture du BIOS des cartes NV4x, ceux-ci pouvant utiliser des opcodes non encore gérés par notre parseur.
Après discussion avec Thunderbird malc0 et stillunknown, SeventhGuardian a travaillé sur la détection de la sortie TV. Ses premiers essais donnaient des détections aléatoires mais la persévérance a payée et lui a permis de découvrir quels registres sont nécessaires ainsi que les informations données par la carte. Nous avons donc maintenant une détection de branchement, c'est à dire, une connexion via une prise VGA, TV-OUT, DVI, etc. Ses connaissances sont résumées sur le wiki : http://nouveau.freedesktop.org/wiki/Load_Detection .
SeventhGuardian devrait maintenant se concentrer sur le TV-OUT proprement dit.
Et maintenant, un petit assortiment de différents sujets :
- Marcheu a implémenté un filtrage bicubique sur l'adaptateur de texture des NV40, éliminant les artéfacts connus. Le code n'est pas encore inclus mais devrait l'être incessament.
- Ce code sera également porté sur les NV30. Cette expérience est nécessaire pour finir le framework Gallium3D des anciennes cartes. Le travail pour la 3D de celles-ci pourra alors commencer.
- Après quelques jours de hacking, pq a réussi à faire fonctionner MMioTrace sur le noyau 2.6.21-rc7. C'est en bonne voie pour une soumission pour inclusion sur la LKML. Il y a tout de même encore du travail à faire dessus, les retours de la LKML devront notamment être pris en compte. etc.
Darktama a adopté une nouvelle stratégie sur IRC : rester silencieux, immobile. Et si quelqu'un a un problème avec le pilote, lacher juste une phrase qui permet de le résoudre (même s'il ne concerne par les NV5x ou NV4x) avant de retomber dans le silence (c'est arrivé au moins 2 fois
). - Darktama a relevé quelques problèmes sur les NV4x et la façon dont nous gérons les contextes. Il a quelques pistes pour corriger ça mais il a besoin de plus de traces MMio.
- Le problème avec la configuration du viewport sur les NV30 a été résolu par pmdata mais sa solution casse les autres NV3x. Il semble que Stillunknown a trouvé et corrigé le problème :
Nous avons reçu des plaintes comme quoi le dithering (NDT : http://webstyleguide.com/graphics/dither.html ) était mauvais sur les écrans plats (hughsir, egn, tango_). D'après, malc0, Nouveau utilise les même valeurs pour les registres de dithering que nv, qui sont différentes de celles du blob. Il suspectait que nv utilisait des valeurs par défaut (mais sures) alors que le blob utilisaient des valeurs plus spécifiques à chaque carte. Des tests réalisés sur le blob par hughsie et tango_ à l'aide de radeontool (branche nvidia) ont permis de confirmer cette hypothèse. alors que ça fonctionnait pour hughsie, ça ne fonctionnait pas pour Tango_.
Radeontool est encore un autre outil qui permet de lire certains registres MMio. Originellement développé pour les radeon, il a également un branche pour les cartes Nvidia.
Nous avons reçu des rapports comme quoi les NV1x étaient extrêmement lent sur le rendu 2D. Cela semble être une régression et nous cherchons actuellement ce qui les cause.
Finalement, quelques petites informations sur le statut du code Gallium. Comme indiqué précédemment, darktama y travaille pour les NV4x. Cela fonctionne plus ou moins mais il y a encore du code un peu baclé qui l'empêche de fonctionner correctement dans toutes les situations. Corriger tout ça devrait prendre du temps. La bonne nouvelle, c'est que Nouveau3D est beaucoup plus rapide que la version logiciel (softpipe).
3. Aide requise
Comme toujours:
- Jetez un oeil à la page TestersWanted
- Vérifiez qu'il n'y a pas de régression dans le code RandR1.2
En plus :
- envoyez nous des traces MMio pour les cartes NV4x (!Geforce 6x00 et 7x00) et si vous le faites, lancez une application 3D, au moins glxgears, durant la trace (et dites nous ce que vous avez fait dans votre courriel).
- Nous cherchons des testeurs pour RandR1.2, particulièrement sur NV04 (TNT). Testez et informez malc0 du résultat.
Le code RandR1.2 changeant souvent, il faut tester souvent. Les régressions, si vous en trouvez, sont à reporter à malc0 ou stillunknown.