Commit 8cf2cd22 authored by 86.215.219.80's avatar 86.215.219.80

No commit message

No commit message
parent 12dc39f3
......@@ -22,7 +22,7 @@ Si vous préférez les versions traduites (français et espagnol), jetez un oeil
La majorité du travail se fait actuellement sur la partie 2D, en grande partie pour faire fonctionner Xv. Ahuillet et p0g ont réalisé des traces des registres MMIO pour YV12 et YUY2 et les ont comparées entre elles. Les résultats leur ont permis de déterminer quels registres étaient utilisés pour l'overlay (''NDT : écriture directe de l'image dans la mémoire vidéo, le travail de redimensionnement et autres étant fait par la carte et non par le CPU''). Le 10 août 2007, Ils annoncèrent avoir réussi et commencèrent à chercher des testeurs.
À peu près au même moment, dagb a créé un [:http://nouveau.freedesktop.org/wiki/FeatureMatrix: tableau des fonctions] qui marchent (ou non) et celles sur lesquels nous travaillons (ou non).
À peu près au même moment, dagb a créé un [:FeatureMatrix: tableau des fonctions] qui marchent (ou non) et celles sur lesquels nous travaillons (ou non).
Finalement, nous avons plusieurs types d'overlays :
* celui des NV04/NV05 fait seulement du YUY2
......@@ -37,7 +37,7 @@ L'overlay des NV04 ne fonctionne pas pour le moment car ahuillet ne possède pas
Mjules a testé le tout sur NV3x et il fonctionne, pq a testé sur NV28 sans problème également. Mais dcha notifia des corruptions d'images sur NV11 (!Geforce 2 Go) qui furent investiguées par ahuillet et p0g. L'explication est que les cartes < NV17 n'ont pas d'overlay YV12 et gèrent seulement le YUY2. L'overlay YV12 fut donc désactivé pour ces cartes. Quand au cartes >NV4x, elles n'ont pas d'overlay du tout et utilisent le blitter (''NDT : circuit sur la carte dédié à la combinaison de différents masque l'un au dessus de l'autre'') pour cette fonction. Ahuillet accéléra cette fonction également.
ALors qu'ils testaient le pilote, matc et p0g obtinrent tous les 2 l'erreur INVALID\_STATE émise par la carte. Ahuillet et p0g essayèrent d'isoler le bug et découvrirent rapidement qu'il était dans le code EXA. Et il devait être là depuis l'origine des temps (enfin, au moins depuis le début de ce projet) puisqu'il existait déjà dans la version 0.0.4 du DRM, obligeant à une autre approche pour le régler. Après quelques test, ahuillet et p0g remarquèrent que le problème apparaissait quand on essayait la fonction blend. Chaque fonction d'EXA utilisant ce type de traitement faisait apparaitre l'erreur. Xv était seulement une victime et crashait simplement parce qu'une erreur dans EXA se produsait juste avant.
ALors qu'ils testaient le pilote, matc et p0g obtinrent tous les 2 l'erreur INVALID_STATE émise par la carte. Ahuillet et p0g essayèrent d'isoler le bug et découvrirent rapidement qu'il était dans le code EXA. Et il devait être là depuis l'origine des temps (enfin, au moins depuis le début de ce projet) puisqu'il existait déjà dans la version 0.0.4 du DRM, obligeant à une autre approche pour le régler. Après quelques test, ahuillet et p0g remarquèrent que le problème apparaissait quand on essayait la fonction blend. Chaque fonction d'EXA utilisant ce type de traitement faisait apparaitre l'erreur. Xv était seulement une victime et crashait simplement parce qu'une erreur dans EXA se produsait juste avant.
Avec le Vacation of Code arrivant à son terme, nous aimerions remercier Ahuillet pour son travail qui a permis d'obtenir une implémentation efficace et fonctionnelle de Xv pour les cartes NV18 à NV4x. Nous sommes heureux que tu aies choisi Nouveau (et encore plus que tu restes avec nous).
......@@ -52,7 +52,7 @@ cmn s'est penché sur les NV35 et glxgears. Le dernier statut remontait au Fosde
Il y a tout de même un problème avec les NV3x : l'initialisation 3D de la carte n'est pas faite correctement. Et donc, démarrer X avec Nouveau ne vous mènera pas très loin. Il faudra charger le blob en premier, il initialisera correctement la carte, ce que nous ne faisons pas encore, puis décharger le blob avant de lancer X avec nouveau, qui fonctionnera. Cela signifie une chose ; notre code pour basculer entre les contextes est correct mais le code d'initialisation manque des quelques morceaux importants. Marcheu travaille dessus et cherche ce que ces morceaux peuvent bien être. Malheureusement, pour trouver les bonnes valeurs, il doit éplucher 90 Mo de dump MMIO. ça prend du temps (mais il est presque à la fin, il ne lui reste que 250 ko).
Quelques brèves :
* le générateur de nouveau\_drm. était cassé pour le mode par défaut (il créait des #defines inutilisables). corrigé par KoalaBR
* le générateur de nouveau_drm. était cassé pour le mode par défaut (il créait des #defines inutilisables). corrigé par KoalaBR
* Createdump.sh s'est vu ajouté des tests pour les entêtes SDL et la bibliothèque libXvMVNVIDIA.so pour que renouveau puisse compiler
* pmdata a implémenté des commandes clear fonctionnelles pour les cartes NV04 à NV1x. Maintenant, les parties de votre écran qui doivent réellement être nettoyées le sont. On manque encore de tests et de retours à ce sujet néanmoins.
* Un disque dur de Marcheu a crashé et il a perdu différents patch pour faire fonctionner les NV04 sur le DRM actuel, ils corrigeaient la bascuel entres contextes. Il pourra les réécrire (et le fera) mais c'est toujours une perte de temps ennuyeuse.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment