glisse a écrit 248 commentaires

Intel.

OpenGL 2.0 demande des extension comme les framebuffer hors pour faire proprement l'extension du framebuffer il faut un memory manager, c'est principalement pour extension du même type que les drivers libre radeon ne sont pas GL 2.0 (GLSL aussi mais dans une moindre mesure). Mais l'avenir est plutôt rose, il y a de plus en plus de resources (être humains ;)) qui travaillent sur tout le stack graphique (X, mesa, drm, ...)

Le problème ici c'est surtout qu'il y a plein de nom (GEM, TTM, ...) et que la définition à laquel chacun pense peut être différente. Pour le moment le compromis c'est qu'on utilise l'API GEM ie l'interface userspace qu'expose le noyau pour radeon est la même que GEM mais que derriére on réutilise du code de TTM pour gérer la VRAM (les sources de radeon sont très parlante, toutes les ioctls gem appellent du code TTM :)).

Après, pour les générations futures le problème est encore plus compliqué (enfin plus simple d'un certain côté), les nouvelles cartes ont un MMU qui peut générer des pagefault, on se rapproche donc d'une gestion comme sur le CPU et la l'interface GEM c'est peut être pas ce qu'on voudra.

Juste pour préciser, dans le cas de GEM c'est plus l'API qui a été accépté que le code de gestion de mémoire. Pour radeon, on a pour le moment l'API GEM mais dans le noyau c'est grosso modo TTM qui fait le boulot. Le fait est que les GPUs intel n'ayant jamais de ram propre ils n'ont pas la complexe tâche de gérer celle-ci. Donc on aura forcément dans le noyau un autre truc que ce qu'intel utilise (on partagera certainement des bouts comme la gestion des droits, ...).

Il ne peut y avoir de généralisation de l'interface des GPU comme il peut y en avoir une pour les cartes réseaux où autre périphériques. En effet, les cartes réseaux et la grand majorité des périphériques répondent à des standards bien définis (Ethernet, Wifi, usb, ...) alors qu'une carte graphique doit accélérer le rendu d'objets au travers au travers de polygones, il s'agit la d'une définition bien vague et qui laisse beaucoup de libertés aux concepteurs de hw. Cette liberté est en partie cadrée par microsoft au travers de Direct3D. Toujours est il que les différences matérielles de bas niveau me semblent bien trop importantes pour pouvoir faire l'objet d'une unification.

Enfin une telle unification se ferait au détriment d'un acteur, celui qui a le meilleur driver. Si un même driver peut faire fonctionner les différentes cartes alors les investissements fait dans l'écriture de celui-ci profiteraient à la concurence. Je doute qu'aucun des trois acteurs est envie d'aller dans ce sens.

Le problème dont il est ici question est tout autre (GEM vs TTM). Durant de longue années il n'y pas eu de gestionnaire de mémoire digne de ce nom sous linux. Aujourd'hui certaines cartes graphiques ont plus de mémoire qu'il n'y de RAM dans l'ordinateur. Par ailleurs les gouleaux d'étranglement continuent de se multiplier. Le débit entre le GPU et sa mémoire est sans commune mesure avec celui du CPU avec la RAM. De même le débit entre la RAM et le GPU peut être particuliérement impacté par l'architecture et je pense ici notament aux architectures NUMA qui semblent être la voie choisit pour le futur.

Il devient donc évident qu'on ne peut se permettre de gérer la mémoire vidéo à la légére et qu'il faut minimiser le déplacement des objets entre VRAM et RAM. GEM est conçu dans le cadre de carte qui n'ont pas de VRAM, il n'a donc pas exactement les mêmes objectifs. TTM est bien trop complexes (une bonne métaphore : "take a gun to kill a fly").

Enfin le fond du problème ici c'est qu'intel a mit les moyens pour le dévelopement de drivers video efficaces sous linux pour son matériel. Si aucun des autres constructeurs NVidia ou AMD ne fait de même, on risque de se retrouver avec une infrastructure qui s'adaptera mal avec les cartes ayant leur propre mémoire vidéo. Tout revient donc à une question de moyens, d'argent. Il faut prendre conscience qu'aujourd'hui le dévelopement du noyau est gouverné par ceux qui investissent de l'argent dedans, ce qui me semble normal dans le cadre des régles qui régissent les interactions dans nos sociétés au sens large.

Quand je dis que c'est orthogonale ca veut dire qu'il a une intersection, je suis balaise en math moi ;d, et l'intersection c'est le fait que le modesetting a besoin d'allouer de la mémoire. Mais le modesetting il s'en fout du gestoinnaire de mémoire sous jacent et c'est le point auquel je voulais en venir en disant que c'est orthogonale (expression souvant utilisé sur lkml d'ailleurs :)) Donc le modesetting il peut fonctionner avec ttm ou toto ou brouzouf tant que ca lui permet d'allouer la mémoire qu'il veut.

Ensuite le modesetting pour moi c'est une part importante du travaille mais pas l'essentiel et pas la plus grosse. Et sur le reste gallium et userspace nouveau est plus avancé que radeon. Ok pour les nv50 et après c'est pas ça mais sur AMD on en est pas plus loin sur r600 & compagnie.

C'est dingue ça je défends nouveau :o) marcheu t'es ou ?

Non ce n'est pas intégré et je pense qu'il faudra attendre la fin de l'année avant que cela le sois, 2.6.27 dans le meilleur des cas ou 2.6.28. Une fois que c'est intégré on peut plus changer l'API avec le monde extérieur donc il vaut mieux être prudent.

De mon point de vue, et je code principalement pour le matos AMD, nouveau est plus avancé que le code pour radeon donc mon classement ça serait Intel, Nouveau, AMD.

Ensuite TTM est un memory manager c'est complétement orthogonale au modesetting. Pour faire une caricature grossière et pas tout à fait exacte aujourd'hui le memory manager estime que le contenu de la mémoire video est perdu à chaque changement de client (programme) et à chaque fois que ca arrive on retransmet l'ensemble des objets (textures, ...) évidement c'est débile mais ce schéma était tout à fait satisfaissant quand les carte video avaient 4 ou 8 Mo de ram :)

Aujourd'hui on perd énormement de temps à copier depuis ou vers la ram video et on a donc besoin d'un gestionnaire de mémoire. Et c'est le rôle de TTM (qui n'est qu'une partie d'un gestionnaire de mémoire). Pour le moment rien n'est arrété sur le choix du memory manager.

Donc le modesetting peut fonctionner sans TTM.

Pour AMD les scripts interprété ne font pas grand chose et on peut facilement les restreindre à des parties non sensible des cartes ie leur interdire le DMA. Bref je doute fortement que cela soit une vecteur d'attaque pour compromettre la sécurité d'un système.

Vois tu je n'étais pas au courant et pourtant je suis de près l'actualité de DRM parceque j'y participe. Ne voyant pratiquement aucun patch de la part des gens de BSD depuis quelque temps j'en ai déduis que plus personnes ne travaillaient dessus. Par ailleurs je répondai aussi à des questions de dev BSD sur DRM et sur ce qu'il serait bien de faire, je pensais donc que tout n'était encore que discussions et projet. Visiblement j'ai tort et du code tourne déjà.

Maintenant le problème est qu'on a pas de retour de leur part. Et si les gens de BSD ne contribuent pas upstream DRM pourrait bien finir linux only et je trouve ça domage. Particuliérement avec le modesetting dans le noyau. Je ne connai pas la position des BSD people sur ça mais une chose est très, mais vraiment très probable les futurs drivers pour carte graphique vont être conçut avec le modesetting dans le noyau. Alors soit BSD nous accompagne soit ils redéveloppent tout.

Enfin ma remarque n'était pas critique, c'était curiosité de ma part qui ne sait probablement pas où trouver les informations sur BSD. Néanmoins je souligne je trouve domage que upstream on ne soit pas vraiment au courant ni qu'on ne recoive des patchs.

Tu as vu où qu'ils travaillaient sur DRI/DRM ? De ce que j'en sais, ils sont juste au tout début, à savoir discuter de ce qu'ils doivent faire, et je ne pense qu'il y ait un résultat qui puisse être activé par défaut avant un an/un an et demi. Sauf si des personnes travaillent dessus à plein temps...

Seulement pour le desktop il n'y a que redhat et suse (parmis les distributions apres il y a Intel et AMD parmis les constructeurs, il y a aussi sun) qui payent des gens pour travailler sur Xorg et sur le serveur. Va voir les commits de mesa, drm, xorg/xserver, ou des drivers tu ne verra pas une seul contribution de canonical.

Alors dirent que redhat ou suse ne fait rien pour le desktop, c'est de la desinformation et un manque de respect pour leur travail.

D'abord tu occulte mon premier point, attend pas que l'information vienne a toi, enfin si tu veux etre passif va regarder la star ac, au moins tu ne fatiguera pas tes doigts.

Bravo tu as compris l'idee de detournement ! Oui le detournement des mails par l'envoi de spam c'est chiant. Ce detournement peut il conduire a une limitation de tes libertes ? Non. Si par contre tes mails font l'objet d'une surveillance systematique, tes libertes sont-elles preserve ? Non. Si tu sais tes mails surveille tu n'insultera, ni ne fera une blague malheureuse.

Enfin si tu crois que les cameras vont aider a la securite laisse moi te dire que j'en doute fortement. Il y a quelque temps j'ai ete victime d'une agression, il se trouve que cela c'est passe devant une camera de surveillance. Un pompier est venu m'aider apres que mon agresseur soit partie me laissant gissant au sol. Je precisse que le pompier etait dans son centre de control a 10M du lieu ou je me faisais agresser, il ma montre les images et dit on voit pas la gueule du type ca te servira a rien si tu veux porter plainte (sachant que mon etat physique attestait deja pleinement de la realite des faits). La camera n'a donc ni empecher l'agression, ni dissuader l'agresseur, ni permis l'intervention rapide de secour ou d'aide, ni permis de donner des suites legales...

Oui j'acceptes d'etre logge par LinuxFR et toute la difference est la, j'accepte (je suis null avec les cites alors imagine le mot souligne :))

Demande aux gens de la CIA l'idee qu'ils se font de l'usage possible d'une baignoire, tu ne regardera plus ta baignoire du meme oeil ;). La V republique avait pour but, si j'en crois certains historiens et hommes politiques, de reequilibrait les pouvoirs entre executif (gouvernement et le chef de l'etat), legislatif (assemble et senat) et judiciaire. Aujourd'hui le legislatif n'est plus qu'une chambre d'enregistrement, completement vassalise par l'executif. Il s'agit d'exemples de detournement d'outils qui conduisent a des atteintes aux libertes (voir les lois votes dernierement, et le type qui experimente les modes d'utilisation des baignoires de la CIA le fait probablement pas de bon coeur).

Mon argumentation etait donc de dire que les cameras ont des defauts et qu'elles ne regleront pas le probleme et risque au finale d'etre detourne de leur usage. Le probleme c'est l'inegalite dans nos societes, tu crois que si tout le monde rouler en ferrari il y aurait des agressions, ormis celle comis par des gens relevant de la psychiatrie.

La racine du probleme et donc ailleurs, et chercher a controller ces effets nefastes ne peut aboutir au final qu'a une situation encore plus dangeureuses (control des libertes, ...). Apres si vivre dans un monde ou un type roule en ferrari pendant que 5m plus loin un mec creve de faim te semble etre envisageable tant que l'on garantit la securite, cela te regarde.

Pourquoi attends tu qu'on te dise à quoi tu renonce. J'ai la ferme conviction que dès que tu renonces à une chose la personne qui en profite, s'il y en a une, n'aura aucune véléité à te l'expliquer le plus promptement possible.

Sur le fond tu cautionnes toi même ta position à l'utilisation correcte de l'outil. Un informaticien ou une personne au faite de l'outil informatique devrait savoir l'évidence que constitue l'inecductabilité du détournement qui serait un jour faite de chaque outil (mail->spam,programme->virus,...) Il y a peux de certitudes en ce monde mais jamais la nature humaine, dans ce qu'elle a de plus vil, ne devrait préter à l'étonnement.

Et qui surveille ceux qui surveillent ceux qui surveillent ? Et d'ailleur au final qui surveille qui ? Pauvre serpent, il n'a pas finis d'avoir des indigestions...

J'ai vu bien des gens écrire des programmes politiques, signer des engagements, ... mais bien peux finissent par les tenir, en réalité aucun exemple ne me vient à l'esprit, car tout engagement est une contrainte et s'affranchir de contraintes est plus aissé que de les respecter (ne sous estimons pas la paresse de l'homme qui est l'une des choses les mieux partager parmis l'espéce humaine).

Les outils finissent toujours par être détourné, ce n'est qu'une question de temps. Le monde qui nous entoure est remplis d'exemples (baignoire, V république, ...).

La question n'est donc pas dans les outils, mais dans l'approche. Le problème de fond de l'insécurité ne peut relever de la compétence d'un établissement d'enseignement, ce n'est pas son rôle, aussi aucune des décissions qu'il pourra prendre ne pourra avoir un réel effet positif, il ne peut que s'agir de déplacer le problème.

C'est pourquoi ce genre de question ne devrait même pas se posser, il ne s'agit pas de ce substituer à l'état même si celui-ci n'est pas capable ou refuse d'assurer ses obligations à savoir de faire respecter les lois républicaine. Loi qui ne garantissent pas la sécurité, il semble malheureusement nécessaire de le rappeler. Rappelons également que rien ni personne ne peut garantir la sécurité.

Je termine par une citation d'un dénomé Benjamin Franklin :
Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety.

Et, oui, les cameras peuvent être considéré comme une atteinte au liberté. Vous ne feriez probablement pas de nombreuses choses (pas forcement délictueuse) face à une camera. Il s'agit alors de controller l'agissement des personnes afin qu'il corresponde à une norme prétendu, bref il s'agit du conditionnement du comportement humains. Relisez 1984... Ou tout une analyse un temps soi peu documenter de la problèmatique.
http://www.urbaneye.net/results/ue_wp15.pdf
http://www.agoravox.fr/article.php3?id_article=26772

A bon entendeur salut, chercher pas je suis plus sur l'image...

Une question au passage comment sont géré les versions des distributions ou des drivers ? Ca change vite et donc il est possible que ce qui n'était pas supporté le soit. Aussi quand il y a un nouveau report sur le même matérielle est ce que cela ecrase l'ancien si la version du driver est plus récent ? Si non je pense qu'au final on obtient un site vite obsolete.

Je sais que le problème du matériel compatible est complexe, entre le nom commercial est le matériel il peut y avoir des différences (marketing, marketing, ...). L'exemple que j'avais bien aimé était celui de chez atheros ou il y avait une liste avec le chipset et les possibles noms commerciaux. Mais il n'y aura pas de solution miracle temps que le nom commercial est sans raport avec le chipset du dit matériel.

Non le reverse engineering ne devient pas déraisonnable ; effectivement les GPU deviennent de plus en plus des CPU et faire le reverse engineering d'un CPU c'est facile :). Naturellement il y a des choses difficiles a bien saisir avec le RE je pense par exemple à la synchronisation des textures unit sur R500. Mais l'un dans l'autre au final c'est en plus facile qu'avant mais ca demande plus de temps ou une bonne organisation.

Les compétences ca s'acquiert, on nait pas programmeur de pilote ;)

OpenGraphics c'est sympa comme projet universitaire ou pour apprendre l'électronique. Mais sincérement je pense pas quand l'an de grâce 2008 une carte graphique VGA comme celle de 1998 (voir même d'avant) est beaucoup de sens. Qui plus est VGA est un standard que nous voulons oublier, comme VESA. Ces standards ne sont pas concu pour le matériel d'aujourd'hui (fréquence de rafraichissement variable, multiple-ecrans, DVI, ...).

Autre point, l'indépendance, comme les libertés, les droits de l'homme ou autre concept propre à une démocratie ne sont pas acquis, jamais, il faut toujours rester vigilant (j'arrête la car après ca devient de la politique). Il en va de même avec les informations que l'on a. Aujourd'hui AMD fournit ces informations car ca leur semble être la meilleur chose à faire malgrès tous les problèmes légaux et le travail nécessaire. Demain personne ne sait ce qui pourrait changer.

La tendance c'est que nouveau, radeon (à partir des r300) et intel (à partir des i915) passeront à gallium3d et le reste restera avec les drivers actuel. La raison en est un simple il n'y pas assez de développeurs seul nouveau à une équipe assez grosse. Pour intel il attende d'avoir un driver gallium3d plus ou au moins aussi performant que leur driver actuel.

Sur radeon il y a cet guerre entre radeon & radeonhd qui est catastrophique car les deux équipes non pas la même vision de ce qui doit être fait. Chacun travail donc dans le sens qui lui semble être le bon. Je ne dis pas que je sais ce qui est mieux à faire, seulement qu'au final ca détruit la productivité. Chez nouveau Stéphane c'est le despote qui dit on fait modesetting randr 1.2, EXA, puis 3D gallium et tout le monde travail dans le même sens.

Comme quoi des despotes comme Linus ca a du bon. Je rapelle au passage que la dictature, d'un point de vu mathématique, est l'un des systèmes les plus démocratique :)

Je rajouterai deux killer features (avec l'accent je vous prie) de git:

- Pouvoir facilement recuperer du code de differents repository du meme projet (je fais ca tout le temps):
git-clone git://anongit.fdo.org/git/mesa
cd mesa
git-remote add toto git://toto.org/git/mesa

Et hop on peut recuperer les branches de toto faire du cherry picking et compagnies. A si vous connaissez titi ben vous pourrez aussi faire la meme chose.

- Git bitsect très utile pour retrouver une régression.

Donc git c'est bien ;)