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?
Posté par Stephane Marchesin . En réponse à la dépêche XGI et VIA libèrent le code de leurs pilotes. Évalué à 10.
- 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>