 |
| |
| Lucidlogix Virtu MVP en pratique Cartes Mères Publié le Jeudi 29 Mars 2012 par Guillaume Louel URL: /articles/858-1/lucidlogix-virtu-mvp-pratique.html Page 1 - Introduction Lancé en fanfare avec la plateforme Sandy Bridge, Virtu est une offre logicielle développée pour prendre en compte les problèmes engendrés par la présence de deux GPU de marque différente au sein d'une même machine. Avec Sandy Bridge, Intel a ajouté en effet un GPU à tous les processeurs de sa gamme.  Or, si utiliser deux GPU sous Windows n'est pas une nouveauté, ni un problème - le SLI de Nvidia et le Crossfire d'AMD gèrent la situation depuis des années - utiliser deux GPU de marque différente est un challenge. Facile sous XP, la possibilité de charger deux pilotes graphiques de marque différente avait disparu avec la version 1.0 de WDDM (le nouveau modèle de pilotes graphiques introduit avec Windows Vista). Si elle est revenue sous Windows 7 avec WDDM 1.1 (et sous Vista via un Service Pack), des limitations perdurent, chaque GPU gérant ses propres écrans. Quand il s'agit de vouloir utiliser un GPU pour une tâche différente, par exemple celui intégré au processeur sur le bureau Windows, et celui d'une carte graphique supplémentaire pour les jeux, il faut soit débrancher son écran et redémarrer son système, soit passer par une solution logicielle comme par exemple l'Optimus de Nvidia sur les plateformes portables. Virtu de Lucidlogix est, elle aussi, une solution logicielle de ce type destinée en priorité aux plateformes desktop. Avant de parler de ce qui différencie MVP - la version 2 de Virtu - de la précédente, voyons déjà les fonctionnalités communes. Mode D, Mode I La vocation principale de Virtu consiste à autoriser l'utilisation d'un GPU lorsque l'écran est connecté sur l'autre. D'un point de vue technique, Virtu intercale une couche d'abstraction entre Windows et les drivers WDDM (nous allons prendre pour exemple pour la suite l'utilisation dans une machine d'un processeur Intel avec une carte graphique GeForce. Ici, les pilotes de chaque carte, IGP Intel et GeForce, doivent être chargés). Cette couche permet de faire croire au système qu'il fonctionne sur un GPU différent du GPU principal, de manière quasi transparente. Ainsi le rendu 3D d'un jeu peut être lancé sur la GeForce, même si l'écran est connecté sur l'IGP via la carte mère. Ce n'est que la moitié du problème puisqu'il faut ensuite ramener l'image de la GeForce vers l'IGP, une opération effectuée par le driver qui copie les images calculées dans le framebuffer de la GeForce vers le framebuffer de l'IGP, par le biais du PCI Express. Cette seconde étape n'est pas forcément nécessaire dans le cas d'applications qui n'utilisent pas le rendu 3D, comme par exemple une application d'encodage vidéo qui utiliserait CUDA ou Quick Sync.  L'interface principale de Virtu MVP Virtu propose donc deux modes de fonctionnements distincts qui correspondent surtout à l'utilisation que l'on veut faire de sa machine. Dans le mode "I", on connecte l'écran sur la carte mère. L'IGP est alors le GPU principal sous Windows et, pour les jeux 3D, le rendu est délesté vers la GeForce. Ce scénario - semblable à ce que l'on retrouve sur des PC portables - était le premier à être rendu disponible dans Virtu. Il propose en théorie l'avantage de limiter la consommation sur le bureau tout en autorisant les performances maximales en 3D. L'autre mode, baptisé "D" fonctionne à l'envers. Pour rester sur notre exemple, l'écran est cette fois ci connecté sur la GeForce, et l'on peut virtualiser l'IGP, par exemple pour utiliser l'unité de compression vidéo Quick Sync d'Intel. L'existence du mode "D" tient surtout du fait que l'implémentation du mode "I" n'est pas complètement transparente. En effet, l'abstraction réalisée par le logiciel de Lucid a un double cout, d'abord sur les performances, et ensuite sur la latence (incompressible et dû au transfert du framebuffer via le PCI Express). Afin de voir en pratique ce que valent ces différents modes, nous avons utilisé la configuration suivante :
Virtu est annoncé comme compatible avec tous les pilotes WHQL des constructeurs. Côté GPU, la version que nous avons utilisée - indiquée comme version de production - n'est pas compatible avec les Radeon HD 7000 et les GeForce 680. Il sera intéressant de voir si, dans une future version, la compatibilité HD 7000 inclut le Zero Core Power en mode "I", ce qui permettrait théoriquement l'extinction de la carte graphique sur le bureau Windows ou pour la lecture de vidéo, une fonctionnalité qui pourrait être très utile ! Notez enfin que Virtu n'est pas compatible avec les solutions multi GPU AMD et Nvidia. Page 2 - Performances, consommation Impact sur les performances 3D Nous avons tenté de mesurer précisément l'impact de ces différents modes en comparant les performances dans différents cas :
Commençons d'abord par les performances en jeu 3D, ou nous avons comparé les performances 3D d'une carte graphique Nvidia et AMD via les trois modes de connexion possibles : carte seule, mode D et mode I. Les tests sont réalisés en 1920 par 1200. Nous avons choisi cinq jeux pour réaliser ce test, quatre d'entre eux disposaient de profils préconfigurés dans l'interface de Virtu. Ce n'était pas le cas cependant de Batman Arkham City, pour ce dernier nous avons créé manuellement un profil via l'interface. Nous n'avons pas relevé de problème particulier avec ce titre.  [ Radeon HD 6870 ] [ GeForce GTX 480 ] Premier point à régler, les performances désastreuses du mode "I" avec une Radeon HD 6870. La baisse de performance observée est liée à un bug de fréquence. Ici, et malgré plusieurs tentatives de réinstallation, la Radeon reste bloquée à sa fréquence 2D, soit 100 MHz. Les performances sont donc sévèrement impactées, même si le rendu est bien réalisé sur la carte graphique.  GPU-Z confirme la fréquence 2D. Autre détail à noter concernant les Radeon, en mode "I", le panneau de contrôle CCC n'est plus accessible, un bug connu depuis les premières versions de Virtu et qui n'est toujours pas corrigé. Le panneau de contrôle de Nvidia est par contre accessible en mode "I", même s'il peut mettre plusieurs minutes à se lancer.  Le pilote Radeon peut mettre plusieurs minutes avant d'afficher ce message d'erreur en mode I. Deuxième point, Virtu est bel et bien transparent en mode "D" pour les jeux. En effet, il n'y a pas de différence de performances dans ce mode - le pilote Virtu n'est pas lancé - ce qui est une très bonne chose. L'impact en mode "I" enfin, pour la GeForce est relativement variable en fonction des jeux, on notera de 5 à 17% selon les cas, notez enfin que Civilization V n'a pas souhaité se lancer. Impact sur les performances d'encodage  Le logo Virtu apparait sur les applications virtualisées. Il est désactivable, mais est très pratique pour vérifier si le pilote s'enclenche correctement. A l'inverse nous avons voulu mesurer l'impact de Virtu sur l'encodage vidéo, nous avons cette fois ci comparé Virtu en mode "D", "I" et l'IGP seul. Nous avons utilisé MediaEspresso de Cyberlink, qui dispose d'un profil, ainsi que MediaCoder (logiciel que nous avions évalué précédemment dans notre dossier sur l'encodage H.264) qui n'en dispose pas et pour qui nous en avons crée un :  On choisit l'exécutable, et l'on indique si l'on souhaite qu'il soit lancé sur la carte graphique (D) ou sur l'IGP (I). Nous utilisons ici Quick Sync (l'accélération de l'IGP) dans les deux logiciels.  [ Radeon HD 6870 ] [ GeForce GTX 480 ] Là encore si Virtu est transparent en mode I quand l'on souhaite utiliser l'IGP, nous aurons noté une très légère baisse de performances sur les deux logiciels en mode "D", relativement insignifiante par rapport à ce que l'on avait mesuré dans le sens inverse sur les applications 3D cependant. Consommation Nous avons également regardé l'évolution de la consommation dans les différents scénarios présentés. Nous avons mesuré trois cas, la consommation au repos, sous Cyberlink Media Espresso, et sous F1 2011.  [ Radeon HD 6870 ] [ GeForce GTX 480 ] Premier point, l'utilisation du mode "D" ne change pas grand-chose par rapport au mode où l'IGP est désactivé d'un point de vue consommation, à un ou deux watts près. C'est surtout dans l'autre sens, en mode "I", que l'on aurait pu espérer voir une baisse de la consommation au repos sur le bureau. Malheureusement il n'en est rien. Notez que si la consommation est plus faible sous F1 2011 en mode "I" avec la GeForce, cela est à relier aux performances plus faibles. La carte graphique travaille moins, et donc, consomme moins. Il en va évidemment de même pour toutes les performances de la Radeon HD 6870 qui pour rappel fonctionne à 100 MHz. Page 3 - Hyperformance, Virtual V-Sync HyperFormance Pour sa version MVP, Lucid introduit deux nouvelles fonctionnalités qui avaient été entrevues précédemment, Hyperformance et Virtual V-Sync. Commençons par la première. Pour tous les tests suivants nous avons utilisé la GeForce GTX 480, l'écran étant connecté sur la carte mère (mode I), nécessaire pour profiter d'HyperFormance et Virtual V-Sync.  Sur son site , Lucid décrit Hyperformance de la manière suivante, "éliminer les tâches de rendu redondantes, prédire les problèmes de synchronisation potentiels et les enlever ou les remplacer pour améliorer les contrôles". Dans la documentation (que vous pouvez télécharger en PDF sur le site d'Asrock ) ou dans l'interface du logiciel, l'explication est plus lapidaire, il s'agit d'augmenter les performances et le framerate. Si un "white paper" est disponible (PDF) , il se contente d'évoquer principalement Virtual V-Sync. Lorsqu'il s'agit d'entrer dans des détails sur l'implémentation précise, le document indique qu'elle ne sera pas détaillée "pour des raisons de brevets". D'un point de vue pratique, toutes les applications ne sont pas supportées, la liste comporte principalement des benchmarks, ou des jeux disposants de benchmarks intégrés. Tenter d'activer HyperFormance sur Batman Arkham City aura provoqué des clignotements et des erreurs d'éclairage à titre indicatif.  Une fois activé, HyperFormance augmente bel et bien le framerate dans les applications supportées, mais augmente également les scores 3D Mark (nous avons dépoussiéré la version 2006 pour l'occasion). Jugez plutôt :  Nous reviendrons sur l'astérisque concernant Mass Effect un peu plus loin. Pour les autres titres, comment expliquer ces augmentations miraculeuses ? La carte graphique a-t-elle réellement créé plus d'images ? Oui et non. Nous avons utilisé Fraps pour mesurer le temps de calcul des images sous Lost Planet 2, avec et sans HyperFormance.  Attention ! Ce graphique indique le temps de calcul successif d'une série d'images. L'axe horizontal n'est pas un axe temporel, on ne peut donc pas comparer un à un le temps de rendu des images. Ceci étant posé, on peut remarquer quelques tendances. D'abord en mode normal, le temps de rendu d'une image est relativement constant, variant entre 10 et 16 millisecondes. En mode HyperFormance, on distingue deux cas :
Visiblement donc, si le nombre d'images calculés augmente, toutes les images calculées ne sont pas égales. A l'aide de GPU Perf Studio , outil développeur fourni par AMD, nous avons pu voir, pour au moins une application, le type d'optimisation utilisé par Virtu MVP. Malheureusement GPU Perf Studio est très pointilleux, nécessitant par exemple des applications DX10 ou 11 qui ne font pas la majorité des titres accélérés par HyperFormance. Nous avons cependant réussi à illustrer ce qui se passe sous 3D Mark Vantage. Nous ne pouvons pas confirmer que le même type d'optimisation soit systématiquement utilisé dans tous les titres HyperFormance, même si cela semble probable. Afin de simplifier la tâche à notre pauvre Radeon bloquée à 100 MHz (les outils d'overclocking tels MSI Afterburner, s'ils détectent correctement les fréquences 3D une fois un profil Virtu créé, et permettent de les changer, ne les rendent pas pour autant actives), nous nous sommes contentés pour ce test du mode Entry en 640 par 480. Voici une fois de plus le temps de calcul par frame, pour une série de 25 frames avec et sans HyperFormance :  Une fois de plus on peut noter que si en mode normal, toutes les frames se ressemblent, il y'a encore au moins deux types distincts de frames en mode HyperFormance. Avant d'aller plus loin, permettez nous de rappeler que le rendu d'une image sous DirectX est subdivisé en étapes, chacune étant ce que l'on appelle un draw call, un ordre envoyé par le CPU à la carte graphique pour réaliser une tâche. Pour plus de détails nous vous renvoyons à ce dossier où nous avions décomposé le rendu graphique par étape de 3D Mark, en version 11. Ici, GPU Perf Studio nous a permis de voir qu'en mode Entry sous Vantage (test graphique 1), les images du début de la scène nécessitent toutes un peu plus de 200 draw call en mode normal. Avec HyperFormance, les frames "B" sont du même type, il s'agit bien d'images normales. Mais quid de ces frames qui se calculent magiquement en moins de 5 millisecondes ? En pausant sur l'une de ces frames, nous pouvons voir via le Frame Debugger que seulement quatre draw call sont effectués. Contrairement à ce que nous évoquions dans notre article, et qui est la pratique normale (appliquée sur les frames B), ici la remise à zéro des mémoires tampons ne se fait pas. L'image précédemment calculée est ainsi récupérée. Les quatre draw call vont ainsi :
 Bien évidemment, on ne peut que qualifier de tricherie cette pratique. Virtu MVP intercepte les draw calls envoyés par le CPU pour ces images de type A et supprime tous les draw calls "utiles" pour ne garder que ces quatre call du bandeau. Ainsi l'image précédemment calculée est bel et bien répétée, sauf pour le compteur en bas de l'écran. Ces images intercalées ne font ici que grossir artificiellement le framerate, si l'on compte le nombre de frames "utiles" réellement calculées par seconde, HyperFormance en produit un nombre inférieur. Le subterfuge doit donc être adapté à chaque jeu ou benchmark, et nous supposons que la suppression des draw calls doit être soit quasi totale, soit se limiter dans certains titres à des rafraichissements minimes (on peut imaginer par exemple supprimer tous les calls sauf le dessin du HUD ou de la croix de visée pour un FPS par exemple). Cela explique aussi pourquoi HyperFormance est ainsi limité à si peu de titres : ces "optimisations" doivent être écrites au cas par cas pour les jeux. Notez que cela ne marche pas en permanence puisque Mass Effect, pourtant marqué comme supporté nous a donné des clignotements constants. En pratique nous avons pu capturer ces deux images qui alternent en permanence pour causer le clignotement :   Des images partiellement rendues apparaissent à l'écran, indiquant un problème de synchronisation dans le choix des images à afficher. En théorie, via l'utilisation de deux framebuffer (celui de la carte graphique et celui de l'IGP), le pilote de Virtu MVP pourrait sélectionner les images à transférer vers l'écran. Ainsi, des images partiellement rendues peuvent très bien ne jamais arriver vers l'écran. Visiblement dans Mass Effect, soit le mécanisme de tri des draw call ne fonctionne pas correctement ici, soit le mécanisme de choix des images à afficher est défectueux. Dans tous les cas, le jeu est injouable. Avec cette tricherie, HyperFormance manipule la notion de ce qu'est réellement une frame, pour afficher des scores plus hauts dans les benchmarks. Comment justifier une telle pratique ? Dans son "white paper", Lucid explique qu'augmenter le framerate augmente la réactivité de l'application par rapport aux entrées souris/clavier avec ce schéma :  Ici, c'est le point A, à gauche, qui nous intéresse, il rappelle effectivement que c'est le CPU qui pilote le GPU et lui demande de rendre les images (via les draw call évoqués plus haut). Cependant par la suite Lucid nous semble faire un raccourci en expliquant qu'augmenter le framerate augmente la réactivité des entrées sorties. Nous pensons que cela est relativement incorrect pour de multiples raisons. D'abord, il faut rappeler que les périphériques comme le clavier et la souris sont limités dans leur réactivité par l'interface sur laquelle ils sont connectés. Dans le cas de l'USB, la souris et le clavier ne sont interrogés que 125 fois par seconde par défaut (on parle de poll rate) par Windows. Passer de 140 à 300 images par seconde n'augmente donc pas la réactivité de lecture des entrées sorties quand ces dernières sont limitées elles mêmes à 125. Ensuite, les joueurs qui ont manipulé le poll rate de l'USB sous Windows le savent (certains pilotes de souris "gamer" le permettent par exemple, même si d'autres utilitaires existent), l'augmentation de la sensibilité n'est pas directement lié au nombre d'images par secondes affichées. Comme l'indique pourtant le schéma de Lucid, c'est bien le CPU qui au final pilote la carte graphique, et sa rapidité de rendu est (en partie) accessoire dans la fluidité des entrées. Les moteurs de jeux modernes sont en effet multithreadés. La gestion des entrées comme le clavier et la souris (mais aussi le réseau) sert à réaliser, côté CPU, un modèle de la simulation en mémoire. Ce modèle est une représentation du monde dans lequel évolue le joueur, sous la forme de coordonnées (pour la position) et de vecteurs (pour la direction/mouvements) et d'autres données diverses (nombre de balles restantes dans le chargeur, etc). Au moment de rendre une image, ce modèle est interrogé par le thread CPU qui récupère ces informations avant d'envoyer les draw calls à la carte graphique qui effectuera de son côté son travail. Ainsi, on peut considérer qu'en augmentant (réellement) le framerate de 80 à 120 FPS, le temps de latence entre l'interrogation du modèle (que l'on peut placer à la fin du calcul de l'image précédente) et la fin de calcul de l'image peut passer de 12 à 8 millisecondes dans le cas le plus avantageux possible. Cependant, l'écran ne pouvant afficher (généralement) que 60 images par secondes (la dernière image complète si le VSync est activé, ou un mélange d'image dans le cas ou la copie dans le framebuffer n'est pas terminée lorsque l'écran réclame son image sans Vsync - ce qui cause le tearing), le gain pratique se retrouve réduit. Mais que se passe-t'il en réalité avec Virtu MVP ? Si l'on prend le cas le plus avantageux, en intercalant une image "vide" entre chaque image réelle, on profite effectivement d'un petit avantage de latence à cet endroit, mais ce n'est pas exactement ce qui se passe. En effet, parfois deux images "normales" sont calculées à la suite, c'était plus particulièrement le cas dans Lost Planet 2 un peu plus haut. Dans ce cas, on se retrouve avec un avantage de latence fluctuant qui peut se transformer soit en très légère avance, soit en très léger retard selon les cas. Dans l'absolu cependant, nous parlons au mieux de deux à trois millisecondes sur cette étape seule. Qu'il faut placer en perspective dans le pipeline complet du jeu et de l'affichage, la latence totale entre l'appui sur une touche jusqu'à ce que l'image soit visible par l'œil à l'écran est plus proche des 100 millisecondes dans sa globalité. Et dans le cas du mode I, le transfert par le PCI Express ajoute une latence supplémentaire de l'ordre d'un peu plus d'une milliseconde. En étant largement sous 60 fps, comme c'est le cas dans notre exemple sous 3DMark Vantage, la latence peut être raccourcie comme l'indique Lucid lors du premier affichage de l'image, mais étant donné qu'elle est dédoublée, la latence moyenne n'est pas réellement réduite et moins d'images réelles sont affichées. En pratique dans ce cas, HyperFormance n'a qu'une utilité à nos yeux : augmenter artificiellement les scores dans les benchmarks. L'argument de la latence ressemble alors plus selon nous à une justification pour cette pratique qui reste avant tout une tricherie dans les benchmarks. Virtual V-Sync Reprenons ce schéma pour évoquer ce que propose Lucid avec Virtual V-Sync, il s'agit ici du point B : A l'image du V-Sync traditionnel, l'idée de Virtual V-Sync est d'éliminer les effets de tearing, les images incomplètes placées dans le framebuffer qui sont parfois envoyées à l'écran. Le VSync s'assure que seules des images complètes sont ainsi envoyées à l'écran en gardant une image calculée à l'avance (le double buffering). Virtual V-Sync profite du fait qu'en mode "I", deux buffers sont bel et bien disponibles, d'un côté celui de la carte graphique, de l'autre celui de l'IGP. Comme nous l'avons vu avec HyperFormance, le pilote de Lucid a donc la possibilité de choisir quelles images sont envoyées vers le framebuffer réellement connecté à l'écran (à l'image de ce que l'on évoquait avec la souris et le clavier, l'écran fonctionne avec un taux de rafraichissement fixe, 60 fois par seconde le framebuffer est envoyé vers l'écran pour être affiché). Le framebuffer de l'IGP n'est ici plus mis à jour en permanence, mais uniquement 60 fois par seconde si le framerate dans le jeu le permet. De là deux cas se produisent :
Quel est alors l'intérêt ? Il revient toujours au même, selon Lucid, augmenter le framerate permet d'augmenter la réactivité de l'application. L'algorithme de Virtu choisit alors lesquelles des images calculées durant un intervalle de 16 ms (1 seconde divisé par 60) devra transiter jusqu'au framebuffer de l'IGP. En pratique notre constatation reste la même que pour HyperFormance, si l'augmentation du framerate peut avoir un rôle sur une partie de la latence, le fait d'activer la synchronisation verticale, et donc un double (ou triple) buffering rallonge encore la latence totale. Le gain théorique est insignifiant et en pratique, nos jeux n'étaient pas plus réactifs qu'avec un simple VSync activé, alors qu'ils l'étaient légèrement une fois le Vsync desactivé. Page 4 - Conclusion Conclusion  Avec cette nouvelle version de Virtu, LucidLogix continue de proposer des solutions originales qui répondent en partie à certains besoins et certaines limitations des plateformes PC modernes équipées de plus d'un GPU. Ainsi, si l'utilisation du mode I (écran connecté sur la carte mère) ne nous semble pas la plus intéressante - elle fait perdre des performances sans pour autant réduire la consommation énergétique au repos - le mode D permettra à ceux qui désirent utiliser Quick Sync pour réaliser des encodages vidéos (et ce malgré ses défauts point de vue qualitatif, voir notre dossier sur le sujet pour rappel) de le faire sans devoir débrancher leur écran et redémarrer leur machine. En cela, Virtu répond à un problème réel… d'Intel. En ce qui concerne cependant les nouvelles fonctionnalités apportées par MVP, à savoir HyperFormance et Virtual V-Sync, nous nous devons d'être beaucoup plus critiques. Si l'argument marketing derrière ces deux technologies peut sembler séduisant, dès que l'on y regarde de près, les choses ne sont pas aussi simples. En réutilisant des technologies développées pour ses pilotes Hydra de manipulation du rendu graphique, HyperFormance ne fait qu'augmenter virtuellement les performances, sans apporter, en théorie ou en pratique d'avantage réel sur la "réactivité". Nous trouvons d'autant plus dommageable ce communiqué de presse de FutureMark qui, à défaut d'interdire purement et simplement ces manipulations de pilotes qui, nous l'avons vu, sont purement et simplement des tricheries dans le cas de 3D Mark, choisit un compromis en proposant dans les semaines qui viennent une mise à jour qui permettra de détecter l'utilisation d'HyperFormance afin de séparer les scores publiés sur son site qui utiliseraient cette technologie. Si AMD et Nvidia avaient procédé à de telles modifications dans leurs pilotes (par exemple pour le SLI et le Crossfire), nous ne pouvons nous empêcher de penser que FutureMark n'aurait pas réagit de la même manière. Ici l'argument marketing de la réactivité, pour un benchmark passif, tient encore moins. En ce qui concerne Virtual V-Sync en pratique nous peinons de la même manière à voir l'intérêt de la technologie au-delà d'une indication visuelle d'un framerate plus élevé qu'il n'est réellement affiché, c'est d'ailleurs comme cela que Lucid présentait sa technologie lors de l'IDF en septembre dernier. Notez enfin que nous n'avons pas évoqué les multiples problèmes de compatibilité que nous avons rencontrés. Au-delà de notre Radeon, bloquée aux fréquences 2D, nous aurons noté de manière assez persistante des problèmes de blocages au lancement et à la fermeture de certains jeux, particulièrement présents sous Batman Arkham City et Lost Planet 2. Un redémarrage de la machine aura été assez souvent nécessaire durant nos tests. Des problèmes qui là encore ne sont pas nouveaux puisque nous avions rencontrés les mêmes en testant les solutions Hydra. En attendant un éventuel support du mode I pour les Radeon HD 7000 qui serait cumulé à une gestion du Zero Core Power, l'intérêt de Virtu MVP se résume pour nous uniquement à l'utilisation de son mode D pour l'encodage vidéo via Quick Sync. Un problème pour lequel Intel aurait pu trouver une autre solution en fournissant une passerelle gratuite à tous les utilisateurs, plutôt que de passer par un investissement dans Lucidlogix pour une solution qui est ensuite revendue aux constructeurs de cartes mères, et qui donc, augmente le coût de ces dernières pour les utilisateurs. Mise à jour du 11 juillet 2012 : Lucid a apporté une clarification concernant les observations que nous avons réalisés dans cet article autour de la technologie HyperFormance. Le traitement apporté aux benchmarks comme 3D Mark (ou d'autres tels Unigine) sur lequel nous avons basé nos observation est différent de celui appliqué dans les jeux. Vous pouvez retrouver plus de détails dans cet article. Copyright © 1997-2024 HardWare.fr. Tous droits réservés. |