Articles : XGI et VIA libèrent le code de leurs pilotes
Posté par Adrian (page perso, ). Modéré le 19 avril 2005.
Les sociétés VIA et XGI, anciennement SiS graphics, ont annoncé la libération des sources des pilotes de leurs puces graphiques, VIA publiant dans la foulée les pilotes de ses fameuses puces réseaux VIA Rhine (équipant par exemple les cartes réseau D-Link) ainsi que la quasi-totalité des pilotes des puces graphiques de cartes mini-ITX.
Les coûts de développement de pilotes et la progression de GNU/Linux ont sans aucun doute encouragé les deux sociétés à se reposer sur la communauté linuxienne pour développer des pilotes. Les codes ainsi libérés ont été placés sous licence GPL (avec des variantes selon le mode de distribution dans le cas de XGI).
NdM ! merci à CyrilButtay pour avoir également proposé la news.
Les coûts de développement de pilotes et la progression de GNU/Linux ont sans aucun doute encouragé les deux sociétés à se reposer sur la communauté linuxienne pour développer des pilotes. Les codes ainsi libérés ont été placés sous licence GPL (avec des variantes selon le mode de distribution dans le cas de XGI).
NdM ! merci à CyrilButtay pour avoir également proposé la news.
L'annonce chez XGI (398 hits)
L'annonce chez VIA (514 hits)
La source de la news chez infos-du net (359 hits)
VIA Open Source and Linux Downloads (430 hits)
Journal DLFP : « Après VIA, XGI libère les sources de ses pilotes » (346 hits)
Projet Unichrome sur SourceForge.net (367 hits)
> Lire la dépêche (52 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #563746.




une avancée pour les drivers des autres cartes?
Je suis dans la microelectronique, et je peux constater que les ingénieurs, ca va ca vient, un jour ca bosse pour une compagnie A, un jour pour le concurrent B.
C'est pourquoi m'est venue cette réflexion :
- la liberation des drivers SiS ne permettrait elle pas, indirectement, de comprendre certains principes de fonctionnement commun aux cartes concurrentes (ATI, nVidia)?
- Et donc éventuellement d'aider à l'écriture de drivers libres pour les puces ATi et nVidia?
Qu'en pensez vous?
David.
-- Front de Libération des Sources --
Pour stopper les trolls, citons les sources !
[^]Re: une avancée pour les drivers des autres cartes?
C'est pourquoi m'est venue cette réflexion :
- la liberation des drivers SiS ne permettrait elle pas, indirectement, de comprendre certains principes de fonctionnement commun aux cartes concurrentes (ATI, nVidia)?
- Et donc éventuellement d'aider à l'écriture de drivers libres pour les puces ATi et nVidia?
Non, malheureusement ça n'aide pas.
Pour résumer, toutes les cartes graphiques font effectivement la même chose (dessiner des triangles avec des textures). On sait assez précisément ce qui se passe à l'intérieur (le comportement est spécifié par des specs comme OpenGL), mais tout le problème est en général de savoir comment s'en servir. En effet, pour programmer une carte on utilise des registres, qui ne sont que des adresses (et on ne sait pas à priori quel registre fait quoi). Et tout le problème quand on ecrit un driver sans docs est justement d'associer une adresse à une fonctionnalité, et pas de comprendre les foncitonnalités elles-mêmes (pour comprendre ces fonctionnalités, il suffit de lire des docs sur OpenGL).
Pour comparer avec de la programmation en C, c'est un peu comme si on avait le code (les .c) et qu'on savait ce qu'il fait, mais qu'on ne connaisse pas les interfaces pour s'en servir (les .h).
< pub>
D'ailleurs, pour ceux que ca intéresse de bosser sur des drivers 3d libres, il y a une mailing list (dri-devel sur sourceforge) et un channel irc #dri-devel sur freenode.
< /pub>
[^]Re: une avancée pour les drivers des autres cartes?
Pour ma part, l'existances de drivers libres intégrés dans le noyaux commande directement mes achats matériels!
C'est ma façon à moi de m'exprimer envers ces fabricants. Surtout quand le cartes valent a peu pret le meme prix pour a peu pret les meme performances....
Mes 2 cents...
JMS
Les chalets de la mer rouge!
[+] [^]Re: une avancée pour les drivers des autres cartes?
Ben c est pas si fou , mais dans le cas des cartes graphiques c est encore un voeux pieux .
J ai 2 Voodoo 2 en Sli et une Nvidia 6600 GT , devine laquelle me sers les plus , a part wine Unreal,exe :)
Faut aussi dire que Sis , sur le plan des CG . ils sont tellement a la traine que ls n ont plus grand chose a perdre pour diffuser leurs specs .
[^]Re: une avancée pour les drivers des autres cartes?
< pub>
D'ailleurs, pour ceux que ca intéresse de bosser sur des drivers 3d libres, il y a une mailing list (dri-devel sur sourceforge) et un channel irc #dri-devel sur freenode.
< /pub>
Pour ceux que tout cela intéresse :
http://wiki.duskglow.com/index.php/Open-Graphics(...)
De plus, l'article d'un des concepteurs d'OpenGraphics dans GLMF explique bien tout ce que bknight introduit dans son précédent post.
Bonne journée,
- Christophe -
[^]Re: une avancée pour les drivers des autres cartes?
Je ne pense pas, mais pour des raisons un peu complexes :
Il existe en gros deux catégores de designers/fabricants de puces graphiques ou autres produites en grande série en Asie :
La première catégorie est l'industrie tout à fait locale ou du moins asiatique (capitaux et main d'oeuvre), par exemple l'ex-SiS. La seconde est une industrie d'initiative locale rachetée ou contrôlée par des capitaux étrangers (souvent d'origine nord-américaine).
Le premier type d'industriels n'a qu'un objectif : faire des puces qui marchent, pas chères (quitte à laisser quelques bugs passer en vérif : le logiciel corrigera, et distribuer du logiciel ne coûte pas cher) et en vendre des millions par boîtes de mille.
Le second type d'industriels cherche la maximisation du profit pour l'investisseur, ceci impliquant, souvent, des accords industriels entre détenteurs de "technologies" (ici, on dirait plutôt, "brevets sur des algorithmes" implémentés dans les circuits) et fabricants, voire intégrateurs (mais ce business model là commence à être un peu usé). Les puces du "second type" contiennent donc des technologies éventuellement originales implémentées en dur, soit sous la forme de logique câblée, soit sous la fome de processeurs auxiliaires dédiés pour la mise en oeuvre d'algorithmes réputés efficaces et par ailleurs brevetés.
Les puces du premier type peuvent facilement être "libérées" car elles ont été conçues et fabriquées en dehors de cadres incluant des accords relatifs à de la reco. mutuelle de "propriétés sur des technologies".
Les puces du second type ne peutvent être libérées que bien plus difficilement, puisqu'il faut convaincre les partenaires parfois purement financiers d'accepter le deal.
Evidemment, les puces du second type sont bien plus marketées et promues sur les marchés des pays riches que les premières. En général, d'importantes campagnes de communication soulignent les mérites très spécifiques des puces du second type pour justifier leur prix bien plus elevé que celui des premières (sans oublier les possibles synergies entre industries s'appuyant sur les mérites spécifiques des puces du second type : par exemple : 3D et industrie du divertissement). Mais à supposer qu'on puisse, à partir ou non de pilotes libérés de puces du premier type, déduire les caractéristiques essentielles de puces du second type, y parvenir reviendrait à exposer les utilisateurs (et les programmeurs) de pilotes libérés à des ennuis juridiques à n'en plus finir. Avez-vous remarqué, par exemple, que Longhorn incluera des technologie de déport d'algos sur des circuits spécifiques ? Il s'agira simplement de prévenir les conséquence d'une évolution (ou plutôt, une naissance) d'une législation sur les brevets purement implémentés en logiciels (par opposition à la protection industrielle d'un schéma de cricuit implémentant l'algo de la manière la plus efficace possible, plus conforme à la logique de protection de l'innovation industrielle existante depuis le XIXème).
Et, accessoirement, tout ingénieur sachant cela sait bien qu'il ne rend service à personne (à part s'il a un goût pervers pour la provoc gratuite) en se cassant le cul à écrire du code libre pour piéger ses utilisateurs :-))
Amis industriels de l'électronique, tirez-en vos conclusions !
--
Sauvez la planète, mangez un financier.
[^]Re: une avancée pour les drivers des autres cartes?
Je suis pas sur d'avoir tout compris, mais je vais aller manger un financier.
[^]Re: une avancée pour les drivers des autres cartes?
Bon : alors, entre deux bouchées de financier (bouilli, rôti, ou à la broche), tu peux éventuellement te dire que, si tu veux faire du code réellement vendable, donc, utilisable par tous (gratuitement ou non, libre ou non d'ailleurs, le raisonnement est le même pour du code commercial tout ce qu'il y a de plus classique), il ne faut pas que ce code dépende de matériels (ou de librairies dédiées au bon fonctionnement de tels matériels) fabriqués par les fabricants du second type.
Dans le cas des jeux, le problème est un peu différent : la plupart des jeux sont conçus pour ne pas durer plus de six mois sur le marché (pour laisser la place à de nouveaux jeux) tout simplement parce qu'il est plus lucratif de faire ainsi que d'essayer d'imaginer de bons jeux : inutile alors de se demander comment "les Sims" ont tenu le haut du pavé des ventes depuis si longtemps.
Les fabricants du second type sont assez simples à repérer : soit ils ont des accords stratégiques avec de grands fabricants américains de PCs, soit ils font beaucoup de pub dans les torch^W^W la presse informatique pour PCs de Jackies (ou font l'objet des articles "performance deathmatch" chez anandtech)