glisse a écrit 248 commentaires

Oui c'est du foutage de gueule, encore plus quand la partie noyau est vide et fournie juste des entry point pour une library userspace qui fait le vrai travail. Il est clair que jamais aucun driver de ce type ne sera accepté upstream.

Le pilote radeon supporte les sorties VGA & HDMI, si ca ne marche pas pour toi ouvre un bug.

Il exist egalement un support libre pour la 3D sur les HD5600 mais il faut au moins mesa 7.10 (aucune distribution ne l'a encore si je ne me trompe pas).

C'est le probleme avec tout materiel recent sous linux, il faut les toutes dernieres versions du noyau ou de l'userspace pour que cela marche.

C'est exactement ce que fait piglit, donc non on a pas attendu webgl pour tester tout plein de cas tordu. Mais oui on est ravi d'avoir une nouvelle suite de test car il y a probablement des tests qu'on avait pas dans notre suite.

Les drivers open source passe deja plus de 90% de la test suite webgl...

https://bugzilla.mozilla.org/show_bug.cgi?id=616416#c27

https://bugzilla.mozilla.org/show_bug.cgi?id=589546#c75

Ces bugs sont trop gros, trop de monde se joigne a eu, il y a rien de pire que ce type de bug, le mieux c'est de les fermer et dire a ceux qui ont un probleme d'ouvrir chacun leur bug et d'etre circonspect et claire sur le probleme. Apres qd un bug se resout reping les autres et voire qui a encore le bug, c'est bien mieux ainsi qu'un bug a rallonge.

Perso j'ignore completement ce genre de bug parceque j'ai vraiment pas le temps de me plonger dans la lecture approfondi de chaque log et de chaque post. Donc m'on analyse est peut etre fausse ou incomplete, c'est juste le resultat d'un rapide coup d'oeuil et l'experience du type d'erreurs rencontre.

Un bug c'est parceque le context GL a des valeurs pas normale ymin>ymax (forcement ca peut pas marcher mais oui on devrait pas assert ou segfault dans de tel cas).

Le second c'est la creation d'un context GL avec un format pas correct, la je vois pas vraiment ce qu'on peut faire de notre cote, c'est juste interdit de cree un context GL avec un format pas supporte c'est a firefox de verifier ca. Apres naturellement le driver a pas a segfault ou abort face a ca.

Le simple fait de cree plus d'un context GL pose probleme avec le stack open source, le simple fait de switcher entre 2 context GL pose probleme. De ce que je comprends de l'implementation WebGL de firefox, un nouveau context GL est cree pour chaque app/page WebGL. Cela etant dis, oui ca devrait marcher.

On supporte mieux les FBO que les pbuffers, je pense que l'explication est ailleurs (certainement dans la maniere dont il flush GL et dans la gestion des context GL).

Certains jeux utilise plus d'API GL2 que WebGL (GL ES2) comme Doom3 ou Nexuiz qui marche avec les drivers libre, donc non WebGL ne viens pas soudainement tester plus d'API que les applications GL déjà existantes, nous avons beaucoup de tests qui couvre beaucoup d'aspect de l'API.

Juste pour precision, webgl semble marcher sans probleme avec chrome et les driver open source (pas eu l'occasion de verifier par moi meme). Les drivers GL open source sont tout a fait capable la preuve il arrive a faire tourner pas mal de jeux (il y a des listes qui trainent). Les drivers libre passe deja une large partie des tests ~5000/5344 en fonction du driver considere.

Le probleme viens du fait que firefox cree des context GL comme des petits pains (je sais c'est bon les petits pains) et de ce point de vue oui les drivers open source sont pas vraiment bullet proof.

Ce que je trouve domage dans cette histoire c'est que visiblement aucun dev firefox n'a jamais essaye avec les drivers open source, les chipset intel ou radeon sont pourtant relativement courant. Par ailleurs la formulation laisse penser que les drivers open source ne marchait pas et que c'est grace a firefox 4 que ca va finir par marcher...

(GPU HW)<->(KERNEL DRIVER)<->(GALLIUM-WINSYS)<->(GALLIUM-PIPE-DRIVER)<->(GALLIUM)<->(API OpenGL, Cairo, OpenVG, OpenCL, SuperPapyGPUAPIQuiEplucheLesPommes, ..)

Gallium est concu pour permettre a plusieur API d'utiliser le GPU, l'idee est qu'on ecrit 1 fois un winsys et pipe driver par GPU et que grace a gallium on peut alors accelerer plusieurs API par dessus, que ca soit du rendu 3D ou du GPGPU ou l'api du père Cruchaud le pipe driver s'en fout.

En gros gallium abstrait les GPU mordern, un peut comme un les sockets pour les network devices, et par dessus tu peux faire plein de trucs.

Tu veux dire migrer une application ? Genre tu es entrain de rediger un document sur libreoffice sur ton portable et zou d'un coup tu veux passer sur ton fixe ? Ci c'est ca je pense que c'est plus un probleme liee a la virtualisation.

Wayland c'est vraiment la philosophie unix, un probleme simple bien definie -> un outil simple. Ici l'affichage d'une station de travail. Tout ce qui est affichage distant deviens un autre probleme ou de nouvelles solutions peuvent etre teste comme spice ou alors des trucs qui chope le rendu et le renvoi en jpeg ou autre sur le reseau.

Primo pour le moment les dev wayland c'est les memes que les dev Xorg ...

Il n'est pas possible de changer le protocol X tous les 4 matins, le protocol X c'est comme l'API du noyau linux pour l'userspace. Une fois que le protocol existe tu dois le supporter et tu ne peux pas le changer. Ce qui c'est passe dans l'histoire de X c'est qu'il y a une des rajouts (extensions du protocol) comme xrandr, render, ou autres. Le probleme aujourd'hui c'est qu'aucune application utilise reellement le protocol X pour faire le rendu, les applications font le rendu dans leur coin et upload le resultat au server X sous forme de gros pixmap. C'est une realite a laquelle nous ne pouvons rien. Ce genre d'utilisation rend completement (pas totalement) inutile d'avoir un driver qui accelere X.

Par ailleur, les dev X ont pas envie de faire plusieurs drivers (1 driver pour Xorg, 1 driver pour OpenGL, 1 driver pour accelerer la decompression video ...). Donc comme tout le monde se tourne vers EGL (tous les android et autre platform embarque ou linux domine) il semble naturel aujourd'hui d'abandonner X et de se tourner vers une solution plus simple.

Wayland c'est tres basique, un client wayland donne une reference vers une image EGL et demande a wayland de l'afficher. Wayland essaye pas d'accelerer le rendu de l'application. L'application est libre d'utiliser ce qu'elle veut pour faire sont rendu (cairo, EGL ou autre).


Pour le switch je te conseille la presentation de Dave Airlie a la linux plumber (desolee je connais pas de lien). Techniquement Xorg pourrait aujourd'hui supporter le switch en implementant une solution batarde a la windows optimus (1 driver qui cache 2 driver et qui s'occupe de faire le switch). Mais ce n'est pas une solution perenne, c'est juste un hack crade.

La solution vers laquelle on s'oriente et de pousser le switch vers l'application, on demande alors a l'application de bien vouloir changer de driver GL et voir si celui-ci lui plait, si toutes les applications dises oui alors on switch, si une application dit non bah alors on switch pas. Ici 90% des applications n'auront jamais a ce soucier de ca (cela sera dans les toolkit qt ou gtk).

La raison pour laquelle un switch peu echouer c'est dans le cas d'une application GL qui demande une extension qui n'est pas presente sur la carte vers laquelle on veut switcher.

Pour les solutions a l'optimus (ou seul une fenetre ou une application est rendu avec un GPU different) la encore l'idee c'est de pousse le choix vers l'application puis d'avoir wayland capable de rapatrier les donnees vers le GPU qu'il utilise pour l'affichage.


Tout ca pour dire que le plus gros probleme de X c'est le manque de concurence c'est le manque de contributeurs.

Pour les HD5XXX ce n'est probablement encore dans aucune distribution mais le driver 3D existe (ou alors je bosse sur du code imaginaire :))

Je conseille a tout le monde de regarder le talk de Keith Packard a LPC, talk qui a eu lieu avant l'annonce de Mark. En resumer nous souhaitons (la plus part des dev X) migrer les toolkit vers EGL et par consequent abandonner X. L'idee est donc d'avoir les toolkit utilisant EGL et affichant avec wayland. Wayland est aussi capable de faire tourner un server X on pourra donc encore lancer n'importe qu'elle application qui n'est pas encore porte.

Pour l'affichage distant c'est probablement vers des solutions comme spice que nous nous orienterons.

Donc non Mark ne donne pas la direction, il profite du mouvement que les dev X ont inities (et je ne vois aucun probleme a cela). Par ailleurs qt et gtk sont entrain d'etre porter et marche deja en partie avec wayland.

Juste pour infos, toutes les radeon jusqu'au HD5XXX sont supporte et avec de la 3D (ok espere pas encore jouer a doomIII mais compiz et le reste marche bien)

Faut pas commencer a troller le jeudi comme ca ! ;)

A non c'est pas du jeu, tu dis pas c'est quoi qui change et qui dérange ! Moi je veux du troll le vendredi :)

Youhou les trolls ! Vous etes ou ?

Xorg n'evolue pas, le protocol est le meme. Les extensions par contre evoluent bcp, mais bon a mon sens j'aime pas trop Xorg je prefere des approches a la wayland ou c'est les bibi telque gtk ou qt qui sont en charge de dessiner et d'accelerer parceque l'accel comme xrender c'est null, impossible a proprement accelerer avec les gpu d'aujourd'hui (ceux d'hier aussi).

X est pas pret de disparaitre, une grosse partie des utilisateurs de linux ont des appli metier qui tourne que sous X. Apres pour l'average desktop user effectivement si GTK/QT sont porte vers wayland bah tu auras toutes leur applis avec.

Quand vous aurez des bugs et un debut de barbe on vous laissera goûter un peu !

Avec des bon bourgognes mais bon ca les dev nouveau peuvent pas comprendre ce que c'est que du bon vin.

Si tu avais pas balancé les clef en sortant de la cave on serait pas coinçé ! :)

D'un point de vue developeur de driver le materiel nvidia est bcp plus "facile", propre, sympa.

Apres pour radeon il faut comprendre qu'on est enferme dans des choix techniques fait il y a plus ou moins longtemps et qu'on ne peut en changer que tres tres tres difficilement (l'interface noyau userspace est fige pour nous, pas pour nouveau).

Au debut je voulais faire une blague sur la necessite de faire des apt-get update/upgrade un peu plus souvent puis je me suis dis que c'etait pas drole. Cela etant dis je suis sidere que des gens ne se rendent pas compte que des drivers 3d existe, 5 ans apres. En faite je me demande ou les gens vont chercher leur informations ...

J'avais aussi oublie de remercier Patrick pour sa depeche. Allez bonne journee a tous.

l'accel 3D sur X800 est dispo dans mesa depuis 5-6ans de memoire ...