Entretien avec Ryan Gavin, directeur d'Internet Explorer chez Microsoft

Entretien avec Ryan Gavin, directeur d’Internet Explorer chez Microsoft

La navigation n’est pas une fonctionnalité de « seconde zone »

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

15/11/2012 7 minutes
103

Entretien avec Ryan Gavin, directeur d'Internet Explorer chez Microsoft

Internet Explorer 10 est disponible depuis le 26 octobre avec Windows 8. Bien que de nombreuses actualités soient apparues depuis, nous nous sommes entretenus avec Ryan Gavin afin d’en apprendre davantage sur certains points précis.

 

Internet Explorer 10 marque un nouveau virage dans l’évolution du navigateur de Microsoft. Il s’agit d’une version hybride disponible en deux interfaces : l’une, classique, pour le bureau, l’autre, Modern UI, pour l’utilisation tactile. Microsoft a en outre largement insisté sur la prise en charge des technologies du web. On notera pour rappel la prise en charge :

  • De plusieurs éléments CSS3 tels que grid, flexbox, multi-column, positioned floats, regions, et hyphenation
  • Des effets visuels CSS3 : Text Shadow, 3D Transforms, Transitions, Animations et Gradient
  • Des SVG Filter Effects
  • De technologies diverses encadrant le HTML5 : la File API, le Sandboxing, le Drag-drop, les Web Workers, les Web Sockets, Application Cache, IndexedDb ou encore le Strict mode de l’ECMAScript 5.

Enfin, Internet Explorer 10 bénéficie d’une augmentation significative de ses performances.

ryan gavinPas de mise à jour avant Internet Explorer 11

Nous nous sommes intéressés à certains points particuliers qui génèrent régulièrement des questions. Le premier d’entre eux est la fréquence des mises à jour. On le sait, Internet Explorer a toujours fonctionné sur la base de versions majeures que seules des mises à jour de sécurité viennent modifier. Nous avons donc voulu savoir si schéma changerait avec Internet Explorer 10, notamment pour répondre à l’évolution rapide des standards du web. Ryan Gavin s’est montré clair :

 

« Nous publions des mises à jour mensuelles, essentiellement pour la sécurité et la fiabilité, et c’est notre approche depuis longtemps pour Explorer. En ce qui concerne la prise en charge des technologies émergentes, nous préférons publier des Platform Previews pour que les développeurs puissent essayer de nouvelles capacités. C’est notre modèle de développement. »

 

Il n’y aura donc pas réellement de mise à jour du moteur avant Internet Explorer 11, ce qui nous a été clairement confirmé. Les Previews seront là pour donner un aperçu de ce qui vient, mais Ryan Gavin n’avait pas d’information sur l’arrivée de la prochaine.

Do Not Track

La question de la fonction DNT était également importante. Activée par défaut dans Internet Explorer 10, elle est censée bloquer le signal permettant à des sites d’opérer un suivi de navigation, en vue de personnaliser les publicités. Une activation par défaut qui a provoqué de nombreuses discussions houleuses et a par exemple conduit Yahoo! à refuser le signal émis par Internet Explorer 10.

 

Nous avons donc demandé à Ryan Gavin quelle était la situation chez Microsoft à ce sujet. Le directeur a indiqué « que la demande des utilisateurs est claire : ils veulent plus de contrôle sur leur vie privée. La vie privée est devenue en quelque sorte la nouvelle sécurité. Les utilisateurs veulent savoir ce qu’ils partagent et avec qui. Notre décision d’activer par défaut le Do Not Track est fondée sur notre engagement à respecter la vie privée. »

 

Nous lui avons par contre demandé comment Microsoft réagirait si les réactions négatives, à l’instar de Yahoo!, devaient se multiplier : l’entreprise ferait-elle machine arrière ? Ryan Gavin a bien confirmé qu’il existait une porte de sortie : « Il est évident que nous allons continuer à écouter les retours. Une technologie comme Do Not Track est intéressante car elle possède plusieurs angles : technologique, légal et industriel. Industriel pour l’ensemble des réseaux publicitaires. Nous avons décidé de placer les utilisateurs en premier, et nous pensons que des sociétés comme Yahoo trouveront des moyens de mettre une nouvelle économie saine sur ce modèle. Et n’oubliez pas que nous sommes nous-mêmes sur le marché publicitaire, notamment avec Bing. Mais oui, nous continuerons à écouter à et prendre note des réactions. »

Internet Explorer côté Modern UI

Internet Explorer occupe une place sur le Start Screen à cause de son pendant Modern UI. Toutefois, bien qu’il ait une interface spécifique, il n’est pas une application WinRT comme Courrier, Contacts, Actualités et ainsi de suite. Nous avons voulu savoir si Microsoft prévoyait des mises à jour comme il y en a régulièrement pour les autres applications.

 

Ryan Gavin nous a indiqué que la situation était « un peu la même que pour les mises à jour du moteur de rendu. Nous continuerons à mettre à jour le navigateur, mais on ne peut pas comparer avec les applications de Windows 8 qui sont complètement nouvelles. Nous continuerons quand même à écouter les retours, et il pourrait y avoir des modifications si c’était nécessaire ».

Flash : autant de mises à jour qu’il le faudra

L’intégration de Flash dans Internet Explorer 10 a été accompagnée d’une inquiétude. En effet, on sait que les mises à jour éventuelles de Flash transiteront à travers les « Patch Tuesdays », les fameux deuxièmes mardis de chaque mois où Microsoft publie des lots de correctifs. Nous avons donc demandé à Ryan Gavin ce qui se passerait en cas de faille majeure hors-cycle :

 

« Nous allons bien distribuer les mises à jour de Flash lors des Patch Tuesdays pour que l’ensemble des mises à jour soient alignées. Mais nous travaillons directement avec Adobe pour la situation générale des mises à jour. En cas de correctif d’urgence, une mise à jour sera publiée en dehors du cycle ».

La navigation n’est pas une fonctionnalité de « seconde zone »

Ryan Gavin a insisté sur l’importance d’Internet Explorer dans le cadre d’une utilisation tactile. « Nous savons que 63 % des utilisateurs d’iPad se servent toujours du navigateur pour aller chercher leurs informations » a indiqué le responsable, « et ce en dépit de la présence d’applications spécialement conçues pour ça. Les applications peuvent être fantastiques car réellement adaptées à un écran tactile ».

 

Pour Gavin, il n’était pas question de rater le coche. Il remarque cependant que le marché de la mobilité change rapidement la donne : « Les clients ne choisissent plus réellement un navigateur pour lui-même mais utilisent celui fourni avec la machine. Et quand vous achetez une machine, vous disposez d’un écosystème. Vous avez donc des applications qui sont capables d’extraire le contenu pour le restituer. Mais dans Internet Explorer, vous pouvez épingler directement une page en tant qu’application. Nous sentons que les sites s’utilisent globalement de plus en plus comme des applications et il était important que le tactile y fonctionne bien. »

 

En clair, même si les applications continueront à se multiplier, Microsoft ne souhaite pas relâcher les efforts investis dans le navigateur. Ryan Gavin nous a donné d’ailleurs l’exemple du site Pulse qui permet de faire de l’agrégation d’informations en fonction des goûts. Il s’agit pour lui du cas parfait d’un site qui peut vivre par lui-même sans avoir besoin d’application. Et le responsable nous a clairement indiqué que la réactivité tactile et les performances étaient vitales pour ce type d’expérience.

 

Au final, Internet Explorer 10 est un bon cru, surtout par son support des technologies et ses performances. Cependant, il est dommage que Microsoft n’envisage pas des mises à jour régulières du moteur de rendu pour accompagner l’évolution des standards, surtout durant la phase de finalisation du HTML5. Une décision compréhensible d’un autre côté à cause d’une politique de support sur le long terme.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

ryan gavinPas de mise à jour avant Internet Explorer 11

Fermer

Commentaires (103)




Les clients ne choisissent plus réellement un navigateur pour lui-même mais utilisent celui fourni avec la machine. Et quand vous achetez une machine, vous disposez d’un écosystème.



Incroyable constatation pour quelqu’un de chez microsoft ! Il va surement finir chef lui. Ah trop tard.


Toujours pas de WebGL (à priori ?)

Concurrence avec les technos maison (directx), dommage.








chriscombs a écrit :



Toujours pas de WebGL (à priori ?)

Concurrence avec les technos maison (directx), dommage.





Je t’invite à lire ceci

C’est la raison pour laquelle Microsoft ne gère pas WebGL ils se sont déjà exprimés la dessus.



Ca fait pas un peu tâche d’avoir ça sur son CV :

Directeur d’Internet Explorer ? <img data-src=" />

Mais bon vu sa photo, c’est quand même pas n’importe qui, il arrive à éclairer le mur derrière lui :).





Mais dans Internet Explorer, vous pouvez épingler directement une page en tant qu’application.



C’est à dire ? Car fait un cliqué-glissé de l’url dans la barre des tâches (là ça fonctionne sous XP avec Chrome) c’est la même chose non ?

Si il parle de pouvoir faire clic droit dessus et d’avoir des raccourcis dans ce raccourcis alors je pense que ce n’est pas le genre de chose qui sera beaucoup utilisé.



Sinon pour le DNT c’est dommage. Les gens qui font très attention à leur vie privée auraient été capable de s’y intérêsser un peu, et d’activer la fonctionnalité d’eux même. Pendant que les autre auraient générés beaucoup de revenus.

Du coup ça risque de ne pas profiter à grand monde. Du côté du site, si tu le gère pas, alors ça fait une mauvaise image. Et du côté de l’utilisateur il y aura peut de chances que ce soit pris en compte.


L’absence de mise à jour régulière pour suivre les standards peut être regrettable pour l’utilisateur, mais comme le conclut l’article, il y a un support derrière. Et la prise en charge de standards non encore officialisés reste une opération bancale : les premières versions de standard sont toujours plus ou moins bancales (quand je lis sur cluclu que la spec d’IndexedDB n’intégrait pas le quota disque… !), après je suis d’accord pour dire qu’il faut un retour d’usage pour valider le standard.

Bref, leur modèle actuel de fonctionnement ne me semble pas délirant, au contraire.








charon.G a écrit :



Je t’invite à lire ceci

C’est la raison pour laquelle Microsoft ne gère pas WebGL ils se sont déjà exprimés la dessus.







L’eau a coulée sous les ponts depuis… Les failles ont été corrigées et la sécurité a été renforcée à la fois du côté des navigateurs et des pilotes 3D.

Ces craintes là n’ont plus lieu d’être, et l’excuse de Microsoft ne tient plus.



Toujours pas de support du codec audio Vorbis, pas de WebGL, pas de support d’APIs comme Full Screen, Web Audio ou getUserMedia/Stream, pas de point sampling, pas de détection de l’orientation ou du mouvement, IE10 est parti pour être une bonne plaie pour le dév d’applis comme les JV HTML5 en remplacement de Flash. <img data-src=" />


De plusieurs éléments CSS3 tels que grid, flexbox, multi-column, positioned floats, regions, et hyphenation

Des effets visuels CSS3 : Text Shadow, 3D Transforms, Transitions, Animations et Gradient





<img data-src=" /><img data-src=" /><img data-src=" />








-Stephane- a écrit :



L’eau a coulée sous les ponts depuis… Les failles ont été corrigées et la sécurité a été renforcée à la fois du côté des navigateurs et des pilotes 3D.

Ces craintes là n’ont plus lieu d’être, et l’excuse de Microsoft ne tient plus.





C’est faux il suffit de faire un shader programme un peu long et tu fais une DDOS sur le sous système graphique. Il n’y a aucun moyen de l’éviter. Et quand tu rends ce genre de possibilité disponible à n’importe quelle page web , ça fait peur.









charon.G a écrit :



C’est faux il suffit de faire un shader programme un peu long et tu fais une DDOS sur le sous système graphique. Il n’y a aucun moyen de l’éviter. Et quand tu rends ce genre de possibilité disponible à n’importe quelle page web , ça fait peur.





Sur XP tu te tapes un BSOD. Sur Vista et 7 le sous système graphique se reinitialise à la volée.

Sur 8 vu que WDDM1.2 utilise un ordonnanceur GPU preemptif il y a des chances que ça puisse passer dans certains cas.









Crysalide a écrit :



Toujours pas de support du codec audio Vorbis, pas de WebGL, pas de support d’APIs comme Full Screen, Web Audio ou getUserMedia/Stream, pas de point sampling, pas de détection de l’orientation ou du mouvement, IE10 est parti pour être une bonne plaie pour le dév d’applis comme les JV HTML5 en remplacement de Flash. <img data-src=" />







Bientôt il sera tellement insignifiant en part de marché que ça sera même plus important de développer pour ça.



Il faudrait qu’ils aient 2 navigateurs l’un pour le support vis a vis des entreprises et un autre plus pour les utilisateurs non pro avec un rythme plus soutenue parce que la attendre 3 ans <img data-src=" />



Bon c’est vrai que leur preview s’en approche mais j’ai cru comprendre qu’il prenait la place d’IE donc <img data-src=" />



Sinon Charon pour ton dossier technique sur W8 j’espère que tu expliqueras ce qu’est un “ ordonnanceur GPU preemptif ” parce que la je suis largué <img data-src=" /> d’ailleurs c’est pas de ca qu’avait besoin midori ou helios ou un de ces projets top secret de Ms <img data-src=" /> ? Ou alors je confonds complètement <img data-src=" />

Sur ton blog :



Helios ne fonctionne pas avec les GPU actuels qui ne possèdent pas le minimum matériel (il manque un timer et un contrôleur d’interruption).



Du coup ca a evolué ou pas ?








arno53 a écrit :



Il faudrait qu’ils aient 2 navigateurs l’un pour le support vis a vis des entreprises et un autre plus pour les utilisateurs non pro avec un rythme plus soutenue parce que la attendre 3 ans <img data-src=" />



Bon c’est vrai que leur preview s’en approche mais j’ai cru comprendre qu’il prenait la place d’IE donc <img data-src=" />



Sinon Charon pour ton dossier technique sur W8 j’espère que tu expliqueras ce qu’est un “ ordonnanceur GPU preemptif ” parce que la je suis largué <img data-src=" /> d’ailleurs c’est pas de ca qu’avait besoin midori ou helios ou un de ces projets top secret de Ms <img data-src=" /> ? Ou alors je confonds complètement <img data-src=" />





rien à voir avec Midori. C’est le morceau de code qui gère le multitache GPU entre les applications. Depuis Vista ,Windows est doté d’un noyau graphique qui gère la mémoire vidéo et les différents paquets envoyés sur le gpu. Comme pour le processeur il existe un ordonnanceur GPU. Jusqu’à maintenant il était coopératif mais plus sur Windows 8.

La différence entre coopératif et préemptif









chriscombs a écrit :



Toujours pas de WebGL (à priori ?)

Concurrence avec les technos maison (directx), dommage.





Non mais tu as toujours la même barre d’adresse moisie depuis IE 0:



Elle ne répond pas à la demande de l’utilisateur faut attendre que MÔSIEUR le navigateur est fini de jouer avec pour enfin espérer pouvoir taper quelque chose dedans. <img data-src=" />



et oups elle ne comprend pas certains patterns de texte que les autres navigateurs acceptent pour lancer une recherche directement sur le moteur de recherche par défaut.



Ah et adieu la version modern UI si tu le met pas par défaut… puéril comme comportement…. ca coûtait quoi de laisser à l’utilisateur la possibilité de l’épingler à nouveau ?



Quand même, ça commence à être bien IE. Il manque bien deux ou trois trucs. Mais globalement ça va.



En plus, on a même le positioned floats, qui m’a l’air bien sympa.




De plusieurs éléments CSS3 tels que grid, flexbox, multi-column, positioned floats, regions, et hyphenation





Ça serait bien de préciser « expérimentaux », ils sont préfixés (et en plus pas super à jour)









charon.G a écrit :



Je t’invite à lire ceci

C’est la raison pour laquelle Microsoft ne gère pas WebGL ils se sont déjà exprimés la dessus.







Par contre ça ne le dérange pas d’inclure directement Flash.



Bon Firefox va faire la même chose, mais en JS.



Toujours pas de respect du minimum dans les normes w3c (margin/padding, window/document javascript, etc) ?

Non ? Bien sûr, faudrait surtout pas simplifier la vie des développeurs <img data-src=" />



IE10 : poubelle <img data-src=" />








lolotwingo a écrit :



Toujours pas de respect du minimum dans les normes w3c (margin/padding, window/document javascript, etc) ?

Non ? Bien sûr, faudrait surtout pas simplifier la vie des développeurs <img data-src=" />



IE10 : poubelle <img data-src=" />





<img data-src=" /> un troll de compét’ !! <img data-src=" /> Il sent à des km celui-là.



Et sinon, ils voudraient pas tous utiliser le même moteur de rendu les concepteurs de navigateurs ?



Franchement ça leur arracherait la gueule d’utiliser du Webkit par exemple ?



Autant que chacun dev son navigateur, avec différentes visions, fonctions etc. je peux comprendre… mais alors casser les couilles de tous les dev web pour le moteur, je comprends pas…








BlackYeLL a écrit :



Franchement ça leur arracherait la gueule d’utiliser du Webkit par exemple ?





Désolé mais si on me donne à choisir en tremps webkit, gecko, presto ou trident, je vous webkit en dernier sur ma liste. Okay c’est lui qui gère le plus de chose, mais c’est probablement le plus buggé. <img data-src=" />



L’intérêt d’avoir plusieurs moteurs, c’est que chacun à sa vision. Par exemple je trouve la sélection particulièrement exécrable au rendu sur Webkit, je préfère largement plus celle de Presto ou Gecko. On rajoute à cela qu’il y a aussi plusieurs “compilateur” JS qui ont chacun leur point fort.









zefling a écrit :



Désolé mais si on me donne à choisir en tremps webkit, gecko, presto ou trident, je vous webkit en dernier sur ma liste. Okay c’est lui qui gère le plus de chose, mais c’est probablement le plus buggé. <img data-src=" />



L’intérêt d’avoir plusieurs moteurs, c’est que chacun à sa vision. Par exemple je trouve la sélection particulièrement exécrable au rendu sur Webkit, je préfère largement plus celle de Presto ou Gecko. On rajoute à cela qu’il y a aussi plusieurs “compilateur” JS qui ont chacun leur point fort.







Peu importe, c’était un exemple.



A vrai dire, j’en ai tellement ma claque que je serais prêt à avoir du Trident partout <img data-src=" /> J’aimerais juste qu’ils se mettent d’accord, histoire de pas avoir à faire des raccord pour avoir la même gueule partout.



Concernant les compilateurs JS qui ont chacun leur point … OK… mais c’est quoi l’intérêt, puisqu’ils sont différents ?









BlackYeLL a écrit :



Peu importe, c’était un exemple.



A vrai dire, j’en ai tellement ma claque que je serais prêt à avoir du Trident partout <img data-src=" /> J’aimerais juste qu’ils se mettent d’accord, histoire de pas avoir à faire des raccord pour avoir la même gueule partout.



Concernant les compilateurs JS qui ont chacun leur point … OK… mais c’est quoi l’intérêt, puisqu’ils sont différents ?





Je ne sais pas : éviter la stagnation qu’on a eue avec IE 6. Chacun essaie de faire mieux que l’autre avec des approches différentes. C’est un peu comme vouloir un seul OS, un seul traitement de texte, un seul client mail, un seul logiciel de retouche… C’est sûr, c’est plus simple, mais ça peut bloquer l’évolution.



De plus, on est très loin des problèmes qu’on avait avec IE 6 ou 7. Aujourd’hui avec un framework comme Jquery et du CSS sans préfixage t’as largement moins de problèmes qu’avant. Pour IE6 faire des correctifs ça pouvait me prendre des semaines (j’ai vécu ça l’an dernier), pour IE9, Chome ou Firefox au pire quelques minutes sauf gros bug.



toujours pas de systèmes d’adds on avec ie10?


Le 15/11/2012 à 22h 03







eatherquake a écrit :



toujours pas de systèmes d’adds on avec ie10?





Cela existe depuis des années dans IE.









zefling a écrit :



<img data-src=" /> un troll de compét’ !! <img data-src=" /> Il sent à des km celui-là.





Même pas, suffit de dev en cross browser pour ouvrir les yeux <img data-src=" />



Le meilleur c’est quand on clique sur la photo du monsieur… <img data-src=" />



<img data-src=" />








lolotwingo a écrit :



Même pas, suffit de dev en cross browser pour ouvrir les yeux <img data-src=" />







Je sais pas, je pense qu’en faire 40 heures par semaines ça doit pas me suffire pour m’en rendre compte. <img data-src=" />









zefling a écrit :



Je sais pas, je pense qu’en faire 40 heures par semaines ça doit pas me suffire pour m’en rendre compte. <img data-src=" />





On s’en rend p-e mieux compte en dirigeant comme moi une équipe de 5 personnes qui en font 40h/semaine <img data-src=" />

Bon allez, c’est surtout le support IE6 qui est pénible, mais les + récents ne sont pas pour autant sans problème <img data-src=" />





« Nous savons que 63 % des utilisateurs d’iPad se servent toujours du navigateur pour aller chercher leurs informations » a indiqué le responsable, « et ce en dépit de la présence d’applications spécialement conçues pour ça.



Ça n’a pas vraiment avoir avec la choucroute de l’article mais si les applications de sites web se limitaient seulement à proposer le contenu tout en fournissant une interface plus agréable, je pense que les utilisateurs en seraient plus friands.

À chaque application, il faut donner des droits d’accès et de modifications à tout (contacts, localisation,…).








lolotwingo a écrit :



On s’en rend p-e mieux compte en dirigeant comme moi une équipe de 5 personnes qui en font 40h/semaine <img data-src=" />

Bon allez, c’est surtout le support IE6 qui est pénible, mais les + récents ne sont pas pour autant sans problème <img data-src=" />





Je sais pas ça fait 3 ans que je fais ça en pro (10 ans en amateur), et franchement IE8 est bien moins chiant que IE7 ou IE6 qui sont à s’arracher les cheveux. De plus, le modelbox d’IE 8 est celui du 3D contrairement aux précédents. En tout cas, que connaissaient si bien les problèmes d’IE6 et IE7 qu’on m’a assigné à tous les hacks pour ses navigateurs de merde. Depuis j’ai changé de boîte et là où bosse le support s’arrête à IE8 : je revis. <img data-src=" /> Sinon je te le concède, IE8 est un navigateur complètement à la masse aujourd’hui et ça aurait bien que MS ne se limite pas à corriger la sécurité, mais aussi les bugs de leur support « parfait » du CSS2.1.



Par contre pas un mot sur la volonté de fusionner a nouveau IE avec les bases du SE.

Chassez les vieux démons ils reviennent au galop



Sacré bande de branquignols a Bruxelles ils avaient les moyens que celà se reproduise pas et ont préféré encaisser les subsides de micr$oft et accepter le balotscreen <img data-src=" />








charon.G a écrit :



C’est faux il suffit de faire un shader programme un peu long et tu fais une DDOS sur le sous système graphique. Il n’y a aucun moyen de l’éviter. Et quand tu rends ce genre de possibilité disponible à n’importe quelle page web , ça fait peur.





Je suis curieux d’avoir un exemple concret dans ce cas… Pour le moment ce n’est que du FUD.



Ce monsieur ressemble terriblement à Tim Curry, le professeur Oldman dans Scary Movie 2 <img data-src=" />








-Stephane- a écrit :



Je suis curieux d’avoir un exemple concret dans ce cas… Pour le moment ce n’est que du FUD.





Demande à un programmeur de jeux vidéo. C’est arrivé plusieurs fois à des programmeurs DirectX de faire planter la pile graphique pendant le développement d’un jeu.

.

Sinon certains vieux jeux conçus sous XP font planter la couche graphique car le program shader rend pas la main assez tôt

Dans cette histoire il y a deux choses:

L’attaque DDOS c’est le plus simple à faire



*Mais tu as aussi tous les bugs dans les drivers graphiques et même les cartes graphiques. Par mon boulot je peux te dire que les drivers graphiques sont les drivers les plus buggés qu’on peut trouver. Tu devrais demander à Jean Baptiste de VLC ce qu’il en pense il a déja approuver ce post dans un de mes anciens commentaires.









zefling a écrit :



Ça serait bien de préciser « expérimentaux », ils sont préfixés (et en plus pas super à jour)







Par contre ça ne le dérange pas d’inclure directement Flash.



Bon Firefox va faire la même chose, mais en JS.





Sauf si je me trompe mais flash ne donne pas un accès aussi bas niveau que WebGL permettant d’écrire son propre shader program.









charon.G a écrit :



Demande à un programmeur de jeux vidéo. C’est arrivé plusieurs fois à des programmeurs DirectX de faire planter la pile graphique pendant le développement d’un jeu.

.

Sinon certains vieux jeux conçus sous XP font planter la couche graphique car le program shader rend pas la main assez tôt





Tu parles de DirectX là. Es-tu certain que le comportement du driver OpenGL ES serait équivalent ?



EDIT : Je ne nie pas le danger de WebGL, hein, je pose juste la question :)









ldesnogu a écrit :



Tu parles de DirectX là. Es-tu certain que le comportement du driver OpenGL ES serait équivalent ?



EDIT : Je ne nie pas le danger de WebGL, hein, je pose juste la question :)





OpenGL permet aussi de charger des programmes shaders. C’est une fonctionnalité matérielle des cartes graphiques.

Ensuite le driver OpenGL s’insère dans l’architecture graphique Vista. Il communique avec le noyau graphique dont j’ai parlé plus haut et le driver graphique.









charon.G a écrit :



Demande à un programmeur de jeux vidéo. C’est arrivé plusieurs fois à des programmeurs DirectX de faire planter la pile graphique pendant le développement d’un jeu.

.

Sinon certains vieux jeux conçus sous XP font planter la couche graphique car le program shader rend pas la main assez tôt

Dans cette histoire il y a deux choses:

L’attaque DDOS c’est le plus simple à faire



*Mais tu as aussi tous les bugs dans les drivers graphiques et même les cartes graphiques. Par mon boulot je peux te dire que les drivers graphiques sont les drivers les plus buggés qu’on peut trouver. Tu devrais demander à Jean Baptiste de VLC ce qu’il en pense il a déja approuver ce post dans un de mes anciens commentaires.







Je suis déjà développeur 3D, donc je connais la problématique.

Si je demande un exemple concret c’est parce que la situation a pas mal évoluée depuis le début de WebGL. Contrairement à un programme natif, les applications WebGL passent par le parser du navigateur qui peut autoriser ou pas certaines choses, voir même modifier les shaders avant de les compiler. De même certains pilotes 3D peuvent être “blacklistés” s’ils possèdent un problème connu, empêchant toute application WebGL de tourner.

Bref les problèmes de sécurité ne sont pas plus élevés que ceux qui concernent les API 3D de Flash par exemple. Tant qu’il n’y a pas d’exemple récent démontrant une réelle faille de sécurité, ça relève du FUD.









-Stephane- a écrit :



Je suis déjà développeur 3D, donc je connais la problématique.

Si je demande un exemple concret c’est parce que la situation a pas mal évoluée depuis le début de WebGL. Contrairement à un programme natif, les applications WebGL passent par le parser du navigateur qui peut autoriser ou pas certaines choses, voir même modifier les shaders avant de les compiler. De même certains pilotes 3D peuvent être “blacklistés” s’ils possèdent un problème connu, empêchant toute application WebGL de tourner.

Bref les problèmes de sécurité ne sont pas plus élevés que ceux qui concernent les API 3D de Flash par exemple. Tant qu’il n’y a pas d’exemple récent démontrant une réelle faille de sécurité, ça relève du FUD.





Je doute fort qu’il soit possible de voir si le code d’un program shader soit mauvais ou pas. Pour donner un exemple c’est comme si tu racontais qu’on pouvait écrire un programme qui empêche de faire bugger d’autres programmes.

Pour le blacklistage donc si on trouve une faille sur un pilote qui existe depuis le début on bloque l’accès à WebGL sur toutes les machines. Ca aussi c’est très foireux.



Sans compter que sur bon nombre de machines les drivers ne sont jamais mis à jour. Ce serait assez grave en terme de sécurité.


Dernière chose si il devait arriver quelque chose on reporterait la faute à Microsoft car en réalite c’est le système qui planterait . Il suffit de voir les plaintes des utilisateurs sur les BSOD liés en réalité soit aux drivers ou au matos.








charon.G a écrit :



OpenGL permet aussi de charger des programmes shaders. C’est une fonctionnalité matérielle des cartes graphiques.

Ensuite le driver OpenGL s’insère dans l’architecture graphique Vista. Il communique avec le noyau graphique dont j’ai parlé plus haut et le driver graphique.





Oui tout cela, je le sais :) Mais la façon dont les programmes shader sont chargés et la manière dont OpenGL ES s’insère dans l’architecture graphique ne sont pas forcément nécessairement identiques et donc pas nécessairement soumis aux mêmes bugs/problèmes.









ldesnogu a écrit :



Oui tout cela, je le sais :) Mais la façon dont les programmes shader sont chargés et la manière dont OpenGL ES s’insère dans l’architecture graphique ne sont pas forcément nécessairement identiques et donc pas nécessairement soumis aux mêmes bugs/problèmes.





Le problème vient surtout du program shader lui même qui peut faire planter le GPU ou le monopoliser. Du coup le GPU ne réponds plus. le program shader s’execute sur le GPU.









charon.G a écrit :



Je doute fort qu’il soit possible de voir si le code d’un program shader soit mauvais ou pas. Pour donner un exemple c’est comme si tu racontais qu’on pouvait écrire un programme qui empêche de faire bugger d’autres programmes.

Pour le blacklistage donc si on trouve une faille sur un pilote qui existe depuis le début on bloque l’accès à WebGL sur toutes les machines. Ca aussi c’est très foireux.





Sans vouloir t’offenser, c’est justement ce qu’est en train de faire Microsoft depuis plusieurs années avec .NET : Même si tu codes tes programmes n’importe comment, il y a toujours une verification faite par windows qui empêche le programme de faire planter le système.



Pour Javascript (et donc WebGL) c’est pareil, puisque le langage est interprété, les concepteurs de navigateurs peuvent à loisir contrôler l’exécution du code pour empêcher de faire planter le programme voire le système.



Le 16/11/2012 à 10h 26

:popcorn:








charon.G a écrit :



Je doute fort qu’il soit possible de voir si le code d’un program shader soit mauvais ou pas. Pour donner un exemple c’est comme si tu racontais qu’on pouvait écrire un programme qui empêche de faire bugger d’autres programmes.

Pour le blacklistage donc si on trouve une faille sur un pilote qui existe depuis le début on bloque l’accès à WebGL sur toutes les machines. Ca aussi c’est très foireux.







Détrompe toi.

Le GLSL que permet OpenGL ES 2.0, est beaucoup plus limité que ce qu’un langage classique comme le C permet de faire. De ce fait il est bien plus simple de détecter une anomalie dans le code.

Et je ne vois pas ce que le blacklistage a de foireux, puisqu’il ne bloque WebGL que si la version des pilotes est trop ancienne et comporte une faille. C’est une saine façon d’alerter les gens sur la nécessiter de mettre à jour leur pilote.









earth01 a écrit :



Sans vouloir t’offenser, c’est justement ce qu’est en train de faire Microsoft depuis plusieurs années avec .NET : Même si tu codes tes programmes n’importe comment, il y a toujours une verification faite par windows qui empêche le programme de faire planter le système.



Pour Javascript (et donc WebGL) c’est pareil, puisque le langage est interprété, les concepteurs de navigateurs peuvent à loisir contrôler l’exécution du code pour empêcher de faire planter le programme voire le système.





.NET n’empêche pas un programme de planter. Il ne va pas modifier le code du programme. Si il y a un bug il restera.

Ensuite le program shader est executé sur le GPU. Je ne vois pas comment OpenGL ou DirectX pourrait modifier le code. Déjà il faudrait connaitre les failles futures et je ne vois pas comment il peut détecter le temps d’éxécution pour éviter le timeout.

Si ca avait été possible de faire cela. Ca ferait longtemps que ms l’aurait ajouté dans son architecture graphique.



Pour le driver OpenGL il s’execute aussi en mode noyau, il permet le même genre d’attaque que DirectX en exploitant les bugs dans les drivers graphiques ou la carte graphique.









-Stephane- a écrit :



Détrompe toi.

Le GLSL que permet OpenGL ES 2.0, est beaucoup plus limité que ce qu’un langage classique comme le C permet de faire. De ce fait il est bien plus simple de détecter une anomalie dans le code.

Et je ne vois pas ce que le blacklistage a de foireux, puisqu’il ne bloque WebGL que si la version des pilotes est trop ancienne et comporte une faille. C’est une saine façon d’alerter les gens sur la nécessiter de mettre à jour leur pilote.





Si tu trouves une faille sur un pilote récent nvidia et puis Ati. Généralement les failles existent depuis longtemps. Je t’ai expliqué avant que les drivers graphiques sont de vrais passoires. Donc tu crois que WebGL va bloquer ces pilotes. Ca signifierait que quasiment plus personne puisse accéder à WebGL. Sur le coup je doute que les devs de WebGL fassent le blacklist nécessaire.



Pour le GLSL comment ils gèrent l’attaque DDOS qui consiste à envoyer un program shader très lent. Je doute fort qu’ils vont s’amuser à mesurer le temps d’éxecution du code. Ca ressemble plus à une heuristique qu’autre chose.



FUD FUD FUD… La preuve, t’as aucun exemple précis.








Crysalide a écrit :



FUD FUD FUD… La preuve, t’as aucun exemple précis.





Personne ne s’y est encore intéressé en effet mais ça viendra. Surtout si WebGL atteint une part de marché importante. On en reparlera à ce moment là.

J’ai argumenté donne des liens si tu ne veux pas me croire c’est ton problème.



PS: J’utilise Chrome depuis quasiment le début pour d’autres raisons.









charon.G a écrit :



Si tu trouves une faille sur un pilote récent nvidia et puis Ati. Généralement les failles existent depuis longtemps. Je t’ai expliqué avant que les drivers graphiques sont de vrais passoires. Donc tu crois que WebGL va bloquer ces pilotes. Ca signifierait que quasiment plus personne puisse accéder à WebGL. Sur le coup je doute que les devs de WebGL fassent le blacklist nécessaire.



Pour le GLSL comment ils gèrent l’attaque DDOS qui consiste à envoyer un program shader très lent. Je doute fort qu’ils vont s’amuser à mesurer le temps d’éxecution du code. Ca ressemble plus à une heuristique qu’autre chose.







Le blacklistage n’est pas fait par celui qui écrit le code WebGL, mais par l’éditeur du navigateur. Ce n’est pas “je crois”, c’est déjà en place chez Mozilla et Google dans leur navigateur respectif, et ça marche trés bien.

ça veut dire quoi “envoyer un programme shader trés lent” ? Depuis tout à l’heure tu parles dans le vide, donne un exemple concret.

J’ai déjà fait des shaders qui “rament” sur un GPU faible, au pire j’arrive à faire ramer le navigateur, jamais je n’ai réussi à faire planter l’affichage du PC via WebGL.









-Stephane- a écrit :



Le blacklistage n’est pas fait par celui qui écrit le code WebGL, mais par l’éditeur du navigateur. Ce n’est pas “je crois”, c’est déjà en place chez Mozilla et Google dans leur navigateur respectif, et ça marche trés bien.

ça veut dire quoi “envoyer un programme shader trés lent” ? Depuis tout à l’heure tu parles dans le vide, donne un exemple concret.

J’ai déjà fait des shaders qui “rament” sur un GPU faible, au pire j’arrive à faire ramer le navigateur, jamais je n’ai réussi à faire planter l’affichage du PC via WebGL.





GPU reset





To prevent timeout detection from occurring, hardware vendors should ensure that graphics operations (that is, direct memory access (DMA) buffer completion) take no more than 2 seconds in end-user scenarios such as productivity and game play.



Vista et 7 essayaient de découper les paquets envoyés au GPU mais ça ne marchait pas toujours.


Voici un exemple précis du problème que j’évoque. Je viens de le trouver.

Regardez ce message








charon.G a écrit :



GPU reset





C’est vieux ça, Nvidia a déjà mis en place des corrections pour les problèmes de TDR dans ses pilotes… L’an dernier.

J’attends encore de voir un sample code WebGL qui produit ce genre de problème sur un système avec un navigateur récent.









-Stephane- a écrit :



C’est vieux ça, Nvidia a déjà mis en place des corrections pour les problèmes de TDR dans ses pilotes… L’an dernier.

J’attends encore de voir un sample code WebGL qui produit ce genre de problème sur un système avec un navigateur récent.





NVidia ne peut pas corriger les problèmes de TDR. Ils n’ont aucun contrôle sur l’execution d’un program shader. Tu as lu le lien ou quoi? Le mec a juste créer un program shader très gourmand pour provoquer le TDR.

Il arrive régulièrement que des utilisateurs se tapent le message d’avertissement du TDR comme quoi le driver graphique ne répondait plus. Mais même avec ça ces problèmes n’existent pas d’après toi :(



Enfin bref là j’ai tout dis j’arrête là. J’ai des problèmes personnels bien plus importants à résoudre <img data-src=" />









charon.G a écrit :



Voici un exemple précis du problème que j’évoque. Je viens de le trouver.

Regardez ce message





Il ne dit rien ton message sinon que les drivers ne doivent pas bloquer des ressources trop longtemps. Je ne suis pas certain de comprendre ce que tu essaies de prouver dans le contexte d’une attaque par WebGL, puisqu’apparemment ce processus de déblocage est automatique et ne provoque pas de plantage. Ou alors j’ai rien compris <img data-src=" />









ldesnogu a écrit :



Il ne dit rien ton message sinon que les drivers ne doivent pas bloquer des ressources trop longtemps. Je ne suis pas certain de comprendre ce que tu essaies de prouver dans le contexte d’une attaque par WebGL, puisqu’apparemment ce processus de déblocage est automatique et ne provoque pas de plantage. Ou alors j’ai rien compris <img data-src=" />





Reprend le premier lien que j’ai donné. ils parlent d’attaques DDOS. En clair tu balances en continue un program shader bien lourd.Le système va récupérer mais l’application(voir d’autres applications qui utilisaient aussi le GPU) vont planter.. De plus le TDR a une limite de 7 redémarrages si je me souviens bien. Au delà tu devrais te taper un BSOD.









charon.G a écrit :



Je t’invite à lire ceci

C’est la raison pour laquelle Microsoft ne gère pas WebGL ils se sont déjà exprimés la dessus.





WebGL ne peux pas être sandboxé ?









fitfat a écrit :



WebGL ne peux pas être sandboxé ?





Marre d’expliquer désolé j’ai d’autres problèmes à résoudre j’arrête là.

Ce n’est pas WebGL qui chie à la base. Ca se passe au niveau de la carte graphique et des drivers graphiques. WebGL expose juste des fonctionnalités dangereuses au niveau du web.









charon.G a écrit :



Marre d’expliquer désolé j’ai d’autres problèmes à résoudre j’arrête là.

Ce n’est pas WebGL qui chie à la base. Ca se passe au niveau de la carte graphique et des drivers graphiques. WebGL expose juste des fonctionnalités dangereuses au niveau du web.





Et Flash ou Silverlight c’est pas le même problème ? Je demande, perso mon domaine c’est plus le CSS et le DOM HTML.









charon.G a écrit :



NVidia ne peut pas corriger les problèmes de TDR. Ils n’ont aucun contrôle sur l’execution d’un program shader. Tu as lu le lien ou quoi? Le mec a juste créer un program shader très gourmand pour provoquer le TDR.

Il arrive régulièrement que des utilisateurs se tapent le message d’avertissement du TDR comme quoi le driver graphique ne répondait plus. Mais même avec ça ces problèmes n’existent pas d’après toi :(



Enfin bref là j’ai tout dis j’arrête là. J’ai des problèmes personnels bien plus importants à résoudre <img data-src=" />







Comment ça ils n’ont aucun contrôle sur l’exécution des shaders ?!

Les shaders s’exécutent sur le GPU, bien sur que si qu’ils peuvent contrôler ce qui s’y passe. C’est justement ce que Microsoft leur demande explicitement (cf. ta citation)

To prevent timeout detection from occurring, hardware vendors should ensure that graphics operations (that is, direct memory access (DMA) buffer completion) take no more than 2 seconds in end-user scenarios such as productivity and game play.



Bref c’est bien à Nvidia et consort de mettre en place les watchdogs (ou de scheduler) en amont, avant que la couche de Microsoft ne s’en occupe.

Pour le reste tu continues à brasser du vent, moi je n’ai toujours pas vu de sample code WebGL qui plante mon système.









zefling a écrit :



Et Flash ou Silverlight c’est pas le même problème ? Je demande, perso mon domaine c’est plus le CSS et le DOM HTML.





Le flash ne donne pas accès aux shaders. Ce probleme existe aussi avec toute application openGL,DirectX et le dernier silverlight.









-Stephane- a écrit :



Comment ça ils n’ont aucun contrôle sur l’exécution des shaders ?!

Les shaders s’exécutent sur le GPU, bien sur que si qu’ils peuvent contrôler ce qui s’y passe. C’est justement ce que Microsoft leur demande explicitement (cf. ta citation)

Bref c’est bien à Nvidia et consort de mettre en place les watchdogs (ou de scheduler) en amont, avant que la couche de Microsoft ne s’en occupe.

Pour le reste tu continues à brasser du vent, moi je n’ai toujours pas vu de sample code WebGL qui plante mon système.





Tu as tord Microsoft n’aurait pas sorti le multitache GPU preemptif si c’était le cas.



Voilà ce qui mette sur une doc Microsoft







This is made worse by the fact that an increasingly larger number of applications are trying to broadly use GPUs. Windows 7 saw the introduction of the Direct Compute API targeted specifically at scenarios wanting to leverage the GPU for compute-intensive applications such as video encoding. Leveraging this API today is not without risk. It is very easy for an application to inadvertently submit a very complex and long workload to the GPU, which may take a significant amount of time to complete during which the GPU is unavailable to other applications, resulting in an unresponsive desktop.

The GPU is a shared resource that is used by many applications, including UI rendering of most applications. Today, applications have to cooperate to avoid this problem. Cooperating is accomplished by attempting to break down the work to be executed on the GPU into small batches to avoid using the GPU exclusively for extended periods of time. This task is much more difficult than it may sound as the performance characteristics of a GPU can change drastically from low end to high end and batch size is a combination of application and driver behavior. There is no strict guideline on how to achieve this either. It is essentially accomplished through trial and error one application/developer at a time.

GPU preemption offers a better solution to this problem by making it possible to preempt long-running workloads on the GPU. This should free developers from having to fine tune their application for every GPU, allowing them to fully leverage the power of the GPU while maintaining great desktop responsiveness and allowing scenarios such as touch to feel great no matter what other applications are doing.



Sur Vista et 7 le multitache GPU était coopératif. Ils tentaient de diviser les taches GPU invoqués par les applications mais c’est loin d’être parfait. Ils expliquent clairement qu’ils ne peuvent pas assurer de rendre la main dans les temps si une tache GPU est trop longue.



Je pense qu’on ne peut pas faire plus clair comme explication. Du coup j’arrête la je n’ai pas que ça a faire de tenter d’expliquer des trucs à des gens obstinés. <img data-src=" />









charon.G a écrit :



Tu as tord Microsoft n’aurait pas sorti le multitache GPU preemptif si c’était le cas.



Voilà ce qui mette sur une doc Microsoft







Sur Vista et 7 le multitache GPU était coopératif. Ils tentaient de diviser les taches GPU invoqués par les applications mais c’est loin d’être parfait. Ils expliquent clairement qu’ils ne peuvent pas assurer de rendre la main dans les temps si une tache GPU est trop longue.



Je pense qu’on ne peut pas faire plus clair comme explication. Du coup j’arrête la je n’ai pas que ça a faire de tenter d’expliquer des trucs à des gens obstinés. <img data-src=" />







Je crois que tu n’as pas compris pourquoi Microsoft a fait ça en fait.

Ils ne l’ont pas fait parce que les marchands de GPU ne peuvent pas le faire à leur place (ce qui serait complètement ridicule puisque ce sont eux qui font les pilotes de leur matériel quand même).

Ils ont fait ça parce qu’ils ne contrôlent pas ce que font les marchands de GPU, et qu’ils voulaient une solution qui garantisse à windows d’avoir des ressources dans tous les cas.

Il est tout à fait naturel pour Microsoft de prévoir un système qui puisse redonner la main à windows (qui utilise le GPU pour la composition de la GUI), au cas où une application trop gourmande viendrait à le monopoliser.

Ils font aussi ça pour faciliter le boulot des développeurs d’applications sous Windows.

Maintenant le constructeur du GPU peut trés bien implémenter des mécanismes bas-niveau pour faire la même chose dans le driver. Le pilote sait de quel contexte viennent les instructions qu’il doit exécuter (sans quoi il ne pourrait pas y avoir d’utilisation concurrente du GPU), il peut donc trés bien partager le temps d’exécution en fonction des contextes et éviter les problèmes de déni de service. Ce n’est pas quelque chose de facile à faire, car il est trés difficile d’arbitrer l’utilisation des ressources de façon “équitable”. Mais ce n’est pas impossible, et la solution de Microsoft dans ce domaine n’est pas universelle.



Et désolé d’être obstiné, mais je ne peux pas te laisser dire n’importe quoi sur WebGL. Tu t’appuies certes sur des articles de Microsoft parlant des problèmes de TDR, mais tu oublies de dire (un peu comme eux), que ce type de problème survient sans même utiliser WebGL. L’utilisation par Microsoft de l’accélération matérielle dans le navigateur peut également provoqué ce type de problème, tout comme des programmes Flash qui permettent également d’utiliser les shaders.

Étrangement ça n’empêche pas Microsoft d’autoriser ces technologies dans leur navigateur…











charon.G a écrit :



Le flash ne donne pas accès aux shaders. Ce probleme existe aussi avec toute application openGL,DirectX et le dernier silverlight.





C’est faux, la dernière version de flash possède une API Stage 3D qui permet d’utiliser les shaders :

http://www.adobe.com/devnet/flashplayer/stage3d.html





Et désolé d’être obstiné, mais je ne peux pas te laisser dire n’importe quoi sur WebGL. Tu t’appuies certes sur des articles de Microsoft parlant des problèmes de TDR, mais tu oublies de dire (un peu comme eux), que ce type de problème survient sans même utiliser WebGL. L’utilisation par Microsoft de l’accélération matérielle dans le navigateur peut également provoqué ce type de problème, tout comme des programmes Flash qui permettent également d’utiliser les shaders.

Étrangement ça n’empêche pas Microsoft d’autoriser ces technologies dans leur navigateur..



Pour le flash je n’etais pas au courant qu’ils ont proposé cette fonctionnalité autant(ou au temps comme vous voulez <img data-src=" /> ) pour moi d’ou “mon de mémoire si je trompe pas” sur un commentaire précédent.

Ensuite je viens de le dire dans ce commentaire que ça ne concerne pas uniquement WebGL:



“Le flash ne donne pas accès aux shaders. Ce probleme existe aussi avec toute application openGL,DirectX et le dernier silverlight.”



J’ai oublié WPF d’ailleurs. La différence avec WebGL c’est que quasiment toutes ces technologies ne sont pas faites pour le web. Le danger est de proposer un accès bas niveau à des fonctionnalités systèmes dangereuses pour n’importe quelle page web. Ce n’est pas le même danger qu’une application tu conviendras.



Pour Silverlight 5 par contre oui c’est pour le web. Mais je me souviens que julien manici avait posté des liens msdn ou Microsoft évoquait ce problème aux développeurs de WPF. Ce n’est pas juste un archarnement sur WebGL comme tu sembles prétendre puisque Microsoft previent les développeurs sur ses propres technologies. Par contre je doute fort que silverlight5 soit un problème de sécurité, au vu des dernières informations sur WinRT je ne connais pas beaucoup de développeurs autour de moi qui comptent y passer.


Je viens de tomber sur cet article





problem with WebGL is poor graphics driver support for OpenGL. Chrome and Firefox have chosen a very radical approach to solve this: on Windows, they convert all WebGL GLSL shader code into DirectX 9 HLSL code through a converter called ANGLE.



Apparemment vu le support restreint des drivers OpenGL Firefox et Chrome convertissent les GLSL shader code en directX9 HLSL. Du coup ta théorie sur un OpenGL tuné pour WebGL ne tient pas debout ça passe par DirectX.








charon.G a écrit :



Je viens de tomber sur cet article





Apparemment vu le support restreint des drivers OpenGL Firefox et Chrome convertissent les GLSL shader code en directX9 HLSL. Du coup ta théorie sur un OpenGL tuné pour WebGL ne tient pas debout ça passe par DirectX.







C’est encore mieux, l’API bas niveau est donc complètement décorellée de celle qui est utilisée dans la page, ce qui signifie qu’il y a forcément un travail d’analyse et de conversion. Bonne chance pour tenter d’exploiter une hypothétique faille dans le driver DirectX au travers d’un shader GLSL…









-Stephane- a écrit :



C’est faux, la dernière version de flash possède une API Stage 3D qui permet d’utiliser les shaders :

http://www.adobe.com/devnet/flashplayer/stage3d.html





Je me disais bien que j’en avait entendu parler, alors que je ne fais même pas de 3D. <img data-src=" />





Je crois que tu n’as pas compris pourquoi Microsoft a fait ça en fait.

Ils ne l’ont pas fait parce que les marchands de GPU ne peuvent pas le faire à leur place (ce qui serait complètement ridicule puisque ce sont eux qui font les pilotes de leur matériel quand même).

Ils ont fait ça parce qu’ils ne contrôlent pas ce que font les marchands de GPU, et qu’ils voulaient une solution qui garantisse à windows d’avoir des ressources dans tous les cas.

Il est tout à fait naturel pour Microsoft de prévoir un système qui puisse redonner la main à windows (qui utilise le GPU pour la composition de la GUI), au cas où une application trop gourmande viendrait à le monopoliser.

Ils font aussi ça pour faciliter le boulot des développeurs d’applications sous Windows.

Maintenant le constructeur du GPU peut trés bien implémenter des mécanismes bas-niveau pour faire la même chose dans le driver. Le pilote sait de quel contexte viennent les instructions qu’il doit exécuter (sans quoi il ne pourrait pas y avoir d’utilisation concurrente du GPU), il peut donc trés bien partager le temps d’exécution en fonction des contextes et éviter les problèmes de déni de service. Ce n’est pas quelque chose de facile à faire, car il est trés difficile d’arbitrer l’utilisation des ressources de façon “équitable”. Mais ce n’est pas impossible, et la solution de Microsoft dans ce domaine n’est pas universelle.



Ce que tu expliques c’est le fonctionnement actuel du multitache GPU cooperatif. où l’os et le constructeur essayent de diviser les paquets trop gros avant de les envoyer au GPU . Ce mécanisme est imparfait.

Sur un même execution context(le GPU en gère tout un tas ce qui garantit le parallélisme) le GPU ne sait pas interrompre la tache et redonner la main au noyau graphique. les documents que j’ai donné l’expliquent bien. c’est la raison même du dévelpppement du TDR. Tout comme les nombreuses applications qui provoquent des TDR à cause d’un shader trop lourd.

Pour faire le rapprochement avec le processeur, les premiers processeurs ne géraient pas les context switch et donc les premiers systèmes de l’époque utilisaient un multitache coopératif.

Le principe du multitache preemptif c’est que c’est géré directement par le matériel.

Pour WDDM 1.2 une carte graphique DirectX11 est obligatoire.

Je finirai en disant que ce mécanisme avait étéannonce par Microsoft dès 2006. Microsoft connaissait le problème depuis le début.


Tu réclamais un exemple. je te l’ai donnéplus haut

C’est pour OpenGL mais ça s’applique très bien à WebGL arrête d’être de mauvaise foi.

Comme je l’ai expliqué au dessus ça s’applique pour toutes les technologies qui utilisent les Shaders. Pourquoi WebGL y réchapperait? . Si c’était possible Microsoft l’aurait modifié au niveau du système.

De plus sachant qu’ils se basent sur DirectX pour les shaders, ça risque d’être dur de le gérer.








-Stephane- a écrit :



C’est encore mieux, l’API bas niveau est donc complètement décorellée de celle qui est utilisée dans la page, ce qui signifie qu’il y a forcément un travail d’analyse et de conversion. Bonne chance pour tenter d’exploiter une hypothétique faille dans le driver DirectX au travers d’un shader GLSL…





Sauf qu’exploiter une faille était qu”‘une partie du problème.

L’attaque system DOS en saturant le GPU est bien plus simple à réaliser. Vu que ca passe par DirectX,ton argument comme quoi les gens de webGL peuvent le gerer tombe à l’eau. De toute façon comme je l’ai expliqué précédemment ce n’est pas possible. Il y a des cas ou on ne peut rien faire comme le lien que tu as omis de commenter.



Encore un exemple avec un shader gourmandaprès on me dit que le problème n’existe pas


WebGL agit à un niveau applicatif et ils arriveraient à résoudre un problème d’ordre système et matériel.

Chez Microsoft ce sont vraiment des grosses tanches ils ne savent pas changer le plomb en or contrairement aux mecs de WebGL. <img data-src=" />


Je cite quelques paragraphes intéressants sur le doc de 2006:





WDDM 2.0

New generation of GPUs designed for multi-tasking

Mid command buffer preemption

Demand faulting of resources

Surface fault (preferred mode for v2.0)

Page fault (stall the GPU)

Per process page tables

Better multi-tasking than WDDM v1.0,still some client cooperation required









WDDM 2.1

Everything WDDM v2.0 GPU can do

Fine grained context switching

Can preempt mid pixel

Doesn’t stall GPU on page fault

True preemptive multi-tasking

Ultimate flexibility for the GPU

GPU can be used for any scenarios without impact on the desktop





Cette présentation été écrite en 2006 le système de version a changé. on ne sait pas si 1.2 correspond à 2.0 ou 2.1.

Mais ce que je cite parle bien d’un context switch plus précis géré par le matériel.








charon.G a écrit :



Ce que tu expliques c’est le fonctionnement actuel du multitache GPU cooperatif. où l’os et le constructeur essayent de diviser les paquets trop gros avant de les envoyer au GPU . Ce mécanisme est imparfait.

Sur un même execution context(le GPU en gère tout un tas ce qui garantit le parallélisme) le GPU ne sait pas interrompre la tache et redonner la main au noyau graphique. les documents que j’ai donné l’expliquent bien. c’est la raison même du dévelpppement du TDR. Tout comme les nombreuses applications qui provoquent des TDR à cause d’un shader trop lourd.

Pour faire le rapprochement avec le processeur, les premiers processeurs ne géraient pas les context switch et donc les premiers systèmes de l’époque utilisaient un multitache coopératif.

Le principe du multitache preemptif c’est que c’est géré directement par le matériel.

Pour WDDM 1.2 une carte graphique DirectX11 est obligatoire.

Je finirai en disant que ce mécanisme avait étéannonce par Microsoft dès 2006. Microsoft connaissait le problème depuis le début.







Le TDR, c’est juste un mécanisme de watchdog qui réinitialise l’affichage. Microsoft décrit simplement un mécanisme (qui doit être supporté par les pilotes), pour faire de l’ordonnancement. Ce n’est pas Microsoft tout seul qui peut mettre ça en place. Si le hardware et les pilotes ne le gèrent pas ça ne fonctionne pas. Les éditeurs de navigateur travaillent également avec les constructeurs de hardware pour trouver des solutions aux différents bug et problèmes qu’ils rencontrent.









charon.G a écrit :



Encore un exemple avec un shader gourmandaprès on me dit que le problème n’existe pas







Montre moi un exemple en WebGL, tous les exemples que tu as montré jusqu’à présent ne sont pas en WebGL, et aucun ne donne le source du shader en question, donc on ne peut pas en déduire que c’est généralisable en WebGL.



J’ai trouvé quelque chose qui devrait clore le débat définitivement (sauf mauvaise foi bien sur):

Spec WebGL

Chronos reconnait le problème dans sa spécification WebGL:





It is possible to create, either intentionally or unintentionally, combinations of shaders and geometry that take an undesirably long time to render. This issue is analogous to that of long-running scripts, for which user agents already have safeguards. However, long-running draw calls can cause loss of interactivity for the entire window system, not just the user agent.



In the general case it is not possible to impose limits on the structure of incoming shaders to guard against this problem. Experimentation has shown that even very strict structural limits are insufficient to prevent long rendering times, and such limits would prevent shader authors from implementing common algorithms.



User agents should implement safeguards to prevent excessively long rendering times and associated loss of interactivity. Suggested safeguards include:



Splitting up draw calls with large numbers of elements into smaller draw calls.

Timing individual draw calls and forbidding further rendering from a page if a certain timeout is exceeded.

Using any watchdog facilities available at the user level, graphics API level, or operating system level to limit the duration of draw calls.

Separating the graphics rendering of the user agent into a distinct operating system process which can be terminated and restarted without losing application state.

The supporting infrastructure at the OS and graphics API layer is expected to improve over time, which is why the exact nature of these safeguards is not specified.



Chronos reconnait le problème et explique que les devs doivent s’arranger pour découper les appels en plus petites requêtes. Ils disent bien que c’est impossible de régler totalement ce problème.








charon.G a écrit :



Tu réclamais un exemple. je te l’ai donnéplus haut

C’est pour OpenGL mais ça s’applique très bien à WebGL arrête d’être de mauvaise foi.

Comme je l’ai expliqué au dessus ça s’applique pour toutes les technologies qui utilisent les Shaders. Pourquoi WebGL y réchapperait? . Si c’était possible Microsoft l’aurait modifié au niveau du système.

De plus sachant qu’ils se basent sur DirectX pour les shaders, ça risque d’être dur de le gérer.





Qu’est ce que tu en sais ? Tu as vu le source pour l’affirmer ? Les shaders WebGL ne sont pas compilés tels quels, et encore moins quand ils doivent être traduit vers une autre API. Je ne suis pas de mauvaise foi, je demande juste un exemple concret du problème en WebGL qui démontre une bonne fois pour toute l’importance du problème que tu décris.

Un truc qui serait tellement grave qu’il justifie la décision de Microsoft de ne pas vouloir l’implémenter.









-Stephane- a écrit :



Montre moi un exemple en WebGL, tous les exemples que tu as montré jusqu’à présent ne sont pas en WebGL, et aucun ne donne le source du shader en question, donc on ne peut pas en déduire que c’est généralisable en WebGL.





WebGL est juste un wrapper amélioré d’OpenGL. Les Shaders sont gérés au niveau système c’est pas dur à comprendre pourtant.

Je n’ai pas d’exemples pour le moment mais t’inquiète ca viendra on en reparlera dans une future news. je t’invite à regarder ce que met chronos dans la spec WebGL ils admettent le problème









-Stephane- a écrit :



Qu’est ce que tu en sais ? Tu as vu le source pour l’affirmer ? Les shaders WebGL ne sont pas compilés tels quels, et encore moins quand ils doivent être traduit vers une autre API. Je ne suis pas de mauvaise foi, je demande juste un exemple concret du problème en WebGL qui démontre une bonne fois pour toute l’importance du problème que tu décris.

Un truc qui serait tellement grave qu’il justifie la décision de Microsoft de ne pas vouloir l’implémenter.





C’est toi qui veut pas comprendre les shaders sont executes sur le gpu au final. WebGL utilise les memes shaders(voir la spec). Moi je te parle d’un probleme au niveau systeme et GPU. Toi tu viens raconter que WebGL n’est pas concerné. Sache que depuis Vista tous les accès graphiques passent par le noyau graphique OpenGL y compris.









charon.G a écrit :



J’ai trouvé quelque chose qui devrait clore le débat définitivement (sauf mauvaise foi bien sur):

Spec WebGL

Chronos reconnait le problème dans sa spécification WebGL:





Chronos reconnait le problème et explique que les devs doivent s’arranger pour découper les appels en plus petites requêtes. Ils disent bien que c’est impossible de régler totalement ce problème.





Il disent que c’est impossible de le régler dans le cas général, cependant ils donnent des pistes de solution, et certaines d’entre elles sont déjà mises en œuvre dans les browsers :



User agents should implement safeguards to prevent excessively long rendering times and associated loss of interactivity. Suggested safeguards include:



Splitting up draw calls with large numbers of elements into smaller draw calls.

Timing individual draw calls and forbidding further rendering from a page if a certain timeout is exceeded.

Using any watchdog facilities available at the user level, graphics API level, or operating system level to limit the duration of draw calls.

Separating the graphics rendering of the user agent into a distinct operating system process which can be terminated and restarted without losing application state.

The supporting infrastructure at the OS and graphics API layer is expected to improve over time, which is why the exact nature of these safeguards is not specified.









-Stephane- a écrit :



Il disent que c’est impossible de le régler dans le cas général, cependant ils donnent des pistes de solution, et certaines d’entre elles sont déjà mises en œuvre dans les browsers :





Ces pistes c’est de découper les appels en plus petits appels ce que fait deja Windows. Si tu lis ils disent qu’ils ne sont pas capable de regler le probleme reellement mais ils essayent de le le limiter.

Ensuite les watchdogs comme je l’ai dis avant tu ne peux pas interrompre une tache une fois execute sur le gpu.

Enfin ils demandent de gerer le rendu dans un process à part pour gérer le cas dont je parlais ou le gpu sera resetté entrainant la fermeture de l’application.

Ils disent clairement qu’ils peuvent pas corriger complètement le problème. reconnais le.









charon.G a écrit :



WebGL est juste un wrapper amélioré d’OpenGL. Les Shaders sont gérés au niveau système c’est pas dur à comprendre pourtant.

Je n’ai pas d’exemples pour le moment mais t’inquiète ca viendra on en reparlera dans une future news. je t’invite à regarder ce que met chronos dans la spec WebGL ils admettent le problème







Au final c’est le browser qui va générer le code qui sera compilé par les drivers 3D.

Entre temps il peut faire un travail de pré-compilation, détecter des problèmes éventuels, et splitter le travail que doit faire le shader en plusieurs bout si possible.

Bref il y a beaucoup de chose ;que le browser peut faire avant qu’un shader ne soit réellement exécuté par le GPU.





IlIl disent que c’est impossible de le régler dans le cas général,



Tu vois tu reconnais déjà ça. Donc maintenant tu vois qu’on peut très bien imaginer d’envoyer des shaders gourmands de facon volontaire sur le GPU. WebGL ne pourra rien faire.








-Stephane- a écrit :



Au final c’est le browser qui va générer le code qui sera compilé par les drivers 3D.

Entre temps il peut faire un travail de pré-compilation, détecter des problèmes éventuels, et splitter le travail que doit faire le shader en plusieurs bout si possible.

Bref il y a beaucoup de chose ;que le browser peut faire avant qu’un shader ne soit réellement exécuté par le GPU.





Ils le font déjà et ca ne marche pas tu lis ce que j’ecris ou quoi.









charon.G a écrit :



Ces pistes c’est de découper les appels en plus petits appels ce que fait deja Windows. Si tu lis ils disent qu’ils ne sont pas capable de regler le probleme reellement mais ils essayent de le le limiter.

Ensuite les watchdogs comme je l’ai dis avant tu ne peux pas interrompre une tache une fois execute sur le gpu.

Enfin ils demandent de gerer le rendu dans un process à part pour gérer le cas dont je parlais ou le gpu sera resetté entrainant la fermeture de l’application.

Ils disent clairement qu’ils peuvent pas corriger complètement le problème. reconnais le.







Oui ils disent que la spec de WebGL ne peut pas fournir de mécanisme général pour résoudre tous les cas pouvant poser problème. ça ne veut pas dire qu’il n’existe pas de solution à chaque problème dans l’absolue.

Chaque solution dépendra de la pile graphique de chaque OS, des pilotes 3D et du travail fait par “l’implémenteur” de WebGL dans chaque navigateur.









charon.G a écrit :



Ils le font déjà et ca ne marche pas tu lis ce que j’ecris ou quoi.





ça règle une partie des problèmes, je n’ai jamais dit que tous les problèmes étaient résolus par le browser lui même (relis mon tout premier message).









-Stephane- a écrit :



Oui ils disent que la spec de WebGL ne peut pas fournir de mécanisme général pour résoudre tous les cas pouvant poser problème. ça ne veut pas dire qu’il n’existe pas de solution à chaque problème dans l’absolue.

Chaque solution dépendra de la pile graphique de chaque OS, des pilotes 3D et du travail fait par “l’implémenteur” de WebGL dans chaque navigateur.





Dans un monde idéal il faudrait que tout le monde possede au minimum Windows 8 avec une carte graphique DX11. Mais j’ai vu hier que la part de marché de win8 vient d’atteindre seulement celle de linux. Parmis ceux la tous n’ont pas une cg dx11. pour les smartphones ils utilisent tjs des dx9. Vu la lenteur de progression du marché on ne sera pas dans une bonne situation avant dix ans et je suis peut être optimiste.



Tu as aussi toujours plus de 40% des utilisateurs sous XP. Dans leur cas un problème comme ça c’est le BSOD.








charon.G a écrit :



Dans un monde idéal il faudrait que tout le monde possede au minimum Windows 8 avec une carte graphique DX11. Mais j’ai vu hier que la part de marché de win8 vient d’atteindre seulement celle de linux. Parmis ceux la tous n’ont pas une cg dx11. pour les smartphones ils utilisent tjs des dx9. Vu la lenteur de progression du marché on ne sera pas dans une bonne situation avant dix ans et je suis peut être optimiste.







Je pense que tu sur-éxagères le problème, comme Microsoft le fait pour éviter d’implémenter une technologie qui s’appuie sur une API concurrente à la leur.

Heureusement qu’il n’y a pas que Windows 8 et directx…



Si Microsoft avait appliqué le même principe de précaution aux autres technologies du Web… Tu aurais un IE qui ne gère ni javascript, ni l’accélération graphique, et ne supporte pas le Flash.








-Stephane- a écrit :



Si Microsoft avait appliqué le même principe de précaution aux autres technologies du Web… Tu aurais un IE qui ne gère ni javascript, ni l’accélération graphique, et ne supporte pas le Flash.





Javascript et l’accélération graphique le danger est minimal.

Pour flash au départ ça venait du retard du W3C à appliquer les normes.

Tu remarqueras que IE Metro ne supporte plus les ActiveX et donc flash(a part une white liste pour la transition)

La les dangers qui sont présentés ne sont pas du tout dans la même catégorie. (attaques systèmes)



On est pas totalement d’accord mais je voulais quand même te remercier de ne pas partir en vrille comme ça peut se passer habituellement <img data-src=" />








charon.G a écrit :



Javascript et l’accélération graphique le danger est minimal.

Pour flash au départ ça venait du retard du W3C à appliquer les normes.

Tu remarqueras que IE Metro ne supporte plus les ActiveX et donc flash(a part une white liste pour la transition)

La les dangers qui sont présentés ne sont pas du tout dans la même catégorie. (attaques systèmes)





Il y a dejà eu des failles Javascripts aux conséquences bien plus grave qu’un problème de TDR..









charon.G a écrit :



On est pas totalement d’accord mais je voulais quand même te remercier de ne pas partir en vrille comme ça peut se passer habituellement <img data-src=" />





Je suis trop vieux pour ça, et ça n’en vaut pas la peine :)









AnthonyF a écrit :



Cela existe depuis des années dans IE.





et ça marche comment?



Le 12/12/2012 à 06h 38







eatherquake a écrit :



et ça marche comment?





Ils appellent çà des modules complémentaires.

Tu n’en trouveras malheureusement pas à foison, mais le système existe depuis très longtemps dans IE mais n’a jamais bien intéressé les développeurs qui, pourtant, se sont jetés sur Firefox et Chrome.



Je sais que tu as Ghostery qui a fait un module pour IE 32 bits par exemple. Le système de mise à jour est très mauvais cela dit, il faut fermer IE pour qu’il la fasse. Après à savoir si c’est Ghostery ou une limitation d’IE vis à vis des extensions qui doivent tourner en sandbox peut-être.