Le compagnon irrégulier du développement de Nouveau (TiNDC)

Édition du 13 février 2008

1. Introduction

A peu près 2 semaines ont encore passé, il est donc temps pour un nouveau TiNDC

Comme vous le savez sûrement déjà, nous utilisons le système de suivi de bogues de freedesktop.org. Si vous rencontrez des problèmes qui ne peuvent pas être résolu rapidement en passant sur notre canal IRC, il est important que vous reportiez ces bogues afin qu'ils ne soient pas oubliés.

Si vous faites, n'oubliez pas de :

• Suivre notre canal, les réponses peuvent arriver longtemps après votre question
• Garder un œil sur votre bogue dans le système de suivi, ainsi vous pourrez
  • réagir aux réponses des développeurs (qui peuvent demander plus d'information, des tests, des patchs etc)
• Tester régulièrement le pilote (au moins une fois par semaine) pour contrôler
  • que votre problème n'a pas été résolu entre temps.

Reporter un bogue et l'oublier ne nous aidera et ne vous aidera pas beaucoup. Nous avons besoin de vos feedbacks régulier !

Quand nous avons commencé à publier les TiNDC en premier sur Phoronix, notre intention était d'obtenir un peu plus de publicité : le Wiki était lu par ceux qui nous connaissaient déjà et leur nombre restait relativement constant. Phoronix avait déjà manifesté un certain intérêt pour notre projet, publiant des nouvelles des TiNDC et de certains commits.

Ainsi, d'une certaine façon, c'était (et c'est toujours), une excellente association : nous gagnons plus de publicité et Phoronix obtient des informations directement à la source. Et, nous l'espérons dans la foulée, vous êtes aussi informé.

Quelques semaines après le début de notre collaboration, Phoronix nous a demandé si ils pouvaient nous aider en nous donnant du matériel inutilisé. Ne voulant pas être impolis ou avoir l'air trop gourmands, nous avons décliné. Nous sommes déjà bien équipé avec un panel large de cartes NVidia, à l'exception des plus onéreuses.

Les échanges de courriels suivant nous ont montrés que Phoronix possédait du matériel prenant la poussière beaucoup plus performant que celui de nos développeurs. Nous avons fini par accepter qu'ils envoient du matériel à Marcheu (CPU, cartes mères, RAM) qui le redistribuera aux développeurs durant le FOSDEM ou leur enverra directement.

En somme, nous tenons à remercier chaleureusement Phoronix pour leur support !

À propos du FOSDEM, nous serons au moins trois (Ahuillet, Malc0 et Marcheu) à nous y rendre. KoalaBR tachera également de s'y rendre et de couvrir l'événement comme l'année dernière, mais ayant quelques soucis de santé actuellement, il ne pourra peut-être pas être là.

La citation de la semaine : {{{< fatal_> writing a graphics driver is hard. Writing a graphics driver for hardware you don't have any documentation for has been described as "impossible". The Nouveau project is about making the impossible possible. Don't expect it to happen overnight.}}}

{{{< fatal_> écrire un pilote graphique est difficile. Écrire un pilote graphique pour du matériel dont vous n'avez aucune documentation a été décrit comme « impossible ». Le projet Nouveau est en train de rendre l'impossible possible. N'espérez pas que ça arrive en une nuit.}}}

2. Statut actuel

Depuis quelques temps, nous avions des problèmes avec les cartes NV4x quand on voulait utiliser Nouveau juste après le blob. Ceux-ci ont été identifiés et réglés par stillunknown : ils étaient dus à un registre inconnu, utilisé par le blob et ignoré par Nouveau. Après avoir placer le registre à sa valeur par défaut 0x01, tout c'est mis à fonctionner. (Git: http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commit;h=733e07663e50087ca1e9af8e9b5def556521e3b5)

Marcheu a commité une série de patches pour l'adaptateur de textures Xv. Ils concernaient (cf édition précédente) :

• un filtrage bicubique pour les NV4x (NV3x ?)
• prévention des traînées
• ajout de l'adaptateur de textures via shaders sur les NV3x

Malheureusement, des tests montrèrent que ce nouveau filtrage donnait un flou général marqué par rapport au blitter (NDT : uniquement en résolution native, redimensionné, c'est net) . Marcheu suspecte des erreurs de précision dans son code et enquête sur le sujet. Là aussi, nous avons également un problème d'ordre des bits sur PPC. Les gens semblent tous être bleus, ce qui a conduit Marcheu à forcer l'adaptateur de texture à permuter les canaux U et V sur cette architecture. Enfin, les NV34 semblent être trop lente pour cet adaptateur, utilisez le blitter ou l'overlay à la place.

Après ça, Marcheu devrait travailler sur Gallium3D pour NV3x jusqu'à ce qu'il soit prêt à être laissé à d'autres mains.

Malc0 et Stillunknown se préparent à activer Randr1.2 par défaut. Dans ce but, ils ont créé un Meta-bug qui répertorie tous les bogues liés à Randr1.2 qui empêchent cette activation : https://bugs.freedesktop.org/show_bug.cgi?id=14405.

Il y a eu du mouvement du côté des PPC également. Dans un premier temps, moondrake a trouvé comment contourner les blocages hard. Il fallait synchroniser les FIFO plus souvent lors du téléchargement de grosses quantités de données vers la carte. Kelnos l'a testé et a confirmé qu'il éliminait aussi les blocages chez lui.

Néanmoins, ce patch se contente d'éviter le bogue réel, qui est une corruption de la mémoire. Laquelle est causée par un AGP writeback non-fonctionnel sur ces Powerbook. Benh et Marcheu joignirent leurs forces et des patches volèrent ça et là, sans pour autant parvenir à une solution. La dernière incarnation du patch de moondrake est disponible ici : https://bugs.freedesktop.org/show_bug.cgi?id=14284

En passant Marcheu a remarqué que le code du DDX pour l'AGP sur PPC était totalement délirant.

Durant tous ces tests, l'idée est apparue de comparer l'état de certains registres entre MacOS X et Linux. Kelnos s'est proposé de réduire sa partition linux pour installer OSX. Sbriglie est alors arrivé, ayant déjà OSX sur le même matériel, et a proposé de tester radeontool (de airlied) sur OSX (http://www.skynet.ie/~airlied/nouveau/AppleSamplePCI.tar.gz), sans toutefois réussir à le faire fonctionner.

Mais moondrake ne s'est pas découragé. Il a essayé pas mal de modes, désactivé le SBA (Side Band Addressing) pour finalement bloquer le chargement de uninorth-agp (pilote pour le northbridge utilisé par Apple). Ce qui soudainement a résolu le problème de corruption et blocage.

Malc0 a également réparé le problème des « NV34 qui ne fonctionnent qu'au deuxième essai » qu'il a aussi rencontré sur x86 : http://cgit.freedesktop.org/mesa/drm/commit/?id=a0781e762295ce3d5f6e839d437a0de505cefa3b

Et maintenant, notre assortiment habituel de brèves :

• jb17some travaille toujours sur l'accélération XvMC, le statut est à l'adresse : http://nouveau.freedesktop.org/wiki/XvMC

• Airlied a mené une présentation au LCA sur le statut des pilotes graphiques. La rumeur dit qu'il aurait fait une démonstration de notre pilote Gallium3D. Mais jetez plutôt un œil ici : http://linux.conf.au/programme/presentations (Look for kittens)

• pq travaille a inclure MmioTrace dans le noyau. Même si les hackers comme Ingo Molnar l'aident, la tâche se révèle plus difficile que prévu et pq vise le 2.6.26 maintenant.

• Darktama cherche pourquoi le rendu 3D ne fonctionne pas sur NV5x.
• Et il réfléchi à créer un « générateur de voodoo » qui permettrait de générer automatiquement le voodoo pour la permutation des contextes.

3. Besoin d'aide

Comme toujours:

• - Jetez un oeil à la page TestersWanted
  - Vérifiez qu'il n'y a pas de régression dans le code RandR1.2

Vérifiez que l'utilisation après le blob, qui a été réparé par Stillunknown fonctionne bien. Et si vous avez des blocages sur NV4x (ou mieux, NV40), contactez le.

Et oui, les testeurs sur PPC sont bienvenus (les développeurs aussi), de même que les patchs pour BSD, étant donné que personne ne s'est manifesté quand nous l'avons évoqué dans l'une de nos précédentes éditions.

<<Édition précédente