Bjacob 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🦥 . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. É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.