Les contenus liés au tag AMD

Enfin ! Après quelques mois d'attente, la première version de l'API graphique Mantle est en approche avec un support intégré aux Catalyst 14.1 beta, un patch pour Battlefield 4 et la démo technique StarSwarm.

Rappel

Dévoilée fin septembre lors de la présentation du GPU Hawaii et des Radeon R9 290/290X, l'API graphique propriétaire Mantle s'est fait quelque peu attendre. Il était au départ question de l'arrivée fin décembre d'un patch dédié pour Battlefield 4, EA-DICE s'étant investi dans le développement de Mantle, mais celui-ci a finalement été reporté d'un mois. Le délai n'est pas réellement lié à Mantle, même si tant AMD qu'EA-DICE ont eu un peu plus de temps pour peaufiner son implémentation, mais plutôt aux nombreux bugs qui ont affectés ce jeu et dont la prise en charge était prioritaire.

Les récentes rumeurs qui mentionnaient un nouveau report d'un mois étaient sans fondement et c'est aujourd'hui que débarque le support officiel de Mantle ainsi qu'un patch pour Battlefield 4 préparé par EA-DICE et la démo technique d'Oxide Games : StarSwarm.


Pour rappel, Mantle est une API graphique tout comme Direct3D ou encore OpenGL. Elle s'en démarque par un niveau d'abstraction différent qui propose un compromis orienté vers plus de liberté pour les développeurs et plus de performances, principalement en réduisant le surcoût CPU du traitement des commandes graphiques au niveau des API et des pilotes. Pour plus de détails à son sujet :

APU13: AMD Mantle : premiers détails
APU13: Frostbite & Mantle: proche de la PS4? 15 jeux...
APU13: Oxide fait exploser la limite CPU avec Mantle

Mantle est globalement une API de plus bas niveau que Direct3D et OpenGL, mais il ne s'agit pas de programmer le GPU dans un langage assembleur barbare, les shaders restent d'ailleurs identiques à ceux de Direct3D. Tout l'héritage et l'aspect rétrocompatibilité de ces API les ont alourdies, notamment en imposant de nombreuses vérifications à chaque commande pour s'assurer qu'elle respecte bien tout un tas des paramètres dont certains n'ont plus aucune base technique sur les GPU modernes.

Mantle profite pleinement de l'architecture unifiée des GPU GCN (depuis les Radeon HD 7000) et du support d'une mémoire virtuelle unifiée pour remettre l'API à plat et la simplifier autant que possible. Sous certains aspects, cela simplifie le travail des développeurs mais leur transfère une plus grande part de responsabilité en ce qui concerne la robustesse de leur moteur graphique.

Les gains principaux en termes de performances sont à chercher du côté CPU, à travers ces quatre points :

- Low-overhead validation and processing of API commands
- Explicit command buffer control
- Close to linear performance scaling from recording command buffers onto multiple CPU cores
- Reduced runtime shader compilation overhead

En d'autres termes, Mantle permet de réduire le coût CPU du rendu graphique et de mieux utiliser les CPU multicores pour le traitement de ce dernier. Des gains sont également possibles à travers une utilisation plus efficace du GPU :

- Reduction of command buffers submissions
- Explicit control of resource compression, expands and synchronizations
- Asynchronous DMA queue for data uploads independent from the graphics engine
- Asynchronous compute queue for overlapping of compute and graphics workloads
- Data formats optimizations via flexible buffer/image access
- Advanced Anti-Aliasing features for MSAA/EQAA optimizations

Il va cependant falloir plus de temps pour que les développeurs en tirent parti, soit parce que cela demande encore pas mal de recherche soit parce que cela correspond à des cas qui sont encore peu courants tels que le traitement simultané de tâches de types graphique et compute.

AMD insiste bien sur le fait que Mantle n'est pas sa vision de choses imposée aux développeurs mais bien une réponse à une demande de leur part. AMD indique travailler sur Mantle depuis 3 ans en étroite collaboration avec EA-DICE qui développe le Frostbite Engine exploité notamment dans Battlefied 4. La version alpha de Mantle, qui sert de base aux deux exemples rendus disponibles aujourd'hui, a ensuite été proposée à une poignée de développeurs dont Oxide Games. AMD fait même référence à un "consortium Mantle", laissant penser que les prises de décisions à son sujet se font au moins en partie par les développeurs.

Mantle reste une API propriétaire, actuellement spécifique aux Radeon, mais elle a été conçue pour pouvoir être étendue à d'autres architecture si nécessaire. Nous estimons cependant nulles les chances que Nvidia accepte de rejoindre une initiative d'AMD et/ou que ce dernier ne pose pas des conditions difficiles à accepter.

Les pilotes Catalyst 14.1 beta

Tout d'abord, AMD s'apprête à distribuer ce qui permet à Mantle de fonctionner, soit un pilote qui intègre son support : les Catalyst 14.1 beta. Initialement ce pilote devait être rendu public ce matin à 6h. AMD nous a indiqué hier soir qu'il y aurait probablement un retard de quelques heures mais s'est ravisé ce matin : suite à des problèmes de dernière minute la sortie du pilote prévu est annulée et un nouveau est en préparation. AMD promet ce pilote rapidement pour la presse, peut-être aujourd'hui, mais il ne sera rendu public que 24h plus tard. Vous pourrez alors les télécharger via ce lien :

Catalyst beta 

Au niveau de l'implémentation, si toutes les pistes étaient sur la table au départ, AMD a opté pour l'intégration classique d'un pilote Mantle dans ses pilotes Catalyst, en opposition, par exemple, à l'intégration d'une DLL directement dans les jeux. Nous avions au départ pensé que cette solution serait proposée par AMD pour éviter qu'une mise à jour des pilotes ne vienne modifier le comportement de Mantle et poser un problème dans certains jeux.

AMD nous explique cependant que Mantle est une API tellement simple qu'il n'y a pas de changement de comportement significatif possible après une mise à jour du pilote qui servira plutôt à ajouter des fonctionnalités ou à optimiser les performances. Pour s'assurer qu'un développeur ne construise pas son code autour d'un bug, ce qui pourrait alors poser problème une fois ce bug corrigé, Mantle intègre directement dans l'API ce qu'AMD appelle le "validation layer". En plus d'être fonctionnel, le code des développeurs devra se conformer aux exigences de ce "validation layer" pour que l'application puisse passer au stade de production.

Ces Catalyst beta intègrent une version alpha de Mantle qui est accompagnée de plusieurs limitations :

- Pas de support direct de CrossFire X
- Pas de support des plateformes Enduro / PowerXpress
- Support limité des GPU GCN "1.0"

Le support des plateformes Enduro viendra plus tard, tout comme des facilités d'utilisation du multi-GPU. En attendant, les développeurs restent libres d'implémenter eux-mêmes le multi-GPU, ce que permet de faire Mantle, par ailleurs avec des possibilités d'optimisation plus poussées. AMD publiera et actualisera la liste des limitations sur cette page :

Mantle Known Issues 

Rappelons qu'AMD a fait évoluer légèrement son architecture GCN, notamment en y intégrant un support complet de la mémoire unifiée virtuelle. Celles-ci étant à la base de l'API Mantle, ces GPU plus récents se trouvent avantagés et AMD a optimisé en priorité pour le cas de figure qui leur correspond. Ces GPU, que nous qualifions de GCN "1.1", sont Bonaire, Hawaii et Kaveri et correspondent à ces produits :

- Radeon HD 7790
- Radeon R7 260/260X
- Radeon R9 290/290X
- APU A-Series 7000

Les autres GPU GCN, niveau "1.0", se contentent d'un support partiel de la mémoire unifiée, suffisant selon AMD pour une compatibilité totale avec Mantle, mais il faudra probablement un peu plus de travail pour en finaliser la prise en charge optimale. Ces GPU, Oland, Cape Verde, Pitcairn et Tahiti sont compatibles avec cette version de Mantle mais les gains de performances seront limités dans Battlefield 4. AMD précise que ces produits représentent la prochaine priorité sur sa liste et que des optimisations leurs seront dédiées dans de futurs pilotes. Cela concerne ces cartes graphiques :

- Radeon HD 7700/7800/7900 (sauf 7790)
- Radeon HD 8000 OEM
- Radeon R9 270/270X/280X
- Radeon HD 7700M/7800M/7900M
- Radeon HD 8000M
- Radeon R5 M230, R7 M265, R9 M290X

A noter que ces pilotes Catalyst 14.1 beta apportent, enfin, le support du frame pacing (cadence d'affiche régulière en multi-GPU) pour les résolutions supérieures au 1600p pour l'ensemble des cartes graphiques ainsi que pour les APU Kaveri couplées à une Radeon R7 250. Ces pilotes incluent également le support de la HSA pour Kaveri.

Patch Mantle pour Battlefield 4

Selon les informations fournies par AMD, EA-DICE va publier à partir de ce matin à 10h une mise à jour pour Battlefield 4 qui apporte, en plus du moteur de rendu Direct3D, un moteur de rendu Mantle. Nous n'avons pas pu avoir accès en avance à ce patch et tâcherons donc de le tester dans la journée. En attendant, voici ce qu'indique AMD concernant les performances :

- Gains de 41% pour une Radeon R9 290X sur un A10-7700K en 1080p Ultra AA4x
- Gains de 40% pour une Radeon R9 290X sur un A10-7700K en 1600p Ultra AA4x
- Gains de 3% pour une Radeon R7 260X sur un Core i7-4960X en 1080p Ultra FXAA
- Gains de 1% pour une Radeon R7 260X sur un Core i7-4960X en 1600p Ultra FXAA

AMD parle ensuite de gains moyens d'un peu plus de 10% en mélangeant des résultats obtenus sur Radeon R9 290X et Radeon R7 260X avec différents CPU. Un chiffre qui ne veut pas dire grand-chose compte tenu des écarts observés dans les situations données ci-dessus.

Cela confirme donc bien que les gains sont à chercher du côté CPU et non du côté GPU. Ce n'est pas une surprise, EA-DICE l'ayant indiqué dès le départ en précisant que les optimisations au niveau des performances GPU étaient toujours à l'état de R&D.

Battlefield 4 intègre le support de CrossFire X directement au niveau de son moteur. AMD précise malheureusement que la stabilité n'est pas parfaite et que le frame pacing n'est pas fonctionnel. En d'autres termes pour le multi-GPU, il faudra encore patienter un petit peu. Eyefinity est par contre fonctionnel à l'exception des configurations de type 5x1 dans lesquelles les écrans sont en mode portrait.

Mise à jour 10h30 : la mise à jour de Battlefield 4 est arrivée comme prévue. Une option dans les paramètres graphiques permet de passer de Direct3D à Mantle si cette API est supportée par le système :


Vous pourrez retrouver quelques informations de plus sur ce patch ainsi que quelques mesures de performances dans le blog de Johan Andersson , le directeur technique du moteur Frostbite.

Démo StarSwarm

StarSwarm est une démo proposée par Oxide Games tirée d'une scène de test exploité en interne pour le développement du moteur Nitrous qui a été pensé pour pouvoir gérer des immenses champs de bataille et donc de très nombreux éléments. Augmenter le nombre d'éléments fait exploser le surcoût au niveau des API classiques, ce qui fait du moteur Nitrous et de StarSwarm un bon exemple de la différence énorme que peut faire Mantle, AMD annonçant des performances pouvant être jusqu'à 4x supérieures en cas de limite CPU.


L'aspect graphique de la démo est relativement basique mais correspond à un cas réaliste, selon ses développeurs, de simulation spatiale dans laquelle plusieurs milliers d'unités s'affrontent. De quoi mettre à genoux les plus gros CPU dans la version Direct3D alors qu'un CPU modeste peut encaisser la charge sans trop de problème dans la version Mantle.

StarSwarm devrait être disponible publiquement et gratuitement à 21h. Ni le support d'Eyefinity, ni celui de CrossFire X ne seront de la partie, cela viendra dans une future version de la démo. A l'heure où nous écrivons ces lignes, nous disposons d'une version presse de la démo… mais pas encore des pilotes Catalyst 14.1 beta qu'AMD semble fignoler jusqu'à la dernière minute.

Un début et puis ?

AMD indique qu'il ne s'agit que d'un début, que des premiers pas de Mantle alors que de nombreux chantiers restent ouverts. Le spécialiste des technologies graphiques promet ainsi progressivement plus de performances et le support de plus de jeux, 15 sont par exemples prévus sur base du Frostbite 3. En attendant, il reste bien entendu à évaluer les gains réels de ces débuts, ce que nous ferons dès que possible.

AMD a profité de l'Open Compute Summit  (une conférence issu de l'Open Compute Project démarré par Facebook ) pour annoncer officiellement ses SoC serveurs basés sur une architecture ARM.

Ce n'est pas une surprise puisque le constructeur avait annoncé son intention dès 2012 suite au rachat de SeaMicro et l'année dernière, les roadmaps du constructeur incluaient l'arrivée d'un premier SoC baptisé Seattle pour la seconde partie de l'année 2014.

AMD annonce donc officiellement ces SoC qui porteront le nom d'Opteron A1100. Comme indiqué précédemment, AMD utilisera des cores Cortex-A57 de design ARM, et non un design custom. Ces derniers sont compatibles avec l'architecture ARMv8 qui apporte pour rappel le support du 64 bits. Ces puces sont destinées à des serveurs visant des charges légères (serveurs web, etc) à l'image des Opteron X1150 et X2150.

Ces SoCs sont fabriqués par GlobalFoundries en 28nm et intègrent huit cœurs Cortex-A57 et quatre Mo de cache de niveau 2, auquel AMD rajoute des blocs customs. Le tout fonctionne à une fréquence annoncée comme supérieure à 2 GHz pour un TDP de 25 watts.

Parmi les fonctionnalités custom, AMD intègre un contrôleur mémoire 128 bits compatible à la fois avec les standards DDR3 et DDR4. On retrouve également 8 lignes PCI Express 3.0 ainsi que de quoi gérer huit disques Serial ATA 6 Gb/s et deux ports 10 GbE.


AMD mettra à disposition un kit de développement en mars, mais il faudra attendre le quatrième trimestre pour voir arriver ces solutions dans le commerce. AMD dispose d'ambitions élevées avec ARM côté serveur, espérant pouvoir profiter de son expérience sur le marché de l'Opteron ainsi que celles acquises avec SeaMicro pour en capter une part importante.

AMD profite également du vide laissé par l'arrêt de Calxeda  à la fin du mois de décembre dernier pour se positionner. Reste que la disponibilité annoncée seulement pour le quatrième trimestre risque d'être tardive pour ce qui reste un SoC 28nm utilisant des cores non custom, et l'on devrait voir d'ici là d'autres acteurs émerger, possiblement en 20nm.


On notera enfin avec attention qu'AMD n'hésite pas à jouer la carte de l'alternative face au x86 indiquant que les OEM, ODM et les clients souhaitent « qu'ARM gagne », ce que l'on comprend entre les lignes comme une rébellion envers Intel dont la domination du marché x86 serveur s'accompagne de marges importantes. Reste à voir si la vision d'AMD se cantonne aux serveurs, ou s'il s'agit d'une vision plus générale, AMD déclinant déjà le x86 sur de multiples marchés.

Durant le CES, AMD nous a surpris en dévoilant une alternative gratuite au G-Sync de Nvidia. Si de nombreuses questions restent en suspens, nous en savons aujourd'hui un peu plus : elle devrait passer par une nouvelle option intégrée au standard DisplayPort 1.2a actuel.

Pour rappel, en octobre dernier, Nvidia a dévoilé G-Sync, un mode d'affichage qui repose sur une fréquence de rafraîchissement variable (ou dynamique, ou encore non-isochrone, FRV) destinée à forcer l'écran à se synchroniser par rapport au GPU. L'intérêt est d'éviter les désagréments de la fréquence de rafraîchissement fixe traditionnelle : elle force le GPU, qui par nature ne produit pas les images à intervalle parfaitement régulier, à se contorsionner pour se synchroniser par rapport à l'écran, ce qui entraîne suivant les cas et le mode de V-Sync des cassures dans les images, des saccades et/ou une latence supplémentaire. Des désagréments que les joueurs PC doivent accepter depuis de nombreuses années, à moins de disposer de systèmes très puissants capables de maintenir en permanence un niveau de performances égal ou supérieur au taux de rafraîchissement de l'écran.

Pour pouvoir proposer ce mode d'affichage miracle, Nvidia a recours à un "module G-Sync", relativement onéreux, qui vient prendre la place des contrôleurs de dalles LCD tradionnels ("scalers"). Nous avons pu tester un écran compatible G-Sync et les résultats sont probants : aucune cassure dans les images et une fluidité qui progresse nettement quand les performances se situent entre 40 et 60 fps.

Durant le CES, soit 4 mois plus tard, AMD a enfin réagi en indiquant qu'un standard VESA (Video Electronics Standards Association) allait permettre de faire de même sans devoir passer par un module spécial. Une initiative surnommée "FreeSync" en référence au surcoût élevé de la solution de Nvidia, et directement mise en démonstration à travers Toshiba Satellite Click (2-in-1 13.3") pour lequel la fréquence de rafraîchissement variable a été activée.

Bien que très brève, cette démonstration a mis en avant un résultat identique à celui de G-Sync et pour cause, son fonctionnement est exactement le même : partir de la fréquence de rafraîchissement maximale de l'écran et moduler la durée du VBLANK (espace entre 2 images sur le signal vidéo) pour forcer l'écran à "patienter" le temps que le GPU lui propose une nouvelle image à afficher.

Une démonstration qui a soulevé de nombreuses questions. Comment est-ce possible de faire aussi bien que G-Sync sans module spécial ? A quoi sert ce module G-Sync ? De quel standard s'agit-il ? Quand est-ce que cela pourrait être disponible ? Pourquoi Nvidia fait-il mine d'ignorer qu'un standard est en approche ? … Tant AMD que Nvidia ont préféré éviter de répondre à des questions trop précises, le premier probablement parce que sa solution n'est pas encore prête, le second probablement pour éviter d'avoir à admettre ne pas nous avoir tout dit…


Nous avions en effet dès le départ posé de nombreuses questions aux responsables de Nvidia concernant G-Sync, et à nouveau au début du mois de décembre en préparant le test du premier écran compatible. La possibilité qu'il fonctionne sur base d'un standard actuel ou futur ? Son intégration dans les portables qui pourrait être plus simple via l'eDP ? Nvidia n'a jamais répondu clairement à ces questions, se contentant de tourner autour du pot et de laisser penser que rien de tout cela n'était à l'ordre du jour, mais que tout était possible dans l'avenir. Après la démonstration d'AMD, Nvidia n'était pas plus pressé de répondre à ces questions, mais a tenu à préciser que la gestion de l'affichage est différente sur un écran intégré dans un portable par rapport à un moniteur de bureau et que sa solution repose sur une technologie propriétaire pour laquelle des brevets ont été déposés.

Rappelons à ce niveau qu'un brevet déposé n'est pas un brevet accordé (cela prend du temps) et encore moins un brevet validé puisque cela n'intervient en pratique aux Etats-Unis que s'il est contesté. Si la fameuse mention "patent pending" est prévue pour prévenir des concurrents éventuels qu'ils risquent d'enfreindre un brevet, son utilisation est devenue courante, toutes industries confondues, pour renforcer la communication en termes de crédibilité, de sentiment de complexité, d'exclusivité, etc.

Le plus simple aurait bien entendu été que VESA clarifie la situation. AMD indique que pas mal de personnes qui prennent part à l'organisation ont fait de gros yeux quand ils ont vus Nvidia annoncer une technologie propriétaire de gestion de la fréquence de rafraichissement variable. En fait, cette fonctionnalité existe depuis 2008 dans le standard eDP 1.0 (DisplayPort interne) puisqu'elle peut permettre des économies d'énergie, par exemple en ne rafraîchissant pas l'affichage du bureau Windows quand rien ne bouge. Nvidia ne ferait donc qu'en profiter dans une situation différente.


Malheureusement, VESA se contente de répondre qu'il ne leur est pas possible de commenter officiellement le sujet et qu'une communication officielle aura lieu plus tard dans l'année. L'accès à toutes les documentations des standards VESA est par ailleurs restreint à ses seuls membres.

En l'absence de plus de détails de la part de Nvidia, d'AMD ou de VESA, nous avons heureusement pu compter sur un lecteur bien informé, que nous remercions, puisqu'il a eu accès à ces documents et a pu nous les communiquer.

Nous apprenons ainsi qu'une demande de type SCR (Specification Change Request) a été déposée de manière à intégrer le support optionnel de la fréquence de rafraîchissement variable au standard DisplayPort 1.2a. Compte tenu du nom du document daté du 25 novembre, DP1.2a Extend MSA Tmg Para AMD SCR, il semble évident que la proposition a été soumise par AMD. Elle est actuellement au stade GMR  (General Member Review) est donc en bonne voie d'être finalisée et ratifiée.

Voici un extrait du document en question :

Summary
Extend the "MSA TIMING PARAMETER IGNORE" option to DisplayPort to enable source based control of the frame rate similar to embedded DisplayPort.

Intellectual property rights
N/A

Benefits as a result of changes
This enables the ability for external DisplayPort to take advantage of the option to ignore MSA timing parameter and have the sink slave to source timing to realize per frame dynamic refresh rate.

Assessment of the impact
The proposed change enable per frame dynamic refresh rate for single stream devices that expose dynamic refresh rate capability in EDID for DisplayPort interface. The source will be able to enable this with an SST interface or MST hub with physical ports. Logical MST port support of the feature is not included as part of this SCR. A generic framework to enable such feature for logical port is required that can accommodate other feature where stream related configuration is programmed in DPCD.

Analysis of the device software implication
SST device which support "MSA TIMING PARAMETER IGNORE" option will be able to expose the capability in EDID and DPCD to let source enable dynamic refresh rate.
Source driver would have to be updated to parse EDID and enable "MSA TIMING PARAMETER IGNORE" feature when source want the sink to be refreshed based on its update rate.

Analysis of the compliance test and interop implications
Currently this feature is tested as part of eDP CTS. New test would have to be added as part of DP LL CTS and EDID CTS.

D'ici quelques temps, les écrans DisplayPort 1.2a pourront donc, si les fabricants le désirent, supporter une fréquence de rafraîchissement variable. Pour cela, il faudra que la dalle LCD l'accepte ainsi que le contrôleur de l'écran. Durant le CES, AMD avait affirmé que certains moniteurs actuels seraient capables de supporter cette évolution avec une simple mise à jour de leur firmware, sans donner plus de détails. Nos questions à ce sujet sont restées lettres mortes et nous n'en savons donc pas plus, ni quand ces écrans actuels pourraient être mis à jour, ni quand de nouveaux modèles pourraient être commercialisés.

AMD nous a affirmé que le support de la fréquence de rafraîchissement variable était déjà intégré aux pilotes Catalyst récents mais qu'une interface pour en donner le contrôle aux joueurs était toujours en cours de développement. Même si les moniteurs compatibles FRV tardent à arriver, AMD devrait ainsi pouvoir proposer cette fonction rapidement sur certains portables, ce qui tombe d'ailleurs très bien puisque leur puissance graphique plus limitée fait qu'ils en auraient bien besoin pour proposer plus de confort aux joueurs.

Il est probable que Nvidia ait été le premier à réaliser l'intérêt que pourrait avoir la fréquence de rafraîchissement variable pour les joueurs. Friand de solutions propriétaires, Nvidia a cependant évité de soumettre son idée à VESA et opté pour le développement confidentiel d'un G-Sync limité à ses seules cartes graphiques. Une approche qui réduit immanquablement l'offre et empêche de généraliser son utilisation, même chez les utilisateurs de GeForce, mais qui a l'avantage de permettre de tirer des revenus supplémentaires de cette fonctionnalité, de se démarquer de la concurrence… et d'aller vite.

Ajouter une fonctionnalité à un standard VESA existant ou en cours de développement demande de prendre le temps qu'elle soit débattue par tous ses membres, validée et exploitée par l'industrie. Avec G-Sync, Nvidia a pu aller très vite, certes au prix d'un contrôleur écran émulé à l'aide d'un composant relativement cher. Ainsi, le module G-Sync est réellement utile à l'heure actuelle, car en attendant que des contrôleurs classiques supportent la FRV, que ce soit à travers un nouveau firmware, une nouvelle révision ou un nouveau modèle, c'est le seul moyen d'activer ce support sur les écrans de bureau.

Mais pourquoi Nvidia ne s'est-il pas contenté dans un premier temps de proposer G-Sync sur les portables, domaine où le lien eDP connecte la dalle au GPU d'une manière plus directe ? Sans surcoût ou revenu direct supplémentaire, cela aurait malgré tout apporté de la valeur à ses cartes graphiques mobiles. Le problème est que sur la majorité des portables équipés en GeForce, Nvidia n'est plus maître des sorties vidéos ! A travers la plateforme Optimus, toute cette partie est sous-traitée à l'IGP Intel. Ce dernier aurait donc dû collaborer à son support, or il a tout intérêt à préférer attendre un standard que favoriser une solution propriétaire de Nvidia.

Au final, vous l'aurez compris, aussi intéressante que soit la fréquence de rafraîchissement variable pour les joueurs, de nombreuses questions restent encore en suspens quant à sa généralisation éventuelle. Nvidia va-t-il supporter sa version standardisée dès qu'elle sera disponible ou tenter de forcer les joueurs à payer, en plus de leur carte graphique, la taxe d'une solution propriétaire ? Nvidia va-t-il arriver à s'entendre avec Intel pour l'arrivée de la FRV sur la plateforme Optimus ? Quand est-ce que des moniteurs DisplayPort 1.2a avec support de la FRV seront disponibles ? Si certains contrôleurs actuels acceptent la FRV via mise à jour de leur firmware, y aura-t-il des limitations telles que la désactivation de l'overdrive ?

En attendant d'en savoir plus, la technologie G-Sync de Nvidia doit être vue comme une manière d'accéder en primeur aux bénéfices du DisplayPort 1.2a + FRV, avec tout ce que cela implique : surcoût élevé et possibles limitations dans le futur en terme de compatibilité. Sans changer fondamentalement notre avis sur G-Sync tel que nous l'avions exprimé dans le test du premier écran compatible, avant d'apprendre l'arrivée d'une version standardisée, cela rend le surcoût plus difficile à accepter. Opter pour un des premiers écrans G-Sync en 1920x1080, les modèles de séries ne vont plus tarder, est difficilement justifiable s'ils s'accompagnent d'une surtaxe de 200€, de 150€ voire même de 100€.

Plus haut en gamme, par exemple sur le futur Asus RoG Swift PG278Q en 2560x1440 ou sur un éventuel moniteur UHD / 4K, notre avis est moins tranché. Il est plus difficile pour les cartes graphiques, même haut de gamme, de générer un affichage fluide dans cette résolution et dans les jeux gourmands. Nous pouvons donc comprendre que Nvidia se presse d'y apporter une solution d'autant plus que le tarif plus élevé de ces moniteurs, 800€ pour cet exemple, permet d'y intégrer plus facilement le surcoût actuel de G-Sync. Reste néanmoins à accepter de faire une croix sur toute possibilité d'évolution de son système vers une future carte graphique Radeon.


Le PG278Q d'Asus au CES.
Nous aurions bien entendu préféré que Nvidia se contente de lancer G-Sync tel qu'il existe aujourd'hui sur ce type d'écran, sans chercher à cacher le fait qu'il s'agit d'une version primeur d'un mode d'affichage qui est voué à être exploité par tous puisque basé sur le transfert d'une technologie qui existe déjà vers un autre type d'utilisation. Plus loin dans l'idéalisme il serait sans aucun doute bénéfique pour tous si Nvidia pouvait voir plus grand de temps en temps et viser des retours sur investissements indirects en transformant ses bonnes idées en propositions ouvertes, pour faire progresser l'écosystème PC, plutôt que de chercher une variante propriétaire à chaque technologie, dont la portée est mécaniquement plus limitée.