Benoit Jacob a écrit 217 commentaires

non, Brian dit "failures" ce qui veut dire "echecs" (des tests), pas plantages.

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.

Je crois que certaines distros ont deja des depots pout les betas/nightlies de firefox 4: au moins fedora.

Ensuite s'il y a quelque chose qu'on pourrait faire pour rendre cette tache plus facile, ca serait interessant a savoir... je suppose que le point le plus epineux doit etre la gestion des permissions pour les mises a jour automatiques; peut etre qu'un peu de coordination avec les distros permettrait de trouver un compromis. J'avoue ne pas avoir regarde comment faisait Fedora.

Tres bon ca, merci. De mon cote je vais essaye une ou 2 petites modifs pour moins declencher les crashs dans les pilotes existants, et en route vers le de-blocage.

Par contre pourquoi il y a plus de test sur Nvidia que sur intel (dans l'email il y a >5000 tests)?

Parce que tu as "5 timed out" et les sous-tests de ces pages n'ont pas etes comptabilises.

Justement, ces temps ci je n'ai pas autant de temps pour Eigen que je le voudrais...

Comme le dit Glisse, en fait ils avaient deja 'Piglit' grace a laquelle ils passaient deja 99% des tests WebGL. Mais oui, c'est toujours bon d'avoir plus de tests qui montrent de nouveaux plantages, comme ici.

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

Je dirais meme 99%. Des que les plantages sont resolus, on va pouvoir 'whitelister' plein de trucs!

Merci beaucoup, je regarde des que possible et je te tiens au courant.

Oui, ces bugs sont 'en mauvais etat', je ne m'en suis pas trop occupe ces derniers jours.

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.

Oh t'abuses un peu, la situation n'est pas symetrique! C'est bien d'un bug dans le pilote qu'on parle, pas dans Firefox. Et puis, encore une fois, ce blocage des pilotes juges plantants, c'est temporaire, c'est juste une necessite pour sortir firefox 4, et pour la plupart des utilisateurs WebGL n'est pas encore utile.

Mais regarde, par rapport a un jeu comme Doom, une batterie de tests comme celle de WebGL va tester TOUS les formats de textures, TOUTES les combinaisons possibles tordues de FBOs avec des 'attachments' pourris, toutes les combinaisons possibles de textures pourries (bonjour les regles de opengl ES pour l'echantillonage des textures NPOT...) etc... on teste meme plein de trucs bizarres en GLSL: toute implementation de WebGL doit etre capable de valider les shaders avant de les passer a OpenGL.

Juste pour expliquer en quoi c'est tres different du type de test offert par un jeu video.

Mince alors, je suis piste!

Hm. Toutes les implementations de WebGL creent 1 contexte OpenGL par contexte WebGL. C'est quasi impossible de faire autrement (multiplexage tres tres lourd).

Par contre, les bizarreries de Javascript font que chaque implementation est libre de tuer les contextes WebGL (et donc OpenGL) non-references quand elle le veut. Et il est vrai que, quand on execute la batterie de tests WebGL, qui execute environ 100 scripts a la suite, chacun creant un contexte WebGL, l'implementation de Firefox a souvent tendance a garder en vie un certain nombre de contextes avant de les detruire tous d'un coup (ce qui les makecurrent() et fait quelques glDeleteXxx()). On est alles jusqu'a plus de 100 contextes en meme temps, ce qui je l'avoue est stupide, mais c'est tres nouveau pour Javascript tout ca.
https://bugzilla.mozilla.org/show_bug.cgi?id=617453

Ceci n'explique cependant pas du tout les plantages qu'on a eus des l'initialisation du premier contexte WebGL :)
https://bugzilla.mozilla.org/show_bug.cgi?id=616416
https://bugzilla.mozilla.org/show_bug.cgi?id=589546

Que je comprenne bien. Ca veut dire que vous (mozilla ?) êtes en train d'intégrer une fonctionnalité basée sur la 3d sans avoir une batterie de pc avec différentes cartes pour voir ce que ça donne ?

Nous n'avons effectivement pas de batterie de machines pour tout tester. Par contre, nous avons des outils tres puissants pour etudier les plantages des utilisateurs:
http://crash-stats.mozilla.com/products/Firefox
et on a 1 million de beta-testeurs pour nous envoyer des rapports de bugs.
Donc lorsqu'il s'agit de desactiver une fonctionnalite instable, on a beaucoup de donnees.


Et dans le cas où ça fonctionne sous chrome, pourquoi ne pas reprendre le même principe ?

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.


(Apres je n'arrive pas a comprendre la fin de ton message, je ne pense pas rouler qui que ce soit dans la farine)

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.

"Juste pour precision, webgl semble marcher sans probleme avec chrome et les driver open source"

En effet, ca m'a pas mal surpris:
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.


"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."

Mais non, justement, on n'en cree pas plus que necessaire. 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.


Ce que je trouve domage dans cette histoire c'est que visiblement aucun dev firefox n'a jamais essaye avec les drivers open source


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.


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...


Je ne voulais pas insister sur cet aspect la, et c'est sur que les pilotes libres semblent tres pres de marcher. Mais il reste que les pilotes libres sous linux restent de loin la plateforme ou on a eu le plus de plantages: de ce point de vue, effectivement, ca 'ne marchait pas'. Ensuite je veux bien admettre que le fait que ca marche pour Chrome montre que les plantages n'etaient pas si triviaux.

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/webgl/sdk/tests/webgl-conformance-tests.html

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.

on a enregistre mozilla.42, redirigeant vers mozilla.org...

j'ai aussi enregistre eigen.42 qui redirige vers eigen.tuxfamily.org, grace au staff de tuxfamily.

Bref 2 projets de plus vers la domination totale...

> en plus de ne pas s’embêter à embêter les geeks qui veulent jouer avec HTML5 (en les empêchant de jouer avec les vidéos déjà sur le serveur pour Flash, soit... H.264).

A Mozilla on a le courage de ne pas soutenir des technologies qui vont contre l'interet general. On ne fait pas ca pour embeter les gens.

Desole de te decevoir, mais apres la sortie de FF4, on va adopter un cycle beaucoup plus rapide avec 3 sorties par an. Enfin, ca ne sera toujours pas autant que Chrome avec ses 8 sorties par an...

En fait, il est (encore et toujours) trop tot pour benchmarker les performances javascript de firefox 4, car le travail dans cette direction est effectue dans des branches separees de la branche 'mozilla-central' qui se retrouve dans les betas.

Tu peux cependant voir des benchmarks representatifs du travail effectue dans ces branches, ici:
http://arewefastyet.com/

L'integration de ces branches se fera tres tres bientot...

Au temps pour moi.

Je me suis completement plante ci-dessus quand j'ai dit que le support de WebM avait ete back porte. J'ai confondu avec les plugins hors-processus (OOPP).

En effet, WebM est seulement supporte dans les betas de Firefox 4.

Desole.

Merci beaucoup!

En fait, si tu pouvais ajouter un commentaire a ce bug avec ta version precise de driver (10-7-1 c'est un numero de version ca? C'est la meme chose que 1.7.1?) ca serait tres utile. Le fait que tu aies le meme bug avec un driver different indiquerait que le probleme est de notre cote.

Ouah, super rapport tres detaille, exactement ce qu'il nous faut. Par "composant Core:Graphics" je voulais dire que quand tu enregistres un nouveau bug,

https://bugzilla.mozilla.org/enter_bug.cgi

clique d'abord sur le produit "Core", puis dans "component" clique sur Graphics.

Mentionne bien ta version de driver et MOZ_ACCELERATED=1.

Merci!

ne manquent comme navigateurs majeurs que Firefox

Ah non, j'oubliais: le support de WebM a ete back-porte a Firefox 3.6 dans une mise a jour mineure, donc en WebM est bel et bien supporte dans une version stable de Firefox. Ensuite je ne sais pas trop ce que ca a donne avec les distros linux qui (c'est comprehensible) n'aiment pas trop voir de tels ajouts de fonctionalites dans des versions mineures.