Benoit Jacob a écrit 217 commentaires

Voila, maintenant tu dois être CPU-bound, alors essaye Firefox Nightly et là avec asm.js les perfs devraient être vraiment bonnes.

Sous X11 pour avoir des perfs correctes dans Firefox, il faut activer l'accélération matérielle du compositeur: va dans about:config et mets layers.acceleration.force-enabled à true.

Bien sûr l'idée est qu'on aura activé ça par défaut d'ici que les jeux Web se répandent. C'est déjà activé sur toutes les autres plateformes, mais sous X11 on a des problèmes compliqués, voir https://wiki.mozilla.org/Platform/GFX/X11GLLayers

D'autre part Firefox 19.0 n'a pas encore les optimisations asm.js. Pour ça il faut Firefox 22 (en Nightly pour le moment)

Tu parles d'intrasec javascript ? Je croyais qu'il était question de créer une lib javascript utilisant des tableaux pour faire des calculs dessus avec des instructions SIMD.

On verra quelle forme ça prend, mais oui je pense que le plus probable est que ça soit des constructions JS interprétables comme des intrinsics. Après, je ne fais que spéculer, ce n'est pas moi le spécialiste.

Je croyais que openMP devenait très courant. C'est quand même plus propre que pthread.

Je ne suis pas très au courant des derniers développements. Mais on ne peut pas nier que pthreads (ou APIs de threads similaires) est de loin la façon la plus répandue de faire du multithreads en-dehors du monde scientifique.

J'imagine que cela n'existe pas encore dans les codes de jeu actuels. Mais si c'est bien un port de openCL pour le web, c'est quand même le meilleur moyen d'exposer une puissance de calcul parallèle complexe et changeante, à base de multicpu, SIMD + GPU.

Je ne sais pas trop. OpenGL 4.3 et ses «compute shaders» risque de faire pas mal d'ombre à OpenCL. Et quand on voit que ce n'est que maintenant en 2013 avec Unreal Engine 4 que ce genre de choses commence à être réellement utilisé dans les jeux… je ne suis pas convaincu que WebGL, avec ses bons 5 ans (voire 10 ans) de retard sur OpenGL, en ait besoin à court terme i.e. on a d'autres problèmes plus urgents.

Emscripten est basé sur LLVM, et supporte donc tous les langages qui ont un front-end LLVM. Par exemple, pour compiler du C/C++ on utilisera généralement Clang, qui supporte très bien le C et le C++ (y compris une bonne partie du C++11), va donc voir leur site web… et oui, bien sûr, C est un langage séparé du C++, Clang le sait très bien…

même avec les bidouilles à la asm.js, on n'atteindra jamais la vitesse du code natif.

Asm.js permet de s'en approcher d'assez près, comme expliqué plus haut. Je pense que les liens ci-dessus donnent assez d'informations vérifiables là-dessus. On ne sait pas encore à quel point on va pouvoir s'en approcher, mais on est déjà à 50% du code natif, après seulement 3 mois de travail d'une seule personne travaillant sur le compilateur.

le navigateur bouffe une quantité non négligeable de RAM.

Non négligeable certes, mais raisonnable tout de même. C'est ce qui permet aux prototypes de téléphones Firefox OS que j'utilise, dotés de seulement 256 M de mémoire (pour nous forcer à optimiser), de fonctionner correctement, alors que tout y tourne dans Gecko.

ça va encore plus inciter les développeurs à rendre les jeux injouables hors ligne.
[…]
demander une connexion permanente.

Non! Aucun rapport entre «être un jeu Web» et «demander une connexion permanente»:
- il y a beaucoup de jeux Web qui ne demandent pas de connexion permanente, comme par exemple presque tous les jeux Firefox OS et Chrome Web Store, qui sont installables en local.
- réciproquement il y a beaucoup de jeux non-Web qui demandent une connexion permanente, par exemple le dernier jeu que j'ai acheté, Might&Magic Heroes 6.

le web, c'est aussi une excellente plateforme de tracking et de publicité.

On verra. En attendant je vois beaucoup de pub aussi sur les jeux sur iOS/Android non-Web… Pour le tracking, c'est un souci très important à prendre en compte, on verra. Mozilla a déjà fait un pas important en bloquant les biscuits émis par des tiers.

En fait je parlais uniquement de SIMD. Cela va revenir au support d'«intrinsics» similaire à ce que les compilos comme GCC supportent pour SSE/Neon. Les difficultés à surmonter vont être de trouver des «intrinsics» portables et efficaces à la fois (pas question de faire des intrinsics spécifiques à SSE par exemple) et de trouver la bonne façon de représenter un __m128 et autres types de paquets.

Pour le parallélisme (je n'avais pas vu cette partie de ton commentaire) plusieurs pistes sont en train d'être explorées. Gecko contient une implémentation expérimentale de RiverTrail. Une autre approche est simplement d'exposer une API du type pthreads: c'est moche, mais c'est 99% du parallélisme dans le monde réel. Il y a déjà les Web Workers mais ils sont dépourvus de mémoire partagée (ce qui est aussi leur beauté). Enfin une autre approche est WebCL, mais il est peu probable que les fabriquants de navigateurs l'adoptent massivement à court terme.

C'est la question à un million de dollars. Je l'ai posée la semaine dernière aux spécialistes, ils pensent que quelque chose dans ce goût-là va se passer probablement plus tard cette année, mais ils ont quelques problèmes à régler au préalable.

Quelques liens que j'aurais dû mettre:
- le blog de Clochix, en fait plus complet que son journal que j'ai lié ci-dessus
- un article dans la presse relatant Unreal Engine 3 tournant dans le navigateur

J'ai aussi oublié de préciser que la démo Unreal Engine 3 devrait être publiée par Epic sous quelques semaines. D'ici-là malheureusement il faut se contenter de regarder la vidéo… ou bien il fallait venir au GDC la semaine dernière ;-)

Le nombre d'employés ne veut rien dire. Ces 900 personnes ont sans doute pour beaucoup deja pas mal de choses à faire.

Alors que les employés de Mozilla n'ont rien à faire?

Ils vont pas continuer le developement de leur propre moteur juste pour le plaisir, il faut que ca represente un interet suffisement important.

Personne ne nie qu'Opera considère servir son intérêt avec ce changement. Je dis que 1) c'est au détriment du Web en général et 2) l'annonce d'Opéra prétendant qu'ils vont conserver leur influence sur les standards du Web est vide de sens. Ce n'est pas pour rien que le grand spécialiste des standards d'Opera vient de partir pour Mozilla.

proche de mozilla != mozilla

Sur Internet il y a des trolls de tous bords… et des personnes qui se disent proches d'un projet libre pour se donner de l'importance, il y en a aussi…

Mais quelle aurait été la réaction si opéra passait à gecko ?

Comme il n'en a pas été question, je ne peux être certain de rien, mais il me semble très probable que si Opéra avait approché Mozilla à propos de ça, Mozilla n'aurait pas été chaud parce que 1) moins de diversité de moteurs c'est mal (Mozilla n'essaye déjà pas trop de faire adopter Gecko par d'autres navigateurs en général, alors encore moins par l'un des derniers navigateurs à moteur indépendant!) et 2) Opéra étant une plus grosse entreprise que Mozilla et ne partageant pas ses valeurs, ç'aurait été une liaison dangereuse pour Mozilla. Et si Opéra avait fait ça sans approcher Mozilla au préalable, ç'aurait eu tout l'air d'un fork hostile.

Et je trouve qu'il y a un peu de mauvaise fois dans tout ça, car au final Opéra vient de passer sur un moteur open source (le leur ne le sera peut-être pas mais la base, webkit, l'est). Et c'est très bien.

Je ne vois pas de mauvaise foi ici, mais il y a la question intéressante de savoir si un moteur à code ouvert comme WebKit est forcément "le Bien" comparé à un moteur à code fermé comme Presto. Je pense que l'ouverture du code n'est qu'un facteur parmi d'autres, et le nombre de moteurs indépendants est un autre facteur qui me semble particulièrement important quand ce nombre tombe à seulement 3. Imagine une situation où un unique moteur à code ouvert serait en situation de monopole. Je dis que ce serait une moins bonne situation que si on avait disons 5 moteurs en lice, dont seulement disons 3 seraient à code ouvert. Car ce qu'on perdrait en ouverture de code, on le regagnerait en standardisation. Si un unique moteur domine trop longtemps, le risque est que la notion de standards s'évapore et qu'il devienne impossible pour un nouveau moteur indépendant d'émerger.

Opera est une petite entreprise tout de même.

900 personnes, soit plus que Mozilla Corporation (Puisqu'on parle du fait d'entretenir un moteur indépendant).

par certains côtés ils perdent en indépendance

Ils ne passent pas seulement «à WebKit», ils passent à Chromium. Google étant déjà en mesure d'allouer des ressources essentiellement illimitées à Chromium, il n'y a aucune raison d'espérer qu'ils soient intéressés par les éventuelles contributions d'Opera.

Je veux dire, quel choix auraient-ils pu faire ?

Continuer de développer leur moteur indépendant? Ils ont 900 personnes, contre 750 pour Mozilla (dont seulement 150 sur Gecko): ce n'était donc pas impossible.

Gecko ? Ca fait bien longtemps que personne n'essai de l'embarquer

On n'a effectivement pas de politique d'encourager les gens à utiliser Gecko en dehors des logiciels de Mozilla, c'est un sujet intéressant, mais c'est hors sujet ici car Opera a assez d'ingénieurs (plus que Mozilla!) pour gérer ça (s'ils forkaient Gecko, leur fork aurait au moins autant de contributeurs…)

Alors lorsque je vois des personnes proches de mozilla se plaindre, j'ai un peu envie de leur demander ce qu'ils ont fait pour que ce ne soit pas le cas.

Si tu avais entendu une seule personne de Mozilla suggérer qu'ils auraient dû passer à Gecko, ton commentaire aurait été fondé. Mais comme ce n'est pas le cas…

À Mozilla on pense et on dit que pour le bien du Web il est dommage de tomber à seulement 3 moteurs. On est dans une situation d'oligopole et ça empire.

Liens:
https://brendaneich.com/2013/02/why-mozilla-matters/
http://robert.ocallahan.org/2013/02/and-then-there-were-three.html

J'ai dit qu'avoir une équipe d'au moins 50 personnes était une condition nécessaire; je n'ai pas dit que c'était une condition suffisante.

Il ne s'agit pas de processus ici (du moins pas sur le bureau, pas pour le moment) mais de threads.

La seule plateforme où il s'agisse réellement d'un processus séparé est Firefox OS.

Ce que Cédric a écrit est vrai, et le fait qu'il ait été moissé à -2 en dit long sur les abus du système de modération de LinuxFR. Certains standards n'auraient jamais dû devenir des standards parce qu'ils sont incapables d'offrir ce qu'ils prétendent offrir. C'est le cas des SVG Fonts, qui ne sont à la rigueur appliquables qu'aux langues à écriture simple (alphabet latin, japonais, etc) et certainement pas aux écritures complexes (arabe, persan, langues indiennes). Voir ce commentaire de Behdad:
https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c49
Ce n'est pas à Mozilla qu'il faut s'en prendre, c'est aux idiots qui ont conçu une technologie inadaptée au Web et qui l'ont fait accepter par le W3C.

Si tu penses vraiment que WOFF est une 'technologie moisie' comparée aux fontes SVG, tu es à côté de la plaque, mais je penses que tu trolles.

C'est pour ça que Firefox Mobile a été réécrit pour pouvoir afficher son UI instantanément sans attendre le chargement effectif du moteur de rendu des pages Web.

Ton commentaire montre que tu n'as pas lu le mien.

Valide ou pas, je crois qu'il remonte à plus de 10 ans donc il va bien finir par expirer.

Non! Mesa ne met qu'un pied dedans en prenant 2 précautions:
- 1) en isolant la compression dans une bibliothèque séparée, libtxc_dxtn.so.
- 2) en demandant à ce qu'une variable d'environnement soit définie pour activer le moindre support de S3TC.

Si je comprends bien le but de S2TC est de permettre de supporter la compression sans avoir à prendre ces précautions.

Pas mal d'appareils gèrent le ETC1 en effet, mais c'est ETC2 qu'il nous faut, et je n'ai pas vu d'appareil, Mali-400 ou autre, le gérant. Je suppose que le suppot d'ETC2 va se répandre avec OpenGL ES 3.0, mais ça veut dire qu'il faudra attendre plusieurs années avant que ça ne représente l'essentiel du marché.

Mesa fait plus que ça: elle implémente la fonction glCompressedTexImage2D de OpenGL qui permet de compresser des données de texture non compressées. C'est cette partie dont l'implémentation est sujette à brevet même si le matériel supporte S3TC, parce qu'il faut faire la compression en logiciel. C'est cette partie qui est absente de l'extension WebGL, qui n'est pas très utile pour les jeux vidéo, et que je suggère d'omettre d'une variante de l'extension OpenGL.

Apparemment ils doivent aussi porter un peu sur la compression, puisque le message sur la liste de diffusion dit:

• when an uncompressed texture is uploaded as a compressed format, it is converted using the S2TC encoder, which typically yields less quality than a S3TC encoder, but still renders correctly and usually "good enough" (see screenshots on my wiki)

En gros ce que je dis c'est que la compression par le GL n'est déjà pas une fonctionnalité très utile en soi pour les jeux vidéo (et pour la plupart des applications), et donc l'idée de faire un compresseur castré qui évite les brevets au prix d'une qualité inférieure ne va sembler intéressante qu'à un marché limité, en tout cas probablement pas aux éditeurs de jeux vidéo (la dernière phrase de ta dépêche suggère que Valve est intéressé par S2TC, peux-tu donner une source?)

Peux-tu me citer un seul appareil mobile disponible sur le marché qui offre effectivement le support de ETC2 dans les bibliothèques OpenGL ES 2 livrées dessus?

Parce que j'avais regardé il y a quelques mois et j'en avais trouvé zéro. Si le support de ETC2 était largement répandu, on n'aurait pas choisi PVRTC et ATC comme formats mobiles à exposer par WebGL en plus de S3TC pour bien couvrir le marché.

Exactement! Mon argument était que ceci suffit à couvrir les besoins des jeux vidéo tout en évitant les difficultés avec les brevets, et j'aimerais donc voir Mesa spécifier une extension OpenGL n'offrant que ça, disons calquée sur la spécification de l'extension WebGL, et la rendre toujours disponible du moment que le matériel sait le faire.

Au fait, note aussi que pour activer le support de S3TC par Mesa, il suffit de définir une variable d'environnement… ce que Firefox fait depuis la version 16 fraîchement débarquée.