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

Regardez ce message

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

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





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.

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.

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

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.

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

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

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.

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

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

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 :



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.

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

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.

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.

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

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

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.

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



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.

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



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



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é " /> d’ailleurs c’est pas de ca qu’avait besoin midori ou helios ou un de ces projets top secret de Ms " /> ? Ou alors je confonds complètement " />





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