Markov a écrit 95 commentaires

  • [^] # Re: Faut pas déconner non plus

    Posté par  . En réponse au journal Fichage généralisé. Évalué à 3.

    Je vais faire le paresseux mais sur les 5 critéres pour un système de vote de mémoire celui à deux tour rempli les moins interessant (de mon point de vue) comme permettre d'élire un candidat detesté par une majorité 2002. Et un système de vote à la condorcet existe dans certains pays comme l'Australie (http://en.wikipedia.org/wiki/Australian_electoral_system). Et je suis de l'avis qu'un système de vote différent permettrait de sortir du bi-partisme y compris au USA.

    Après je ne commenterai pas sur travailler 60h par semaine la ca devient de la politique et c'est pas bien ;)
  • [^] # Re: Faut pas déconner non plus

    Posté par  . En réponse au journal Fichage généralisé. Évalué à 4.

    Je pense que ton raisonnement ne s'occupe pas d'un point des plus important : le système de vote. Aujourd'hui le système de vote de nombreuse démocratie est archaique et totalement inadapté. Ce qui me pousse à dire que l'assemblé pas plus que le président ne représente le choix des Francais.

    Je suis effectivement convaincu qu'avec des proportionnels au législative on aurrait plus de député d'extréme gauche et également des députés resté fidéle aux idées d'indépendance idéologique d'un certain centre droit. Je ne parle pas des municipales qui procéde par un système encore plus inégalitaire. Et pour président je pense que les Francais aurait préféré un compromis au centre plutôt que le choix qu'ils leur à était donné au second tour.

    Alors oui on peut dire qu'on est en démocratie mais une démocratie où les aspirations du peuples ne sont pas représentées. Croies tu que les gens veulent travailler 60heures par semaines pour 250jours par an ? Croies tu qu'ils désirent que le fisc fassent des chéques de plusieurs centaines de millier d'euros aux plus riches ? Ce n'est pas mou souhait et je ne connais personnes qui aiment ces mesures. Et la liste est longue (immigrations, justice, éducations, ...)

    Alors avant de dire que nos démocratie nous permettent de choisir en tout indépendance nos dirigeant je t'invite à te renseigner sur le problème des systèmes de vote dont on peut démontrer mathématiquement qu'il n'en existe pas de parfait. Mais également que ceux que nous utilisons sont les parmis les pires...

    Enfin, à titre d'exemple, je connais des gens qui ont voté le Pen en 2002 afin d'empécher le PS d'être au second tour, ces gens se vantaient alors d'avoir imposé Chirac grâce à leur manipulation du système de vote. Je ne pense pas qu'ils soient totalement responsable car l'abstention à certainement joué un rôle.

    De saines lectures :
    http://en.wikipedia.org/wiki/Condorcet_criterion
    http://en.wikipedia.org/wiki/Voting_system
  • [^] # Re: DRI/Mesa etc.

    Posté par  . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 1.

    On aimerait bien voir les gens de BSD participer. Je pense que le seul obstacle de taile se trouve être le gestionnaire de mémoire qui demandera probablement d'effectuer des changements qui peuvent être profond dans les noyaux des BSD. Tout ce qui concerne la gestion des pages et les configurations des politiques de cache, ainsi que certaine optimisation comme de ne mapper la mémoire que sur un seul processeur pour les multi coeur. Je connais pas les noyaux BSD (je n'ai toujours fait que survoler leur code) je ne pourrai donc prédire l'ampleur du travail.

    Une fois cet partie complété tout l'userspace devrait normalement fonctionner sans problème. Sauf si bug ou dépendance linux caché.
  • [^] # Re: DRI/Mesa etc.

    Posté par  . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 5.

    Je m'en suis excusé à la fin du message. Je crains malheureusement que mes lourdes lacunes en français ne se combleront jamais, l'orthographe ne m'est pas naturel, la grammaire non plus. Sans relecture je commai également de lourde faute qui donne l'horrible syntaxe que tu soulignes et aboutit souvent à des phrases sans queue ni tête. Crois bien que j'en suis le premier à en souffrir.
  • [^] # Re: DRI/Mesa etc.

    Posté par  . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 1.

    Gallium c'est complémentaire, c'est un changement qui impacte plus la "partie mesa" qui commencez à se faire vieillote. Tout le reste peut très bien se faire sans mais ca serrait un peu comme changer la carroserie, et l'intérieur et oublier de s'occuper du moteur.
  • [^] # Re: DRI/Mesa etc.

    Posté par  . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 10.

    Je vais essayer de me préter à cet exercise. Tout d'abord une observation générale, qui a sont importance, les progrés des cartes graphiques ont principalement été poussé par l'industrie du jeux vidéo (je ne pense pas soulever polémique ici :)). C'est donc une parties "limités" des fonctionalités des cartes qui a été privilégié, à savoir la 3D (là encore je pense rallier la majorité :)).

    Au début les cartes 3D avaient peux de mémoire (2, 4, 8, ...Mo) aussi la premiére version du DRM (direct rendering manager) ainsi que de DRI (Direct rendering infrastructure) ne ceux sont pas soucier de gérer dynamiquement cet mémoire et on a préférer une solution simple de découpage de celle-ci en différentes zones à la discrétion du driver. Pour les jeux avec peux de texture ou avec des texture pas très grosse, cela ne pose aucun (ou peu) de problème et cela ne pénalise pas les performances (aux contraire un gestionnaire dynamique de mémoire peut se révéle couteux en performance). Donc premier point absence de gestionnaire de mémoire.

    DRI est une extension qui permet a un programme opengl de "parler" directement avec le driver de la carte via mesa(opengl) sans passer par le serveur X ce qui évite d'être dans les "bouchons" du protocole X. DRI posséde des limitations issues de son design original à savoir l'accélération d'un programme opengl en plein écran (il s'agit ici d'une hypothese de ma part baser sur le protocole et son implémentation tant celui-ci semble bien adapter à cet situation et mal à d'autres, il faudrait demander aux auteurs originaux qu'elles étaient leur intention à l'époque).

    En ce sens le DRI ne concoit que le rendu 3D s'opére forcement dans le scan out buffer (le buffer qui est afficher à l'écran). C'est pourquoi sous compiz avec une application 3D utilisant DRI vous ne voyez pas l'application se déplacer avec le cube, celle-ci envoit ses commandes à mesa qui dessine directement dans le scan out buffer. Cela explique aussi pourquoi le support de certaines extension comme les pbuffer ou les framebuffer object d'opengl n'ont vu le jour que récemment, tant leur implémentation été problématique dans ce cadre.

    Enfin l'ensemble de cet infrastructure se retrouve éparpillé. Nous avons le DRM dans le noyau, nous avons le driver 2D (DDX) du serveur X qui est en charge d'initialiser la carte et le DRM ainsi que d'activer le DRI dans le serveur X et enfin le driver 3D à proprement parler dans mesa. Un grave problème se pose alors, si vous voulez changer radicalement l'interface (comme ce qui se passe aujourd'hui) vous devez assurer une compatibilité arriére ou alors vous préparer à de sérieux problèmes.

    Effectivement souvent les distributions ou les utilisateurs ne mette à jour qu'une partie du systéme: quand vous recompilez un nouveau noyau vous ne recompiler pas un nouveau serveur X, ni un nouveau DDX ni un nouveau mesa. Or la régle c'est qu'un nouveau noyau doit marcher avec un vieux server X et un vieux DDX et un vieux mesa. Donc tout changer, ou faire des modifications radicales n'est pas chose aisée.

    Pour résumer les grands problèmes sont: absence de gestionnaire de mémoire, protocole DRI peut adapter à l'usage de l'accélération 3D qu'on aimerait avoir (accélération de l'interface en utilisant la 3D et donc plusieurs clients 3D ne dessinant pas forcement directement à l'écran mais ailleur en mémoire), fragmentation du code gérant la carte graphique (outre le problème de compatibilité descendante on peut aussi évoquer suspend/resume qui est souvent aléatoire). Keith Packard dresse une liste plus compléte des problèmes qui doivent être résolue dans son talk du LCA ou du FOSDEM de cet année.


    Les solutions c'est simple avoir un gestionaire de mémoire c'est chose faite grâce a Tungsten graphic. Réunir le code d'initialisation de la carte dans le noyau (comme pour les autres drivers). Un nouveau protocole pour la communication entre le server X, les applications et le driver 3D de la carte graphique: DRI2.

    Le gestionaire mémoire permettra de tirer partie de la mémoire des cartes graphique. En exagérant on peut dire aujourd'hui qu'a chaque frame rendu on recharge toute les textures dans la carte graphique et qu'on les estimes perdu pour la prochaine frame (donc qu'on renvoit tout). Aujourd'hui les textures des jeux videos c'est des centaines de Mo et renvoyer 100Mo à la carte pour chaque frame c'est couteux même avec les gros busses qu'on a :). Avec le gestionaire de mémoire les textures, vertex, ... sont soit dans la ram principale soit dans la ram de la carte graphique et on ne déplace les données que quand le besoin se présente.

    Avoir le modesetting et l'initialisation de la carte dans le noyau permettra d'avoir un seul acteur en charge de la carte, cela s'implifira le suspend/resume, cela permettra aussi de ne pas avoir à changer plusieurs de mode video pendant le boot (flicker problem), un démarrage bcp plus rapide du serveur X car celui-ci n'aura plus à faire plein de chose que le noyau faisait déjà lors du boot...

    DRI2 pour l'utilisateur principalement c'est avoir glxgears qui s'intégre enfin à compiz ;). Mais cela apportera aussi d'autre avancées comme permettre de supporter plus simplement et efficacement les buffer object d'opengl et autre pbuffer.

    Pamplemouse sur la pelle à tarte Tungsten graphique termine le développement d'un nouvelle infrastructure de driver qui rend non seulement l'écriture de ceux-ci plus simple mais également devrait permettre de bien mieux exploiter les cartes graphiques récentes.


    Malheureusement tout ceux-ci est en chantier et le temps semble long, je n'ai pas encore vu de bench pour comparer les performances mais je doute que tant que tout ne se stabilise pas cela soit bien significatif.

    Pour le nombre d'actif si il n'y a que peut de personnes à travailler sur tout ca c'est simplement une question de moyen. Comme je le disais seul Intel, Redhat, Tungsten Graphics, Suse, AMD paient des gens (certaines plus que d'autre) or face à l'empleur de la tache c'est bien peu. Je dois dire que je suis particuliérement choqué que des gens de canonical se pleignent sur la mailing list que les choses n'avance pas vite, s'ils veulent les faire avancer vite ils n'ont qu'a payer des gens pour travailler dessus.

    (Vous m'excuserez pour l'orthographe mais l'heure et la taille du message on raisont de tout motivation pour le corrigé...).
  • [^] # Re: Mauvaise image de Linux ?

    Posté par  . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 6.

    Non NVidia n'utilise pas l'architecture de linux pour les graphiques: NVidia n'utilise pas DRM, nvidia utilise sa propre librairie OpenGL, et sa propre librairie GLX donc pour ce qui est de la 3D NVidia n'utilise absolument aucun composant libre et par consequent n'a pas la meme architecture. Merci de te renseigner plus en avant.

    Si tu veux acheter une carte pour jouer soit. Je te demande juste d'etre de bonne foi, a savoir compare le driver intel windows et le driver libre, je sais que le driver libre actuel est moins performant que le driver windows mais je pense que le nouveau driver experimental s'en rapproche nettement (je n'ai pas de windows pour pouvoir comparer par moi meme).
  • [^] # Re: Mauvaise image de Linux ?

    Posté par  . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 3.

    Soupires.... Intel est aujourd'hui le seul constructeur à mettre des moyens important pour améliorer la partie graphique de linux. AMD ni dévolue pas encore grand monde.

    Oui les drivers libres sont lent mais tous les drivers libres sont lents. Le probleme viens de l'infrastructure globale qu'on a actuellement (DRM, Xorg/DRI, Mesa), elle a été conçue il y a des années et certaines choses n'étés pas importantes à ce moment là. Aujourd'hui toute l'infrastructure et retravaillé cela demande du temps (cela va faire maintenant plus de 2 ans que le travail est engagé). C'est d'autant plus long que très peut de personnes travail sur cela à temps plein (à la louche je dirais moins de 10 personnes). Par ailleurs il faut savoir que le libre à des contraintes (compatibilité arriére) qui rendent certains changement difficiles ou plus complexe à mettre en place, que n'a pas nvidia.

    Donc oui le tableau n'est pas rose pour les drivers libres mais la politique de NVidia ne fait pas avancer les choses et de proposer des drivers closed source sans même essayer de mutualiser l'infrastructure. D'une certaine maniére il préfére laisser l'infrastructure open source dans un état "préhistorique".

    Alors non NVidia n'est pas a remercier pour ces drivers linux, ce driverslinux n'existe pas pour faire plaisir à 3 geeks mais parceque nvidia a des gros clients pour qui c'est nécessaire. Pour résumer NVidia n'a jamais supporté la communauté et son travail va même à l'encontre de la progression de celle-ci. En conséquence nvidia ne mérite rien, pas un merci.

    J'espére t'avoir fait comprendre que cracher sur intel qui est le seul constructeur à mettre des moyens pour faire avancer le bousin est injuste. Au passage on peut faire la meme observations pour les distributions (supportées par une compagnie) sur ce terrain seul redhat et suse emploient des gens pour travailler sur ces sujets. Mandrake ou Canonical n'emploient que des packagers dont la contribution me semble anecdotique.
  • [^] # Re: Fichtre, ça va vite

    Posté par  . En réponse au journal AMD libère un guide programmation 3D des R5xx. Évalué à 9.

    Il y a de la doc qui explique toute l'infrastructure de gnome ? du noyau ? La derniere fois que j'ai regarde c'etait assez eparse. Je dis pas que la doc ne sert a rien, mais pour pouvoir en ecrire il faut du monde et si tu regarde le nombre de nom different sur les commit d'xorg, mesa, drm tu verras que ca ce reduit a une trentaine de personnes pour un projet qui avez plus de lignes de code que le kernel il y a pas si longtemps.

    Je pense pas que developer un driver soit si complique que ca, il suffit juste d'etre assez interesse pour devenir passione. Pour retranscrire l'idee de Dave on en avait marre des gens qui venaient sur irc dire j'aimerai bien aider mais il y a pas de doc sur le gpu. On attend donc de revoir tous ces gens venir aider maintenant qu'on a des docs. Juste le cris de desespoir d'une petite communaute...
  • [^] # Re: Et après ça ..

    Posté par  . En réponse à la dépêche Prix Turing 2007 pour la vérification de modèles. Évalué à 4.

    Ces recherches dates de 1980....alors peut être que c'est en 1980 que la recherche se portait bien en france. De manière général les grandes distinctions (nobel, turing, ...) viennent couronner une carriére et récompense des travaux anciens; probablement pour être sur de ne pas céder à un effet de mode et récompenser un travail qui au final n'a rien de bien novateur.

    Etant par ailleurs moi même dans ce monde de la recherche je peux te dire que les vieux ils disent vous êtes dans la merde désolé. Les jeunes ils cherchent a survivre et trouver un financement pour mener leurs recherches mais c'est souvent décourageant, Naturellement comme dans toute profession il y a aussi des planqués qui pensent qu'a leur carriére, ou ceux qui ont chopé un obscur poste et qui se la coule douce. Je pense qu'au finale il s'agit d'un bon échantillons de la société francaise: certains qui profitent grâce à une grande majorité qui est payé au lance pierre.

    Allez je retourne broyer du noir dans ma cage...
  • [^] # Re: Intel : 41% des parts de marché pour les cartes graphiques

    Posté par  . En réponse à la dépêche Intel livre les spécifications complètes et sans NDA des chipsets graphiques récents. Évalué à 1.

    Tu peux tout a fait utiliser ce gpu pour du calcul scientifique seulement aucune interface ou API simple n'existe dans ce but. Par ailleur les GPU d'intel semble faire du calcul floatant en précision simple (je crois que nvidia ou amd font de la précision double).
  • [^] # Re: Zarb

    Posté par  . En réponse au journal GTK+ et OpenGL pour bientot ??. Évalué à 1.

    Oui je me suis mal exprime ce n'est pas le protocol mais le serveur qui est lent pour ce genre d'operation. Ensuite XAA, EXA sont des architecture d'acceleration et tu cree ta propre architecture d'acceleration PlouPlouf si tu veux. NVidia implemente donc sa propre architecture, c'est leur choix et le resultat est plus que correcte.
  • [^] # Re: Zarb

    Posté par  . En réponse au journal GTK+ et OpenGL pour bientot ??. Évalué à 1.

    E17 utilise ses propres librairies pour le rendu, essaye la transparence sans e17 et sans acceleration (ni xaa ni exa) tu vas ressentir d'affreuses lenteurs.
  • [^] # Re: Zarb

    Posté par  . En réponse au journal GTK+ et OpenGL pour bientot ??. Évalué à 1.

    Je crois que tu n'as pas encore compris toi meme les tenants et les aboutissants. Ils sont nombreux et peux claire alors c'est comprehensible. Je vais tanter de les resumer ici.

    Tout d'abord oui la transparence est une operation couteux avec le protocol X pour la simple est bonne raison que jusqu'a present l'acceleration de l'extension render laisse pour le moins a desirer. Note q'ici il s'agit pas d'une simple transparence opaque ou totalement transparent. La complexite des operations en jeux est bien presente dans ce document:
    http://keithp.com/~keithp/talks/KeithPackardAls2000/index.ht(...)

    L'acceleration exa perment en partie de combler le retard mais beaucoup pensent que l'avenir s'oriente plutot vers une solution du type glucose (une adaptation de xgl pour simplifier dans les grandes lignes).

    Ensuite les drivers libre intel dans leur branches fbo supporte le rendu opengl off screen et je te met au defis de prouver le contraire (si j'etais riche je parierai tout mon argent ou je ferrai comme notre amis Patrick qui fait un all in alors que le mec en face bluff pas...on t'en veux pas Patrick)

    Le probleme auquel tu fais reference viens de l'architecture de l'acceleration opengl sous X window pour les driver libre: DRI. DRI c'est direct rendering infrastructure ou en francais dans le texte infrastructure pour le rendu direct. Comme dans tout bon film de serie E tu t'apercois que le mechant c'est pas celui que tu pense mais en faites un mec qui se faisait passer pour un gentil.

    Donc le DRI ca permet aux applications opengl de faire leur rendu directement dans le framebuffer le truc qui est afficher a l'ecran; ca evite de faire une copie entre un buffer temporaire et l'ecran. Et tout ca se passe dans le dos du serveur X. Tant qu'on etait avec un serveur X tout bete en 2d aucun probleme mais quand on a un composite manager alors la plus rien ne va car le composite manager est incapable de recuperer l'image de l'application opengl proprement.

    Voila pour la petite histoire. Maintenant la solution (il y a toujours une happy end c'est la regle on n'y peut rien...) passe par une modification de cette infrastructure c'est ce qui est connu aujourd'hui sous le nom de dri2 (le titre finale n'est pas connu mais ca sera un truc du genre: la revanche, il revient et ca va en jeter un max...on fait avec le budget qu'on a desole...). Et au passage dri2 necessitera d'avoir un gestionnaire de memoire digne de se nom qu'on appel aujourd'hui par abus de langague ttm.

    Voila, il y aurait problablement de quoi ecrire un bouquin tant les choses sont encore plus complexe (au moins dans leur realisation) que je ne les ai ici presenter. Mais ca ferai un mauvais polar...
  • [^] # Re: Zarb

    Posté par  . En réponse au journal GTK+ et OpenGL pour bientot ??. Évalué à 1.

    D'une part les drivers libre intel & radeon sont parfaitement capable de faire tourner un composite manager comme compiz. D'autre part les drivers libre intel supporte l'extension frame buffer object a laquel je pense tu fais reference. Donc: non nvidia n'est pas le seul a proposer cela dans sont driver.

    Enfin la chose est utile car il me semble (je peux me tromper je hais me pencher sur le protocol X) que si tu veux de la vrai transparence avec le protocol X tu tue les performances car cela necessite une relecture des pixels et tout doit repaser par le client (meme si en local ce n'est pas la partie la plus lente). Alors qu'en opengl tu dis alpha blending et la miracle ! ;)

    Enfin avoir le toolkit comme gtk gerer cela permet a l'application de gerer sa transparence et non pas d'avoir la transparence sur toute la fenetre mais par exemple que des parties de celle-ci. Et il y a certainement d'autre applications a ce truc...
  • [^] # Re: Précisions par rapport aux cartes Mobility

    Posté par  . En réponse à la dépêche radeonHD 1.0.0. Évalué à 5.

    Tu trouvera sur wikipedia la correspondance entre nom commercial et chipset:

    http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Proc(...)

    Et oui ta carte fait partie de celle supportee par radeonhd, d'ailleurs l'effort d'AMD porte sur toute leur cartes passees et futures.
  • [^] # Re: Et...

    Posté par  . En réponse à la dépêche radeonHD 1.0.0. Évalué à 2.

    Il n'y aura probablement pas de specifications pour la 3d mais plutot des bouts codes comme exemples des diverses fonctionalitées. AMD n'a probablement pas de spécifications déjà écrite et en écrire prendrait trop de temps. De toutes les façons les gens qui travaillent sur les drivers AMD savent déjà en grande partie comment marche le bousin.
  • # Correction

    Posté par  . En réponse au journal RadeonHD 1.0.0 : driver libre pour ATI. Évalué à 6.

    Alex Deucher a principalement travaile sur le driver radeon et pour la 3D jusqu'au carte R200. Le driver R300 etait dernierement principalement maintenue par Olivier McFadden qui a succede a Jerome Glisse (l'un des auteurs d'avivo le premier driver libre a avoir supporter les cartes r500). Bon j'arrete la pour l'historique :)
  • # Liberté et sécurité

    Posté par  . En réponse au journal Marre de l'intégrisme chez les libristes !!!. Évalué à 4.

    Faire des comparaisons avec des sujets aussi écartés est licencieux. Il est faux, à mon avis, d'assimiler les personnes attachées à des drivers libre à des intégristes. Si tu n'accordes pas d'importance aujourd'hui à de tels drivers alors demain c'est l'ensemble des drivers qui seront "closed source", il ne te restera plus qu'a retourner sous windows ou tu devras repayer une license dès que tu changes de souris (la caricature est bon pour la santez mangez en !)...

    De plus si les spécifications sont connues alors rien n'empêche d'avoir 15 drivers différents pour la carte, et pour moi la liberté c'est avant tout le choix. Sans choix il ne peut y avoir de liberté, après il y a aussi le libre arbitre mais on s'approche ici d'une discussion philosophique quand au sens de liberté et ce n'est pas lieux (et je n'en ai probablement pas non plus les capacités :))

    Pour terminer (et revenir à mon incitation à retourner sous windows pour toutes personnes près à accepter des drivers proprio) une petit citation:

    Those who would give up Essential Liberty to purchase a little temporary Safety, deserve neither Liberty nor Safety.
    Benjamin Franklin

    En francais (pour ceux développant une allergie prononcée à la langue de notre vieille ami Shakespeare):
    Ceux qui sont près à abandoner des libertés essentiel afin d'obtenir temporairement plus de sécurité, ne mérite ni l'un ni l'autre.

    Et je crois que l'accès aux spécifications ou aux moins à un driver libre intelligible est une liberté essentiel dans le monde de l'open source. Bon je te laisse je dois allez faire exploser une tomate devant l'immeuble de nvidia (c'est dure d'être intégriste).
  • [^] # Re: Et encore d'autres infos sur le sujet

    Posté par  . En réponse à la dépêche Un représentant d'AMD annonce l'ouverture des spécifications des Radeons. Évalué à 1.

    Probablement que si j'avais les capacites d'ecrire dans un francais correct je le ferai avec plaisir, mais je crains que mes lacunes restent a jamais evidentes. Biensur je pourrai prendre 5heures pour ecrire 2 lignes sans fautes d'orthographe (malheureusement c'est le temps qu'il me serait necessaire) mais je prefere passer 2min...

    Je te pris de bien vouloir m'excuser.
  • [^] # Re: Et encore d'autres infos sur le sujet

    Posté par  . En réponse à la dépêche Un représentant d'AMD annonce l'ouverture des spécifications des Radeons. Évalué à 10.

    Sachant que j'ai passe bcp de temps sur avivo et sur r300 (qu'elle francais peut bien se cacher sous le nom de markov :)) j'espere pouvoir y acceder.

    Bcp des actuels contributeurs aux drivers DRI n'ont pas acces aux specifications et ca ne les a pas empeches de se lancer dans le code, aujourd'hui l'ensemble a plus besoin d'un travail sur les parties generiques (ce qui ne necessite pas les specifications du tout) que sur des parties specifiques des drivers. Apres c'est vrai que c'est plus agreable de bosser avec les specifications mais c'est pas le saint graal, ecrire un driver si on a les specifications sans connaitre au paravant mesa/dri/drm/ddx (l'architecture sur laquel on construit le driver) serra presqu'aussi long que pour un type sans datahsheet mais connaissant deja bien l'architecture.

    Sur le reste je ne preferre pas trop en dire et laisse le plaisir a AMD d'annoncer de nouvelles bonnes nouvelles (si tout ce deroule comme prevu la semaine prochaine). Ce que je peux dire c'est que contrairement a se qui se passez au paravant il y une veritable collaboration qui semble se mettre en place avec AMD et la communaute.
  • [^] # Re: Noël 2008 ? (ou pas)

    Posté par  . En réponse à la dépêche Un représentant d'AMD annonce l'ouverture des spécifications des Radeons. Évalué à 9.

    Les raisons de la lenteurs de la 3D sont multiples, disons pour resumer que longtemps l'architecture global DRM/DRI/DDX couple avec Mesa n'etait pas optimal. C'est dernier temps un effort important est apporte a ameliorer l'ensemble: gestionnaire de memoire (aujourd'hui on peut recopier plus d'une fois une texture a chaque frame ie transfert RAM -> VRAM, puis VRAM -> RAM et autre joyeusete), veritable amelioration de la pipeline de transformation de vertex permettant a termer une veritable implementation efficace des VBO, refonte de l'architecture de mesa, ... Tout ca prend du temps mais aujourd'hui les ressources necessaire sont presentes pour mener a bien tout cela.

    Enfin en ce qui concerne ton cas je suis un peu etonne qu'une 9000 presente de mauvaise performances (bien sur elle est pas faite pour jouer a doom 3) mais la derniere fois que j'en ai utilise une tuxracer et autre jeux du genre etaient fluide. Je te conseil d'installer driconf (generalement pas installer de base dans les distribs) et de jouer avec les parametres (activer tiling, fast z buffer clear, ...) on peut gagner enormement en performance et certaines options devrait probablement etre active par defaut...

    Au passage glxgears n'est pas un benchmark, c'est meme la pire maniere de tester une carte :) de plus je connais bcp d'utilisateur de R200 qui en sont content et jouent a WoW, quake et company... pour resumer il ne faut pas generaliser une mauvaise experience personnel qui peut etre du a plusieurs facteurs (comme ces cartes vendues avec des bus memoire 64bits qui sont catastrophique pour les performances...). Et n'hesite pas a demander conseil sur dri-user ou meme a ouvrir un bug. Les developpeurs sont toujours interesses par les remonter des utilisateurs afin d'ameliorer le bouzin encore faut t-il que ceux-ci se manifeste.
  • [^] # Re: Noël 2008 ? (ou pas)

    Posté par  . En réponse à la dépêche Un représentant d'AMD annonce l'ouverture des spécifications des Radeons. Évalué à 10.

    Une precission, et je commence a etre enerve de la faire a chaque fois car ca me donne l'impression qu'une enorme partie de la communaute ignore (volontairement ou pas) le travail fait par un petit nombres de contributeurs d'Xorg.

    Oui il existe d'autre pilote libre 3D pour bcp de cartes R100, R200, R300, R400 (des radeons 7500 au x850), il y a aussi des drivers libre pour des MGA (jusqu'au G550 me semble t-il) et pour certain chipset VIA/Unichrome....en attendant nouveau :)

    Donc merci de na pas oublier le travail deja realise et de ne pas tout resumer a il n'y a qu'intel avec des drivers 3D. Intel a ete jusqu'a present le partenaire le plus important et celui qui a fait avance le plus ces domaines sous linux grace aux financement. Aujourd'hui, clairement, AMD ne veut pas laisser Intel seul prendre la place et pourrai bien mettre les bouches double pour rattraper son retard car au final ne l'oublions pas que s'ils font cela c'est pour battre la concurrence et gagner des parts de marcher, si linux etait encore anecdotique soyez sur que ni intel ni AMD nous aiderez pour nos beaux yeux (vous je sais pas mais les miens ils sont beaux ;))

    Pour finir je pense qu'un driver libre 3d assez complet apparaitra au plus tard au courant de l'ete 2008 (je dis au plus tard car je pense qu'AMD va vraiment mettre les bouches double et qu'on arrivera a sortir un driver avant). Donc a Noel 2008 tu jouera avec le dernier Quake sur la derniere ATI pilote par le dernier driver libre inclus d'office dans ta distrib avec un framerate plus important que sous windows et dc tu ferra plus de frags...si c'est pas beautifull ca l'ami :p ?
  • [^] # Re: Et encore d'autres infos sur le sujet

    Posté par  . En réponse à la dépêche Un représentant d'AMD annonce l'ouverture des spécifications des Radeons. Évalué à 5.

    On sera tres prudent avant de signer un NDA, personnellement je n'en signerai pas si les conditions sont trop floue ou trop restrictive sur ma liberte. Enfin tout ca pour dire qu'on va pas signer comme ca.
  • [^] # Re: Twinview ?

    Posté par  . En réponse au journal Aidez le projet nouveau. Évalué à 1.

    Je crois que le driver nouveau possede une branch randr 1.2 et avec randr 1.2 tu auras comme twinview, en mieux meme je pense pas que twinview supporte toutes les options de xrandr 1.2 mais je connais pas twinview :)

    Donc autodetection, autoplug sans changer de config ni redemarrer le server tout ca est au menu. Par contre je ne sais pas si la branche randr1.2 de nouveau est prete a etre merge...