| Accueil | ?TiNDC 2006 | ?TiNDC 2007 | ?Archives anciennes | ?Archives récentes | DE/EN/ES/FR/RU/?Team |
Le compagnon irrégulier du développement de Nouveau (TiNDC)
Édition du 29 juin 2007
[!] La traduction est terminée, mais une relecture ne serait pas de refus
Introduction
Ceci est le numéro 22 du compagnon irrégulier du développement de Nouveau façonné avec attention. Il contient toute la sagesse du projet Nouveau (progressions et malheurs inclus) et - probablement comme d'habitude - je vais obtenir les requêtes de correction de Darktama avant même que je n'annonce sa publication (allez admettez-le, vous avez un script qui tourne pour vérifier la sortie de nouvelles versions :) ).
Il est bon d'être prudent. Il y a une raison pour laquelle nous appelons ça le compagnon /irrégulier/ du développement de Nouveau. Puisque ces semaines n'ont pas vu beaucoup d'activité, cette édition a été retardée.
Marcheu était porté disparu au combat (il a prétendu quelque chose à propos de <
Statut actuel
Malgré cela, nous avons réussi à finir quelques travaux.
Rules-ng et l'outil ?MmioTrace semblent être un bon outil pour faire du reverse engineering. Peu de temps après que notre précédente édition ne soit en ligne, Philip Ezolt, du projet du driver radeon, est venu sur le canal et a proposé des améliorations pour le sous-projet rules-ng. Il a demandé si nous nous opposions à ajouter des données spécifiques aux radeon au fichier XML de rules-ng. Le but étant que MMio-parse donne aussi un résultat utile pour les dumps des radeon. Nous avons bien sûr accepté et il est actuellement occupé à travailler sur ces ajouts. (http://nouveau.cvs.sourceforge.net/nouveau/rules-ng/databases/).
D'ailleurs il semble que ça soit le bon moment pour finalement parler du blog TiRDC de la communauté radeon (http://tirdc.livejournal.com/). Après 3 éditions comme les nôtres, ils ont changé vers un mode de publication de type blog. Ils prétendent que cela leur donne de l'inspiration pour leur compagnon. Nous en sommes honorés, mais pour l'instant il n'y a pas d'innovation de notre part non plus. De notre côté nous nous sommes inspirés des Wine Weekly News et des résumés du noyau de LNW.net.
Il semble que notre idée de bulletin d'information irrégulier prenne si bien (en plus de celui du projet radeon dont nous avons parlé, nous en avons vu au moins un pour l'outil Dtrace et pour les éditions XML).
Lorsque pq a commencé à comparer les noms réels des registres et les valeurs des constantes dans le code source qui allaient être générés à l'aide de rules-ng et de ses outils, il est venu avec quelques problèmes. Après avoir discuté de ces problèmes avec Marcheu il est devenu clair que nous voulions un changement de noms uniquement si aucune autre option n'existait. Par exemple, pour éviter des problèmes de référence, si un bout de code appelle un registre FOO alors qu'un autre l'appelle FOOBAR. Ce problème apparaît notamment lorsque l'on parcourt les sources du driver NVidia Haiku. C'est tout simplement déconcertant.
pq a donc changé quelques restrictions de son schéma de nommage et la vie fut belle à nouveau.
Jwstolk a comme qui pris une autre voie concernant son projet de trouveur de macros. Comme il s'est aperçu que nous avions différents types de dumps MMio (32 et 64 bits, anciens sans les timestamps/markers et une nouvelle version avec en plus des traces qui pouvaient soit être brutes soit du texte (lorsque passé à travers mmio-parse)), il a commencé à travailler sur la conversion entre les différentes versions. Vous pouvez trouver son travail actuel à cette adresse (). Ses propres mots : MMio-convert effectue l'opposé de mmio-parse tout en effectuant la conversion entre les traces binaires 32 et 64 bits et le nouveau format binaire (toujours en attente). (et un format texte simple)
Pmdata est en train de faire faire une cure de jouvence à Renouveau. Il souhaite être débarrassé de cette énorme structure interne nv_object[] et charger ces information depuis une base de données XML à la place. De plus, l'outil sera probablement divisé en une partie sortie brute et une partie parser. Cela nous permettra d'envoyer des dumps plus petit et de les reparser lorsque nous trouverons de nouvelles fonctionnalités. (Actuellement nous aurions besoin de demander aux utilisateurs d'effectuer une fois de plus le dump).
Darktama est revenu dans le jeu en ajoutant des corrections trainant sur la mailing list pour l'initialisation des cartes NV49 et NV4b. Ces patchs ont été proposés par jb17some et stephan_2303 et ont été appliqués par Darktama. Évidemment nous avons également ajouté d'autres corrections dans la foulée.
De plus, nous avons ajouté toutes les modifications de son arborescence à l'arborescence principale. Puisque les changements suivants casseront l'API, Darktama demande des tests. Vérifiez sur votre matériel et dites-lui si cela marche ou pas (n'oubliez pas de mentionner votre matériel et quelques informations supplémentaires). Pour l'instant, les NV4x marchent, Pmdata a récupéré ses freezes (mais seulement lorsqu'il essaye de lancer glxgears une seconde fois). Il a aussi confirmé que les NV1x ne marchent plus.
Comme mentionné auparavant, la prochaine étape inclue de casser l'API entre le DRM et le DDX une fois de plus. Il serait donc bon de s'assurer que les dernière mises à jour n'introduisent pas de nouveaux bugs.
Aucune progression du côté des G8x puisque Darktama nettoyait sa pile de patchs des parties génériques du driver. KoalaBR a contacté Matthew Garrett (qui a écrit libx86 / emux86) par rapport à vbetool et il lui a été demandé de compiler un nouveau serveur Xorg avec cette bibliothèque activée (Xorg a sa propre version inclue), même si une version de Xorg sur x86 n'en a normalement pas besoin. Cela pour comparer le comportement de Xorg avec celui que nous observons. Toute fois, le problème "l'affichage va se mettre en mode veille" est identique sur le G84 de Darktama, quel que soit l'outil utilisé. KoalaBR n'a pas encore rassemblé assez de courage pour s'attaquer à cette tâche.
ahuillet est actuellement en train de mettre en place son projet Xv. La première chose qu'il fit fut d'écrire un sommaire des choses qu'il envisage de faire dans le cadre de son projet (voir http://nouveau.freedesktop.org/wiki/ArthurHuillet). Il l'a ajouté en bas de la page, en dessous des documentations existantes.
Après avoir reçu l'approbation de Darktama, il a configuré son dépôt git sur fd.o, mais a eu quelques problèmes à comprendre les concepts de git. Notamment la configuration en utilisant notre dépôt principal DDX comme source tout en envoyant ses modifications depuis sa copie locale a mené à quelques confusions.
Après les avoir résolues, il a commencé avec un simple patch qui modifiait la structure de ?XvPutImage pour que les transferts DMA puissent plus tard être facilement ajoutés. L'étape suivante a été d'écrire un patch pour l'AGP afin de supporter les copies DMA depuis l'aperture vers la ram vidéo.
Le DMA peut être fait facilement avec l'AGP car l'AGP a été conçu exactement pour cela : il fournit un GART (une table de relocation) qui permet à la carte d'accéder à une grande quantité de mémoire système, qui apparaît contigue à la carte. Cette fonctionnalité permet de faire du DMA relativement simplement : d'abord vous copiez les données dans l'aperture, et alors effectuez le DMA depuis ces données en faisant pointer la carte dessus et en lui donnant la taille des données à copier. Le PCI-e devrait être similaire mais demande un peu plus de tests. Pmdata et cmn se sont portés volontaires pour tester le patch, les résultats de cmn sur un processeur AMD à 350MHz indiquent que la FIFO timeout après environ 1 minute. Cependant, le driver nv et le driver Nouveau standard ont le même problème chez lui.
En détaillent son patch à marcheu, une discussion à propos des objets mémoire et de la copie DMA s'est ensuivie, de dont j'ai pu comprendre que :
- les cartes NVidia offrent une objet mémoire PCI et un objet mémoire AGP. Elles ont aussi leur propres mémoire (frame buffer). L'objet PCI et l'objet AGP diffèrent en un point principal : l'objet PCI pointe vers une liste de pages mémoire allouées alors que l'AGP pointe vers une adresse et a une taille. Les deux sont des objets requis pour les transferts DMA, mais continuez la lecture.
- Le DRM alloue la mémoire AGP, PCI (pas encore, voyez dessous) ou FB et retourne une adresse physique
- La carte attends un offset à l'intérieur de votre objet mémoire actuel, où chacun de ces objets fait référence à un bout de la mémoire, soit AGP, PCI ou FB. Dans notre configuration, nous avons un objet AGP (appelé NvDmaAGP) et un objet FB (appelé NvDmaFB). Les deux couvrent la totalité de la mémoire disponible pour eux (la mémoire sur la carte pour FB et la mémoire de l'aperture pour AGP).
- Maintenant, si vous voulez démarrer une copie de mémoire à mémoire, vous prenez l'objet NVidia Mémoire à Mémoire et vous y mettez les deux objets en tant que source et destination. Voilà pour la théorie, mais malheureusement nous ne pouvons créer des objets mémoire PCI pour l'instant. D'un autre côté, rivatv a déjà fait exactement ça. Donc nous devons juste regarder comment ils l'ont fait et le réécrire afin que cela marche à l'intérieur de notre driver.
Marcheu a résolu le double appel à la matrice de projection mais a affirmé qu'il avait encore des problème avec swtcl ("software transform, clipping and lightning" pour "transformation, coupure et éclairage logiciel"). À cause de contraintes de la vie réelle, il s'est restreint lui-même à la réponse aux questions.
Le problème de viewport mentionné dans l'édition précédente est toujours d'actualité.
Finalement, kmeyer a eu son compte fd.o et a créé un nouveau dossier pour les dumps. Lui et JussiP sont maintenant en train de configurer la page de statuts (http://users.tkk.fi/~jpakkane/ren/) une nouvelle fois.
Aide requise
Récupérez les DRM et DDX actuels et donnez-nous des nouvelles, que ça soit un succès ou un échec. Nous devons savoir si tout marche comme avant puisque la prochaine étape va casser l'API interne, ce qui va rendre encore plus difficile de suivre les bugs introduits.
Si vous voulez aussi, testez les patchs de ahuillet (git://people.freedesktop.org/~ahuillet/xf86-video-nouveau) et dites-lui les résultats. Cependant, soyez préparé à des problèmes, dysfonctionnements et crashs puisque c'est vraiment un travail en cours!