Patrice Mandin a écrit 194 commentaires

Test mon avatar aussi tiens

Les slides sont dispo:
http://icps.u-strasbg.fr/~marchesin/nvdri/nouveau_update.pdf
http://icps.u-strasbg.fr/~marchesin/nvdri/g3dllvm.pdf

J'ai fait un essai de nettoyage de l'audio (il manque 1/3 a peu près, qui est inaudible, que j'ai remplacé par du silence):
http://people.freedesktop.org/~pmandin/nouveau_fosdem2009.og(...) (13.4 Mo)

Ce n'est pas suffisant, il ya des zones entières à couper avec un signal à la rue, en tout, ca représente presque 1/3 du total. Faut d'abord remplacer celles-ci par du silence.

L'autre possibilité (je sais pas si c'est dispo dans audacity) serait de mixer les deux pistes en une seule, en faisant l'operation gauche-droite. Vu que le bruit est quasi le meme sur les deux pistes, et que la voix se trouve en majorité à gauche, ca supprimerait deja une grande partie du bruit.

Le mieux c'est encore de tester Nouveau, en utilisant directement les sources des dépots git (plutot que les versions packagées, qui peuvent etre assez anciennes), et rapporter les bugs.

Chez nouveau Stéphane c'est le despote qui dit on fait modesetting randr 1.2, EXA, puis 3D gallium et tout le monde travail dans le même sens.

Je pense surtout que pour Nouveau, chaque développeur bosse sur une partie différente des autres. C'est rare que l'on se marche sur les pieds. Si on regarde http://nouveau.freedesktop.org/wiki/FeatureMatrix et que l'on imagine chaque case du tableau comme une tâche à réaliser, on pourrait presque mettre un développeur de Nouveau par case.

Bon, évidemment, on n'a pas assez de développeurs pour remplir tout le tableau :). En ce qui me concerne, seule la 3D m'intéresse, je laisse les autres s'occuper du reste. Gallium3D est un gros morceau à digérer quand même (sans parler des shaders programs que je connais pas trop encore), mais sûrement plus simple au final que les drivers DRI actuels dans Mesa, qui ont beaucoup de code dupliqués entre eux.

Malheureusement pour Nouveau, à chaque fois qu'on arrivait à un point où l'on espérait avoir quelque chose de stable et testable pour jouer avec, il fallait se mettre à réécrire ce qu'on avait fait.

Pour le DRM, il y a eu l'arrivée du TTM, chargé de gérer la mémoire de la carte vidéo. Pour le DRI de Mesa, déjà qu'il fallait passer pas mal de temps à comprendre comment faire un driver, il se trouve que Gallium3D pointait son nez.

Donc on se retrouvait souvent coincé entre l'enclume et le marteau, coté développeurs, entre le code qu'on pouvait écrire avec les infos qu'on avait trouvé par reverse engineering, et les nouvelles API "beaucoup plus mieux qu'avant" sur lesquels baser le code à écrire. Ce qui a fortement ralenti le développement je pense, en tout cas pour moi.

Hé bien le son grésillait à mort lorsque ça bougeait beaucoup à l'écran.

C'est peut etre juste une question de priorité des périphériques sur le bus PCI. Evidemment, une carte video qui dessine des polygones texturés accapare beaucoup plus le bus qu'une carte audio.

Il se trouve que justement on peut régler cette priorité avec la commande 'setpci', je l'ai découvert vu que j'avais le meme probleme avec ma SoundBlaster 128:
$ setpci -d 1274:1371 latency_timer=ff
(Ceci donne la priorité maximale sur le bus au périphérique précisé).

Avec lspci -v, tu peux voir cette valeur, telle qu'elle est par défaut (réglée par le BIOS?), ligne Flags:, champ latency. Et en général, la carte vidéo a la valeur maxi.

Pas vraiment, c'est juste que les fonctions du GPU mettent plus de temps à passer du status d'extension OpenGL à celui de fonction présente par défaut dans la version x.y d'OpenGL. Il se trouve qu'à l'époque l'API de OpenGL 2.x n'était pas encore complètement définie, donc pour Carmack, il était plus simple de passer à Direct3D, déjà prêt.

Pour Direct3D, c'est Microsoft qui décide des fonctions disponibles pour chaque révision de l'API, que les GPU les supporte ou pas (rendu logiciel dans ce cas). Dans la version 10, Microsoft a fait le ménage, et mis un gros paquet de fonction comme devant être supportées.

Par exemple, pour le Geforce 8 tout nouveau tout beau, il faut Direct3D 10 pour utiliser toutes ses fonctions (Vista seulement), alors qu'avec OpenGL des extensions sont disponibles pour les utiliser (XP, Linux et autres). Je ne sais pas par contre si ces fonctions sont utilisables avec Direct3D 9.

Effectivement, seul OpenGL version 1.4 est pris en charge et est émulé avec DirectX.

Même si c'était effectivement une possibilité (avant que Vista ne soit finalisé), ce n'est pas le cas de la version finale. OpenGL est utilisable de la même manière que sous toutes les versions précédentes de Windows:

- soit le moteur logiciel de Microsoft (OpenGL 1.1)
- soit par le pilote du constructeur de la carte vidéo si installé.

Pour référence:
http://www.opengl.org/pipeline/article/vol003_7/

Evidemment, du fait d'Aero, il peut y avoir quelques différences dans le fonctionnement de certaines applications.

A propos du numéro de version, c'est toujours une version 'instable/de développement' comme on dit (deuxième numéro impair).

Brian Paul, le chef du projet Mesa, a annoncé Mesa 7.0 (la version stable) pour bientôt sur la liste de diffusion, le temps de faire quelques corrections dans la 6.5.x. Cette version 7.0 sera officiellement celle à partir duquel OpenGL 2.0 sera supporté.

Sur la page http://dri.freedesktop.org/wiki/R300 tu peux trouver les liens vers les TiRDC (The irregular Radeon-Development companion) sur le modèle de ceux faits pour Nouveau.

j'ai vu sur les liens que l'on pouvait envoyer plusieurs dumps pour une meme carte

En fait il y a deux types de dumps pour une carte:
- ceux faits avec renouveau, pour les commandes OpenGL (nécessaires pour écrire le pilote DRI pour Mesa donc).
- ceux faits avec mmio trace (un module noyau), pour le controle du chip en lui-meme (nécessaires pour savoir comment initialiser un chip, et lui envoyer des commandes, et qui se retrouve dans le module noyau DRM et la librairie libdrm).

dans le style :
cc -g -Wall `sdl-config --cflags` -c -o main.o main.c
In file included from regl.h:28,
from main.c:8:
regl_gl.h:457: error: erreur de syntaxe before "GLhandleARB"


Cette erreur, en général, c'est quand on utilise des fichiers d'include un peu vieux. En l'occurence, il vaut mieux avoir ceux de la version la plus récente de Mesa sous la main.

C'est juste une section quand on a besoin de dumps spécifiques pour des cartes en particulier. En l'occurence, on avait pas de dumps récents pour les Geforce 1 et 3, donc il a fallu demander ceux-là en priorité. Mais sinon, vous pouvez envoyer les dumps quand même.

Je suis quand même étonné qu'il n'y ait pas de projet (à ma connaissance, fort réduire) de pilotes libres 3D pour Nvidia.

Si si, il y en a un:
http://nouveau.freedesktop.org

Actuellement, la partie 2D du driver est testable (même XVideo pour lire des vidéos), pour ceux qui n'ont pas peur du code expérimental. La partie 3D pour l'instant est encore en gestation.

Nvidia a quand même mis à jour le driver "legacy" pour les vieilles cartes:

http://www.nvidia.com/object/linux_display_ia32_1.0-7184.htm(...)

Je ne vois pas en quoi l'ancienne branche n'est plus maintenu.

C'est simple, il suffit de regarder la date de sortie des pilotes 7174 (31 Mars 2005). Donc voilà, pour moi, jusqu'à preuve du contraire (sortie d'une release avec tous les bugfixes), ils ne sont plus maintenus.

Ceci dit sur leur forum, on voit trainer de temps en temps des patches pour le module noyau, pour les config un peu exotiques.

Oui c'est très embêtant. Cela veut dire deux choses:

- Pas de correction de bugs
Quand on voit que la majorité du Changelog, c'est des bugfixes, ca pourrait être facilement backporté pour le driver des anciennes cartes. Moi j'ai une Geforce 2 Ti, donc concerné aussi.

- Pas d'adaptations pour les noyaux plus récents
Si le noyau change trop, le module noyau 7174 pourrait ne plus être compilable sur de prochaines versions. Là je viens d'essayer avec un 2.6.15, j'ai des warnings, mais ça fonctionne encore.

- Yapluka croiser les doigts pour que ce soit fonctionnel rapidement:
http://nouveau.sourceforge.net

- Je travaille pour l'instant majoritairement sur NV40 (j'ai un NV44 donc geforce 6200). L'architecture du NV40 est très proche du NV30 (donc geforce 5x00), et il semble possible d'unifier le code d'envoi de primitives pour supporter aussi NV10 et NV20 (comme c'est fait dans le CVS nv10_swtcl.c). De la même manière, je pense que le support du G70 (geforce 7x00) restera assez proche.

A ce propos, les cartes plus récentes ont un GPU programmable, donc ce doit être coton, si tu ne connais pas leur jeu d'instructions, non?

- Je n'exclus pas le support des vieilles cartes comme NV03/NV04/NV05, en tout cas au moins un support minimal. En particulier le NV03 n'a pas actuellement de support de la 3D du tout, ni libre ni propriétaire.

Tiens d'ailleurs, sur le ftp de nvidia, où se trouve toutes les versions de leur driver, les premières versions avaient été faites en partenariat avec SGI et VA Linux. Il se trouve que ce sont les chips supportés par ce premier driver qui ne sont plus supportés dans les versions >= 7664, alors coincidence? complot?
ftp://download.nvidia.com/XFree86_40/0.9-1/ (le tout premier driver)

- Je vais pinailler mais L'un des outils créés pour l'occasion enregistre les changements faits au niveau des registres de la carte vidéo sur le bus PCI n'est pas tout à fait exact. Ce que l'outil fait est simplement d'afficher le contenu de la fifo de commandes de la carte.

Oui, pardon, j'ai lu rapidement le peu d'informations sur la page de sourceforge, donc voilà.

Non non, j'ai bien compris, mais il y a des gens qui prennent tout au premier degré, alors j'ai fait tout pareil.

Pour en revenir au HDCP sur les ordis, je pense qu'il y a bien un maillon faible, puisque les cryptages AACS et HDCP sont différents. Donc il faut décrypter l'un avant de recrypter pour l'autre. Si ça passe par des drivers sous win32, ça veut dire que le flux décrypté se trouve en RAM à un moment où à un autre, car je ne pense pas que la carte vidéo puisse piloter elle-même le lecteur de disque (HD-DVD ou Bluray). Et même si le flux passe directement de l'un à l'autre sans passer par la RAM, il y aura bien des petits malins pour sniffer le traffic entre les deux composants.

Pour ce qui est du HDCP en lui-même, il ne semble pas très résistant:
http://www.macfergus.com/niels/dmca/cia.html

Maintenant que j'y penses, Mesa c'est pas seulement opengl 1.2?

Mesa 6.x supporte OpenGL 1.5:
http://www.mesa3d.org/RELNOTES-6.0
http://www.mesa3d.org/VERSIONS

Evidemment, pour tout ce qui est pixel/vertex shader/program/choucroute, ca passe par des extensions (GL_ARB_vertex_program, GL_ARB_vertex_shader) jusqu'à intégration dans le core pour la prochaine version. Par contre, pour ce qui est du support matériel de ceux-ci dans Mesa, cela dépend du driver.

L'dée principale de DirectX 10 est l'uniformisation du matériel. L'idéal serait à terme de faire disparaître la notion de CAPS qui, sur les versions actuelles de DirectX, permet d'interroger les cartes pour en connaître leurs possibilités. Les capacités graphiques deviendraient identiques quelque que soit la marque de la carte graphique et la différence se ferait donc uniquement sur les performances.

OpenGL fait ça depuis le début, modulo la gestion des extensions. Il suffit de se rappeler ce qu'a été l'introduction du 'Texture and lighting' dans les 2 API. Dans OpenGL, tous les progs l'ont utilisés sans le savoir, dans DirectX, il fallait interroger les CAPS du matériel pour savoir si c'était disponible, pour les utiliser. C'est quand même le but d'une API que de masquer les différences entre les matériels.

Quelque part, ca ressemble à la même idée que d'avoir une API stable pour des drivers binaires, pour que les constructeurs de matériel n'aient pas à adapter leurs drivers à chaque version du noyau; et principalement pour ne pas à avoir à fournir les sources.

Donc, je dirais que c'est un projet qui ne sent pas bon.

<i>De toutes façons, comme nous n'avons rien à nous reprocher, ça n'a aucune raison de nous déranger, n'est-ce pas ? ...</i>

Pas tout à fait. Si on veut regarder des films protégés sous Linux, en théorie, ca ne devrait poser aucun problème, puisque le flux reste crypté. En pratique ce ne sera pas possible, si la source du flux a un cryptage différent de celui de diffusion, par exemple avec le futur AACS des HD-DVD/BluRay, qu'il faut afficher sur une TV HDCP.

Le flux dans ce cas doit être décrypté du média, et réencrypté pour le HDCP, donc on dispose d'une version en clair à un moment donné. Alors si cette opération est faite en logiciel, on peut courrir pour avoir un player sous Linux. Si toute la chaine est matérielle, ca devrait être possible. Mais quelque chose me dit, que ce ne sera pas le cas.

- si un logiciel dans cette chaîne de confiance (par exemple GRUB) ne vérifie pas l'intégrité du prochain logiciel (exemple: le kernel), tout ce passe très bien avec les fonctions TCPA.

D'ailleurs, le mainteneur de GRUB lui-même refuse tout patch qui ajouterait ce genre de fonction:
http://linuxfr.org/~albancrequy/18368.html

Cela n'empêche pas d'avoir une version (non officielle doc) toute prête de GRUB avec le support présent (c'est bô les logiciels libres, on peut mettre ce qu'on veut dedans):
http://trousers.sourceforge.net/grub.html

Apparemment, il y a aussi une version (prévue? déjà fonctionnelle?) de Gentoo:
http://www.symlink.ch/articles/05/01/31/1436207.shtml