Compte_supprime_74291

@tyrann27 : ceci dit, ça marche bien avec le driver libre (je t'écris depuis un laptop avec 9700m sur lequel j'ai déjà fait tourner compiz avec aiglx et les drivers libres)... ... si tu as besoin d'un coup de main pour les utiliser, faut pas hésiter à demander...

Le X3100 (normalement, dans les G33) d'intel a l'air sympa... je ne sais pas ce que ça vaut en pratique, mais j'ai lu pas mal de bonnes choses à son sujet (je compte m'acheter une mobo µATX à base de X3100, quand le Q9450 sortira, pour convertir mon E6600 en routeur ... je pense que je saisirai quand même l'occasion de tester le X3100 au passage, lors de mes essais, même si au final, je ne m'en servirai certainement pas sur cette machine)...

Faut pas exagérer... - Xv: aucun souci de la 9200 à la X800 (j'en ai plein )... même en dual-carte (tri-écran)... - 3D: bon, c'est clair... il y a du mieux à faire... mais on peut jouer à UT2003 avec de la X800 (pas essayé avec la 9700) si on n'est pas trop exigeant sur la résolution... - compiz: lent sur de la 9200 (en plus limitée à 2048x2048 pour la 3D, 3968x3968 à partir du R300...), mais au-dessus, ça marche correctement (même s'il faut peut-être regarder du côté des R400 pour les très grosses résolutions)... - dual head: aucun souci (et pourtant, mes 3 ordis à clickodrome font au moins du dual-head, y compris mon portable, même si c'est moins souvent)... ... le seul truc, c'est le triple-screen en dual-carte PCIe (seule manière de chercher à avoir du dri en multi-carte, puisque pas de DRI pour le PCI): apparemment, ce n'est pas encore compatible avec DRI (ce qui n'empêche pas que ça marche correctement sans DRI, pour de la 2D simple)... ... pas de problème non plus pour des modelines exotiques en multi-écran (que ce soit pour ma TV HDMI, ou les bons vieux cathodiques [overclockés ] de mon bureau)... Par contre, ça m'étonne que tu ne puisses faire que 2048x1536... normalement, en 2D, le driver est censé supporter 8192x8192 de surface pour les "virtual"... après, c'est peut-être le BIOS ou la puissance de la carte qui limite... Bon, c'est clair qu'il y a du mieux à faire (comme partout... j'avais essayé les blobs des deux ténors du marché sans plus de chances pour le dual carte PCIe...), comme introduire la sortie TV dans le tronc de développement officiel (ça vient), supporter le DRI multi-cartes (ou au moins, pouvoir le désactiver sur l'une d'elles pour ne pas faire planter l'autre... ça fait un an que j'ai voulu faire ça... j'avais réessayé il y a 6 mois... faudrait que je regarde à nouveau), optimiser la 3D (bon, je dois avouer que personnellement, je m'en fouts un peu tant que FVWM ne sera pas composité de manière propre, stable, et disponible dans les dépôts de Debian testing... mais ce serait bien, il est vrai), améliorer le support des vieilles cartes aussi (bon, la radeon 7000, c'est du R100... je n'ai jamais testé sous linux... mais même avec un os redmondien, je me souviens que ça ne cassait pas trop des briques...), mieux supporter les cartes mobility aux bios bizarres (je n'ai ceci dit au moins pas à me plaindre de ma 9700m)... ... bref, c'est loin d'être parfait, mais tout à fait fonctionnel pour l'essentiel des besoins de base...

Peut-être qu'il te faut un "C://tmp//"

... vivement tutunub, buntutu, et toutes les autres

Pour glxgears, j'aurais dû préciser que c'était un seul core qui était bouffé à 90%... ça tombait sous le sens pour moi, mais c'est vrai, j'aurais pu préciser... J'ai relu mes propos sur le 90% d'un core que je dis explicitement bouffé par glxgears, ce que tu dis logique de cette manière : Je relis le texte extrait de la doc ubntubntu; pour eux, explicitement, ce n'est pas uniquement quand xorg dépasse les 10% d'occupation CPU, mais aussi quand glxgears le fait... la phrase est claire... et tu es le premier à être d'accord (cf ma quote de ton post juste au-dessus)... je ne vois pas ce que tu me reproches sur ce point... où as-tu vu que c'était X.org qui me bouffait 90% de CPU? Ce pourquoi, d'ailleurs, j'estime qu'il renvoie n'importe quoi, c'est justement que ces chiffres n'ont pas une grande signification, et que se baser uniquement sur eux est extrêmement douteux... rien de plus, rien de moins... J'ai conspué une doc qui raconte, je persiste et signe, des inepties. Je n'ai fait passé personne pour un idiot. Ca me choque juste que le wiki d'une distro raconte des choses pareilles... surtout quand les gens finissent par les croire et par considérer les bonnes méthodes comme mauvaises... ... que ça ne te plaise pas, c'est une chose... mais je ne vois pas en quoi j'ai manqué de respect à qui que ce soit en taxant, à raison, un (et même des, c'est vrai) propos d'ineptie(s)... j'aurais dit que le gars qui a écrit ça était un con, soit, j'aurais abusé, mais permet-moi justement espérer ne pas être assez con pour en arriver là... là, je n'ai manqué de respect (à la limite, d'un peu de déférence, ce à quoi le respect ne se limite, heureusement, pas... comme j'ai pu le vérifier, avec soulagement) à aucune personne... on dit tous des conneries, moi le premier... ça ne fait pas de nous, définitivement, ni même vraiment ponctuellement, des cons... Merci de ne pas déformer mes propos, en montant sur tes grands chevaux... pour le coup, le premier qui manque de respect, c'est toi. Venant d'un modo, je te laisse deviser à loisir sur l'inacceptabilité de la chose. Quant à l'illégalité évoquée par Lorinc, j'imagine qu'il ne parlait pas bien sûr d'un hypothétique fait de devoir utiliser DRI... je le prends comme une allusion au caractère violateur de la GPL des drivers proprios, travaux dérivés du kernel, s'il en est, sous une licence incompatible avec lui... ils ne sont rien de plus que tolérés, ce qui ne les rend pas légaux pour autant.

En passant outre l'illégalité des drivers proprios, ce n'est pas une question de philosophie... fait est que les drivers proprios font toujours leurs tambouilles comme des gorets et/ou que les gens qui veulent les inclure partout le font aussi (passer par un script hors-gestionnaire de paquet pour installer un module noyau est une habitude de master-goret, d'autant plus quand on n'est pas l'auteur du script)... ... ça débouche sur des inepties comme les reproches que tu fais à glxgears alors qu'il n'est en rien en cause... et qui te font conseiller une méthode hautement douteuse pour vérifier si on a l'accélération graphique ou pas... ... si c'est ça le progrès...

... la preuve... le $DISPLAY est couillé

C'est très tristement exact... et c'est encore quelque chose qui montre que les drivers proprios qui font leur tambouille de gorets sont ingérables... va diagnostiquer sans les outils classiques... ... perso, irl (oui, je sais, on s'en fouts) quand je tombe sur une machine qui en a et qu'on me demande de l'aide, je propose de réinstaller tout en repartant sur le driver libre, ou s'il n'existe pas d'équivalent libre, vesa (parce que vu la merde que foutent des trucs comme fglrx, en écrasant parfois certaines libs comme une truie, empêchant de passer au driver libre sans réinstaller X.org, je ne prends pas la responsabilité de mettre les mains dans ces choses... d'autant que les machines actuelles sont largement assez puissantes pour se contenter de vesa tant qu'on ne joue pas l'exigence des kikoololeries pyrotechniques à la compiz... d'autant qu'une bonne carte à drivers libres comme une X800XL vaut moins de 100¤), ou je réponds la même chose qu'aux ouineurs qui viennent vers moi en pleurant que leur os proprio cracké de partout déconne: "si tu ne veux pas écouter ce que je te conseille, ça ne me regarde plus, débrouille-toi avec tes cochonneries: tu es assez grand(e) pour bousiller ton OS en toute connaissance de cause"... Edit: et au fur et à mesure, en général, on finit par m'écouter, et étrangement, il y a après beaucoup moins de problèmes qu'avant, avec les saloperies du genre envy et cie...

Si ton nom de display ($DISPLAY) est mal configuré, c'est la faute de ta distrib qui fait n'importe quoi, voire de la tienne si tu as trifouillé des trucs sans le savoir (ça peut venir d'une configuration inadéquate du xorg.conf, ou de la redéfinition de cette variable, voire de plusieurs cartes graphiques utilisées en même temps, sans redéfinir le $DISPLAY sur chaque screen X.org, ce qui est peu probable, vu que tu n'aurais vraissemblablement pas le dri sur ne serait-ce que l'un d'eux et qu'il y ait de fortes chances pour que X.org l'ait fait de lui-même pour en arriver au multiple GPU... mais vu que tu te dis débutant, je mets ça franco sur le dos de ta distrib, où on fait manifestement les choses comme des sagouins... tu balances le nom, par curiosité?)... sûrement pas de celle de glxgears... ce n'est pas à lui "d'aller chercher le display", mais à l'environnement de lui dire lequel c'est... ... si chaque appli doit vérifier si ce que l'environnement lui dit n'est pas n'importe quoi, à quoi servent les variables d'environnement? Réponse: à rien... ... en outre, j'aurais tendance à dire que là, tu as le devoir de bugreporter... d'autant plus vu le nombre d'applis qui s'attendent à tomber sur un $DISPLAY adéquat... si c'est un bug, m'est avis que c'en est un grave et bête (ça arrive... mais c'est le genre de choses qui doivent absolument être corrigées, d'où que ça vienne, fût-ce même des scripts crados qui permettent d'installer les drivers proprios comme un crado sur une certaine distro crado de chez crado dès qu'on gratte un tantinet la surface...)...

Flexible, oui... ce qui fait qu'il donne plus d'informations que le "|grep direct", mais qu'il n'est pas forcément plus facile à interpréter par un novice... Ca m'est souvent arrivé de tomber sur le PC de gens qui me disaient, "si-si, j'ai dri et tout, mais c'est tout lent, pourquoi?", ou d'autres qui croyaient qu'ils avaient l'accélération matérielle juste parce qu'ils avaient un cpu assez puissant pour rendre glxgears "assez" fluide... et pourtant, dans ces cas, le "|grep direct" disait "no", et le diagnostic imparable: pas de dri... pour dépanner à distance, c'est quand même ce qu'il y a de plus pratique...

S'il ne va pas chercher le bon display par défaut, rien ne t'empêche de faire un "glxinfo --help"... ... et là, ô, miracle! On peut choisir le display (à trouver en faisant "echo $DISPLAY" sur l'écran qui t'intéresse), ce qui pourrait donner un : "glxinfo -display $DISPLAY" (ou en en utilisant un autre)... ... et là, si ça ne marche pas, tu as sûrement un driver bougrement foireux qui fait sa tambouille dans son coin comme un crade... "glxinfo|grep direct" est la meilleure manière de vérifier proprement qu'on a bien une accélération avec dri, et "glxinfo|grep vendor" de savoir ce qui permet de gérer l'OpenGL (software, hardware, blob, ...)... ça implique d'apprendre à s'en servir, mais ça évite de finir par écrire des inepties comme : ... et ça, ça n'a pas de prix...

Pour ça, "glxinfo|grep direct" est tout aussi efficace... et pas de risque de confondre avec un benchmark...

La seule chose que j'ai à dire là-dessus : ... c'est : "mais n'importe quoi!!!" J'ai déjà vu glxgears me pondre un 90% d'utilisation proc sur un X2 ou un C2D, alors que la carte fonctionnait parfaitement fluidement avec UT2003, sans mettre le proc à genoux (glxgears était fluide aussi, note bien... juste qu'il me plombait le CPU va savoir pourquoi)... et prendre moins de proc sur des machines moins puissantes dans une situation analogue... glxgears n'est absolument pas, mais alors, absolument pas, optimisé pour quoi que ce soit... et en général, il renvoie n'importe quoi en fps, et utilise le proc n'importe comment... c'est d'ailleurs ce dernier point qui l'empêche en premier lieu d'être considérable comme un benchmark... il peut tellement tirer des resources bizarrement qu'on ne peut pas décemment classer les résultats qu'il renvoie, pas plus qu'il n'est optimisé que pour tirer sur le GPU en touchant le moins possible au CPU... La seule chose à en tirer, c'est que si on a plus de fps en activant un driver donné qu'en utilisant mesa, il y a des chances qu'on ait une accélération 3D matérielle... mais de la à dire comment, à dire s'il y en a plus qu'avec une autre carte et choses du genre, non, franchement, pas avec glxgears... D'ailleurs, niveau fps, je ne les regarde presque jamais... je regarde plutôt si l'animation est fluide en agrandissant grave la taille de sa fenêtre... si ça reste fluide, je me dis que l'accélération marche... sinon, je me pose des questions... ... après, la création d'un benchmark 3D libre, pertinent, et efficace serait une très bonne idée... malheureusement, il n'y en a pas vraiment... mais ce serait bien: ça éviterait d'avoir à se traîner cette cochonnerie de glxgears, complètement sous acides, que tellement de gens utilisent n'importe comment (en partant du postulat qu'il est utilisable pour quelque chose de précis)...

Allez, on répète tous en coeur: glxgears n'est en strictement rien un benchmark ni une application opengl optimisée ... qu'il bouffe du proc pour des raisons débiles n'est en rien étonnant et le framerate qu'on obtient avec lui n'est pas significatif de grand chose... ... essaye avec le driver vesa, rejette un coup d'oeil à ton occupation proc, et tu verras que le driver libre améliore déjà les choses... Certes, il n'est pas parfait, mais il est très stable et sa présence n'est pas une plaie béante au fondement pour le maintenir... d'ailleurs, avec lui sur une 9700m, pas de souci pour faire tourner compiz ou ut2003...

Genre, Slackware, c'est cheap?

Oui, mais ça, ça va: c'est cachère

Sinon, il peut aussi considérer qu'il fait juste du load balancing entre plusieurs machines... et que si l'une lâche ou est malencontreusement rangée dans une chambre froide... bah tant pis, il en reste encore

Trêve de bla-bla ... au bouchot!

... ah ouais? Et... vous lui rentrez à combien, dedans?

Apparemment, ils en auraient déjà trouvé un autre... ouf...

J'y crois à mort... genre ...

Et? Tu crois qu'ils vont releaser les specs de directx et cie, gratuitement et sans NDA, qui plus est? Qu'ils vont interdire la vente liée avec les machines? Autant je n'aime pas les produits de cette boîte, autant cette affaire ne me paraît pas avoir grand chose avec le libre... que l'infâme commission européenne puisse voir les monopoles d'un mauvais oeil, soit... mais ce n'est sûrement pas pour le bien des consommateurs... plutôt pour le bien de la consommation.

Comme j'aimerais que ma cafetière soit en wifi et pouvoir lancer une itération en shell ... bon, elle tourne avec du bon grain de torréfacteur et pas de capsule proprio... c'est déjà ça

Le vrai geek a une cafetière qui moud le café en grain toute seule