Le 28/11/2012 à 07h 12

lossendae a écrit :



Etent donné la morosité actuel du marché et les tres gros changement opéré dans Windows, parlé de lamentable échec quand le système se vend apparemment mieux que Vista est faire preuve de mauvaise foi.



Le fait de ne pas adherer au concept de ModernUI ne devrait pas t’empêcher d’être objectif…





Ca t’étonne cette réaction? Je l’avais dit qu’ils ne l’admettraient pas si win8 se vendait. CQFD

Le 28/11/2012 à 06h 57

Tolor a écrit :



Finalement, 40 millions de licences vendues en un mois (contre 60 millions en 2 mois pour Windows 7, et 20 millions en 1 mois pour vista), c’est quand même pas mal pour un système dont personne ne veut " />





Pas le bide annoncé visiblement(nouveau Vista " /> )

Le 27/11/2012 à 18h 36

Skeeder a écrit :



Tiens question: il est possible de connecter un Lecteur DVD externe sur une Tablette WinRT, et de lire le DVD avec un mediaplayer issu du store?





Windows 8 ne supporte plus la lecture de DVD pour des coûts élevés de licence dolby. Normalement tu peux quand même lire les DVD avec d’autres logiciels. Mais je ne suis pas certain que tu puisses écrire un mediaplayer en version metro.

Le 27/11/2012 à 17h 42

HarmattanBlow a écrit :



Moi ça ne me fait pas rêver. ;)



Interdiction pour un programme d’écrire dans le dossier d’(un autre programme ? Bon ben plus de logiciel pour installer les mods, à moins d’être en mode admin, ce qui n’est pas vraiment un progrès en termes de sécurité.



Interdiction de charger dynamiquement du code ? Bon ben plus de plugins. La solution sera de lancer un programme en mode admin pour qu’il modifie directement le logiciel, ce qui à nouveau n’est pas un progrès et ouvre la porte à un formidable bazar de maintenance et d’applications qui cesseront de fonctionner au retrait de ces plugins. Ou alors écrire ces plugins dans des langages interprétés et donc beaucoup plus lents.



Etcetera. En tant que développeur, je sais que par expérience qu’un bac à sable empêche toujours des usages parfaitement légitimes.





La sandbox peut être vu comme contraignante sur un os ouvert comme Windows qui a ete trop laxiste pendant des années.La sandbox est un point obligatoire pour arrêter la propagation des virus. Dans quelques années dans un environnement où la sandbox est activé pour toutes les applications ça ne sera pas plus limitatif que ça.

Pour le chargement dynamique de code comme je l’ai mis dans le dossier tu peux charger des plugins si ils sont présents dans le dossier de l’application et inscrits dans le manifeste.

Le 27/11/2012 à 16h 18

Je veux bien croire que le code géré/managé/safe soit inviolable, que ce soit la fin des virus etc…



J’ai pas raconté ça non plus " />. Je précise avant qu’une vague de trolls ne réponde…

Le 27/11/2012 à 14h 11

Tolor a écrit :



" />





Logiciel système en c# pas encore pour tout de suite " />

Le 27/11/2012 à 13h 40

hadoken a écrit :



Mais… mais… mais…. c’est super important !



A l’époque où on avait gueulé pour avoir un Visual Studio 2012 Express pour le Desktop, les développeurs C++ gueulaient déjà pour avoir la possibilité d’utiliser le nouveau compilateur pour targeter du XP !



Bonne nouvelle donc " />





+1 je vais pouvoir quitter visual 2010 pour le C++ :)

Le 27/11/2012 à 13h 29

Glouk a écrit :



À noter qu’une grosse partie est commune entre Cocoa et CocoaTouch, tout de même.





Oui c’est comparable entre le Windows Runtime pour Windows RT et 8 et celui sur WP8. Socle commun d’api mais certaines api spécifiques.

Windows RT ne se base pas sur WP8 par contre.

Le 26/11/2012 à 21h 36

Jiyuu_Hashi a écrit :



Je plussois.

Windows RT est à iOS, ce que Windows 8 est à OSX.

Des systèmes d’exploitation différents, mais ayant un moteur commun (WinRT) – Pour iOS/OSX, n’ayant que de l’iOS, je ne peux pas vraiment me prononcer ^^; J’ai bien du System 7, mais là, je doute que ce soit faisable ^^;





En fait IOS et OSX partagent la même base système mais ce n’est pas le cas du framework. Cocoa touch diffère de Cocoa.

Enfin Windows RT propose aussi une interface bureau et certaines applications microsoft de bureau comme office, ce n’est pas non plus le cas d’IOS

Le 26/11/2012 à 20h 55

Lafisk a écrit :



ah et tu penses que l’api ils l’ont implémentée deix fois pour le fun ??



Bien sur que non … Windows RT a été dev comme une brique et a été collée a Windows 8 pour le desktop et est en stand alone pour les tablettes arm. Dans les deux cas c’est le même





Ce n’est pas Windows RT la brique c’est Windows Runtime (WinRT) qui est en effet commune entre Windows RT et Windows 8.

Windows RT désigne la version de Windows 8 qui n’autorise pas les applications Win32.



Tu ne peux pas dire que Windows RT est inclu dans Windows 8, ça n’a pas de sens

Le 26/11/2012 à 20h 23

Jiyuu_Hashi a écrit :



Je te le concède.

Les gens qui ont vu ma Surface RT m’ont tous dit que j’étais en Windows 8.

J’ai donc dû leur expliquer que non, j’étais en Windows RT, une version spécifique pour tablette (j’ai aussi pris l’exemple entre OSX et iOS), leur indiquant qu’une application standard PC n’est pas installable, même s’ils ont Office sur Surface RT ^^;

Moi, tant que je peux faire du débogage directement sur Surface RT, via VSExpress, ça me convient très bien, ça me permet de mettre mes propres applications compatible WinRT aussi bien sur Windows 8 que sur Windows RT, sans avoir besoin de passer par le Store de Microsoft ^^;

Au passage, toi qui t’y connais un peu/beaucoup, existe-t-il un équivalent du Remote Debugger pour WP8 ?





Non désolé ;) , Je ne développe pas pour WP8

Le 26/11/2012 à 18h 58

Dacoco974 a écrit :



Ce n’est pas de WinRT dont parle la news mais de Windows RT. Ça n’a aucun sens d’annoncer une durée de support pour une API, surtout qu’elle est destinée à remplacer Win32.





pas gagné " /> " />

Le 26/11/2012 à 12h 44

nydale a écrit :



Déjà w8rt et w8 c’est deux systèmes différents, l’unification dont ils parlent pour moi c’est surtout l’unification des interfaces et des comptes utilisateurs et plus ou moins des non-applis du store. Microsoft peut très bien abandonner windows 8 rt, de toute façon il y a tres peu d’applications et elles sont compatibles w8.

w8rt est entre la tablette et le pc, il suffira que intel se bouge avec son atom mobile pour éliminer w8rt.



Ils ont déja prévu le coup avec la version “pro” de la surface, bien plus chère normalement car sur équipée.





Windows 8 et Windows RT partagent la même plateforme : WinRT

Tous les développeurs sont appelés à coder des applications WinRT. Ils ne font pas faire disparaitre WinRT c’est l’avenir de Windows.



De plus la partie Win32 est quasiment inchangée sur Windows 8. C’est plutôt le contraire qui risque de se produire la mort de Win32 à terme.

Le 26/11/2012 à 12h 10

nydale a écrit :



J’y crois pas, ils ont niqué les “early adopters” de windows phone et la ils essayent de faire comme si ils n’allaient pas faire pareil pour la tablette…





Win32 a perduré plus de 20 ans. Avec Windows 8 ils ont décidé de reprendre à zéro sur une nouvelle plateforme.

Pour Windows phone 7 l’unification n’avais pas encore été faite. Sa mort était programmée du départ.

C’est peu probable que la même chose se reproduise. WinRT a été conçu pour durer très longtemps.

Le 27/11/2012 à 09h 59

misterB a écrit :



Surtout pour avoir des app non adaptées au tactile, ça ne va pas servir a grand chose, a part comme excuse pour raler contre MS " />



Office dans l’état actuel est sans doute mieux sur la RT que sur la Pro en tactile





C’est ce que je voulais dire mais en effet lafisk a raison il y a quand même une grosse demande de pouvoir faire les deux. C’est la direction prise par Microsoft. A voir comment ils vont régler les problèmes actuels qui découlent de ces choix.

Le 27/11/2012 à 09h 45

Lafisk a écrit :



Les “geeks” je ne doute pas qu’ils les veulent. De la mauvaise foi par rapport à windows 7 ? hmm je ne sais pas, à ce moment la, il ne me semble pas qu’on avait des tablettes transformable, je ne pense pas qu’aucun d’entre eux veuillent réellement utiliser une tablette W8 intel en tactile avec la version desktop



La je parle plus pour moi, mais si je suis plus intéressé par la PRO c’est surtout que quand je veux faire du multimédia, je passerais en RT et si je veux bosser ben je passe en mode desktop avec un clavier et une souris, la ce qui est bien c’est qu’on a ce choix, la où avec Windows 7 en tactile tu avais toujours que le desktop qui était franchement pas bon à l’usage.



En gros, la tablette intel, c’est le couteau suisse des tablettes, tu peux tout faire avec, la où avec une RT tu es limité à l’usage multimédia/Office (certains métier ce contentent d’office)





Mouais c’est pas faux " />

Le 27/11/2012 à 09h 35

FrenchPig a écrit :



Heu non plus. Je vois pas en quoi c’est de la mauvaise foi de ne pas trouver d’intérêt à RT pour un initié qui veut des softs x86. C’est même logique





Je ne dis pas que ce n’est pas fondé comme remarque. mais l’usage d’une tablette n’est pas la même qu’un pc. C’est ce qui avait été reproché avec Windows 7 sur tablettes. Je met juste en lumiere l’incoherence des propos de certains.

En gros vous auriez réclamer Windows 7 sur tablettes. C’est marrant ça a fait un gros bide.

Le 27/11/2012 à 09h 32

Lafisk a écrit :



Est-ce que les utilisateurs lambda veullent leurs applis win32 ? j’en doute fortement, certains d’entre eux peut être, mais la grande majorité, je ne pense pas.





Entièrement d’accord ils sont bien passé à l”ipad mais par contre pas mal d’inpactiens sur les commentaires les réclament c’est un fait.

Je continue a penser que c’est de mauvaise foi flagrante vu que beaucoup ont gueulé sur Windows 7 sur tablettes à l’époque.



Je ne me fais pas de soucis si le problème se règle sur le prochain Windows il y aura autre chose.

Le 27/11/2012 à 09h 22

Dunaedine a écrit :



Non, il est dit qu’il y a un problème de confusion entre les 2, et que du coup, beaucoup vont s’attendre à retrouver leurs applis Win32, et vont donc forcément être déçus…





Donc ils veulent des applis Win32. Les inpactiens l’ont bien compris t’inquiete.

Le 27/11/2012 à 09h 20

FrenchPig a écrit :



Heu bah non, puisque les INpactiens savent bien que RT n’est pas prévu pour





Si on lit les commentaires beaucoup réclament les applications bureau et ne voient pas l’intéret de Windows RT. Mauvaise foi?

Le 27/11/2012 à 09h 10

J’aime bien il y a deux trois ans Tout le monde disait sur PCI que Windows 7 sur les tablettes c’était de la daube, c’était pas fait pour cet usage. Et là Microsoft sort un os adapté aux tablettes et tout le monde réclame les applis bureaux sur Windows RT " />

Le 26/11/2012 à 09h 54

Pour information les leaks sur la xbox 720 en parlaient.

Ce sont de vrais documents. De plus microsoft a demande d’enlever les documents sur ce leak à plusieurs sites.





Microsoft is also apparently planning to offer a head-mounted display device similar to Google’s Project Glass. The hands-free glasses will be able to connect to Xbox Live and deliver real-time information on people, places and objects. The product is referred to as both “Kinect Glasses” and “Fortaleza Glasses,” and is scheduled for a 2014 release according to the leak.

Le 24/11/2012 à 07h 24

psikobare a écrit :



bah un service pack certainement pas



le seul truc qu’on sait, c’est que sur MSDN, y a deux branches 9 et blue qui sont apparue peu après la RTM de 8

le reste c’est de la spéculation



après, oui, windows se dirige vers un développement plus agile, et oui, sinofsky est un très bon manager plein de bonnes idées





Au départ tu quotais ceci:





De plus le système va être amélioré avec blue



Tu admets que ce n’est pas un SP. Toutes les news sur blue parlaient de mise à jour fonctionnelles. De plus on savait que ça sortirait vers mi-2013 avant Windows 9.

Bien sur on ne connait pas le contenu exact mais si c ‘est une mise à jour fonctionnelle c’est forcément pour améliorer le système.

Et par ce qu’on sait sur WinRT on peut déduire logiquement que ça portera surtout sur métro.

Enfin Windows 8 est unifié avec Windows phone 8. Crois tu que Windows phone 8 n’aura pas de mise à jour avant deux ans.

Ce ne sont pas des suppositions c’est de la logique pure.

Le 23/11/2012 à 19h 52

torentoz2 a écrit :



Bof. J’ai un PC portable avec double boot Vista-7 et je serais bien incapable de voir une différence de performance entre les 2. Le seul défaut récurrent de Vista, c’est que des fois, il veut pas s’arrêter, ça mouline à l’infini sur l’écran de fermeture.



Pour le reste, 7 est une petite amélioration de Vista sur des détails et c’était plutôt une dénomination marketing pour faire oublier la première version de Vista qui était buggée et où les pilotes ont mis le temps à venir.





La différence se voit surtout sur les ressources prises par le système. Si tu as assez de ram et un disque dur potable Vista marchera très bien.

Suis d’accord avec toi sur le fond. Quand windows 7 est sorti tout l’ecosystème était devenu mature. Par contre c’est un fait qu’lls ont aussi pas mal optimisé l’OS pour qu’il bouffe moins de mémoire et fasse moins d’accès disques sur 7.

Le 23/11/2012 à 18h 06

psikobare a écrit :



" />





tout ce qu’on (le peuple) sait de blue, c’est son nom de code





Non on sait que ce n’est pas un service pack mais une mise à jour fonctionnelle de Windows 8

De plus WinRT a été conçu pour évoluer rapidement. ce qu’ils ne pouvaient pas forcément faire avec Win32 ou les effets de bords lors de modifications sont plus dangereux.



Après c’est vrai que par d’autres sources je savais que sinofsky voulait mettre des choses qu’il n’a pas réussi à mettre dans Windows 8. " />

Le 23/11/2012 à 16h 46

Ce n ‘est pas de la spéculation les rumeurs parlaient de feature pack pour Blue. De plus winRT a été conçu pour évoluer facilement

Le 23/11/2012 à 11h 29

Dunaedine a écrit :



Faut arrêter de n’y voir qu’un problème de menu démarrer. Toute l’ergonomie est contraire aux règles dans le domaine.





Pour une utilisation du desktop c’est la seule chose qui change. Après j’ai déjà dit que je ne voyais pas metro comme un environnement utilisable pour le PC.

Je pense que le bureau va évoluer pour gommer ces problèmes. Pour le moment on a affaire une hydre à deux têtes: c’est ça le problème.

Personnellement je n’utilise quasiment jamais métro sur mon PC.

Le 23/11/2012 à 09h 07

Lafisk a écrit :



Pour l’avoir utiliser avec unportable vendu avec de base, SP1 ou pas c’était certe fonctionnel, performant, par contre, de ce côté c’était pas ça, démarrage supra long, et n’importe quelle tâche était plutôt longue à s’exécuter, comparer à 7 sur le même portable.





Le problème les machines vendus a l’époque étaient peu puissantes. Vista est moins performant que 7 c’est clair mais avec la machine qui va bien ca tourne très bien.

Le 23/11/2012 à 09h 06

Le SP1 n’était pas à la hauteur de 7, il améliorait les choses mais globalement vista etait et reste une horreur et 7 le jour de sa sortie était déjà largement meilleur que vista SP1, même si au final on peut dire que 7 n’est qu’un SP de vista



Vista marche très bien si tu as le PC qui va avec. J’ai monté des configs pour des amis et ils en sont très satisfait.(ils sont toujours dessus)

Vista c’est juste la base qui a servi pour Windows 7 et Windows 8.



Pour Windows 8 si vraiment c’était un échec ce serait une première pour Microsoft: A savoir un produit qui échoue juste pour l’interface.

A mon avis ça va faire comme XP. Les gens au début ne voudront pas changer et quand ils comprendront que le menu démarrer ne reviendra pas ils s’habitueront.

De plus le système va être amélioré avec blue puis Win9. Je pense que plusieurs problèmes cités disparaitront à terme.

Le 23/11/2012 à 08h 32

torentoz2 a écrit :



Oui un Vista SP1 très stable et fonctionnel qui n’était que très peu différent de W7.





J’aurai bien aimé entendre ça à l’époque. Hâte de voir ce qu’on dira sur Windows 8 dans trois quatre ans " />

Le 22/11/2012 à 16h 47

freechelmi a écrit :



La vache, W8 a deja depassé Ubuntu en 1 mois " />





Je ne sais pas si on peut s’en vanter " />

Le 20/11/2012 à 21h 02

Les pc qui ne proposent pas la désactivation du secure boot n’obtiennent pas la certification win8. Ca fait parti des pré requis. Par contre c est le contraire pour les tablettes arm.

Le 20/11/2012 à 15h 37

patos a écrit :



Je pense plus à une activité différente d’autres applications, avec plus de droits (un peu comme IE sur WinRT)





Un redémarrage ou un BSOD implique une erreur au niveau de la couche système: Materiel ou OS ou drivers

Au pire une application peut envoyer un paquet mal formé à un driver qui serait mal interprété. Mais au final ce serait bien un driver fautif et pas une application.

Le 20/11/2012 à 12h 26

Tolor a écrit :



Là, les premières hypothèses de Nokia, ce serait un soft qui poserait des problèmes de reboot (donc forcément un soft ayant des accès plus important qu’une application classique). Skype en beta par exemple a été cité





Ca voudrait dire que skype installe un driver perso. Etrange comme bug….

Le 19/11/2012 à 11h 47

Consultant a écrit :



" />" />





tu as un windows phone !!



recherche sur maket place:

maconfig –> KO

monwindowsphone –>KO

moncharon.G –> KO



" />





" /> " />

Le 19/11/2012 à 10h 53

Je n’ai aucun problème sur mon lumia 920 non plus.

Le 17/11/2012 à 12h 33

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

Le 17/11/2012 à 12h 31

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

Le 17/11/2012 à 12h 12

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

Le 17/11/2012 à 12h 11

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

Le 17/11/2012 à 12h 06

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

Le 17/11/2012 à 12h 05

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.

Le 17/11/2012 à 12h 03

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

Le 17/11/2012 à 11h 56

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

Le 17/11/2012 à 11h 52

-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

Le 17/11/2012 à 11h 48

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.

Le 17/11/2012 à 09h 29

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.

Le 17/11/2012 à 09h 11

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

Le 17/11/2012 à 09h 05

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

Le 17/11/2012 à 08h 26

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