glisse a écrit 248 commentaires

Juste une precision avec DRI2 ca passe par le server X, enfin par le DDX ... On aurait peut etre du changer le nom ;)

Tu sais l'avantage des drivers open source c'est que tu peux y contribuer :)

Cela etant dit, oui les drivers libres sont bcp plus lent mais on a pas le meme nombre de personnes que les drivers proprietaires, de plus on passe encore bcp de temps a finir le support correct du materiel plutot qu'a se preoccuper de la vitesse. Personnellement j'aimerai voir plus de monde sur les drivers graphiques parceque je pense que c'est essentiel pour linux.

Petite precision c'est n'est pas vraiment un firmware c'est un language de script simplifie (atombios) dont ont connait le format. On peut donc regarder les sources et ca nous arrive de le faire. Par ailleurs le driver windows utilise aussi l'atombios ce qui fait qu'on est sur que c'est un code teste et qui marche. Le code de modesetting de l'atombios n'est pas tres interessants (rien de bien nouveau dans ces parties du gpu) mais c'est un code particulierement sensible car il doit prendre en compte plein de parametres comme le type de memoire utilise par le constructeur, leur vitesse, et une tripote d'autre trucs propre a chaque constructeurs. Il est donc plus simple d'utiliser atombios qui est customise par les constructeurs pour coller a leur materiel.

script mygl.sh:
#!/bin/bash
export LIBGL_DRIVERS_PATH=<path to Mesa>/lib
export LD_PRELOAD=<path to Mesa>/lib/libGL.so.1
$@

Tu completes les repertoires, et du cree autant de script que de version differents que tu veux tester puis tu fait :
apres tu fais ./mygl.sh glxgears

Tu peux rajouter export LIBGL_ALWAYS_SOFTWARE=1 si tu veux forcer le rendu software de mesa.

Note, valable que pour les drivers open source, marche que pour un seul driver/gpu (tu peux pas changer de gpu si tu as plusieurs gpu dans ta machine). Il y a d'autre options voir: http://www.mesa3d.org

Pour tout de suite mettre les choses au point, je developpe les drivers libres pour carte radeon et je pretend donc connaitre un peu le sujet (je deteste faire ce genre de precision (moi je, moi je ...) mais ca m'evitera de me repeter sur les points techniques). Cela etant dit j'aime les trolls bien velue comme celui que tu viens de nous presenter.

OpenGL est tout a fait capable de supporter plusieurs applications en meme temps et il ne souffrira pas plus que Direct3D dans les meme conditions.

Tu peux tres bien utiliser un driver particulier pour chacune de tes applications (meme avec le compositing active) et ceux sans relancer le serveur X, il existe plusieurs variable d'environnement pour y arriver (je le fais courament pour tester une modif sans casser ma config qui marche et sans relancer X).


Cela etant dis, oui les drivers open source sont a la traine mais il n'y pas le meme nombre de personnes qui travaillent sur les drivers open source et les drivers proprietaires (si ma memoire est bonne AMD ou NVidia on ~400 ingenieurs sur leur driver, un driver open source c'est une dizaine de personnes et pas a temps plein).

Merci pour ce joli Troll qui a surgit du beau brouillard de ce matin.

C'est parceque le driver radeon était dans staging.

Si ma mémoire est bonne ca devrait du niveau d'une radeon 7000, ou alors d'une nvidia TNT, enfin je pense que ca sera plus lent. Peut être plus proche d'une rage 128.

Bref tu pourras pas faire tourner de jeux avec. Enfin pas des jeux que tu peux déjà faire tourner avec un driver vesa et un gros processeur.

S'il n'utilisait pas un driver closed source il aurait moins de problème lors des mises à jour, après il n'aurait pas non plus les même performances mais les dev Xorg travaillent sur ça.

Par ailleurs le noyau linux casse aussi fréquement la compatibilité avec les drivers closed source. Perso je suis pour casser la compatibilité avec les drivers closed source a chaque release...

Intel ne vend pas de gpu pour workstation (catia et compagnies. ..) je crois qu'il ne reste plus que nvidia et amd sur ce marche. Par ailleurs amd emploie 3 personnes a temps plein sur les drivers libre, Red Hat en emploie 2 c'est pas bcp mais c'est déjà bien considérant que ca ne génère pas de revenus direct

AMD conservera le driver prioritaire sous Linux car il leur permet de vendre des solutions workstations avec certification. Je doute que le driver libre soit un jour certifie pour un logiciel pro. Par ailleurs un certains nombre de fonctionnalités ne seront probablement jamais dans le driver libre. Enfin les performances dudriver libre resteront je crains encore longt 30-40%
des perf du driver proprio)

VIA compression, SGI pour les textures floatantes et d'autres, en generale dans les extensions OGL il y a le noms des societes qui revendiquent les brevets.

Oui, le seul truc c'est que la libdrm doit etre compile avec un flags experimental pour activer le kms et le ddx ati et mesa doivent etre compiles contre la libdrm avec le flag experimental.

Enfin faut pas trop s'exciter non plus :), je crois qu'on a plus de 400bugs d'ouvert alors tout marchera pas super pour tout le monde.

Tant qu'on est en staging l'userspace ne sera pas officiellement supporté. Il incombe (tout comme il en décombe à forciori ! ;)) au distribution de l'activer ou non. Fedora 12 aura bien le DRI2 et tout le trala pour les autres je sais pas trop.

Encore bcp de boulot bas niveau, mais je pense que d'ici 1 ans on fera beaucoup plus de progres en userspace qui seront plus visible pour l'utilisateur final.

Pour AMD il y a aussi la 3D:

http://www.x.org/docs/AMD/
Et il y a d'autre docs interessante sur le site d'AMD en cherchant.

Pour fglrx non, mais tu dis que radeon ou radeonhd ne marche pas, c'est pour ces deux drivers là qui faut faire un rapport de bugs :). Les développeurs n'ont pas toutes les combinaisons possibles de matériel ! Ce n'est pas pour rien que Apple a une gamme limité de support matériel (GPU,CPU,carte mère, ...), ça facilite grandement la correction de bugs et il s'assure que les utilisateurs auront une bonne expérience. Nous dans le monde libre sans les rapports de bugs et le test des utilisateurs on ne peut pas améliorer la situation.

D'après ce que je sais les gros logiciel comme catia (3d comprise) marche très bien sur les cartes + computer + distrib certificié par AMD. En générale c'est un vieux noyau linux, un vieille Xorg. En gros qd on install fglrx sur un noyau récent avec un Xorg récent bah on béta test le driver fglrx...

ATI n'a pas les mêmes priorités sous linux. Il supporte un ensemble de distribution (RHEL, SUSE Enterprise, ...) et un ensemble de logiciels de CAO,DAO et il ne teste leur driver que sur ces produits, que Doom3 marche sous wine les intéressent assez peux (même si ça change). Donc compiz, video et compagnie n'est pas forcément dans leur prioritées sous linux.

Toutes les specs n'ont pas été libérées il y a 2 ans, par example la 3d pour hd2xxx,hd3xxx,hd4xxx a été libérées il y a quelques semaines. Ensuite pour ecrire un driver celà prend ~2ans à AMD (d'après ce que j'ai compris de leur cycle en parlant avec eux) mais avec des centaines d'ingénieur à bosser dessus à plein temps. Sur les drivers libre il y a une dizaine de personnes dont 3-4 à plein temps et on doit rattraper du retard....

Tu as ouvert un bug pour faire part de tes problèmes ? bugs.freedesktop.org

Comme souvent dans un projet libre on suit la méthode de la-rache (http://www.cafenware.com/la-rache/) ;)

Sincérement je trouve cette présentation assez biaisée contre git :

Le début commence par sous entendre qu'il faut apprendre les entrailles de git pour pouvoir l'utiliser, on doit faire pareille avec cvs,svn, ... ? Il me semble que non et dans tous les cas c'est faut pour git.

La partie sur la transition difficile de git à svn est malhonnête intellectuellement, sincérement une telle migration ne peux se passer sans problèmes c'est une évidence...

Slide 38->39: allez hop on raille des qualités de git sans justifier ! Oui avec git everythings is local, any work flow et je trouve (personnellement) easy to learn

Il est possible de ne télécharger qu'un seul fichier d'un module (à traver l'interface web par exemple).

Slide 43: Il est parfaitement possible de cloner uniquement le module qui l'intéresse

Et le summum du manque d'objectivité c'est qu'il n'y a que des témoignages relatant les mésaventures de certains suite à la migration. Oui il faut prendre ses marques, trouver les nouvelles url pour cloner et lire 2-3 tutoriaux sur git. J'ai personnellement eu des discussions avec des développeurs gnome qui étaient content d'être passé à git, il n'y a donc pas que des mécontents.

Voilà je suis juste triste du manque d'objectivité et des critiques infondées, les techniques et effet de manches de nos chers|chère amis politiciens semblent devenir à la mode.

Celà étant dis git ne plaira pas forcément à tout le monde mais d'un point de vu technique j'ai assisté à assez de discussion avec des personnes autrement plus compétentes que moi pour être convaincu des qualités techniques de git.

Peut etre peux tu simplement lui faire remarquer que s'il ne cautionnait pas le texte alors en toute logique il aura du etre present et voter contre...

Kristian, qui a developé DRI2, est sur intel (macbook air 1) et les plus gros contributeurs à toutes ces technologies travaillent pour intel (naturellement ils utilisent du matérielle intel)(Anholt, Barnes, Packard). Pour randr 1.3 le plus gros du travail a été réalisé par Hopf qui lui est sous radeonhd. Pour le reste (input) le gpu a pas bcp d'importance.