Nous avons la chance d’avoir quelques développeurs qui fréquentent LinuxFr.org (what else?), dont Jérôme Glisse (alias glisse) qui travaille au sein de la société Red Hat sur le pilote graphique libre pour cartes graphiques ATI/AMD Radeon.
Pour cet entretien, j'ai invité les membres de LinuxFr.org en tribune de rédaction (il faut être inscrit !) à venir compléter mon questionnaire avec leurs propres questions, et Jérôme a bien voulu se prêter au jeu : un grand merci à lui.
À noter que les hyperliens ont été ajoutés après coup par les contributeurs à cette dépêche pour en faciliter la lecture.
1. Bonjour Jérôme, peux‐tu te présenter s’il te plaît ?
Bonjour, que dire : je travaille chez Red Hat sur tout ce qui touche aux cartes graphiques. Je suis impliqué dans le logiciel libre depuis plusieurs années : tout d'abord comme un hobby, puis de nos jours de manière professionnelle. J'aime les croissants, les fraises, les chouquettes, le couscous, la bonne bière et les bon vins ;). Que dire de plus ?
2. Comment définirais‐tu ton rapport au logiciel libre, et comment es‐tu entré en contact avec lui ?
J'ai toujours été curieux, je suis toujours curieux, je suis très fier d'avoir gardé ma curiosité d'enfant qui me pousse toujours à chercher à comprendre, découvrir… Je suis toujours triste de voir ô combien les adultes perdent trop souvent cette curiosité, se satisfont du parce-que-c'est-comme-ça. Naturellement on ne peut pas être expert en tout. Mais bon je reste optimiste, Wikipédia donne un second souffle à tous ceux qui sont intrigués par les choses qui les entourent.
Au delà de ma curiosité, c'est mon passé de demomaker qui m'a également conduit vers le libre. Un système d'exploitation dont on a les sources, je ne pouvais pas ignorer cela. Par la suite je me suis posé des questions sur le partage des connaissances, et je me suis donc rapproché de la philosophie du libre à laquelle je tiens beaucoup.
3. Qu’est‐ce qui t’a conduit à devenir développeur professionnel ?
Mon sens aigu de l'observation m'a conduit à réaliser que l'on pouvait obtenir des fraises ou de la bière contre de l'argent. Ce fut un tournant dans ma vie, il me fallait obtenir de l'argent pour parvenir à ces choses que j'aime.
Sinon dans la vraie vie, c'est tout simplement qu'il me fallait un travail et qu'à la fin de ma thèse je ne souhaitais pas continuer dans mon domaine (surtout que j'étais à contre-courant). J'ai énormément aimé le monde de la recherche, j'y ai énormément appris et me suis considérablement enrichi (au sens figuré, parce qu'au sens propre, c'est plutôt l'inverse ;)).
4. Tu travailles actuellement sur le pilote libre pour les cartes graphiques AMD Radeon (projet radeon), que faisais‐tu avant ?
Avant j'ai réalisé une thèse en biologie. Mais je n'ai pas débarqué comme ça dans le projet radeon, j'y contribue depuis fort longtemps, depuis le reverse engineering des R300 (aka Radeon 9600, Radeon 9800). Je suis simplement un touche-à-tout.
5. Quelles contributions as‐tu apportées au pilote radeon, sur quoi travailles‐tu maintenant, et sur quoi comptes‐tu travailler ?
Je vais essayer de remonter le temps avec ma mémoire. J'ai commencé par écrire le driver AGP pour les Apple G5 (PPC) avec l'aide de Benjamin Herrenschmidt, qui m'a tenu la main pour mes premiers patchs kernel il y a de ça dix ans. J'avais effectivement un G5 à l'époque et je voulais faire marcher la radeon 9600 dessus. J'ai donc également travaillé sur le reverse engineering de la famille R300 (le plus gros de ce travail a été réalisé par Vladimir Dergachev, Nicolai Haehnle, Aapo Tahkola, et d'autres que j'oublie).
Une de mes contributions à cette époque qui m'a rendu « célèbre », c'est libsegfault (j'en garde un très bon souvenir). J'ai repris une idée présentée dans une release du magazine Phrack, pour abuser du segfault pour tracer un programme. L'idée est de se placer entre le programme et le kernel (LD_PRELOAD), d'intercepter les appels système mmap, unmap et de placer un signal handler pour intercepter les segfaults. Sur le segment que l'on cherche à écouter on fait alors en sorte de changer le mapping pour provoquer un segfault. Dans le signal handler, on récupère ensuite l'adresse du code qui a levé le segfault, on décode l'instruction, on recupère l'adresse exacte (offset complet) ainsi que le type d'opération (écriture ou lecture).
Pour faire simple c'est le Valgrind du pauvre. Je ne me souviens plus pourquoi je n'ai pas utilisé Valgrind à l'époque mais je ne regrette pas, j'ai beaucoup appris. J'ai réalisé ce hack pour pouvoir voir ce que faisait le driver X propriétaire sur un GPU particulier, les Radeon 9800. Effectivement, on finissait toujours par avoir un lockup (voir ci dessous pour une explication) sur les Radeon 9800, mais on avait remarqué que si on chargeait en premier le driver propriétaire, alors tout marchait correctement. Le driver propriétaire devait par conséquent écrire un registre que nous n'écrivions pas. J'ai fini par trouver après une année (d'une partie de mon temps libre).
Un lockup pour un GPU, ou de manière plus générale pour n'importe quel matériel, c'est lorsque le matériel se bloque. Pour faire une analogie, le matériel reste coincé dans une boucle d'une de ses fonctions. Plus un matériel est complexe, plus il peut y avoir de raisons pour qu'il se bloque. Sous Windows, cela donne souvent droit au blue screen of death. Les GPU sont les pires cas car c'est probablement le matériel le plus complexe qui existe dans un ordinateur. En effet, le GPU est quasiment un ordinateur à lui tout seul : il possède son propre contrôleur mémoire, ses propres unités de calcul, parfois sa propre mémoire.
Les lockups sur GPU sont ainsi des plus variés, on peut identifier plusieurs grandes catégories. Le GPU essaie de lire ou d'écrire à une adresse invalide en mémoire (plusieurs raisons : le driver à oublié d'éteindre un bloc du GPU, l'update de la pagetable du GPU n'a pas été fait correctement…). Le GPU fait face à des données qui provoquent un cas dégénéré (des sommets donnent un triangle mal formé …). Le GPU rencontre un problème interne de synchronisation (par exemple un des blocs du GPU attend le signal d'un autre bloc mais ce signal est perdu par exemple parce qu'il est arrivé trop tôt).
Naïvement, on pourrait penser que tout cela est documenté, mais c'est très loin d'être le cas. Les GPU ont tellement de blocs (un bloc c'est par exemple le contrôleur mémoire, l'unité qui transforme un triangle en pixel, ou l'unité qui envoie les pixels à l'écran…) qui ont chacun énormément d'inter-connections que des problèmes non triviaux de propagation des signaux se posent. Au final, il est impossible de tester tous les cas lors du développement du GPU, beaucoup des bugs sont découverts seulement lorsque le GPU est finalement dans les mains des utilisateurs.
On pourrait également penser naïvement qu'il est simple de faire un reset du GPU ou de le redémarrer, mais c'est loin d'être le cas. Idéalement, les nouvelles normes PCIe qui permettent un vrai reset hard (comme lorsqu'on redémarre l'ordinateur) vont aider dans cette direction. Mais actuellement, il est possible pour un GPU (ou pour tout autre périphérique PCI/PCIe) de conduire le système à se bloquer complètement.
Et comme il y a une infinité de raisons pour un lockup, il n'y a pas, par conséquent, de recette à suivre pour les déboguer. Il s'agit de deviner ce qui peut mal tourner et surtout de trouver un cas qui permet de reproduire facilement le lockup et de réduire ce cas au minimum possible.
Pour en revenir à mes contributions, pour la famille R300, j'ai touché un peu à tout, du kernel, au driver X en passant par Mesa et libdrm (je suis le genre à coller mes doigts dans tous les pots de confitures, je ne peux pas m'en empêcher). J'ai acquis une vision globale de la pile graphique sous Linux. Après le R300, j'ai travaillé au reverse engineering de la famille R500 (la famille R400 étant très proche des R300, il y avait moins de travail). J'ai réalisé ce travail de reverse engineering avec Daniel Stone et Matthew Garrett, on a sorti ensemble le driver avivo. (Pour ceux qui ont trop regardé Jurassic Park… J'ai dépensé sans compter !)
Alors que nous étions en train de travailler sur avivo, AMD et SUSE étaient en train de travailler sur radeonHD le nouvel effort open source impulsé par AMD. Cela a malheureusement conduit à une guerre larvée entre plusieurs personnes (avec moi au milieu en train de jouer innocemment).
À la même période, j'ai écrit un premier driver Gallium3D pour R300, driver qui sera ensuite réécrit par Corbin Simpson. Pour éviter de me retrouver sur le champ de bataille entre xf86-video-ati et xf86-video-radeonhd, je me suis orienté vers le kernel modesetting (KMS). J'avais participé au design de DRI2, conduit par Kristian Høgsberg, et je ne voulais pas faire DRI2 sur l'ancien driver noyau. J'ai donc écrit un premier driver KMS pour Radeon, qui n'était vraiment pas terrible. Dave Airlie en a écrit un second, qui reprennait le modesetting du ddx alors que j'avais tout réécrit dans le mien. Dave voulait réutiliser les mêmes ioctls (si mes souvenirs sont exacts) et je n'aimais pas cela. J'ai donc écrit un troisième driver KMS, qui reprenait également le code modesetting du ddx (considéré comment possédant plusieurs workarounds accumulés au cours des années). Dans le même temps, j'ai corrigé et adapté au dernier noyau TTM (nécessaire pour radeon), j'ai également participé au design de GEM. Enfin j'ai réalisé le design de l'ioctl pour soumettre les commandes (CS ioctl).
Toutes les pièces du puzzle étaient donc là, j'avais mon dernier code KMS pour Radeon, un code TTM que j'avais longuement débuggué, et une interface GEM qui me satisfaisait plus ou moins. Mon driver KMS fut donc inclus dans le noyau, laissant le soin à Thomas Hellström de poster ma version débugguée de TTM. Le pilote radeon devint ainsi le driver noyau le plus gros (et il l'est toujours le bougre).
Pendant ce temps là, AMD avait écrit un driver Mesa classique pour la génération R600, et qui plus est fonctionnant sans le KMS. Horreur ! Infamie ! Il me fallait laver l'affront, et donc écrire un driver Gallium, et c'est ce que j'ai fait. J'ai écrit le driver r600g pour les Radeon R600/R700, attirant très vite d'autres contributeurs.
La suite, c'est plein de contributions à droite, à gauche : texture/color tilling support (R600, R700, Evergreen, Northern Islands), hyperz support (R600, R700, Evergreen, Northern Islands), texture/color tiling support (Southern Islands/Sea Islands)… Dernièrement j'ai écrit un autre driver X pour les Southern Islands, en utilisant le state tracker XA pour lequel j'ai réalisé plusieurs patchs. Ce travail n'a pas porté ses fruits dans le temps imparti, néanmoins mes patchs pour XA sont aujourd'hui utiles au projet Freedreno (Rob Clark).
Voilà, j'en oublie, j'ai des contributions à droite et à gauche dans des petits projets et des plus importantes, en fonction des bugs qui ont eu l'outrecuidance de se mettre sur ma route.
6. Concernant le projet radeon, comment se passe concrètement ton travail : au sein de Red Hat ; au sein de la communauté ?
Je suis assez libre chez Red Hat, mes grosses obligations concernent l'intégration du travail upstream dans les releases RHEL. C'est tout un travail, souvent silencieux et invisible, qui implique beaucoup plus de personnes dans Red Hat qu'il n'y paraît. Il y a un gros travail d'assurance qualité, de vérification et d'audit, travail réalisé en collaboration avec plusieurs équipes.
Au sein de la communauté c'est un peu la métaphore de la cathédrale et du bazar. Chacun travaille plus ou moins sur ce qu'il veut et on essaye de communiquer suffisamment pour ne pas se marcher sur les pieds. Naturellement les personnes travaillant pour AMD font aujourd'hui beaucoup plus de contributions : ils ont accès au matériel et à la documentation bien avant moi. Souvent quand je leur pose une question, c'est plus simple pour eux de faire le patch que de me répondre.
7. Combien êtes‐vous à travailler sur cette partie ?
Je ne sais pas si j'aurais assez de doigts ! Parlons d'abord des bénévoles ! Nous avons donc Vadim Girlin, Vincent Lejeune, Sylvain Bertrand, … (et d'autres que j'oublie, désolé). Il n'y a pas de petites contributions. Chez AMD, de visibles, ils sont cinq : Michel Dänzer, Alexander Deucher (blog), Christian König, Marek Olšák et Tom Stellard (blog). Enfin, sur radeon, à Red Hat, nous sommes deux : Dave Airlie (blog) et moi. Alors avec l'aide de mes doigts de pieds, ça nous fait neuf personnes (oui je me suis emmêlé des doigts).
8. As‐tu une spécificité ou une façon de travailler inhabituelle ?
Je travaille avec mes deux mains, je ne sais pas si c'est inhabituel, sinon j'aime aussi beaucoup travailler sur papier ou sur un tableau. Poser mes idées à plat comme on dit. Bref je ne pense pas qu'il y ait grand chose d'inhabituel chez moi.
9. Déboguer les fréquents lockups doit prendre une large partie de ton temps, arrives-tu à aussi faire des choses intéressantes ?
Qui a bien pu poser cette question ? Je laisse le soin d'enquêter à d'autres. J'ai fini par avoir la réputation de spécialiste des lockups suite à mon année passée à corriger mon premier lockup sur Radeon 9800. Il peut m'arriver de passer plusieurs mois sur un lockup et d'écrire beaucoup de code utile seulement pour débugger un cas précis. Il m'arrive aussi d'insulter copieusement et de maudire sur plusieurs générations les ingénieurs qui ont conçu le circuit. Dans tous les cas, je refuse de travailler uniquement sur un lockup car c'est souvent très frustrant et très ingrat, je fais toujours quelque chose de plus intéressant en parallèle.
10. Échangez‐vous beaucoup avec les développeurs de Nouveau et des pilotes graphiques libres d’Intel ?
Oui nous partageons déjà énormément de code, notamment au travers de Mesa ou du code commun DRM dans le noyau. Par ailleurs, nous avons souvent les mêmes problèmes et donc nous cogitons souvent ensemble. C'est très agréable. Globalement, tous, quelque soit le GPU sur lequel nous travaillons, nous voulons améliorer la pile graphique Linux et par conséquent nous voyons toute coopération comme bénéfique.
11. Quels efforts AMD pourrait encore faire pour que les pilotes libres soient encore meilleurs ?
J'aimerais avoir accès aux informations plus tôt pour avoir un support au moment du lancement du GPU et pas après. J'aimerais aussi employer plus de personnes pour travailler sur le pilote libre… Mais il faut être réaliste, il y a dans l'équation le coût et le gain qui entrent en jeu. Malheureusement la taille des équipes entre le driver open source et le driver propriétaire est sans commune mesure (plusieurs centaines sur le driver propriétaire).
M'envoyer visiter les îles qui servent de noms au GPU (Hawaii, Maui, Cayman …) ?
12. Quel est l'intérêt pour AMD de développer des pilotes propriétaires ?
Pour les pilotes propriétaires c'est tout simplement de pouvoir supporter leur matériel sous Linux de manière satisfaisante pour leurs clients professionnels. Cela nécessite un driver qui supporte toutes les fonctionnalités OpenGL mais aussi qui est certifié avec les gros logiciels (CATIA, Maya …). Si AMD voulait faire cela avec les drivers libres il leur faudrait embaucher plusieurs centaines de personnes pour travailler sur le driver libre (on ne peut pas partager les équipes entre le driver propriétaire et le driver libre). Il faudrait donc un investissement considérable pour AMD pour un retour nul ou presque. Leurs clients professionnels ne s'intéressent pas de savoir si le driver est libre ou pas, ils veulent juste une solution rapide et à un prix raisonnable.
En utilisant le driver propriétaire sous Linux, AMD peut utiliser le même driver que sous Windows et donc utiliser les mêmes équipes de développement. Il y a une forte mutualisation des coûts à procéder ainsi, au final l'équipe qui travaille sur la partie Linux pour le driver propriétaire est assez restreinte. Elle s'occupe seulement d'implémenter l'API nécessaire pour faire l'interface entre le cœur du driver et les parties spécifiques au système d'exploitation.
Il est malheureusement très probablement impossible de réaliser un driver open source pour les systèmes d'exploitation de Microsoft, particulièrement avec tout ce qui touche aux protections vidéo (HDCP et autres). Les compagnies craignent par ailleurs de s'exposer à une fragmentation du driver et de voir des forks plus ou moins réussis conduire éventuellement à une mauvaise expérience utilisateur. Même si personnellement, je pense que l'on pourrait voir des contributions intéressantes aux drivers et que cela ne ferait qu'améliorer l'expérience utilisateur.
On peut alors se demander pourquoi AMD s'embête également avec un driver open source pour Linux. Je pense qu'il y a plusieurs intérêts. D'abord, un meilleur support pour Linux, une expérience out of the box supérieure. Ensuite, pouvoir avoir la certification de leur matériel avec les distributions professionnelles. En effet, pour certifier les cartes graphiques avec RHEL, seuls les drivers open source sont autorisés, c'est une des autres contributions de Red Hat au monde du libre. Malheureusement, assez peu de fabricants de laptops certifient leur matériel avec RHEL, et cela concerne uniquement les lignes professionnelles de leurs ordinateurs portables (assez peu sexy et souvent gros et lourds). Enfin sur Android/ChromeOS, avoir un driver open source et upstream est beaucoup plus simple même si malheureusement Google ne fait rien pour encourager les drivers open source. Il y a d'autres raisons mais qui ne sont pas forcément publiques et je préfère laisser votre imagination travailler.
13. Que penses‐tu de l’attitude d’Intel, qui s’implique plus que quiconque dans le développement de ses pilotes graphiques libres, mais qui, dans le même temps, persiste à ne pas s’intégrer à l’architecture commune Gallium3D ?
Intel réalise un travail énorme sur l'infrastructure graphique de Linux, nous n'en serions pas où nous en sommes sans eux. J'apprécie donc tout particulièrement leurs nombreuses contributions.
En ce qui concerne Gallium, j'ai eu plusieurs discussions, avec plusieurs d'entre eux. Ils ont des arguments valides et d'autres beaucoup moins. Gallium a été conçu dans l'optique d'écrire un driver graphique une fois et de pouvoir avoir par dessus plusieurs API (ce qu'on nomme le state tracker dans la terminologie Gallium) qui utilisent le driver (OpenGL, OpenCL, OpenVG, DirectX, XA, …).
Pendant longtemps il n'y avait qu'OpenGL et par conséquent pas beaucoup de justifications à Gallium. Car il faut reconnaître une chose, Gallium rajoute une couche et par conséquent un overhead. Mesa est connu pour son overhead parfois pathologique, mais ces dernières années, grâce notamment au travail d'Intel, c'est beaucoup moins le cas. Les développeurs de chez Intel n'ont donc pas voulu rajouter un boulet à leur béquille. Il me semble que c'est aujourd'hui beaucoup moins valide et justifié.
Après il y a aussi des aspects de goût (on aime ou pas, c'est le ou pas qui est important), de familiarité (plusieurs années à travailler avec Mesa classique)… Par exemple il est beaucoup plus facile dans le cadre de Mesa classique d'implémenter son propre compilateur de bout en bout en s'interfaçant correctement avec le cœur de Mesa. Ce qui est autrement beaucoup plus difficile pour un driver Gallium. Effectivement dans le paradigme Gallium les shaders contiennent une partie importante des informations nécessaires au code commun (texture unit, sampler, nombre d'inputs, de constantes …), ce qui rend nécessaire d'utiliser une représentation intermédiaire commune pour les shaders même si cette représentation intermédiaire est particulièrement mal adaptée pour y effectuer des passes d'optimisations.
Bref si un driver Gallium désire améliorer cela il doit d'abord implémenter une nouvelle représentation interḿediaire pour tout le monde et convertir tout les drivers Gallium. Une tâche bien plus compliquée que de travailler sur un seul driver mais qui a l'avantage de profiter à tout le monde (enfin à tout les drivers Gallium).
14. Que penses‐tu de la technologie AMD Dynamic Switchable Graphics (équivalent à Optimus de NVIDIA) ? Avez vous toute la documentation ? Est-ce facile à intégrer ?
Je n'aime pas. C'est très difficile à intégrer proprement d'abord parce que Xorg était jusqu'à récemment pas du tout équipé, et encore moins pensé, pour ce genre de configurations. Mais depuis le travail de Dave Airlie nous avons grandement avancé sur le front Xorg. La documentation est comme souvent problématique, et comme toujours entre la documentation et la réalité il y a un abysse insondable. Ces technologies impliquent presque toujours le BIOS système (ACPI) et par conséquent tous les bugs qui vont avec. Et comme toujours, il n'y pas de test pour les BIOS. L'unique test est le driver propriétaire sous Windows : si ca marche, alors c'est que c'est bon, et tant pis si l'API est implémenté à moitié.
Bref, il y avait un manque sur l'infrastructure X. Et il reste des difficultés dues aux larges variations entre chaque vendeur. Les solutions à la Bumblebee sont des hacks qui permettent néanmoins de se servir en partie de ces solutions. Et aujourd'hui, Prime (NDLA : voir la dépêche consacrée à la sortie du noyau Linux 3.9) permet d'utiliser de manière plus correcte ce genre de configuration mais c'est encore loin d'être transparent pour l'utilisateur.
15. Quels sont les défis techniques, les objectifs déjà atteints et les évolutions du projet ? (notamment : relations avec AMD ? et relations Red Hat/reste de la communauté ?)
Vieille série française ? Je crois que le plus gros défi, c'est de résoudre les bugs. Contrairement à Apple, le monde PC ressemble à une jungle : il y a une combinatoire pas possible entre les différentes cartes mère, différents GPU, différentes barrettes mémoire (l'informatique c'est beaucoup moins déterministe qu'il n'y paraît). Il y a toujours des combinaisons problématiques et elle sont seulement testées avec les drivers propriétaires sous Windows.
J'aimerais donc voir une plus grande part de QA sur le design et la finition des ordinateurs avec Linux. Pour le moment, seul Google avec ses Chromebooks fait cela. Et c'est un travail ingrat et fastidieux.
Concernant les objectifs, je pense que nous les avons déjà atteints : avoir un driver qui marche sur un large panel de configurations et qui a des performances respectables. Il nous reste encore à supporter plusieurs centaines de fonctionnalités du matériel (OpenGL 4, OpenCL 1.2…).
En ce qui concerne les relations, je ne suis probablement pas bien placé pour répondre à cela. Je trouve énormément d'animosité et de violences dans les propos de certains utilisateurs à l'encontre d'AMD (et parfois aussi de Red Hat, mais rarement sur la partie graphique), ignorant souvent l'énorme travail qui est derrière le driver open source ; s'imaginant à tort que si l'on a un bug alors forcément tout le monde l'a aussi et donc que les développeurs sont des incapables. Il y a beaucoup de naïveté sur la réalité de l'informatique, cette certitude que tout est prévisible et documenté, et que par conséquent aucune situation n'est imprévisible.
Dans une expérience, je suis du côté d'Einstein: « La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : rien ne fonctionne… et personne ne sait pourquoi ! ».
Je comprends néanmoins la frustration que cela peut provoquer chez les utilisateurs. Quand nous achetons un ordinateur nous voulons le voir fonctionner, nous voulons pouvoir en utiliser toutes les fonctionnalités. Le driver open source est loin de pouvoir satisfaire tout le monde, mais comme je le disais cela vient d'une incompréhension des gens. Seul un produit pensé pour Linux fonctionnera bien avec Linux, et ce tant qu'il n'y aura pas des millions de personnes capable de débugger chaque combinaison de matériel.
16. Au sujet des firmwares non-libres requis par le pilote libre pour faire fonctionner la carte…
J'aimerais voir des gens faire de l'ingénierie inversée de ces firmwares. Ce n'est pas si compliqué, d'autant plus que l'on sait exactement ce qu'ils font. Bref on connaît le contenu de la fonction, mais on ne connait pas le jeu d'instructions utilisé pour l'implémenter.
17. Justement, à quoi servent-ils ? Leur existence est-elle inhérente à tout GPU (il me semble par exemple que les puces graphiques Intel ne nécessitent pas de tels firmwares) ? Je lis parfois que ces firmwares ne font rien d'évolué, qu'ils sont « bêtes » et qu'ils ne peuvent donc être malicieux… Pourtant le firmware nécessaire à l’accélération vidéo via les unités dédiées UVD a l’air énorme par exemple…
Ils servent à réaliser des tâches simples, principalement ils écrivent et lisent différents registres du GPU, ils s'occupent également de la synchronisation entre différent blocs du GPU. Ainsi sur les anciennes générations de Radeon ils est tout a fait possible de faire un driver libre qui n'utilise pas le command processor (abréviation CP) et donc de n'utiliser aucun firmware mais tout le travail doit alors être fait sur le CPU : le CPU devrait lire en boucle certains registres et, en fonction du statut, écrire ou pas les registres en attente. Bref le driver consommerait d'un coup énormément de temps processeur.
Sur les nouvelles générations c'est probablement impossible, un certains nombre de registres ne sont certainement plus accessible directement depuis le CPU et seul le CP ou les autres micro-contrôleurs y ont accès. De plus le micro-contrôleur est indispensable pour la gestion de l'énergie, il effectue des tâches qui demandent du temps réel avec une précision que l'on ne pourrait pas atteindre depuis le CPU. Ainsi, changer les fréquences mémoire demande plusieurs centaines de micro-secondes et il faut couper certains blocs dans le laps de temps et les réactiver après.
Pour les firmwares video je ne connais pas leur contenu, mais j'imagine qu'il s'agit de l'implémentation du codec, c'est à dire que si l'on savait écrire le firmware on pourrait ajouter le support d'autres codecs comme VP9 ou Daala… Par exemple les firmwares pour R600 et R700 sont énormes également mais c'est parce qu'ils font l'émulation de vieilles commandes 2D en utilisant le bloc 3D.
Pour Intel il me semble qu'ils ont aussi un firmware mais qu'il est caché dans le BIOS, par exemple les APU AMD n'ont pas besoin des mêmes firmwares pour le GPU parce qu'une partie est dans le BIOS système. Enfin je ne suis pas très sûr de tout cela, c'est mon educated guess.
L'avantage d'un firmware c'est que c'est beaucoup plus polyvalent et évolutif, par exemple on peut contourner des bugs hardware dans le firmware du GPU. De plus il existe beaucoup de cores de micro-contrôleur déjà largement éprouvés, donc pour la conception du circuit ils savent qu'ils ne peuvent pas avoir de bug dans le micro-contrôleur et que si bug il y a alors c'est dans le firmware. Au contraire s'ils avaient implémenté le firmware en dur, les bugs ne seraient pas corrigeables sans un nouveau tapeout (et tout les coûts qui vont avec, par exemple il me semble qu'imprimer un masque processeur 28nm c'est de l'ordre du million de dollars).
18. Quelles sont les prochaines avancées à attendre du projet radeon ?
Probablement HSA, sinon comme toujours : corrections de bugs, support de nouveau matériel, améliorations diverses, support de plus d'extensions OpenGL, plus rapide, meilleurs compilateurs, … J'aimerais également voir le support du moteur de compression vidéo même si l'intérêt est probablement limité (h.264 seulement et pas un codec libre).
19. Quelle carte graphique conseillerais‐tu d’acheter pour utiliser Linux ?
Facile comme question, la réponse, Jean-Pierre, c'est Obi-Wan Kenobi ! Et c'est mon dernier mot !
Après, je dirais qu'il faut d'abord définir l'usage. Si c'est pour LibreOffice, le Web, et des petits jeux, AMD ou Intel avec leurs GPU intégrés. Pour jouer à des gros jeux la réponse est plus ardue. NVIDIA a encore, me semble-t-il, un avantage dans ce genre d'usages : leur driver graphique propriétaire se comporte mieux avec un plus large éventail de jeux.
Pour des applications professionnelles, j'ai de bons retours que cela soit pour AMD ou NVIDIA (avec probablement un avantage pour AMD au niveau du prix), mais je parle ici de l'utilisation d'une distribution professionnelle, qui est certifiée pour le logiciel utilisé avec les drivers propriétaires.
20. As‐tu d’autres projets relatifs à Linux ou au Libre en général ?
Oui, comme beaucoup de passionnés du libre, j'ai des tonnes de projets :) Le plus important étant le convecteur temporel de ma DeLorean.
21. Les deux dernières questions ont essentiellement pour but de mettre de l’animation dans les commentaires : quels distribution et environnement graphique utilises‐tu ?
Fedora et GNOME. Je suis assis à côté des gnomeux comme je dis, ils sont plus nombreux et certains plus grands que moi ;) J'ai par ailleurs la chance de voir tout le travail que requiert un environnement graphique, et le souci du détail va loin. Après, je comprends que certains paradigmes choquent et dérangent. L'humain est un animal qui aime trop ses habitudes, qui se complaît trop dans la routine et se braque facilement contre le changement. C'est difficile d'aller contre ça et peut-être pas nécessaire. Mais dans tous les cas, je connais la passion et l'énergie qu'ils mettent dans leur travail. Je leur en suis profondément reconnaissant. Ils me facilitent la vie plus de fois qu'ils ne m'énervent, mais on fait moins attention aux choses qui marchent qu'à celles qui nous dérangent.
J'ai envie de dire Captain Obvious tu sais ce qu'il te reste à affronter !
Pour ceux qui répondront qu'il faut des logiciels et une interface intuitifs, je répondrai que l'intuition de tout humain est avant tout la somme de ses expériences. Par conséquent, pour que cela soit intuitif il faut que cela ressemble à une expérience déjà familière.
22. Ton avis sur la pile graphique de GNU/Linux et ses récentes évolutions (Wayland, Mir, mais pas que) ?
D'abord, je ne parle ici que pour moi, il ne s'agit que de mon opinion et elle ne reflète pas nécessairement la position de Red Hat.
Enfin sur la question troll, la réponse est Obi-Wan Kenobi ! Sinon je pense que la pile graphique Linux a largement progressé comme je l'ai expliqué plus haut. X reste a mes yeux l'étoile noire qu'il faut détruire ! Plusieurs présentations sur Wayland expliquent bien mieux que je ne le ferais tout cela.
Il y a des aspects que je n'aime pas dans Wayland, comme cette erreur, à mon avis, de ne pas encoder le format précis des surfaces dans le protocole (ARGB565, 8888, …, storage pattern, …). Mais globalement c'est un pas de géant dans la bonne direction en comparaison d'X.
Mir est plus politique me semble t-il. Il n'y a aucune bonne raison technique à Mir si ce n'est le refus d'utiliser une API stable. Je ne nie pas les avantages à l'absence d'API. On peut facilement corriger les choses, les changer. Il me semble que Canonical ne visera une API stable que pour les couches supérieures, c'est à dire l'API de programmation des applications. Les applications ne parleront pas avec Mir directement mais utiliseront un toolkit qui lui, aura une API stable.
C'est d'ailleurs me semble t-il la force d'Android : offrir une API stable pour écrire des applications. Mais dans Android, les couches de base sont bien trop instables, il s'agit souvent d'énormes hacks pour faire marcher un produit, c'est l'horrible mantra du "ship and forget". Bref, le bas niveau change pour un oui ou pour un non et est souvent customisé par les intégrateurs (Samsung, HTC, …).
Mais ce qui importe, c'est que l'API pour programmer une application soit stable. A mon avis, c'est une des raisons de l'échec de Linux sur le desktop. Nous avons une API X stable mais ce n'est pas le niveau auquel une application est écrite. Je ne suis pas un expert sur les toolkits, mais il me semble que leur API/ABI a changé plus souvent que les saisons.
Pour en revenir à Mir, si on admet que l'absence d'API peut être intéressante, je ne crois pas qu'elle était pour autant nécessaire. Enfin, et c'est le point qui me gêne le plus, la CLA de Canonical crée une relation asymétrique qui va à l'encontre du libre. C'est à mon goût une trahison. La pseudo-justification de pouvoir ainsi faire une release fermée pour ne pas faire peur au gentil driver propriétaire ne tient pas. Il aurait été tout aussi simple d'utiliser une licence MIT ou BSD. Mais là encore, il s'agit de pouvoir garder le contrôle et d'être le seul à pouvoir profiter du retour sur investissement. Bref contraire au libre.
Voila je m'arrête là j'ai déjà bien papoté.
Les photes d'orthofrages sont la preuve de l'authenticité de cette interview. C'est mon certificat a moi (NDLA : des fautes ont été débusquées avant publication par les contributeurs à cette dépêche).
Aller plus loin
- Blogue de Jérôme Glisse (518 clics)
- Wiki officiel du projet radeon (107 clics)
- Page Wikipédia du projet radeon (97 clics)
- Page Wikipédia de la pile graphique Linux (101 clics)
# Couscous
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
Tu vis aux états-unis, tu n'as pas peur d'indiquer sur un média indexé par la NSA que tu aimes le couscous ?
[^] # Re: Couscous
Posté par glisse . Évalué à 10.
L'orange me va si bien et j'ai toujours rêvé de visiter Cuba !
# Merci !
Posté par Thom (site web personnel) . Évalué à 10.
Merci pour la dépêche et merci pour l'interview.
Je vraiment envie d'en apprendre plus sur ce travail.
Quelles sont les qualifications requises pour faire du développement de pilote graphique et comment bien se renseigner pour commencer à travailler sur le sujet ?
Faut-il être également extrêmement calé sur le fonctionnement d'une distribution, du noyau linux ?
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Merci !
Posté par glisse . Évalué à 10.
Il faut aimer les maths "basique" (matrices, quaternions, en gros bac+2/3). Avoir un intérêt lié à la 3D, les jeux par exemples, personnellement je ne crois pas pouvoir réusir dans un domaine qui ne m'attirerai pas d'une manière ou d'une autre. Pour commencer je dirais que le mieux c'est de bien comprendre une pipeline 3D et pour cela le mieux c'est d'écrire son propre moteur 3D (software et OpenGL). Ne pas visé d'écrire un moteur comme Crytek mais plutôt un truc simple capable de rendre une scène simple en gouraud, ou avec texture. C'est le minimum pour comprendre les bases. Il existe plusieurs article sur le net qui guide pour l'écriture d'un moteur 3D.
Il est également nécessaire d'avoir des connaissances dans le domaine des compilateurs, connaissance théorique et pratique. Encore une fois rien de tel qu'un petit projet comme implémenter son propre langage (encore une fois un langage simple).
Arrivé là, il faut se mettre a lire le code de mesa, du noyau, … et voire si on arrive à comprendre isolément des bouts de codes. Quand on regarde des projets de cette taille il n'est pas possible de regarder une fonction et toute les fonctions qu'elle appellent ou toutes les fonctions qui l'appellent. Il faut donc arriver à deviner ce que fait chaque fonction à partir de son nom. Tout ça est de plus en plus facile plus on lit le code et mieux on le comprend. Lire du code pour lire du code c'est pas top, aussi je conseille de le faire avec un but précis comme corriger un bug, ou amélioré un truc, par exemple on peut voir un hot spot ou le driver passe du temps et chercher à comprendre pourquoi.
Un autre truc qui permet d'apprendre énormément c'est d'écrire son propre programme qui parle directement au GPU et qui dessine un triangle, dans le monde du libre il y a nouveau demo ou r300 demo ou r600 demo qui donne des exemples de programme complet qui parle au noyau et qui dessine un triangle. Ca permet de comprendre et jouer avec le gpu sans avoir à faire face à tout le code de mesa. C'est a mon avis le moyen le plus rapide pour bien comprendre le GPU qui t'intéresse.
Et il est préférable d'avoir une bonne dose de patience et de ne pas tester sur son ordi, je fais tout par ssh sur l'ordi qui a le GPU sur lequel je travail (trop de reboot, ou de tuage de X).
On peut ne pas avoir une large connaissance du noyau mais il est quand même nécessaire de comprendre des trucs fondamentaux comme ce qu'est la mémoire virtual, les iommu, les page fault, … sans pour autant connaitre le détail de l'implémentation. Il faut connaître de même les principes de bases du fonctionnement d'une distribution, comme marche le boot, qui lance quoi quand et comment.
[^] # Re: Merci !
Posté par R. Danell Olivaw . Évalué à 8.
Oui, merci Jérôme pour la dépêche et surtout pour le travail titanesque accompli sur ces pilotes.
J'en profite que tu sois dans les parages pour te parler du bug https://bugzilla.redhat.com/show_bug.cgi?id=541562 la solution proposé dans le dernier post est fonctionnelle : sur mon pc, j'applique ces commandes à chaque sorti de veille. Est-ce-que la correction sera appliqué "upstream" ?
[^] # Re: Merci !
Posté par glisse . Évalué à 5.
J'ai jeté un oeil, il faudrait que je trouve le même portable pour débugger ca, étant donné que le patch que tu revert est important dans bien des cas. C'est souvent le problème on a pas tout le matériel particulièrement pour les portables. Après un vieux GPU comme celui la est considéré moins important et ca finis en bas de la pile de bugs à regarder.
[^] # Re: Merci !
Posté par R. Danell Olivaw . Évalué à 2.
Merci pour la réponse,
Par contre ce n'est pas moi qui est posté, j'utilise cette solution chez moi car je suis sujet à ce bug ; je n'y connais pas grand chose en programmation et je comprend pas ce que fait le patch. J'utilise archlinux, je n'ai pas touché au noyau, et la manip fonctionne.
Jusqu'au moi de mai, j'avais purement et simplement désactivé la mise en veille, grâce à la solution de dennisn, je peux me servir du portable de façon plus complète (suspend to ram fonctionnel).
# Le fil des fôtes
Posté par Zarmakuizz (site web personnel) . Évalué à 5.
Je propose de corriger volontairement les fôtes volontaires :
a
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Le fil des fôtes
Posté par lendemain . Évalué à 3. Dernière modification le 26 août 2013 à 22:59.
Une autre erreur, on ne dit pas "DeLorean" mais "De/Lorean" merci.
Richard.
# comment faire ?
Posté par nonas . Évalué à 4. Dernière modification le 26 août 2013 à 23:02.
Concrètement, comment faut-il faire ? Existe-t-il des outils ou des procédures existantes ?
Merci pour cet entretien fort intéressant :)
[^] # Re: comment faire ?
Posté par glisse . Évalué à 10.
Faut avoir un bon éditeur hexadécimal, savoir utiliser google (de maniére un peu avancé), dépoussiérer ses bouquins de maths sur les probabilités, aller regarder la gueule d'un micro-code d'un truc connue genre un truc comme PIC. Savoir ce que veut dire instruction encoding et regarder des exemples.
A partir de là faut trouver le max d'info publique sur le net, taille des registres, fixed size instruction word, taille des instructions word, … les reviews un peu poussé fait par les sites de gamer ont pas mal d'infos.
Il faut ensuite regarder le truc en hexadecimal, genre tu sais que le packed 0xAD sert à écrire le register 0x1034 bah tu cherche en hexa les occurences de AD et parmis elles tu cherches celle ou tu vois 0x1034 pas loin c'est alors très probablement le code qui t'interesse. Après c'est utiliser les probas, tu sais que l'instruction la plus commune c'est mov, et tu sais la taille des instruction donc tu fais une recherche d'un word qui est le plus répété et partir de la tu te dis que c'est mov. Apres le plus courrant ca doit etre ADD, puis SUB, ou SHL, … bref faut deviner beaucoup et plus tu regardes plus tu penses comprendre et plus tu penses comprendre plus tu peux voir si ce que tu penses comprendre pour une fonction à un endroit te permet de comprendre une autre fonction à un autre endroit si c'est le cas c'est probablement que tu as bien deviner.
Il me semble qu'un des types de nouveau a fait des posts de blogues sur le reverse engineering des firmware nvidia. C'est le même principe.
[^] # Re: comment faire ?
Posté par Martin Peres (site web personnel) . Évalué à 10.
J'allais le dire :D https://reblog.0x04.net/
[^] # Re: comment faire ?
Posté par eingousef . Évalué à 3.
Et tu n'aimerais pas par exemple voir AMD publier les specs pour ces firmwares ?
Parce que là AMD ça fait vraiment : "On aime bien le libre mais bon pas trop quand même faut pas déconner."
Même remarque sur le fait que les specs sont publiés après le lancement du GPU (chez Intel ils les publient avant, nan ?).
Autre question : Ce que les gens de Coreboot appellent le "VGA BIOS", c'est la même chose que le firmware ou c'est complètement différent ? Parce qu'il me semble que là aussi AMD ne joue pas le jeu…
Pour les firmwares NVidia j'étais pas au courant. Les gens qui ont un GPU NVidia doivent installer un firmware proprio en plus du driver ? Quand on utilise nouveau on utilise forcément le firmware libre ou c'est un projet à part ?
*splash!*
[^] # Re: comment faire ?
Posté par antistress (site web personnel) . Évalué à 10.
Je ne réponds pas à ta question mais signale que Intel est une grande boite et qu'il n'y a pas une politique mais des politiques. Certaines sont pro open source (la partie graphique), d'autres pas du tout - cf ses chipsets : Intel ne fournit pas la documentation qui permettrait à Coreboot de fonctionner sur du matériel Intel sans blobs, contrairement à AMD pour le coup http://blogs.coreboot.org/blog/2011/05/06/amd-commits-to-coreboot/ )
[^] # Re: comment faire ?
Posté par eingousef . Évalué à 1.
J'ai pas vu de VGA BIOS libre pour AMD pour le moment, il faut encore patcher coreboot avec le VGA BIOS proprio (qu'on extrait du BIOS du vendeur).
Par contre pour Intel :
*splash!*
[^] # Re: comment faire ?
Posté par Renault (site web personnel) . Évalué à 3.
Si je ne me plante pas, Intel ne fournit que des pilotes et non des specs.
Cela est bien car c'est fonctionnel, le soucis qui a déjà été soulevé c'est que Intel contrôle le pilote et que globalement très peu de personnes sauraient exploiter les pilotes pour en tirer des informations sur leurs puces graphiques ce qui limite la correction de bogues éventuels mais aussi des optimisations extérieures…
Et qu'en gros, quand les développeurs Intel se retireront, les bouts de codes qu'ils ont pondu seront non maintenus ce qui pose soucis pour les cartes anciennes.
[^] # Re: comment faire ?
Posté par antistress (site web personnel) . Évalué à 10.
Intel fournit une doc abondante au contraire https://01.org/linuxgraphics/documentation
[^] # Re: comment faire ?
Posté par Martin Peres (site web personnel) . Évalué à 10.
Tu sais, ça fait autant chier les devs AMD que toi cette situation. Franchement, AMD fait un boulot excellent. Reverser un micro code, c'est long et laborieux mais ça n'a aucune mesure avec le développement d'un driver complet. Si cette situation te gène, considère ça comme un bon moyen de commencer à bosser sur ce projet.
Tu dois parler du VBIOS. Non, ce bios n'est pas libre non plus. Il est inclu par le fabriquant du matériel dans la carte à sa fabrication. Pareil pour NVIDIA/nouveau.
Non, on reverse et on ré-écrit la plupart de nos microcodes (exception faite de ceux pour le décodage vidéo car ils sont pas essentiels et personne est vraiment motivé pour l'instant).
Oui, tu utilises des microcodes libres, ils sont écrit en dur dans le code donc tu les vois pas.
[^] # Re: comment faire ?
Posté par eingousef . Évalué à 2.
Est-ce que c'est celui-là dont on parle ici : http://www.phoronix.com/scan.php?page=news_item&px=MTQyMTg ? (lien sourceforge : http://sourceforge.net/projects/openradeonbios/ )
Cool.
*splash!*
[^] # Re: comment faire ?
Posté par jihele . Évalué à 3.
Donc les microcodes propriétaires de décodage vidéo ne sont ni réécrits en libre, ni embarqués dans le code (puisque non libres). Il n'y a pas de décodage vidéo du tout ? C'est le CPU qui gère et on n'exploite pas le bloc matériel dédié ?
[^] # Re: comment faire ?
Posté par Martin Peres (site web personnel) . Évalué à 8.
Exact.
Pas de décodage vidéo sans microcodes sur les cartes modernes, en effet. Seul le redimensionnement et quelques effets de lissage sont gérés (via XV) dans ce cas.
Si tu veux en savoir plus, j'ai mieux expliqué la situation dans la dépêche "Linux pour Workgroups 3.11" qui devrait paraître à la fin de la semaine, à la sortie de Linux 3.11.
[^] # Re: comment faire ?
Posté par glisse . Évalué à 10.
Martin a déjà répondu en partie. AMD n'est pas aussi gros qu'Intel et Intel publie assez tard les spécifications de ses GPU (plusieurs moi après la sortie du code de mémoire). AMD a des choix à faire et le coût et risque lié à la libération du firmware est probablement considéré trop élevé par rapport au retour en effet seul des distributions comme debian refuse de packager par défault les firmwares. Donc du point de vue d'AMD ça n'est probablement pas viable économiquement (ça reste une boite qui considére ses bénéfices). Biensur j'aimerai qui libère cela mais je reste réaliste.
Le VGA bios c'est différent de ces firmware, cela étant dis il est beaucoup plus facile de faire un VGA bios libre pour carte radeon. En effet les radeon utilise l'atombios ce qui correspond en gros en un langage interpreté avec des structures de données propre à chaque intégrateur et qui varie même pour un intégrateur (dans les table atombios tu trouves par exemples les fréquences des chips mémoire utilisé et celà varie en fonction du fondeur de mémoire). Bref pour le vga bios suffis d'écrire un atombios interpréteur en asm voir même en c et compiler ca pour du i386. Et pour coreboot la dernière fois que j'ai regardé AMD participe beaucoup plus qu'Intel.
[^] # Re: comment faire ?
Posté par barmic . Évalué à 7.
Pour ceux qui veulent en savoir plus, l'analyse fréquentielle est une technique basique de cryptanalyse.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Merci
Posté par O'neam Anne . Évalué à 6.
Il y a 3/6 mois (je ne sais même plus exactement), quand j'avais essayé de jouer à Shank 2, jeu récupéré via le Humble Indie Bundle, ça ne marchait pas (ou ça n'était pas jouable j'ai aussi oublié). Il n'y a pas longtemps, j'ai retesté : maintenant ça marche bien dès qu'on désactive les options graphiques trop gourmandes !
Il y a longtemps, j'ai eu le même genre de bonnes surprises avec Aquaria !
Bref, merci énormément pour l'amélioration continue des pilotes. Et un jour, je re-testerai même de mettre mon portable en veille !
(J'ai peut-être tort d'accuser un problème avec la carte graphique quand mon ordinateur refuse de sortir de veille, mais j'ai cru comprendre que c'était souvent la carte graphique qui posait problème…)
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Merci
Posté par xcomcmdr . Évalué à 1. Dernière modification le 27 août 2013 à 09:47.
Chez moi Aquaria (qui est pourtant un jeu 2D) ne passe pas les animations (vidéos) 2D d'introduction avec nouveau sur ma GeForce 9300M GS.
Je trouve cela étrange, alors que Darkplaces et ScummVM fonctionnent bien.
Dans le même genre, FTL (2D) ne passe pas le stade du menu principal.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Merci
Posté par O'neam Anne . Évalué à 3.
Je ne sus pas excessivement étonné par les disparités, j'ai aussi un paquet de jeu 2D qui ne marchent pas du tout ou qui rament au point d'être injouable.
Le plus drôle, c'est sans doute Closure : quand je crée une partie, mon personnage tombe à travers le sol, et est donc renvoyé au point d'apparition, où il recommence à tomber à travers le sol, dans une boucle infinie :P. C'est parce que c'est la carte graphique qui est censée calculer s'il y a assez de lumière pour que les objets soient tangibles ou pas, et que manifestement elle ne le fait pas correctement !
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Merci
Posté par Tonton Benoit . Évalué à 3.
Chez moi Aquaria a toujours marché avec nouveau, donc soit ça vient de ton modèle de carte soit du packaging de nouveau dans ta distrib.
[^] # Re: Merci
Posté par Moonz . Évalué à 6.
La même :)
Je viens d’acheter pour la première fois un portable équipé d’une Radeon, et j’ai été très agréablement surpris des capacités du driver libre. Un grand merci à tous ceux qui participent et ont participé à ce projet !
[^] # Re: Merci
Posté par Creak . Évalué à 1.
J'ai un PC avec une Radeon HD7000-qqch et je met mon ordinateur en veille tous les jours.
J'étais réticent, mais maintenant je ne vois plus trop d'intérêt à éteindre mon PC (hormis lors d'une update de kernel).
[^] # Re: Merci
Posté par O'neam Anne . Évalué à 3.
Ce n'est pas parce que ça marche avec un modèle que ça va marcher avec un autre, hein. Si ça marchait, j'utiliserai aussi la mise en veille avec plaisir, mais je n'ai pour le moment jamais réussi à faire que ça marche.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
# Représentation intermédiaire
Posté par med . Évalué à 5.
Est-ce que tu peux nous en dire plus sur cette représentation intermédiaire ? Il y a des travaux pour avancer de ce côté là ? À ce propos, qu'est-ce qu'il manque aux pilotes libres (et radeon en particulier puisque j'ai une HD5750) pour atteindre les performances des pilotes proprios ? J'ai lu un « article » récemment sur phoronix (pas taper ! pas taper !) suggérant qu'une partie non négligeable du différentiel pourrait être dû à l'optimisation des shaders.
Au final, quels progrès en quelques années. Il y a 5 ans je n'aurais pas osé rêver pouvoir jouer à des jeux modernes de façon fluide avec des pilotes libres. Je ne sais si je dois de remercier ou te maudire pour les heures englouties à jouer à Crusader Kings II ou Europa Universalis IV. :)
[^] # Re: Représentation intermédiaire
Posté par glisse . Évalué à 10.
Je ne crois pas que qui que ce soit travaille sur ça en se moment. Ce qui manque point de vue performance c'est un meilleur compilateur pour les shaders (mais c'est déjà en partie là avec SB) et meilleur gestionnaire de mémoire avec a on devrait pouvoir aprocher les 80/90% des performances du driver propriétaire pour tout les cas (on arrive déjà a ce genre de résultat pour certain jeux). Après c'est plein de petite optimisation à droite à gauche si tu veux grapiller les 20% restant.
[^] # Re: Représentation intermédiaire
Posté par antistress (site web personnel) . Évalué à 7.
Du coup, si les performances sont si proches malgré la petite taille de l'équipe dédiée au driver libre, pourquoi faut-il "plusieurs centaines sur le driver propriétaire" ?
[^] # Re: Représentation intermédiaire
Posté par claudex . Évalué à 4.
Vu que le pilote propriétaire est certifié, il doit déjà y avoir une partie de l'équipe qui fait de la QA. Il y a aussi Mesa qui a des parties communes entre les pilotes il me semble et qui permet donc de répartir les tâches.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Représentation intermédiaire
Posté par glisse . Évalué à 5.
Le fait est que les 10% qui resteront c'est ce qui fait la différence pour les acheteurs, ie les gamers sous windows ie 99% des gens qui achétent un GPU. Après, énormément de QA est partagé entre linux et windows sur le driver propriétaire. Si le bug est dans la partie OpenGL alors le bug est à la fois sur windows et sur linux (à moins que celà soit lié à une extension GL spécifique à windows ou linux). Donc tout l'investissement fait dans le driver pour windows sert aussi dans le driver pour linux.
[^] # Re: Représentation intermédiaire
Posté par coïn . Évalué à -3.
parce qu'il y en a un qui invente, et l'autre qui copie.
[^] # Re: Représentation intermédiaire
Posté par bubar🦥 (Mastodon) . Évalué à 3.
[:trop gros passera pas]
# Radeon Mobilty
Posté par taupette . Évalué à 2.
Bonjour,
La série des Radeon Mobility avec deux GPU (INTEL et AMD) (Radeon mobility 5470 pour ma part) pose toujours autant de problème à l'installation des distributions (écran noir) sur Laptop . Le problème des doubles cartes semble avoir enfin été réglé chez NVIDIA mais malheureusement, un nombre (que je pense majoritaire) de personnes achète maintenant des Laptop ce qui rend (avec d'autre soucis comme UEFI), l'expérience Linux insurmontable à cause d'une primo installation impossible pour les novices. (Les très nombreux forums et utilisateurs malheureux sur le net à ce sujet en témoignent) Existe t il un développeur qui se penche sur ce problème peut être pas si difficile à résoudre techniquement mais tellement bloquant pour le déploiement de Linux tant ces cartes sont nombreuses…
[^] # Re: Radeon Mobilty
Posté par Albert_ . Évalué à 2.
Je ne sais pas si c'est encore le cas mais dans le BIOS tu as une option normalement pour dire quelle carte tu veux utiliser (ou les deux). Sur mon laptop, vu que je ne joue pas et que la carte radeon chauffe (c'est pire sous linux mais c'est deja pas tres beau sous windows…), j'ai configure la care intel et ca me va tres bien.
[^] # Re: Radeon Mobilty
Posté par Olivier Esver (site web personnel) . Évalué à 2.
Ce que tu évoques me semble être la techno AMD Dynamic Switchable Graphics, donc la question 14 non ?
Mais comme le dit Albert_, je te conseille de regarder dans ton BIOS en attendant.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Radeon Mobilty
Posté par glisse . Évalué à 10.
Comme je le disais c'est une question de certification de matérielle les constructeurs se fichent éperduement de linux et quand il font certifier un matériel ca n'est jamais un laptop avec du hybride graphique. Donc il y a probablement très peux de développeur qui ont ce genre de matériel (moi j'en ai pas et je suis presque sur que personne dans les devs n'a de laptop hybride intel, radeon). Je conseille de fuire comme la peste ce genre de matériel. Après il y a des travaux pour supporter ca mais en général on s'intéresse a des combinaisons NVidia/Intel ou AMD/AMD. Enfin je conseille de tester fedora 19 qui a un certain nombre des derniers trucs pour ce genre de support.
# Excellent article!
Posté par Benoit Jacob (site web personnel) . Évalué à 10.
J'ai appris beaucoup de choses, je fais circuler auprès de mes collègues de l'équipe Graphiques à Mozilla!
# Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par Benoit Jacob (site web personnel) . Évalué à 7. Dernière modification le 28 août 2013 à 13:30.
Merci pour tes commentaires sur X, Wayland et Mir.
Et dans tout ça que penses-tu de la couche graphique d'Android? C'est à dire SurfaceFlinger, avec les abstractions SurfaceTexture (implémentant EGLSurface) et GraphicBuffer (représentant un unique tampon graphique)?
En tant que naïf développeur d'applications, j'aime beaucoup, parce que ce sont un très petit nombre de classes C++ avec un API agréable, une sémantique bien définie(*), la capacité de gérer tous les cas (dans Android 4, toutes les choses qui arrivent sur l'écran sont des SurfaceTexture, y compris les vidéos, la prévisualisation de la camera, les scènes rendues par OpenGL…) et cerise sur le gâteau, les concepts sous-jacents sont portables/standardisés dans EGL.
(*) oui, je sais qu'initialement la sémantique du verrouillage des tampons graphiques (GraphicBuffer) dépendait du pilote de la puce graphique. Mais ça a été résolu dans Android 4.2.
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par antistress (site web personnel) . Évalué à 5.
Et aussi : que penses-tu de la proposition de NVIDIA de revoir l'ABI OpenGL de Linux il me semble (source : http://www.phoronix.com/scan.php?page=news_item&px=MTE4NDA)
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par antistress (site web personnel) . Évalué à 5.
À ce sujet, d'ailleurs, tout frais pondu : http://www.phoronix.com/scan.php?page=news_item&px=MTQ0NzU
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par ariasuni . Évalué à 1.
Je suppose qu'avec ça ça sera plus facile de bidouiller des trucs comme Optimus, non? Et je pense que ça va bien simplifier la vie de ceux qui naviguent régulièrement entre le pilote libre et le non-libre (les deux pourront être installés en même temps, car plus de conflit entre la libGL et celle de Nvidia).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par Martin Peres (site web personnel) . Évalué à 1.
Oui, mais je sens venir la tonne d'utilisateurs pas content qui ne comprendront pas pourquoi utiliser le module nvidia avec xf86-video-nouveau ne marche pas! Cela dit, j'attend quand même ça avec impatience!
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par ariasuni . Évalué à 1.
Moi-même j'ai galéré plusieurs heures avant de me rappeler que je construisais l'image du noyau avec le module nouveau inclut…
Dans tous les cas ça sera beaucoup plus simple! Au revoir les scripts bizarres pour changer de pilote!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par glisse . Évalué à 3.
Oui c'est une proposition très pratique même si les premiers bénéficiare sont les drivers propriétaire.
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par glisse . Évalué à 4.
Primo je déteste C++. Cela étant dis, oui l'API de surfaceflinger est simple (point de vue graphique) bien plus simple que X. Mais c'est précisement pour cela que wayland est séduisant, l'API wayland est aussi simple que celui de surface flinger. Il est très facile de faire un binding pour wayland qui soit le jumeau de surfaceflinger. Après comme c'est unix des choses comme avoir la preview camera directement dans une surface wayland n'est pas encore possible, il s'agit la d'un problème noyau. En effet avec dmabuf une fois que les drivers camera ou autre seront capable d'exporter un dmabuf on pourra alors directement l'utiliser comme une surface wayland. Donc on se dirige vers un API similaire.
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Merci pour ta réponse.
Juste une chose, quand sous Android on a la Camera Preview dans une SurfaceTexture, ce n'est quand même pas exactement en temps réel un tampon DMA directement lié à la Camera, n'est-ce pas? Si c'était le cas, on lirait des images où certains pixels sont plus récents que d'autres… Je crois plutôt que la SurfaceTexture reçoit des images complètes l'une après l'autre, qui sont donc des copies de ce que la Camera a fourni à un moment donné. SurfaceTexture se comporte donc comme un EGLStream, un flux d'images. Il y a deux degrés de liberté, le nombre d'images dans le flux (par exemple 2 pour du double-buffering, et généralement une dizaine pour un flux video) et un booléen qui dit si au cas où le côté producteur aurait produit plusieurs images en avance, on doit utiliser la plus récente ou la plus ancienne. Avec ces degrés de liberté, SurfaceTexture couvre tous les besoins d'Android. J'ai hâte de voir une solution équivalente (une implémentation de EGLStream / EGLSurface utilisée partout, e.g. pour la camera) sur les bureaux libres!
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par glisse . Évalué à 2.
dma-buf + sync/fence (dont le design est toujours en discussion) c'est ce qui permettra d'avoir un snapshot cohérent de la camera à un moment donné. Après le support plus fin d'EGLStream pourra se faire en userspace (utiliser dernier snapshot, nombre de snapshot en vole, …).
# Parfait. Les questions comme les réponses.
Posté par Loïc Ibanez . Évalué à 6.
Sauf que je préfère l'option "faire pression économique sur AMD" pour obtenir le retrait des firmwares que l'option rétro-ingénierie des firmwares.
La question 13 en particulier me semble plus lourde de conséquence que les débats Xorg/Mir/Wayland. J'aimerais un jour comprendre pourquoi il faut un SDK par marque (intel, AMD, Nvidia) pour compiler un programme OPENCL alors que c'est un standard approuvé par toutes ces marques !!!! °_° !!!!! TONNERRE DE BREST !
[^] # Re: Parfait. Les questions comme les réponses.
Posté par Martin Peres (site web personnel) . Évalué à 10.
Pfff, comme si ils avaient le choix … à moins que tu acceptes de perdre toute accélération graphique! Les avocats d'AMD doivent empêcher la libération pour une bonne raison. La seule solution acceptable est donc la rétro-ingénierie. C'est trop facile de rester dans son fauteuil et dire qu'une entreprise est pas assez libre…
Simplement parce que le standard est sur l'interface, pas sur l'implémentation. Dois-je te rappeler que chaque chipset a sa façon de travailler, son langage? Oui on peut factoriser du code (Gallium), mais au final, les implémentations vont forcement différer à un moment. Tu as vision trop logicielle du problème, on parle de compilateur et de driver là.
[^] # Re: Parfait. Les questions comme les réponses.
Posté par eingousef . Évalué à 5.
Alors j'y connais rien et je ne sais pas vraiment ce qu'on peut mettre ou pas dans un firmware, mais justement ce serait possible de faire un firmware qui s'occupe uniquement de l'accélération video-mp4-divx-h264-toutcequiestbreveté (les trucs dont on se fout, quoi) ?
Parce que là actuellement sur trois GPU AMD que j'ai testé :
ces problèmes disparaissent une fois qu'on installe le firmware nonfree. Donc ça veut dire que le firmware s'occupe un peu plus que d'accélération vidéo nan ?
*splash!*
[^] # Re: Parfait. Les questions comme les réponses.
Posté par Martin Peres (site web personnel) . Évalué à 5.
Oui, les microcodes sont nécessaires. C'est une bonne chose qu'il y ait des microcodes, mais par contre faudrait qu'ils soient libres. D'où le besoin de reverse engineering!
[^] # Re: Parfait. Les questions comme les réponses.
Posté par Loïc Ibanez . Évalué à 2.
Je sais, et c'est ce que j'ai du mal à accepter. Je m'explique : à l'image de VESA 2.0 je pense que tous les chipsets devraient avoir une partie "commune" qui permettrait d'implémenter les standards avec des circuits identiques. Et une partie "propriétaire" qui contiendrait des fonctions supplémentaires dont l'accès serait réservé aux développeurs d'entreprises sous licence. Il y aura toujours un marché pour la carte qui permet de gagner 10 fps sur le dernier jeu blockbuster sorti.
Parce que là, si je comprends bien la situation, en imaginant que l'on reprogramme un moteur de rendu comme PovRay en OpenCL, il faudrait le compiler 3 fois, une fois pour chaque fabriquant…
Quel progrès technique franchement… j'ai l'impression de revenir à l'avant IBM PC…. :-/
[^] # Re: Parfait. Les questions comme les réponses.
Posté par Martin Peres (site web personnel) . Évalué à 10.
La compilation est faite par le driver, c'est caché pour le développeur d'applications. C'est la même chose pour les shaders en opengl.
# Bravo Jérôme Glisse!
Posté par Creak . Évalué à 8.
Juste pour te dire que j'admire ta philosophie! La curiosité avant tout, ne pas se braquer juste à cause d'un petit changement, adopter le libre et ne pas tomber dans le pragmatisme économique. Chapeau l'artiste!
# drivers graphiques
Posté par nazcafan . Évalué à 3.
Cher Jérôme,
Une question qui me taraude depuis un moment et à laquelle tu devrais pouvoir répondre : l'architecture de Wayland permettra-t-elle de se passer de la couche pilote userspace (type xf86-video-intel) que l'on connait avec X ? Si oui, pourquoi ?
Merci de m'éclairer là dessus, car malgré la page wikipedia de l'article, j'ai l'impression que ma compréhension est bien parcellaire
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . Évalué à 10. Dernière modification le 01 septembre 2013 à 02:20.
Oui car toutes les opérations nécessaires pour allouer un contexte graphique et gérer des buffers graphique a été standardisé, c'est EGL. Avec ça, les applications peuvent utiliser le GPU pour faire du rendu (via OpenGL/VG ou toute autre API) et partager ses buffers graphiques avec un compositeur wayland.
C'est implémenté dans mesa pour intel, radeon et nouveau.
Cela dit, y'a plein de façon de communiquer avec un compositeur wayland, celle là est simplement la plus optimale (tout sur le GPU).
[^] # Re: drivers graphiques
Posté par cedric . Évalué à 5.
Pour une certaine definition de optimale ;-) Pour certain cas d'utilisation, tel que editer du code dans un editeur texte quand on est sure batterie, le fait d'utiliser OpenGL pour faire le compositing au lieu du CPU augmente sensiblement la consomation de batterie (Je perds 1W, ce qui represente sur mon PC 1h d'autonomie).
Il est probable qu'avec le support du buffer age et de la mise a jour partiel dans Wayland, ces chiffres ne soit plus les meme. Mais pour l'instant, avec X, quand je suis sur batterie, j'evite d'utiliser OpenGL.
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . Évalué à 6.
C'est étonnant et contraire à mon expérience. Mais c'est possible que si très peu de choses sont modifiées à l'écran, le CPU peut être plus efficace. C'est quelque chose que je le driver devrait prendre en compte!
Tu utilises quoi comme pilote?
[^] # Re: drivers graphiques
Posté par cedric . Évalué à 4.
Un driver Intel Ivy Bridge sur Arch Linux. Quand tu edites du texte, en general, il n'y a que le curseur qui clignote pas bien vite et un peu de texte qui s'ajoute pas bien vite aussi. Alors forcement le software a un enorme avantage :-) Aussi j'utilise le compositeur software d'enlightenment compile specialement pour mon pc. Le tout tester avec PowerTop et c'est reproductible.
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . Évalué à 4.
Hmm, bizarre, c'est exactement le même matériel que toi et mes résultats sont presque inverses, même en idle.
[^] # Re: drivers graphiques
Posté par cedric . Évalué à 5.
Quel est ta version de noyau et driver ? Tu utilises quoi comme composite manager et avec quelle version ?
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . Évalué à 4.
Quand j'ai regardé, j'utilisais linux 3.10 / mesa 9.1 et KDE/kwin. Je suis sur Arch.
[^] # Re: drivers graphiques
Posté par cedric . Évalué à 4.
Hum, je ne savais pas qu'il y avait un compositeur software dans KWin.
Le compositeur software de Enlightenment est en fait le backend software de la bibliotheque de rendu Evas. Celle-ci est en charge de faire l'abstraction complete du backend et Enlightenment ne fait rien de particulier pour utiliser le GPU. Le backend software en question ne fait appel a aucune bibliotheque externe pour les operations de rendu. Ce qui implique que les resultats d'Enlightenment ne sont lie que a Enlightenment et n'engage que cette solution :-)
Il est a note que Samsung qui sponsorise le projet, est tres interesse pour avoir la plus faible consomation batterie et memoire. Ca en devient des fois un peu excessif, mais ca peu expliquer les differences avec d'autres projets :-)
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . Évalué à 4.
Oh, j'avais zappé que tu avais marqué "compositeur software". Forcement que la conso augmente!
Tu sais que enlightenment supporte aussi la composition opengl? Pourquoi tu actives la composition software?
[^] # Re: drivers graphiques
Posté par cedric . Évalué à 6.
Non, non, tu as inverse ce que je dis ! La composition software consomme moins de batterie lorsque j'edite juste du code que la composition OpenGL. Ce qui est logique si le GPU n'est pas capable de faire des mise a jour partiel de l'ecran (limitation du driver plutot que du hardware). Le compositeur OpenGL est oblige de faire une mise a jour complete de l'ecran, alors que le compositeur software va juste rafraichir le curseur qui clignote et quelques pixels a gauche et a droite pour le contenu qui a change. Il y a clairement un avantage indeniable au logiciel dans cette situation.
Wayland avec un driver Intel permet de faire de la mise a jour partiel, si je ne me trompes pas. Mais je n'ai pas encore eu le temps de tester (J'attend surtout l'integration du support KMS/DRM dans Enlightenment pour pouvoir le tester). D'ailleur quel est le status des extention GLX_EXT_buffer_age et eglSwapBuffersWithDamage avec le driver radeon ? C'est vraiment l'extention qui change les choses dans ce que fais un compositeur. Et si tu veux tester, Enlightenment les detecte et utilise directement out of the box ;-) D'ailleur toutes les applications bases sur les EFL les utiliseront automatiquement si elles sont disponible !
# merci.
Posté par Selso (site web personnel) . Évalué à 4.
Mais vous cette interview, elle répond à pleins de questions que l'on ne s'est jamais posées :). Ou dois-je envoyer la barquette de roses ? :D
[^] # Re: merci.
Posté par glisse . Évalué à 7.
Tu as mal lu la première réponse ! Faut m'envoyer des bonnes fraises bio (1 tonne devrait me permettre de tenir 1 semaine), et des bons croissants 2000% beurre !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.