Bravo pour cet article très complet sur l'évolution du driver nouveau.
J'y ai participé occasionnellement et ce que je regrette c'est que l'on ai pas eu un support de la 3D très basique avec dri.
Pas un truc de la mort qui utilise toutes les fonctionnalité du hardware, mais un truc tout pourri qui soit un peu l'équivalent du support des cartes intel i810. [1] Si je veux un support 3D performant, je peux installer les drivers proprio qui marche pas trop mal.
Sur certaines cartes pour avoir un support correct de la gestion de plusieurs FIFO il a fallu presque 1 an.
La gestion de plusieurs FIFO est surtout intéressant pour la 3D (X en utilise une, le drm une autre (mais pour le moment je crois quel ne sert pas à grand chose)).
Le reverse engineering des commandes 3D, pour les cartes assez ancienne, est assez complet depuis quelque temps (même s'il reste surement certains pb qui seront découvert lors de leur utilisation). La gestion des textures à été enrichie lors de l'implémentation des versions accélérées d'EXA.
Une première implémentation mesa/dri [2] est assez ancienne (c'est celle ci qui a servit par exemple au LCA 2007 il y a 1 an). Sur les NV10, glxgears marchotte depuis presque 6 mois.
Tout ceci aurait pu laisser supposer un support basique de la 3D assez vite, mais gallium 3D est apparu.
Or pour les possesseurs de vielle carte (j'ai une NV17), on peut espérer maintenant un support 3D qu'à très long terme : il faut attendre que gallium 3D se stabilise, que la couche de support des cartes anciennes soit rajouté.
Or à ce moment là je crois que je n'utiliserais plus cette carte : elle sera soit morte (le ventillo à déjà cramé), soit je l'aurais remplacé par une autre carte (par exemple les nouvelles ATI avec pilote libre).
Je souhaite longue vie au projet nouveau et j'espère qu'il ne se terminera pas comme nvtv (appli pour faire marcher la sortie tv sous Linux) ou rivatv (driver pour faire marcher les tuner tv sous Linux) qui sont tous les 2 morts.
[1] qui permet tout de même de jouer à neverball, tuxracer, xmoto.
[2] au passage dri est très mal documenté...
A la lecture de la news, j'ai quelques point que je ne comprend pas.
J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
On nous parle pas du tout de bibliothèque rattaché au langage.
Par exemple quelle libc llvm-gcc/clang supporte ?
Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
PS :
Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.
[1] Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.
Ben si c'est ce que fait RT-linux & co.
L'intérêt c'est que l'OS RT fait tout ce qui est critique (stack GSM, ...) et on délégue au Linux ce qu'il l'est moins (multimedia, GUI, réseau, ...) et que l'OS RT ne gére pas d'origine.
Ben le francais n'est pas bien supporté : http://www.languagetool.org/download/README.txt
LanguageTool, a language style checker for English, German, Polish,
and Dutch with initial support for Spanish, French, and Italian
Et puis "sont élue ai parti" aboutit après correction à "Son élue ait parti"... De même "Son élue est parti" est considéré valide.
Toutefois, pour bénéficier de la correction orthographique, il fallait jusqu'à présent installer soi-même le dictionnaire français.
Sous debian, ca a toujours fait automatiquement...
Et même sur seamonkey...
Je me suis amusé, sur du code C à jouer à intervertir certaines instructions commutatives dans des boucles critiques (merci gcov) pour mutualiser les read/write.
Si tu as utiliser gcov, tu as donc fait des optimisation au runtime, chose que le compilo ne sait pas faire.
Par contre ça pourrait être fait par le processeur ou une machine virtuelle.
De plus le C est très complexe à optimiser (les informations de ce que faire le programmeur sont très pauvre). Du coût la plupart du temps l'optimisation d'un code C reflète son codage Ca améliore nettement les performances, et il ya clairement plein de choses de ce genre à faire, tout en restant portable
d'ailleurs un code C "optimiser" pour X86 peut être une grosse bousse sur une autre archi.
Un java light pourrait être très intéressant.
Mais bon, faut qu'ils pensent à faire une couche multimédia performante.
Parce que j'ai regardé il y a pas longtemps et pour faire un lecteur video, il faut forcement sortir du RGB (et donc se farcir la conversion en java)...
Parce qu'il faut regarder les choses en face : plus ça va, plus de transistors sont utilisés pour "réécrire" du code mal écrit par le compilateur. Tous ces transistors consomment, et n'exécute pas du code, et mis ensemble permettrait surement de faire un coeur de plus, un dsp, du cache supplémentaire, que sais-je....
Regardes le succès des RISC par rapport au x86 (qui est compatible avec une archi de plusieurs dizaine d'année).
Un bon compilateur, du moment qu'il sache avec exactitude quel processeur cible il doit attaquer, est capable de préparer le out-of-order lui même.
Oui peux être dans un contexte monotache genre dsp, mais dans un contexte multitâche le compilo ne maîtrise pas du tout ce qui est en cache, quand le flow va être interrompu par un context switch, ...
Sauf qu'intel avait deja fournit ses specs/drivers pour les i810.
Nvidia publiait un driver 3D libre (mais bien offusqué) pour les riva.
Matrox publiait des specs.
PS : maintenant il faut avoir des drivers correct. Vu la complexité de ces cartes, il y a du boulot.
Surtout que les personnes de chez adobe on l'air de répondre assez rapidement : http://www.adobeforums.com/webx/.3c05ae39
Reponse 1h30 apres la question un 31 décembre...
Tiens? Moi j'aurais dit Intel..
Bof, j'ai une carte intel qui marche plus depuis une update du driver sous debian sid...
Du coup c'est soit vesa (ou bidouille dans le xorg.conf).
C'est déjà assez ridicule de voir qu'une animation aussi simplissime pompe autant de CPU (cf les autres commentaires) que Flash quand il joue une vidéo sur Youtube/Dailymotion en fullscreen ou des musiques sur Deezer !
C'est déjà assez ridicule de voir qu'une vidéo (de pas tres bonne qualité) sur Youtube/Dailymotion en fullscreen ou des musiques sur Deezer pompe autant de CPU que pour lire une video HD avec mplayer (ou tout player multimedia digne de ce nom).
Est-ce que SDIO a des caractéristiques tellement uniques que ça justifie une n+1-ième norme ?
L'usb host est assez lourd (a la fois en taille dans le chip et a la fois au niveau soft).
Avec l'usb host il faut gérer les hubs, les périphériques de différentes vitesse. En plus l'usb host qui coordonne le tout doit constamment faire une sorte de pooling sur les périphériques. C'est soit fait en hard (mais le controlleur est cher), soit en soft (mais bonjour les perfs).
Au contraire la sd/sdio c'est tout con : c'est quatre fil de data, un de commande et un autre d'horloge.
[^] # Re: Performances ?
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 3.
Ben propose tes patchs a gcc.
Sur cible ARM, gcc se prend une grande claque par rapport à RVCT .
Qui est le compilo de ARM et qui ne gère que ARM.
De plus le passage gcc3.x à gcc 4.x à quand même améliorer les choses en taille et vitesse.
PS : pour llvm, regarde le README arm pour juger l'état
# bravo ... mais regret
Posté par M . En réponse à la dépêche Un point sur le projet Nouveau. Évalué à 6.
J'y ai participé occasionnellement et ce que je regrette c'est que l'on ai pas eu un support de la 3D très basique avec dri.
Pas un truc de la mort qui utilise toutes les fonctionnalité du hardware, mais un truc tout pourri qui soit un peu l'équivalent du support des cartes intel i810. [1] Si je veux un support 3D performant, je peux installer les drivers proprio qui marche pas trop mal.
Sur certaines cartes pour avoir un support correct de la gestion de plusieurs FIFO il a fallu presque 1 an.
La gestion de plusieurs FIFO est surtout intéressant pour la 3D (X en utilise une, le drm une autre (mais pour le moment je crois quel ne sert pas à grand chose)).
Le reverse engineering des commandes 3D, pour les cartes assez ancienne, est assez complet depuis quelque temps (même s'il reste surement certains pb qui seront découvert lors de leur utilisation). La gestion des textures à été enrichie lors de l'implémentation des versions accélérées d'EXA.
Une première implémentation mesa/dri [2] est assez ancienne (c'est celle ci qui a servit par exemple au LCA 2007 il y a 1 an). Sur les NV10, glxgears marchotte depuis presque 6 mois.
Tout ceci aurait pu laisser supposer un support basique de la 3D assez vite, mais gallium 3D est apparu.
Or pour les possesseurs de vielle carte (j'ai une NV17), on peut espérer maintenant un support 3D qu'à très long terme : il faut attendre que gallium 3D se stabilise, que la couche de support des cartes anciennes soit rajouté.
Or à ce moment là je crois que je n'utiliserais plus cette carte : elle sera soit morte (le ventillo à déjà cramé), soit je l'aurais remplacé par une autre carte (par exemple les nouvelles ATI avec pilote libre).
Je souhaite longue vie au projet nouveau et j'espère qu'il ne se terminera pas comme nvtv (appli pour faire marcher la sortie tv sous Linux) ou rivatv (driver pour faire marcher les tuner tv sous Linux) qui sont tous les 2 morts.
[1] qui permet tout de même de jouer à neverball, tuxracer, xmoto.
[2] au passage dri est très mal documenté...
# questions
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 6.
J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
On nous parle pas du tout de bibliothèque rattaché au langage.
Par exemple quelle libc llvm-gcc/clang supporte ?
Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
PS :
Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.
[1]
Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.
[^] # Re: Performances ?
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
[^] # Re: point de départ
Posté par M . En réponse au message Achat clé Bluetooth avec driver libre. Évalué à 3.
C'est normal vu que c'est l'interface spécifier dans la norme bluetooth.
[^] # Re: Septique...
Posté par M . En réponse au journal TRON RTOS (OS temps réel japonais). Évalué à 9.
L'intérêt c'est que l'OS RT fait tout ce qui est critique (stack GSM, ...) et on délégue au Linux ce qu'il l'est moins (multimedia, GUI, réseau, ...) et que l'OS RT ne gére pas d'origine.
[^] # Re: Bonne nouvelle
Posté par M . En réponse à la dépêche Premier mobile 3G sous Linux - OpenOffice.org et la grammaire - OpenWengo cherche un nouveau nom. Évalué à 1.
http://www.languagetool.org/download/README.txt
LanguageTool, a language style checker for English, German, Polish,
and Dutch with initial support for Spanish, French, and Italian
Et puis "sont élue ai parti" aboutit après correction à "Son élue ait parti"... De même "Son élue est parti" est considéré valide.
# c'est pas nouveau
Posté par M . En réponse au journal Et hop, bientôt le Sonny Bono Act à la française !. Évalué à 1.
Sujet relancé en 2007 [2]
[1] http://www.disqueenfrance.com/snep/dossiers/2006_10.asp ...
[2] http://www.disqueenfrance.com/snep/dossiers/2007_01_14.asp
[^] # Re: Je ne comprends pas
Posté par M . En réponse à la dépêche Picidae : Une nouvelle arme libre contre la censure de l'Internet. Évalué à 3.
[^] # Re: GNASH suxorise
Posté par M . En réponse au journal [lien] Adobe : « on peut imaginer que Flash passe un jour en open-source ». Évalué à 2.
# debian
Posté par M . En réponse à la dépêche Dictionnaire orthographique français inclus par défaut dans Firefox, Thunderbird et Seamonkey. Évalué à 5.
Sous debian, ca a toujours fait automatiquement...
Et même sur seamonkey...
[^] # Re: Pouah
Posté par M . En réponse au journal [lien] Adobe : « on peut imaginer que Flash passe un jour en open-source ». Évalué à 2.
[^] # Re: "scout" thread ?
Posté par M . En réponse au journal Sun Rock : Les détails arrivent. Évalué à 2.
Si tu as utiliser gcov, tu as donc fait des optimisation au runtime, chose que le compilo ne sait pas faire.
Par contre ça pourrait être fait par le processeur ou une machine virtuelle.
De plus le C est très complexe à optimiser (les informations de ce que faire le programmeur sont très pauvre). Du coût la plupart du temps l'optimisation d'un code C reflète son codage
Ca améliore nettement les performances, et il ya clairement plein de choses de ce genre à faire, tout en restant portable
d'ailleurs un code C "optimiser" pour X86 peut être une grosse bousse sur une autre archi.
[^] # Re: Pouah
Posté par M . En réponse au journal [lien] Adobe : « on peut imaginer que Flash passe un jour en open-source ». Évalué à 6.
[^] # Re: flash sera libre s'il y a une concurrence libre
Posté par M . En réponse au journal [lien] Adobe : « on peut imaginer que Flash passe un jour en open-source ». Évalué à 1.
Mais bon, faut qu'ils pensent à faire une couche multimédia performante.
Parce que j'ai regardé il y a pas longtemps et pour faire un lecteur video, il faut forcement sortir du RGB (et donc se farcir la conversion en java)...
[^] # Re: Pouah
Posté par M . En réponse au journal [lien] Adobe : « on peut imaginer que Flash passe un jour en open-source ». Évalué à 9.
Parce que à se niveau elle resemble vraiement au plugin proprio...
[^] # Re: "scout" thread ?
Posté par M . En réponse au journal Sun Rock : Les détails arrivent. Évalué à 4.
Parce qu'il faut regarder les choses en face : plus ça va, plus de transistors sont utilisés pour "réécrire" du code mal écrit par le compilateur. Tous ces transistors consomment, et n'exécute pas du code, et mis ensemble permettrait surement de faire un coeur de plus, un dsp, du cache supplémentaire, que sais-je....
Regardes le succès des RISC par rapport au x86 (qui est compatible avec une archi de plusieurs dizaine d'année).
Un bon compilateur, du moment qu'il sache avec exactitude quel processeur cible il doit attaquer, est capable de préparer le out-of-order lui même.
Oui peux être dans un contexte monotache genre dsp, mais dans un contexte multitâche le compilo ne maîtrise pas du tout ce qui est en cache, quand le flow va être interrompu par un context switch, ...
[^] # Re: Autre époque, autres moeurs...
Posté par M . En réponse à la dépêche Intel livre les spécifications complètes et sans NDA des chipsets graphiques récents. Évalué à 5.
Nvidia publiait un driver 3D libre (mais bien offusqué) pour les riva.
Matrox publiait des specs.
PS : maintenant il faut avoir des drivers correct. Vu la complexité de ces cartes, il y a du boulot.
# Call for community testers for intel driver
Posté par M . En réponse à la dépêche Intel livre les spécifications complètes et sans NDA des chipsets graphiques récents. Évalué à 5.
Par exemple celui de debian est bien rempli : http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&d(...)
# .
Posté par M . En réponse au message FAST dv.now et DV500 (saa7146). Évalué à 4.
[^] # Re: La seule question qui importe :
Posté par M . En réponse au journal PDF, PNG, transparence et ... Acroread. Évalué à 7.
Reponse 1h30 apres la question un 31 décembre...
[^] # Re: signer... des chèques
Posté par M . En réponse à la dépêche Signez la pétition pour un pilote Xorg VIA correct. Évalué à 1.
Bof, j'ai une carte intel qui marche plus depuis une update du driver sous debian sid...
Du coup c'est soit vesa (ou bidouille dans le xorg.conf).
[^] # Re: SVG+JS vs FLash - Requiem
Posté par M . En réponse au journal Un < canvas > rigolo. Évalué à 8.
C'est déjà assez ridicule de voir qu'une vidéo (de pas tres bonne qualité) sur Youtube/Dailymotion en fullscreen ou des musiques sur Deezer pompe autant de CPU que pour lire une video HD avec mplayer (ou tout player multimedia digne de ce nom).
[^] # Re: Patch anti-fragmentation
Posté par M . En réponse à la dépêche Sortie du noyau Linux 2.6.24. Évalué à 3.
http://freshmeat.net/projects/defrag
[^] # Re: ...
Posté par M . En réponse à la dépêche Sortie du noyau Linux 2.6.24. Évalué à 9.
L'usb host est assez lourd (a la fois en taille dans le chip et a la fois au niveau soft).
Avec l'usb host il faut gérer les hubs, les périphériques de différentes vitesse. En plus l'usb host qui coordonne le tout doit constamment faire une sorte de pooling sur les périphériques. C'est soit fait en hard (mais le controlleur est cher), soit en soft (mais bonjour les perfs).
Au contraire la sd/sdio c'est tout con : c'est quatre fil de data, un de commande et un autre d'horloge.