Je m'essaye à l'exercice de la publication LinuxFr pour apporter quelques explications sur le statut de l'accélération graphique dans Firefox 4 sous Linux (plus généralement X11). Je suis le type qui a fait la modification restreignant OpenGL au seul pilote NVIDIA propriétaire dans Firefox 4 sous Linux, donc si vous n'êtes pas contents, c'est moi qu'il faut gronder.
Si vous êtes pressés, je vous conseille de lire au moins ce mail que j'ai envoyé à la liste mesa-dev.
Le fait est qu'on a plein de plantages dans tous les pilotes OpenGL, sauf avec le driver proprio NVIDIA. Donc j'ai restreint OpenGL à ce seul pilote, et j'ai écrit (lien ci-dessus) a mesa-dev pour leur expliquer la situation et leur montrer comment reproduire les problèmes, ce qu'ils ont pu faire très vite, et ils ont fait des rapports de bugs, cf. ce fil de discussion.
Donc les choses avancent : on a une batterie de tests officielle pour WebGL qui permet de valider tranquillement les pilotes et, bien entendu, dès qu'un pilote sera validé, on se dépêchera de l'activer pour Firefox 4.
Ça ne sera pas forcément avant la sortie de Firefox 4 : il ne reste pas beaucoup de temps. Mais ça pourra être dans une sortie mineure, et de toute façon on va se mettre à sortir 3 versions "majeures" par an.
Quelques autres précisions maintenant :
- Vous pouvez débloquer votre pilote en définissant la variable d'environnement MOZ_GLX_IGNORE_BLACKLIST avant de lancer Firefox.
Voir le mail à mesa-dev ci-dessus si vous voulez exécuter les tests WebGL.
- L'accélération due à XRender, via Cairo, est toujours présente. Seul OpenGL est bloqué.
On utilise potentiellement OpenGL pour 2 choses : pour WebGL et pour les 'Layers' (phase de composition des couches d'une page web, ce qui inclut le redimensionnement et les conversions d'espaces de couleurs pour les images et la vidéo).
- WebGL est activé par défaut, donc dès que votre pilote est débloqué (voir ci-dessus), vous pouvez faire tourner du WebGL. Votre pilote OpenGL sera utilisé pour exécuter WebGL, mais pour que le résultat soit utilisé directement pour l'affichage sans repasser par la mémoire centrale (ce qui permet d'accélérer encore plus), il vous faut les Layers, voir ci-dessous :
- les Layers, par contre, ne sont pas encore activés par défaut sous Linux, indépendamment des pilotes, parce qu'il y a un bout de code qui reste à écrire pour ne pas perdre le bénéfice de XRender. (En gros, permettre aux pixmaps de rester sur le serveur X sans faire d'aller-retours inutiles). Tant que ça n'est pas fait, activer les layers cause une perte de performance sur certains benchmarks à base de canvas 2D. Par contre, ça accélère déjà très bien la vidéo et WebGL, par exemple. Si vous voulez activer les Layers, allez sur about:config et activez layers.acceleration.force-enabled.
Dès que les bugs graves qui restent à régler dans Firefox 4.0 seront corrigés, je voudrais m'attaquer à activer les layers par défaut sous Linux. Je pense que ça sera dans la version +1 d'ici quelques mois ; puis, à terme, on a aussi des plans pour se débarrasser complètement de XRender et simplement tout faire par OpenGL, ce qui règlerait pas mal de problèmes : c'est ce qui se passe déjà sous Windows, ou l'équivalent de XRender, Direct2D, est une simple bibliothèque logicielle appelant Direct3D 10. On devrait pouvoir faire aussi bien avec OpenGL à la place de Direct3D 10.
Aller plus loin
- Journal de bjacob à l'origine de la dépêche (8 clics)
- Mail sur la liste de diffusion Mesa-dev (5 clics)
# à propos
Posté par mum1989 . Évalué à 1.
ou alors j'ai pas tout suivi et le bug viendrait de Firefox 4 ?
[^] # Re: à propos
Posté par bubar🦥 (site web personnel) . Évalué à 10.
Je crois que c'est une combinaison de plusieurs facteurs.
Avant WebGL, il n'y avait pas de batterie de tests officielle et publique de la part de Khronos, pour OpenGL et OpenGL ES. Les developpeurs de pilotes pouvaient soit developper la leur (je crois que les devs de Mesa en ont une, 'piglit'), soit payer une licence pour une batterie de tests proprietaires (je crois que Khronos en vend). Avec WebGL, pour la premiere fois on a une batterie de tests complete et libre:
https://cvs.khronos.org/svn/repos/registry/trunk/public/webg(...)
Ensuite il faut bien voir que WebGL touche a 99% de l'API OpenGL ES 2.0 (donc disons 90% de OpenGL 2.1) et atteint donc bien plus de bugs dans les implementations que, disons, Compiz ou Kwin qui se contentent probablement de 20% de l'API, ou meme qu'un jeu video qui va utiliser 50% de l'API.
Enfin, comme WebGL expose 99% de l'API OpenGL ES 2.0 aux scripts sur le web, les bugs dans les pilotes peuvent tres vite se muer en failles de securite. Un simple plantage est considere comme une faille par deni de service si un script peut le causer quand il veut. Du coup, les fabricants de navigateurs, au moins nous et un autre gros, sont en train d'etablie des listes noires / listes blanches de pilotes, ce que les fabricants de jeux video n'eprouvent pas le besoin de faire
Glisse :
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...
Bjacob
On n'est pas les seuls a penser qu'a terme il n'y a pas vraiment besoin d'autre chose que d'OpenGL, c'est par exemple l'opinion de Keith Packard:
http://lwn.net/Articles/413335/
Moins on a d'APIs differentes pour parler au materiel, plus les pilotes/implementations sont petits, mieux ils sont testes. Historiquement, XRender a aussi un gros probleme de mauvais pilotes, qui est une des raisons qui rendent parfois Firefox lent sous linux: Chromium arrive parfois a etre bien plus rapide avec un rendu purement logiciel (Skia), ce qui est un comble.
(...)
http://lists.freedesktop.org/archives/mesa-dev/2011-January/(...)
La discussion a montre que (au moins les versions de dev) les pilotes libres etaient tres pres du but, et qu'il n'y avait qu'un probleme de plantages a corriger.
(...)
Par defaut sous linux, comme on n'active pas les 'Layers', on ne cree que le strict minimum (avec les Layers actives on en cree effectivement plus).
La grosse difference que je vois a ce niveau avec Chrome, c'est plutot qu'ils semblent utiliser des PBuffers alors que nous creons un contexte OpenGL invisible (je crois appuye par un pixmap) et faisons tout le rendu dans un FBO.
(...)
Je n'ai pas le temps de tout faire (et notre 'equipe' WebGL n'a que 2 personnes contre 4 ou 5 chez Google). J'ai une carte nvidia. Initialement j'ai essaye (fedora 13 en mai 2010) avec le pilote nouveau, mais ca ne marchait vraiment pas bien du tout; je n'ai pas eu le temps de reessayer depuis.
(...)
Crev
Et dans le cas où ça fonctionne sous chrome, pourquoi ne pas reprendre le même principe ?Bjacob
Parce que c'est une assez mauvaise idee. Les FBOs sont tout simplement plus puissants, par exemple ils nous permettent de parler directement a notre systeme de Layers (on verra si Chromium passe aux FBOs lorsqu'ils implementeront la fonctionnalite equivelente...) Ensuite. a chaque fois qu'on parle avec des ingenieurs de ATI et NVIDIA (ils participent a l'elaboration de WebGL), ils nous confirment que les PBuffers sont consideres comme un 'hack' et que leur support futur n'est pas garanti. Et d'ailleurs initialement, on utilisait des PBuffers et ca n'etait pas supporte par certains pilotes libres sous linux (ca a ete corrige il y a 6 mois je crois). Meme si c'est supporte maintenant, ca montre bien que c'est non-standand.
Glisse
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.
Bjacob
Ce qui tu ecris ici m'interesse beaucoup!
Peux-tu me pointer plus precisement ou tu vois ca, je voudrais patcher Firefox pour qu'il evite de faire ca.
[^] # Re: à propos
Posté par bubar🦥 (site web personnel) . Évalué à 10.
Espérant que cela apporte un condensé des infos des commentaires du journal d'origine, et un plus à la dépêche. Sinon, moinssez :-)
[^] # À ne pas oublier ...
Posté par Xavier Bestel (site web personnel) . Évalué à 4.
Bref, la paille dans l'œil du voisin, tout ça ...
[^] # Re: À ne pas oublier ...
Posté par Xavier Bestel (site web personnel) . Évalué à 4.
Brian Paul:
On dirait que qu'un grand nombre de plantages apparaissent parceque WebGL suppose que le driver OpenGL implémente GL_ARB_ES2_compatibility alors que cette extension n'est en fait pas présente. Mesa génère une erreur et le test plante.
Par exemple, WebGL appelle glGetIntegerv(GL_MAX_FRAGMENT_UNIFORM_VECTORS) et Mesa génère GL_INVALID_ENUM. Le test gl-get-calls est marqué comme échec.
Si GL_ARB_ES2_compatibility est obligatoire pour WebGL, il devrait y avoir une vérification. Savez-vous ce qui se passe dans ce cas ?
Je n'ai pas creusé beaucoup des échecs, mais beaucoup d'erreurs GL sont générées par Mesa à causes d'indices invalides lors de l'accès aux uniforms de GLSL, etc. Ça aussi me semble suspicieux.
Eric Anholt a commencé à ajouter le support de GL_ARB_ES2_compatibility dans Mesa mais il n'est pas activé dans beaucoup de drivers pour l'instant. Je pourrais travailler à l'activer pour les drivers swrast et gallium.
[^] # Re: À ne pas oublier ...
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
Bref, il y a en effet un truc a corriger a ce niveau dans Firefox, mais ca n'a rien a voir avec les plantages.
Pour les plantages, les devs de xorg ont bien confirme que c'etaient des bugs de leur cote, mais en meme temps Glisse m'a pointe vers des trucs que Firefox pourrait (et devrait) faire pour eviter de les declencher: je regarde.
[^] # Re: À ne pas oublier ...
Posté par Xavier Bestel (site web personnel) . Évalué à 1.
[^] # Re: À ne pas oublier ...
Posté par Albert_ . Évalué à 0.
En tout cas Benoit Jacob semble etre plus pose que certains de la liste du kernel meme si cela manque de piquant du coup on peut apprecier aussi! :)
[^] # Re: À ne pas oublier ...
Posté par dinomasque . Évalué à 1.
BeOS le faisait il y a 20 ans !
[^] # Re: À ne pas oublier ...
Posté par Xavier Bestel (site web personnel) . Évalué à -3.
[^] # Re: À ne pas oublier ...
Posté par Albert_ . Évalué à 8.
D'apres ce qui se dit ici et ailleurs les torts sont partages dans le sens ou il y avait des bugs dans les des deux projets et si l'on regarde du bon cote c'est que cela a mis un coup de pied dans la fourmilleres et la prochaine version de drivers Mesa va etre de tres bonne facture avec de moins en moins de bugs et de manques.
De plus il a poste sur la mail liste mesa-dev, il n'est pas passe par un communique de presse disant que c'etait de la merde etc. Au contraire son post a ete plus que constructif je trouve. Certes il met la faute sur mesa mais il a aussi admit que son code avait des problemes et ne faisait pas les choses a 100% comme il faudrait et il tente de corriger et ca c'est le principal.
[^] # Re: À ne pas oublier ...
Posté par barmic . Évalué à 3.
Linuxfr est devenu tellement une référence que chaque journal peut déclencher la mort ou la résurrection d'un projet ?
Faut pas préter trop d'attention à un journal, hein. J'ai l'impression de revoir ceux qui postaient un journal pour dire qu'ils étaient pas contents d'avoir étaient moinisé dans un commentaire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: À ne pas oublier ...
Posté par Benoit Jacob (site web personnel) . Évalué à 10.
Ben, les plantages sont bel et bien des plantages des drivers, ensuite on pourrait et devrait valider mieux les parametres avant de faire nos appels, ce qui peut eviter certains plantages, ca oui, mais il reste que les drivers ne sont jamais censes planter.
Au final tu vois que les torts sont partagés, mais Xorg n'a pas la puissance de feu médiatique de Mozilla, donc le mal est fait.
Tu rigoles ou quoi? Puissance de feu? Un journal linuxfr, tu appelles ca de la puissance de feu? Et tu ne crois pas que les devs de xorg peuvent aussi faire des journaux linuxfr si ca leur chante?
Faut arreter de chercher du conflit la ou il n'y en a pas. Entre les devs de xorg qui reglent leur plantages et nous qui reglons notre manque de validation qui apparament conduit a declencher ces plantages, tout ca devrait bientot etre du passe.
[^] # Re: À ne pas oublier ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -10.
[^] # Re: À ne pas oublier ...
Posté par Albert_ . Évalué à 10.
Cela sert a quoi ce genre d'attaque gratuite? A degoutter un developpeur?
Ca va arreter ce genre de truc? Les deux cotes ont travaille ensemble et dans la grande tradition du libre tout a ete fait a visage decouvert. Il n'y a rien de cache et aucune des deux partis concernes n'a commence a insulter l'autre. Pourquoi est-ce que des personnes non directement implique se permette de faire ce genre de remarque? Cela me depasse!
[^] # Re: À ne pas oublier ...
Posté par grid . Évalué à 7.
Ca méritait un commentaire.
[^] # Re: À ne pas oublier ...
Posté par fearan . Évalué à 6.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: À ne pas oublier ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -7.
Ceci dit, je ne vois pas pourquoi tu t'emportes sur mon commentaire. Ce que je relevais, c'est la phrase « il reste que les drivers ne sont jamais censes planter ». C'est bien ça qui me pourri quotidiennement la vie. Avec des développeurs, collègues ou non, qui suppose que ça ne vaut pas le coup de se casser la tête à vérifier le retour des fonctions. C'est un peu pour contrer ce genre de comportement qu'on a d'ailleurs inventer les exceptions, histoire que ce ne soit pas aussi facilement ignoré.
Personnellement, je préfère dégoûter un souillon plutôt que de le soutenir dans l'erreur. On a assez de code sale, impossible à maintenir et a fortiori bourré de faille de sécurité pour se payer le luxe de soutenir ceux qui en rajoute.
Systématiquement, quand j'utilises une fonction qui peut générer des erreurs, je les gère.
[^] # Re: À ne pas oublier ...
Posté par claudex . Évalué à 8.
Ça ne doit impacter que le code que tu écris, si le code que tu utilise fait tout planter parce que tu ne vérifie pas un retour de fonction, c'est qu'il y a un problème dans le code.
Pour reprendre ton exemple avec les ouvertures de fichiers, ce n'est pas parce que tu ne vérifie pas les retour qu'il va y avoir un kernel panic.
« 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: À ne pas oublier ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -2.
Lorsqu'en C une fonction segfault, je considère d'abord que c'est de ma faute. Parce qu'en C il est parfois difficile d'utiliser une fonction correctement. Du genre, fournir une zone mémoire non-allouée ou non-initialisée. Un segfault dans ces cas-là est évidement salutaire (c'est toujours pire un programme qui tombe en marche), et quelque soit la localisation du segfault. Si memmove plante, je ne vais pas râler contre UNIX/POSIX.
En l'espèce, dans le présent thread, on parlait des fonctions OpenGL qui échouaient, et que le développeur a ignoré de vérifier le retour. Les crash du serveur X (ou d'un module noyau s'il y a) n'étaient pas considérés. Il est évident que l'utilisateur des fonctions ne peut rien faire si elles partent totelement en couille, malgré la rigueur du développeur.
Je ne peux constater qu'avec effrois que l'époque où les contributeurs aimaient la qualité et la rigueur, avaient une exigence en regard des logiciels propriétaires, est belle et bien révolue sur DLFP. Toute critique franche d'une pratique misérable (la programmation à la truelle, en l'occurrence) est violemment réprimée par la masse. C'est déplorable.
[^] # Re: À ne pas oublier ...
Posté par Albert_ . Évalué à 4.
Quand cela arrive apres la bataille et que cela n'amene a rien si ce n'est a probablement degoutte le dev. Mais c'est beau quelqu'un qui programme sans jamais avoir de bug. C'est vrai c'est beau. (Au passage le code tournait avec certains drivers mais pas avec d'autre donc mettre en cause un probleme de driver etait assez logique comme d'ailleurs l'a montre l'echange avec les devs mesa meme si certaines choses auraient du etre mieux gere).
[^] # Re: À ne pas oublier ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Quand on arrive après la bataille, on compte les morts, on tire les leçons des erreurs commises. C'est un travail important, qui est souvent négligé.
Au passage le code tournait avec certains drivers
Ce code compile et « tourne » :
#include <string.h>
int main()
{
char * orig = "toto", dest ;
strcpy(&dest, orig) ;
}
Bon d'accord, cet exemple n'est pas du même tonneau. Mais imagines-tu faire un *scanf, un write, un read, un open, etc sans vérifier qu'ils ont bien retourné une valeur attendue ? Non, évidement que non. Parce que les développeurs qui ont un peu de bouteille savent que ne pas contrôler le résultat d'une fonction, c'est s'assurer une consommation excessive de paracétamol dans un futur plus ou moins proche.
Et c'est uniquement cela que je critiquais.
[^] # Re: À ne pas oublier ...
Posté par Troy McClure (site web personnel) . Évalué à 9.
Non ce qui est réprimé c'est le donnage de leçons depuis ton mini-piedestal , leçons que tout le monde connait déjà. Ca ne sert à rien à part à te défouler et à etre désagréable avec l'auteur du journal. Un minimum de respect et de bienveillance ne fait pas de mal. Si tu veux aborder le pb de la non verification des codes d'erreurs en général, fais le dans ton propre journal, mais pas ici en rebondissant sur un quart de phrase alors que tu ne connais pas le contexte, tu ne connais pas le code, et tu ne connais la personne à qui tu adresses ton iritation.
Ce thread est lourd, et je suis lourd d'en remettre une couche, je sais.
[^] # Re: À ne pas oublier ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Je ne lis jamais les journaux publiés sur DLFP. Pourquoi en ferais-je un moi-même. Je préfère venir débattre plutôt que de râler dans mon petit coin (sur mon petit piédestal).
Je ne connais effectivement pas ce point précis du code, ça fait un moment que je n'ai pas fouiné dans Gecko.
Je m'en fous de connaître ou non la personne avec qui je discute. Ce qui m'intéresse c'est la discussion, le débat (voir le troll), les arguments échangés. Pour l'instant je m'en prends plein la gueule parce que je déplore un état de fait.
De plus, j'en veux bien plus à ceux qui m'encensent qu'à ceux qui me critiquent ouvertement. Ces derniers me font avancer, évoluer, plutôt que de croupir dans la médiocrité.
[^] # Re: À ne pas oublier ...
Posté par barmic . Évalué à 2.
Comme quoi c'est beau internet, cet univers à la tron où chaque individus à plus de morale que la plupart des prix nobels.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: À ne pas oublier ...
Posté par lolop (site web personnel) . Évalué à 3.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: À ne pas oublier ...
Posté par Antoine . Évalué à 9.
[^] # Re: À ne pas oublier ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Un segfault n'est évidement pas rattrapable. Une fonction qui échoue renvoie un code d'erreur, qui est toujours testable.
[^] # Re: À ne pas oublier ...
Posté par Anonyme . Évalué à 3.
[^] # Re: À ne pas oublier ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . Évalué à -5.
> on pourrait et devrait valider mieux les parametres avant de faire nos appels, ce qui peut eviter certains plantages, ca oui, mais il reste que les drivers ne sont jamais censes planter
En gros on ne vérifie pas suffisamment notre code, et donc ça fait planter. Nous on le fait mais eux ils ne devraient pas, parce que c'est des drivers, toussa.
Je comprend bien que les drivers sont beaucoup plus critiques que firefox, mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même.
Maintenant, ce qui est plutôt une très bonne nouvelle (au delas de tout le blabla inhérent dont il faut finalement assez peu ce soucier ;) ) :
> tout ca devrait bientot etre du passe
[^] # Re: À ne pas oublier ...
Posté par Littleboy . Évalué à 5.
La difference, c'est que d'un cote on a une application, qui tourne en espace utilisateur et qui si elle plante n'affecte qu'elle meme.
Lorsque ton serveur X plante, voir la machine entiere se vautre, ca a un peu plus de consequences pour l'utilisateur. Et comme c'est les couches basses du systeme, elles sont sensees dans une certaine mesure resister aux applications mal ecrites et qui font n'importe quoi.
[^] # Re: À ne pas oublier ...
Posté par zebra3 . Évalué à -2.
Donc les deux sont aussi critiques l'un que l'autre.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: À ne pas oublier ...
Posté par Thomas Douillard . Évalué à 2.
* dans ton propre code : tu peux te permettre de donner les préconditions et supposer que tu les respecteras lors de l'appel
* si tu distribues ton codes : tu blindes les APIS et vérifies systématiquement que les préconditions sont respectées après les appels de fonctions.
[^] # Re: À ne pas oublier ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: À ne pas oublier ...
Posté par Benoit Jacob (site web personnel) . Évalué à 9.
Pourtant, il reste que toute bibliotheque qu'une application appelle a un 'contrat' avec l'application qui definit bien clairement a qui la faute, en cas de plantage. Et la fonction glxMakeCurrent() de GLX n'est pas censee planter. Or c'est ce qui se passe avec certain drivers dans certaines circonstances rencontrees par Firefox.
Bref, encore un commentaire aggressif pour rien de la part de CrEv, merci bien (j'ai ma dose).
[^] # Re: À ne pas oublier ...
Posté par plic . Évalué à 4.
Au vu des notes respectives de vos messages, je pense pouvoir dire que beaucoup de monde te soutient.
En un mot : merci !
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . Évalué à 1.
hum, j'adore lorsqu'on rentre sur le domaine perso, c'est tellement mieux
Pour reprendre le début de ton journal "Je m'essaye à l'exercice du journal LinuxFr" il reste encore la partie style / susceptibilité à appréhender alors
Dans tous les cas je pense que tu as très mal pris mon message alors qu'il était en aucun cas méchant et encore moins personnel.
Mais bon, on peut toujours faire une petite explication de texte.
Tout d'abord :
"Sans vouloir du tout rentrer dans le style des autres réponses" -> ben oui, je trouvais que d'autres réponses partaient en vrille alors je voulais faire soft pour le coup...
"Je comprend bien que les drivers sont beaucoup plus critiques que firefox" -> donc vous pouvez tous répondre que userland, drivers, toussa ... mais je l'ai déjà écris...
"mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même." -> ben oui, désolé mais lorsqu'on lit [https://linuxfr.org/comments/1201200.html#1201200] :
"ça serait dû à Firefox, qui utilise une extension sans vérifier qu'elle est disponible (GL_ARB_ES2_compatibility) et qui accède aux "uniforms" avec des indices invalides." il y a bien faute côté mozilla. Evidemment les drivers ne devraient pas planter et faire des vérifs, mais ce genre de vérif (vérifier que la fonctionnalité est dispo) reste à faire du côté mozilla. Si le drivers devrait être capable de le gérer, mozilla ne devrait lui pas le faire non plus. Le bon côté est que cela permet par contre de corriger des bugs potentiels liés à une mauvaise utilisation.
D'ailleurs je ne faisais que reprendre tes propos : "on pourrait et devrait valider mieux les parametres avant de faire nos appels"
"il reste que toute bibliotheque qu'une application appelle a un 'contrat' avec l'application qui definit bien clairement a qui la faute"
et on rajoutera dans les règles [https://linuxfr.org/comments/1201485.html#1201485]
Et en plus, histoire que mon message initial ne soit pas mal interprété, je finissais par :
Maintenant, ce qui est plutôt une très bonne nouvelle (au delas de tout le blabla inhérent dont il faut finalement assez peu ce soucier ;) ) :
> tout ca devrait bientot etre du passe
Mais pour finir cette fois :
> Bref, encore un commentaire aggressif pour rien de la part de CrEv, merci bien (j'ai ma dose).
(ok, je devrais pas écrire la suite je vais encore probablement me faire moinser...)
Il était évident qu'en venant raconter ton histoire elle allait se faire décortiquer de tous les côtés. Et je pense que c'est bien (je ne voudrais justement pas te dissuader de recommencer car on a appris pas mal de choses). Nombre de commentaires (avec des styles peut-être plus ou moins direct - oui je parle juste de direct plutôt que d’agressif car en aucun cas ce n'était des attaques de ma part) ont permit de préciser exactement la nature des problèmes, en mettant en évidence des tords partagés même si certains ont plus de responsabilité que d'autre quant à l'issue du problème (en l’occurrence les drivers).
[^] # Re: À ne pas oublier ...
Posté par Albert_ . Évalué à 2.
Qui montre qu'il y a aussi des problemes cote drivers!
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . Évalué à 2.
* tords partagés même si certains ont plus de responsabilité que d'autre quant à l'issue du problème (en l’occurrence les drivers)
* le driver devrait le gérer
mais par contre merci d'avoir replacé ce lien
[^] # Re: À ne pas oublier ...
Posté par bubar🦥 (site web personnel) . Évalué à 2.
+ 1 sur le fait que la formulation était peut être maladroite (cela a touché Bjacob, donc c'était maladroit)
+ 1 sur le fait que tes questions, Crev, (me) semblaient pertinentes
+ 1 sur le fait que je fais parfois pareil, et que j'ai vu de nombreuses autres personnes faire et dire bien pire, sur irc
Perso je l'ai lu comme : questions pertinentes, et affirmation demandant en fait aussi une réponse. Bref le coup classique du "dans la vie réelle tu aurais vu mon sourire et mes yeux brillés, éléments indispensables à la compréhension du ton de la phrase. Ouhai mais on est pas dans la vie réelle..."
amlt
[^] # Re: À ne pas oublier ...
Posté par Antoine . Évalué à 3.
C'est une attaque gratuite. Je suis sûr que si tu rapportes un plantage de Firefox sur une entrée incorrecte (javascript foireux par exemple), ils vont essayer de le corriger.
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . Évalué à 2.
Mais oui, la logique voudrait que lorsqu'on demande à une partie externe d'être irréprochable, c'est pas pour de l'autre côté ne pas faire toutes les vérifs qui s'imposent. Ca reste à mon sens assez logique.
Mais bon, là on arrive quand même dans du bel enculage de drosophile avec multi répétition / justification des mêmes contenu...
> Je suis sûr que si tu rapportes un plantage ...
Aucun rapport.
Ha ok, je commence à comprendre ... en fait vous (je reste bien général) l'avez tous pris comme une attaque contre le (les ?) dev de firefox ... ce que ce n'était pas. Lorsque je parle de logique, je parle de logique de dev, absolument pas de la faute de quelqu'un en particulier.
/franchement ça me gave que tout soit toujours pris de manière perso, surtout qu'on aurait pu parler des problèmes, de pourquoi mozilla ne faisait pas les tests (il y a surement une bonne raison, même si c'est jusque que les drivers utilisés n'en avaient pas besoin), pourquoi c'était pas blindé côté driver, pourquoi on s'en aperçoit si tard, etc
/me doit se trouver des disclaimer pour les prochains posts techniques...
[^] # Re: À ne pas oublier ...
Posté par Antoine . Évalué à 2.
Mais non, justement, ça n'est pas la même chose. Tu compares le fonctionnement d'une fonction d'API disponible pour d'autres programmes (les drivers) avec le fonctionnement interne d'un programme (Firefox) qui prend parfois des raccourcis. Oui, prendre des raccourcis c'est pas bien, mais c'est largement pire quand ça entraîne potentiellement le crash d'un programme tiers qui a oublié de valider les paramètres qu'il envoie à une API.
Donc tu n'as pas compris mon analogie, parce que l'équivalent côté Firefox de ce bug de drivers, c'est si un bout de code javascript ou HTML donné (par exemple un truc à la syntaxe incorrecte) permettait de crasher Firefox au lieu d'avoir simplement un joli message d'erreur. Et c'est là que je dis qu'à mon avis ils seront prompts à corriger ce genre de problème.
pourquoi mozilla ne faisait pas les tests (il y a surement une bonne raison, même si c'est jusque que les drivers utilisés n'en avaient pas besoin
La bonne raison dans ces cas-là c'est quasiment toujours la paresse (et l'utilisation d'un langage bas niveau sans système d'exceptions :-)).
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . Évalué à 1.
> La bonne raison dans ces cas-là c'est quasiment toujours la paresse
ha ben voilà, on y arrive ! (en fait je pensais qu'on y serait arrivé beaucoup plus tôt)
Pour reprendre ce que disais tankey, mes affirmations (maladroites) visaient surtout à ce qu'on réponde quelque chose du genre (ou tout autre justification qu'elle qu'elle soit)...
/disclaimer : je sais bien que l'affirmation d'Antoine n'est pas relative à firefox, pas la peine de croire que je prend ça comme une réponse sur le problème de firefox /disclaimer
Et oui, si on ne fait pas ses propres vérifs par paresse, on ne peut absolument pas exiger que d'autres fassent les leurs !
[^] # Re: À ne pas oublier ...
Posté par Albert_ . Évalué à 3.
ha ben voilà, on y arrive ! (en fait je pensais qu'on y serait arrivé beaucoup plus tôt)
Et le probleme du temps cela ne vous traverse pas l'esprit aussi? Il n'y a que 24h dans une journee et surement beaucoup moins pour programmer et parfois d'autre imperatif dans la vie qui contrairement a un logiciel ne peuvent pas attendre (les momes par exemples).
[^] # Re: À ne pas oublier ...
Posté par lolop (site web personnel) . Évalué à 8.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: À ne pas oublier ...
Posté par CrEv (site web personnel) . Évalué à 2.
le "on y arrive" fait référence à n'importe qu'elle raison qui pourrait être donné, et non uniquement "la paresse". D'ailleurs il y avait un zoli disclaimer qui précisais bien que je ne prenais pas ça comme une réponse pour firefox bla bla bla
Donc oui, le temps peut être une raison, la paresse aussi, être mauvais aussi, etc. Il peut y avoir plein de raison, mais j'aurais bien voulu connaître la vrai ...
[^] # Re: À ne pas oublier ...
Posté par Albert_ . Évalué à 3.
La paresse ca veut dire rien foutre et c'est legerement pas tres sympa et honnetement cela sert a quoi de savoir qu'il a proscraniser pendant 2 mois ou que la veille du jour ou il da ecrit ce bout de code, il a passe une nuit blanche parceque son mome etait malade ou 1000 autres raisons. Le logiciel a ete corrige avant sa sortie et donc les differentes beta et RC servent a quelque chose. On parle d'une version de developpement je te rappelle.
[^] # Re: À ne pas oublier ...
Posté par Xavier Bestel (site web personnel) . Évalué à 1.
Tu rigoles ou quoi? Puissance de feu? Un journal linuxfr, tu appelles ca de la puissance de feu? Et tu ne crois pas que les devs de xorg peuvent aussi faire des journaux linuxfr si ca leur chante?
Non non, je parlais plutôt du foin sur Slashdot & co. Effectivement, Linuxfr c'est bien mais .. heuu .. un peu moins visible peut-être ?
[^] # Re: À ne pas oublier ...
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
Ces sites ont tous repris en echo une phrase effectivement ecrite par un developeur de Mozilla (Boris) mais qu'il avait ecrite en commentaire sur une entree de blog:
https://hacks.mozilla.org/2011/01/firefox-4-beta-9-a-huge-pi(...)
Il n'avait donc absolument pas l'idee que ca serait repercute avec un tel echo.
[^] # Re: À ne pas oublier ...
Posté par Albert_ . Évalué à 3.
Enfin good luck et t'inquiete pas nous sommes beaucoup a apprecier les explications du problemes et les efforts mis derriere pour le resoudre.
[^] # Re: à propos
Posté par Albert_ . Évalué à 2.
http://linuxfr.org/comments/1201078.html#1201078
Pour les drivers Catalyst il faut poser la question a AMD ce sont les seuls qui puissent y repondre (bon courage...). Pour les drivers libres ATI un des personnes en charges est deja en train de regarder (et de trouver) les problemes (articles phoronix).
Donc pour repondre a ta question: Pour les drivers libres tous les espoirs sont permis pour les autres on peut juste faire une reponse de normand.
[^] # Re: à propos
Posté par Clément . Évalué à 1.
Mozilla n'activera jamais par défaut WebGL sur les machines équipées d'une ATI ?
[^] # Re: à propos
Posté par Albert_ . Évalué à 2.
[^] # Re: à propos
Posté par O'neam Anne . Évalué à 3.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: à propos
Posté par reno . Évalué à 2.
Bien sûr ça mettrait à genoux la machine, mais bon c'est mieux que rien..
[^] # Re: à propos
Posté par Rémi Birot-Delrue . Évalué à 1.
Par contre, pour les machines utilisant les drivers libres radeon ou radeonhd, c'est une autre histoire…
[^] # Re: à propos
Posté par Albert_ . Évalué à 2.
[^] # Re: à propos
Posté par Benoit Jacob (site web personnel) . Évalué à 4.
Je ne sais pas pourquoi Asgeir a dit "jamais".
Les devs du pilote ATI proprio ont meme repondu dans mon fil de discussion sur mesa-dev.
[^] # Re: à propos
Posté par houra . Évalué à 3.
OSEF des Catalysts . On est pas sous Windows !
On veut des drivers libres qui continuent de progresser au rythme où ils progressent actuellement.
Sedullus dux et princeps Lemovicum occiditur
# Hmm
Posté par gnumdk (site web personnel) . Évalué à 10.
Mais ca serait quand même pas mal de pouvoir migrer un journal en dépêche quand ce dernier en vaut le coup, j'en vois deux dernièrement:
- Ce dernier
- Le journal sur Xfce
Cela permettrait de garder les commentaires du journal et de pas avoir à tout répéter dans la news...
[^] # Re: Hmm
Posté par Manuel Menal . Évalué à 1.
Je pense qu'une plus grande interaction journaux / dépêches est globalement une bonne idée : n'hésite pas.
[^] # Re: Hmm
Posté par gnumdk (site web personnel) . Évalué à 2.
Effectivement, je ne savais pas, je note ceci dans ma "basket" ;)
[^] # Re: Hmm
Posté par Zenitram (site web personnel) . Évalué à 7.
Le hic actuel est qu'on perd tous les commentaires (cf tankey qui doit faire des copier coller du fait que le débat à déjà eu lieu sur un sujet). Et certes il y a des trolls, mais beaucoup de commentaires LinuxFriens ont beaucoup de valeur ajoutée au journal, ne transférer que le journal, sans les commentaires, c'est dommage.
[^] # Re: Hmm
Posté par claudex . Évalué à 5.
« 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: Hmm
Posté par Zenitram (site web personnel) . Évalué à 4.
Effectivement, les arguments contre sont pertinents, cruel dilemme.
[^] # Re: Hmm
Posté par nomorsad . Évalué à 1.
Donc pour ceux qui, comme moi, lisent les journaux et les dépêches, on voit double et c'est un peu horripilant de suivre les mêmes discussion sur 2 articles différents!!
Autre solution, pourquoi ne pas importer les commentaires du journal sous unue autre forme pour les distinguer (couleur, block spécial caché par défaut,...)
En écrivant présentement ce commentaire, je me rend compte en même temps que ca va allourdir l'interface, surtout pour un nouveau venu.
Pourquoi ne pas mettre une option dans les préferences? (connaissant templeet, vous allez sûrement me dire que ça sera pour la version RoR ;)
[^] # Re: Hmm
Posté par patrick_g (site web personnel) . Évalué à 7.
Pas mal de gens sont abonnés au fil RSS des dépêches et ne lisent pas les journaux.
Oui moi aussi ça me dépasse qu'on ne passe pas sa journée à lire LinuxFR mais bon c'est leur choix ;-)
[^] # Re: Hmm
Posté par gnumdk (site web personnel) . Évalué à 3.
[^] # Re: Hmm
Posté par MarbolanGos (site web personnel) . Évalué à 2.
# Simplement tout faire par OpenGL
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Je me souviens de mon expérience avec OpenGL il y a quelques années : on avait passé le moteur du jeu Wormux de SDL à OpenGL (lors du passage de ClanLib 0.6 à 0.8 si je me souviens bien). Plusieurs joueurs sont passés de 30 à 50 images par seconde à moins d'une image par seconde : jeu injouable. (Par contre, certains joueurs ayant la bonne carte graphique avec le bon pilote -genre Nvidia et le pilote proprio- avaient un jeu plus rapide.)
Les développeurs de ClanLib voulaient simplifier leur code en imposant OpenGL... sauf que les pilotes OpenGL sous Linux, c'était pas ça. J'avais tenté de réintégrer le support de SDL dans ClanLib, mais c'était assez complexe, je n'avais pas eu le temps de finir et les développeurs ClanLib ne m'ont pas vraiment soutenu.
Finalement, on a pris la sage décision de migrer directement à SDL, et depuis tout va bien côté rendu graphique :-) Il me semble d'ailleurs que SDL peut utiliser OpenGL en interne (si on active une certaine option ?).
[^] # Re: Simplement tout faire par OpenGL
Posté par Maxime G (site web personnel) . Évalué à 5.
Ça va donner pour les pilotes (dont les dévs voudront bien regarder ça) une bonne base commune.
Cela amène un grand espoir, non ?
[^] # Re: Simplement tout faire par OpenGL
Posté par Albert_ . Évalué à 2.
mais bon un jour ou l'autre il faut faire table rase pour pouvoir avancer et vu le merdier que sont les drivers c'est peut etre le moment.
[^] # Re: Simplement tout faire par OpenGL
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Il y a en effet un projet de rajouter des extensions a WebGL mais pour le moment il n'y en a qu'une (proposee par Google) et nous ne l'implementons pas encore.
Donc, bugs mis a part (bugs dans firefox, dans les pilotes, dans les tests) tout le monde devrait avoir les memes resultats.
[^] # Re: Simplement tout faire par OpenGL
Posté par Albert_ . Évalué à 2.
[^] # Re: Simplement tout faire par OpenGL
Posté par Mathias Bavay (site web personnel) . Évalué à 4.
Ce qui signifie que d'ici à très peu d'années, on ne rencontrera sans doute plus d'ordinateurs sans carte 3D basique, même pour du matériel suffisamment ancien pour qu'il ne coute plus rien ou pour une installation ancienne!
Mathias
PS: et j'ai maintenu un PC sur lequel une matrox millemium 1 tournais jusqu'à noël dernier, mais c'était vraiment par manque de temps pour mettre à jour...
[^] # Re: Simplement tout faire par OpenGL
Posté par Clément . Évalué à 1.
Si on compte que les ordinateurs portables ont une durée de vie un peu inférieure, je dirais même qu'il faudrait compter un peu moins de 3 ans avant du matériel compatible partout.
[^] # Re: Simplement tout faire par OpenGL
Posté par jbbourgoin (site web personnel) . Évalué à 2.
[^] # Re: Simplement tout faire par OpenGL
Posté par M . Évalué à 7.
C'est bien beau d'avoir une carte 3D, mais sans driver c'est la même chose qu'une carte pas 3D...
Et quand je vois le mal que les dev ont pour supporter la 3D sur une génération donnée, je me dis que c'est pas gagné.
Et les pilotes proprio ne maintienne pas le vieux matos
# html5 & co
Posté par M . Évalué à 3.
Sauf qu'avant au pire pour accéder a des fonctionnalité avancé il fallait flash, maintenant il va falloir :
- un navigateur a jour (exit les vieux navigateur)
- un navigateur qui supporte les bon codecs
- un os qui supporte correctement opengl
[...]
Si les webmaster ne prévoit pas un mode de rétro compatibilité [1], on risque de ce retrouver avec un web de moins en moins portable (et tout ca pour des fonctionnalités parfois bien discutable) .
[1] on me souffle a l'oreille que la nouvelle version de linuxfr RoR en html5 ne fonctionne pas avec les broswer un peu vieux.
[^] # Re: html5 & co
Posté par Benoit Jacob (site web personnel) . Évalué à 7.
Ca, il t'en faut un de toute facon, ne serait-ce que pour des raisons de securite (mises a jour).
- un navigateur qui supporte les bon codecs
Si les codecs vraiment libres tels que WebM et Vorbis prennent le dessus, ce probleme sera regle: tout le monde pourra les supporter a peu de frais.
- un os qui supporte correctement opengl
Seulement si tu veux utiliser les fonctionnalites en question.
Si les webmaster ne prévoit pas un mode de rétro compatibilité [1], on risque de ce retrouver avec un web de moins en moins portable (et tout ca pour des fonctionnalités parfois bien discutable) .
Il existe deja des bibliotheques JS qui utilisent WebGL quand il est disponible et Canvas/2D sinon. C'est aussi ce que fait la version experimentale de google streetview.
Flash, pour toi, c'etait portable? Les gens font deja des jeux videos en Flash, aujourd'hui. La question est de savoir si tu veux que Flash continue d'etre LA plateforme pour les applications graphiques pseudo web, ou si tu veux pas plutot qu'on ameliore les standards du web pour qu'il n'y ait plus besoin de Flash.
[^] # Re: html5 & co
Posté par Albert_ . Évalué à 5.
Vu que Google semble degager tout ce qui a trait a H264 cela semble bien parti tout de meme. Je me demande si la decision de faire cela ne vient pas du ras le bol de se faire attaquer pour des brevets a la con par tout le monde. On peut d'ailleurs remarquer que Google n'a, pour le moment, toujours pas utilise ses brevets en mode attaque!
[^] # Re: html5 & co
Posté par Antoine . Évalué à 5.
Ils devraient ajouter un <blink> de compatibilité avec Netscape Communicator.
[^] # Re: html5 & co
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.