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 !
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, …).
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.
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.
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.
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.
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.
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.
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.
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.
Non le GPU n'est pas de chez Intel, enfin pas totalement, la partie controleur video est intel mais la partie acceleration 3D c'est PowerVR aka SGX aka closed source aka marche pas aka no driver for linux.
Mais oui tu as un driver kms pour le modesetting. Tout en software quoi.
Non le pilote libre le plus avancé sur arm c'est freedreno, tu peux lancer gnome-shell, quake, … avec la libGL normale. Pour le moment autant que je sache lima n'offre pas de support GL seulement des hacks pour tester leur developement. Le deuxiéme plus avancé est probablement pour les gpu vivante (encore une fois sur ARM) et enfin lima. Voila mon classement.
Pour le décodage video il faudrait savoir de qu'elle chip il s'agit, celui d'ARM aussi ? (mali c'est le block 3d et rien d'autre à moins que arm recycle ses noms de produits).
Et donc ne tombe pas encore en concurrence avec wayland car les perfs de wayland en embarqué sont lamentables.
Belle déclaration péremptoir, non wayland n'a pas des performances lamentables montrent moi un benchmark une étude qui dise ça. Pour preuve du contraire regarde la technologie démo de wayland sur raspberry pi. Et wayland est bien plus efficace que X ne le pourra jamais être sur les plateformes embarquées (utilisation des overlayer|layer par exemple).
Si un patch corrige une fail de sécurité alors il sera inclus upstream et toutes les autres distributions vont également l'inclure. Ce n'est pas un travail gigantesque, oui il faut des gens qui s'y connaissent. Mais c'est tout à fait réalisable pour un état et encore une fois ubuntu et mandriva sont des exemples pertinant, ils font/faisait du back porting de patch de sécurité et autre.
Et LiMux fait également du back porting de patch de sécurité je me souviens avoir vus un de leur ingénieur trainer sur des listes de sécurité.
Donc la ville de Munich (LiMux) est plus puissante que la Chine selon toi ! :)
Plus sérieusement tu surestimes le coup de supporter sa propre distribution linux, mandriva le faissait très bien, c'est tout à fait accessible à un état. Je ne parle pas d'écrire un OS from scratch mais de forker une distribution linux et d'en faire le support ainsi que l'audit.
Ensuite les chinois utilisent beaucoup plus que tu ne le pensent leur propres systèmes, oui le citoyen normale enlève l'os officiel et switch sur du win xp.
Et pour un ordre d'idée je dirais que pour un bon support tu as besoins de 300 ingénieurs, c'est pas la mer à boire, et tu peux en trouver facilement (encore une fois mandriva, ubuntu, …).
AMD a ouvert le decodage video recement, ca s'appelle uvd. Il vienne de release le power management, il n'y a donc plus que les block crypto, perf counter et debug qui sont garde secret mais je ne vois pas d'interet de les connaitre pour faire un driver.
Et la grosse difference entre el driver open source et closed source c'est d'un cote 7-8 gus qui bossent dessus et de l'autre 1000 ingenieurs. Forcement y a un groupe qui va plus vite et qui a plus de temps pour ameliorer les perfs et autre.
Grub de part sa license semble incompatible avec l'idee d'une console de jeux qui ne bootera que l'os reconnu et signe de sony. A mon avis c'est grub seulement sur la platforme de development pour simplifier la vie de sony et de ses partenaires. La version retail utilisera son propre boot loader avec signature de la mere Denis pour booter seulement le truc de sony.
Bon apres si c'est grub et qu'on peut donc install linux, moi je m'en commande une, un pc avec de la gddr5 voila un truc qui a de la gueule pour un geek.
GPU efficiency 62% / 73% donc bien superieur a 50%, mais oui inferieur au 99% d'efficiency d'un cpu pour ce type de problemes. Mais pour d'autre probleme comme navier-strokes les gpu avec un bon algo atteigne une efficiency > 90% quand on sait que le peak gflops d'un gpu est largement superieur a celui d'un cpu alors on comprend tout l'interet qu'ils ont.
Et de plus ici on parle d'efficiency, donc si tu as un gpu qui atteind 50% mais qui a une puissance de calcul theorique deux fois superieur a un cpu alors tu vas aussi vite que le cpu, tu gaspilles juste des resources.
Comme toujours, tout depend de ce que tu compares. J'arrive sans probleme a atteindre 99% de la puissance theorique sur un gpu, il suffit d'un programme qui fait relativement peu de requete memoire et qui fait des calculs tres long sans branchement ou boucle avec suffissament de thread pour saturer l'occupation de toutes les unites de calculs.
Alors on pourra dire que c'est pas le cas de tout les programmes mais c'est justement tout l'interet des gpus, etre tres bon sur une sous classe de probleme particulier. Note que tu peux reecrire beaucoup d'algorithm pour les rendre GPU friendly, il y a des plusieurs ouvrages qui traitent de ces aspects.
Un vieille example avec du code qui montre comment on peut effectivement approcher le peak computation power sur les gpus : http://emmes.livejournal.com/4211.html
Donc non les carte phi sont loin de faire aussi bien que les gpus sur certaines classes de problemes.
Si tu as des articles de gens qui se pleignent je suis interessais pour apprendre de leur erreurs.
Tu crois que tu peux, aujourd'hui, te pointer au dépôt de camions et être opérationnel de suite? Il faut au moins que vous soyez plusieurs, et organisés, formés!
Si on y met des robots, ce sera encore pire: il faudra des gens qualifiés pour palier aux problèmes techniques rencontrés par les robots. Tu es de moins en moins qualifié. Tu es prêt à te consacrer un peu à ça? Non, ton idée c'est tu y vas quand ça te chante.
Tu déformes mes propos, non je me pointe pas la fleur au fusil, je suis prêt à travailler plusieurs mois comme éboueur et à me former. Je considére ca comme un service civique. Je précise d'ailleurs dans mon commentaire que c'est seulement possible de se pointer la fleur au fusil pour les taches qui ne demande pas de formation (est une partie des tâches liés au éboueur rentre dans ce cas).
Pour faire cour, ton point vue c'est que les humains c'est des feignasses qu'il faut contraindre par un modèle esclavagiste (modèle actuel, oui je troll mais sincérement pour moi l'ouvrier chinois ou l'ouvrier malgache c'est un esclave c'est pas un salaire de misère pour la forme qui change la réalité de leur condition). Dans ce modèle certains ont énormement, beaucoup ont peut ou très peut. Tu considére par avance tout autre modèle comme incapable de continuer à produire les objets aujourd'hui produit.
Dans mon cas j'estime que majoritairement les être humains continuerai à travailler, de manière plus raisonnable et que l'ingéniosité permettra de continuer à produire l'ensemble des choses que nous produisont. Je l'ai dit dès le début de mon commentaire que j'étais optimiste. J'ai également précisé qu'il ne faut pas projeter le modèle dans lequel on est avec le RU, qu'il faut un changement de société qui l'accompagne.
Ton pésimisme te pouse à t'enfermer dans un modèle de société profondément injuste. Tu serais milliardaire je comprendrai que tu défendes le système actuelle mais je doute que ta fortune soit si importante (des millardaires sur linuxfr ? :)).
Voila la différence entre toi et moi. Il est inutile de faire une liste de choses que tu penses qui disparaitraient. Tu n'en sais rien et je n'en sait rien. Moi je veux seulement réfléchir et participer à un modèle meilleur, toi tu ne veux prendre aucun risque pour ton propre confort.
Je pense que l'idée que la société avec le RU sera la même (le macdo, les éboueurs, les boulôts de merdes …) est une grave erreur de raisonnement. Je suis certainement idéaliste mais à mon sens avec le RU un grand nombre d'emplois de merdes ne seront plus necessaires adieux macdo et compagnie (pour faire simple je préfère bosser 8h comme éboueur et me faire un bon restaurant avec mon salaire complémentaire au RU que de bosser 1h et me faire un macdo).
A mon avis il y a deux axes qui rendent le RU viable:
Le premier, la flexibilité du travail, y a des poubelles en bas de chez moi et j'en ai marre, je deviens éboueurs pour une demi-journée j'en touche un salaire et j'ai contribué a mon bien être et à celui de mes voisins. Tout plein d'autre emplois non qualifié deviennent soudainement une posibilité pour augmenter son revenu et le partage des tâches ingrates.
Le deuxième, la vrai valeur des biens, ou l'inflation des biens sous évalué. J'estime que le RU remettra les biens de consomations a leur valeur réelle, ca implique évidement une décroissance, finit de changer de meuble ikea pour un oui ou pour un non. Chaque objet superflus sera ainsi le fruit d'un travail. Cela encouragera également le partage et la vie communautaire (potagé publique, mise en commun de resources comme les voitures, ou des outils, …).
La retraite devra également évoluer, elle devrait devenir un revenue complémentaire croissant avec l'âge (ainsi qu'avec les incapacités physique de la personne qu'elle qu'en soit leur origine). Ce revenue complémentaire sera proportionnel au travail qui accomplis au cours de ta vie (en prenant compte la pénibilité).
Ainsi sont récompensés ceux qui dans la force de l'âge contribueront le plus au bien être commun. Enseignant, médecin, infirmier, éboueur, chercheur, service publique en general…
Bien sur il restera des emplois ingrat qui nécessite une formation ou un savoir faire, il devront être justement rémunéré pour rester intéressant. Il y aura également des emplois plus ou moins pénibles mais valorisant je pense notamment à tout les artisans. Ou l'aspect créatif pourra je l'espére reprendre le dessus sur l'aspect purement marchand de leur travail.
Ceux qui préfère s'orienter vers une activité créatrice (artistique ou non comme la création d'entreprise de bien ou de service) pourront profiter des révenus que celle-ci générés.
Je pense donc que le RU implique une nouvelle relation au travail et à la société en général, il est inconcevable pour moi de créer un RU pour continuer dans la société de consommation effréné qui est la notre aujourd'hui.
Et si le résultat c'est du matos informatique qui change moins frénétiquement mais qui à plus de temps pour maturer (et avoir moins de bug) et bien c'est temps mieux, moins de bugs -> plus de temps pour prendre des bières ;)
Bref l'épanouisement de chacun participe a celui de tous …
[^] # Re: merci.
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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 !
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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, …).
[^] # Re: Représentation intermédiaire
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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: Merci !
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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 . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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: Représentation intermédiaire
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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: Radeon Mobilty
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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.
[^] # Re: comment faire ?
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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 glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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: Merci !
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. É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: Couscous
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 10.
L'orange me va si bien et j'ai toujours rêvé de visiter Cuba !
[^] # Re: Plus de détails
Posté par glisse . En réponse à la dépêche OLinuXino, la RaspBerry Pi version Open Source. Évalué à 1.
~150$
http://www.cnx-software.com/2013/04/24/149-inforce-computing-ifc6410-board-features-qualcomm-apq8064-quad-core-cortex-a15-soc/
[^] # Re: singularité de cette carte
Posté par glisse . En réponse au journal Minnow Board. Évalué à 5.
Non le GPU n'est pas de chez Intel, enfin pas totalement, la partie controleur video est intel mais la partie acceleration 3D c'est PowerVR aka SGX aka closed source aka marche pas aka no driver for linux.
Mais oui tu as un driver kms pour le modesetting. Tout en software quoi.
[^] # Re: Plus de détails
Posté par glisse . En réponse à la dépêche OLinuXino, la RaspBerry Pi version Open Source. Évalué à 9.
Non le pilote libre le plus avancé sur arm c'est freedreno, tu peux lancer gnome-shell, quake, … avec la libGL normale. Pour le moment autant que je sache lima n'offre pas de support GL seulement des hacks pour tester leur developement. Le deuxiéme plus avancé est probablement pour les gpu vivante (encore une fois sur ARM) et enfin lima. Voila mon classement.
Pour le décodage video il faudrait savoir de qu'elle chip il s'agit, celui d'ARM aussi ? (mali c'est le block 3d et rien d'autre à moins que arm recycle ses noms de produits).
[^] # Re: Waylands et Mir ?
Posté par glisse . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 8.
Belle déclaration péremptoir, non wayland n'a pas des performances lamentables montrent moi un benchmark une étude qui dise ça. Pour preuve du contraire regarde la technologie démo de wayland sur raspberry pi. Et wayland est bien plus efficace que X ne le pourra jamais être sur les plateformes embarquées (utilisation des overlayer|layer par exemple).
[^] # Re: Bof
Posté par glisse . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 1.
Si un patch corrige une fail de sécurité alors il sera inclus upstream et toutes les autres distributions vont également l'inclure. Ce n'est pas un travail gigantesque, oui il faut des gens qui s'y connaissent. Mais c'est tout à fait réalisable pour un état et encore une fois ubuntu et mandriva sont des exemples pertinant, ils font/faisait du back porting de patch de sécurité et autre.
Et LiMux fait également du back porting de patch de sécurité je me souviens avoir vus un de leur ingénieur trainer sur des listes de sécurité.
[^] # Re: Bof
Posté par glisse . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 2.
Donc la ville de Munich (LiMux) est plus puissante que la Chine selon toi ! :)
Plus sérieusement tu surestimes le coup de supporter sa propre distribution linux, mandriva le faissait très bien, c'est tout à fait accessible à un état. Je ne parle pas d'écrire un OS from scratch mais de forker une distribution linux et d'en faire le support ainsi que l'audit.
Ensuite les chinois utilisent beaucoup plus que tu ne le pensent leur propres systèmes, oui le citoyen normale enlève l'os officiel et switch sur du win xp.
Et pour un ordre d'idée je dirais que pour un bon support tu as besoins de 300 ingénieurs, c'est pas la mer à boire, et tu peux en trouver facilement (encore une fois mandriva, ubuntu, …).
[^] # Re: Pourquoi parler d'intel ...
Posté par glisse . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 4.
AMD a ouvert le decodage video recement, ca s'appelle uvd. Il vienne de release le power management, il n'y a donc plus que les block crypto, perf counter et debug qui sont garde secret mais je ne vois pas d'interet de les connaitre pour faire un driver.
Et la grosse difference entre el driver open source et closed source c'est d'un cote 7-8 gus qui bossent dessus et de l'autre 1000 ingenieurs. Forcement y a un groupe qui va plus vite et qui a plus de temps pour ameliorer les perfs et autre.
[^] # Re: Orbis OS
Posté par glisse . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 7.
Grub de part sa license semble incompatible avec l'idee d'une console de jeux qui ne bootera que l'os reconnu et signe de sony. A mon avis c'est grub seulement sur la platforme de development pour simplifier la vie de sony et de ses partenaires. La version retail utilisera son propre boot loader avec signature de la mere Denis pour booter seulement le truc de sony.
Bon apres si c'est grub et qu'on peut donc install linux, moi je m'en commande une, un pc avec de la gddr5 voila un truc qui a de la gueule pour un geek.
[^] # Re: Dans la série "Tianhe-2 est un monstre"
Posté par glisse . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 5.
Tiens en cherchant un poil
http://hpl-calculator.sourceforge.net/Howto-HPL-GPU.pdf
GPU efficiency 62% / 73% donc bien superieur a 50%, mais oui inferieur au 99% d'efficiency d'un cpu pour ce type de problemes. Mais pour d'autre probleme comme navier-strokes les gpu avec un bon algo atteigne une efficiency > 90% quand on sait que le peak gflops d'un gpu est largement superieur a celui d'un cpu alors on comprend tout l'interet qu'ils ont.
Et de plus ici on parle d'efficiency, donc si tu as un gpu qui atteind 50% mais qui a une puissance de calcul theorique deux fois superieur a un cpu alors tu vas aussi vite que le cpu, tu gaspilles juste des resources.
[^] # Re: Dans la série "Tianhe-2 est un monstre"
Posté par glisse . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 4. Dernière modification le 21 juin 2013 à 01:40.
Il n'y pas que la 3d, certains algo de simulation physique une fois adapte au gpu tourne bien plus vite que sur cpu.
http://www.nvidia.com/object/computational_fluid_dynamics.html
La litterature scientifique commence aussi a s'etoffer sur le sujet, google scholar donne plusieurs articles.
Pour linpack il manque une reecriture des algo pour gpu. Oui faire tourner un code qui marche bien sur cpu est souvent desastreux sur gpu.
[^] # Re: Dans la série "Tianhe-2 est un monstre"
Posté par glisse . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 4.
Comme toujours, tout depend de ce que tu compares. J'arrive sans probleme a atteindre 99% de la puissance theorique sur un gpu, il suffit d'un programme qui fait relativement peu de requete memoire et qui fait des calculs tres long sans branchement ou boucle avec suffissament de thread pour saturer l'occupation de toutes les unites de calculs.
Alors on pourra dire que c'est pas le cas de tout les programmes mais c'est justement tout l'interet des gpus, etre tres bon sur une sous classe de probleme particulier. Note que tu peux reecrire beaucoup d'algorithm pour les rendre GPU friendly, il y a des plusieurs ouvrages qui traitent de ces aspects.
Un vieille example avec du code qui montre comment on peut effectivement approcher le peak computation power sur les gpus :
http://emmes.livejournal.com/4211.html
Donc non les carte phi sont loin de faire aussi bien que les gpus sur certaines classes de problemes.
Si tu as des articles de gens qui se pleignent je suis interessais pour apprendre de leur erreurs.
[^] # Re: Pourquoi se limiter au développement de logiciels libres ?
Posté par glisse . En réponse au journal Et pourquoi pas un status : "Développeur Open Source" financé par l'état ?. Évalué à 4.
Tu déformes mes propos, non je me pointe pas la fleur au fusil, je suis prêt à travailler plusieurs mois comme éboueur et à me former. Je considére ca comme un service civique. Je précise d'ailleurs dans mon commentaire que c'est seulement possible de se pointer la fleur au fusil pour les taches qui ne demande pas de formation (est une partie des tâches liés au éboueur rentre dans ce cas).
Pour faire cour, ton point vue c'est que les humains c'est des feignasses qu'il faut contraindre par un modèle esclavagiste (modèle actuel, oui je troll mais sincérement pour moi l'ouvrier chinois ou l'ouvrier malgache c'est un esclave c'est pas un salaire de misère pour la forme qui change la réalité de leur condition). Dans ce modèle certains ont énormement, beaucoup ont peut ou très peut. Tu considére par avance tout autre modèle comme incapable de continuer à produire les objets aujourd'hui produit.
Dans mon cas j'estime que majoritairement les être humains continuerai à travailler, de manière plus raisonnable et que l'ingéniosité permettra de continuer à produire l'ensemble des choses que nous produisont. Je l'ai dit dès le début de mon commentaire que j'étais optimiste. J'ai également précisé qu'il ne faut pas projeter le modèle dans lequel on est avec le RU, qu'il faut un changement de société qui l'accompagne.
Ton pésimisme te pouse à t'enfermer dans un modèle de société profondément injuste. Tu serais milliardaire je comprendrai que tu défendes le système actuelle mais je doute que ta fortune soit si importante (des millardaires sur linuxfr ? :)).
Voila la différence entre toi et moi. Il est inutile de faire une liste de choses que tu penses qui disparaitraient. Tu n'en sais rien et je n'en sait rien. Moi je veux seulement réfléchir et participer à un modèle meilleur, toi tu ne veux prendre aucun risque pour ton propre confort.
[^] # Re: Pourquoi se limiter au développement de logiciels libres ?
Posté par glisse . En réponse au journal Et pourquoi pas un status : "Développeur Open Source" financé par l'état ?. Évalué à 3.
J'aime apporter mon grain de sable !
Je pense que l'idée que la société avec le RU sera la même (le macdo, les éboueurs, les boulôts de merdes …) est une grave erreur de raisonnement. Je suis certainement idéaliste mais à mon sens avec le RU un grand nombre d'emplois de merdes ne seront plus necessaires adieux macdo et compagnie (pour faire simple je préfère bosser 8h comme éboueur et me faire un bon restaurant avec mon salaire complémentaire au RU que de bosser 1h et me faire un macdo).
A mon avis il y a deux axes qui rendent le RU viable:
Le premier, la flexibilité du travail, y a des poubelles en bas de chez moi et j'en ai marre, je deviens éboueurs pour une demi-journée j'en touche un salaire et j'ai contribué a mon bien être et à celui de mes voisins. Tout plein d'autre emplois non qualifié deviennent soudainement une posibilité pour augmenter son revenu et le partage des tâches ingrates.
Le deuxième, la vrai valeur des biens, ou l'inflation des biens sous évalué. J'estime que le RU remettra les biens de consomations a leur valeur réelle, ca implique évidement une décroissance, finit de changer de meuble ikea pour un oui ou pour un non. Chaque objet superflus sera ainsi le fruit d'un travail. Cela encouragera également le partage et la vie communautaire (potagé publique, mise en commun de resources comme les voitures, ou des outils, …).
La retraite devra également évoluer, elle devrait devenir un revenue complémentaire croissant avec l'âge (ainsi qu'avec les incapacités physique de la personne qu'elle qu'en soit leur origine). Ce revenue complémentaire sera proportionnel au travail qui accomplis au cours de ta vie (en prenant compte la pénibilité).
Ainsi sont récompensés ceux qui dans la force de l'âge contribueront le plus au bien être commun. Enseignant, médecin, infirmier, éboueur, chercheur, service publique en general…
Bien sur il restera des emplois ingrat qui nécessite une formation ou un savoir faire, il devront être justement rémunéré pour rester intéressant. Il y aura également des emplois plus ou moins pénibles mais valorisant je pense notamment à tout les artisans. Ou l'aspect créatif pourra je l'espére reprendre le dessus sur l'aspect purement marchand de leur travail.
Ceux qui préfère s'orienter vers une activité créatrice (artistique ou non comme la création d'entreprise de bien ou de service) pourront profiter des révenus que celle-ci générés.
Je pense donc que le RU implique une nouvelle relation au travail et à la société en général, il est inconcevable pour moi de créer un RU pour continuer dans la société de consommation effréné qui est la notre aujourd'hui.
Et si le résultat c'est du matos informatique qui change moins frénétiquement mais qui à plus de temps pour maturer (et avoir moins de bug) et bien c'est temps mieux, moins de bugs -> plus de temps pour prendre des bières ;)
Bref l'épanouisement de chacun participe a celui de tous …