Actualités informatiques du 27-03-2013

Nous en avons déjà parlé à plusieurs reprises, les futurs processeurs Haswell pourront être accompagnés de plusieurs versions de l'iGPU sur lesquelles un nombre plus ou moins important de blocs d'unités de shaders seront actifs.

- GT1 : 6 Execution Units
- GT2 : 20 Execution Units
- GT3 : 40 Execution Units

Sur Ivy Bridge, seules deux versions existaient, le GT1 (HD Graphics 2500) avec 6 unités et le GT2 (HD Graphics 4000) avec 16 unités.

Le GT2 sera décliné sur toute la gamme Haswell, à savoir les processeurs pour PC de bureau, pour PC portables et pour Ultrabook (pour rappel ces derniers disposeront d'une version spécifique avec le chipset intégré au packaging). Dans les deux premiers cas il sera dénommé HD Graphics 4600 et dans le dernier cas HD Graphics 4400 ou 4200, selon son niveau de performance. Les fréquences seront donc inférieures sur Ultrabook.

Le GT3 ne sera pour sa part pas présent sur les CPU destinés aux PC de bureau. Sur les CPU pour Ultrabook, il se nommera HD Graphics 5000 ou 5100 selon sa fréquence. Sur les CPU pour PC portables, on ne retrouvera pas la version classique du GT3 mais une version spéciale, le GT3e, accompagnée d'une puce mémoire dédiée intégrée au packing du processeur. Il porte le nom de HD Graphics 5200.

Deux processeurs sont actuellement prévus avec HD Graphics 5200, les Core i7-4950HQ et i7-4850HQ. Dotés de 4 cœurs physiques et 8 cœurs logiques via l'Hyperthreading, leur cache L3 est de 6 Mo pour un TDP de 47 watts et une fréquence graphique variant entre 200 et 1300 MHz. La différence se fait au niveau de la fréquence, 2.4 GHz de base et un Turbo à 3.6 GHz pour l'i7-4950HQ, contre 100 MHz de moins pour le 4850HQ.

Si le GT3 avec mémoire embarqué devrait permettre à Intel de revenir au niveau d'AMD voir de le dépasser du côté des iGPU, le positionnement tarifaire de ces i7 risque d'être autrement plus élevé.

Ceux qui se contenteront d'un HD Graphics 4600 pourront profiter d'une fréquence CPU plus importante pour la même enveloppe thermique. Les i7-4800MQ et i7-4900MQ ont des fréquences de bases de 2.7 et 2.8 GHz pour des Turbo maximums de 3.7 et 3.8 GHz. Toujours en HD Graphics 4600, l'i7-4930MX et son TDP de 57w sera à 3 GHz pour un Turbo maximal de 3.9 GHz.

A l'occasion d'un long article sur le sujet , AnandTech indique qu'AMD compte (enfin!) mettre en ligne en juillet un pilote réglant le problème de micro-saccades rencontré de manière plus ou moins fréquente, principalement en CrossFireX lorsque l'on désactive la synchronisation verticale. Un problème lié à la technologie AFR (Alternate Frame Rendering) qui n'est pas tout neuf puisque nous en avions déjà parlé en... mars 2000, sur la Rage Fury MAXX !

Ce pilote laissera à l'utilisateur le choix entre deux réglages. Le premier correspond au comportement actuel, c'est-à-dire que l'image sera affichée dès qu'elle est prête, alors que le second décalera dans le temps l'affichage d'une image si elle est trop proche de la précédente.

Si le comportement actuel, qui correspond à une non prise en compte du problème, permet d'être au plus près de l'action il peut aussi entraîner des problèmes de fluidité (micro-saccades) dans les cas où peu de temps sépare les images rendues par chacun des GPU. On peut ainsi avoir des images qui restent dans le frame buffer (la partie mémoire lue pour l'affichage à l'écran) pendant 2ms, 40ms, 2ms, 40ms etc… ce qui donne une impression de fluidité moindre que si on était sur 21ms, 21ms, 21ms, 21ms, etc… pour une moyenne qui reste pourtant dans les deux cas à 21ms soit 47,6 fps.

Décaler les images qui arrivent trop rapidement n'est pas une nouveauté et c'est le choix que fait Nvidia depuis longtemps en SLI sous le nom de frame metering. Cela entraine toutefois une latence plus importante sur le rendu graphique de certaines images, dans le cas cité plus haut il faut ainsi rajouter 19ms de présence à l'écran sur les images les plus "rapides" (temps qui sera déduit sur les plus "lentes"). Dans certains cas le choix actuel d'AMD, qui sera toujours possible, permet donc d'afficher une image plus récente par rapport à l'état du jeu.

Attention, ce problème de variabilité est surtout présent lorsque la synchronisation verticale n'est pas activée, ce qui est le cas lors des mesures de performances afin que celles-ci soient les plus précises possibles, mais aussi pour certains utilisateurs qui préfèrent ce mode considéré généralement comme plus réactif. Si la qualité d'affichage est en effet réduite, du fait de cassure pouvant apparaître à l'écran puisque plusieurs images distinctes rendues peuvent se suivre sur une même affichée, c'est aussi le mode qui permet d'avoir une image affichée au plus proche de l'état du jeu. Beaucoup préfèrent conserver la synchronisation verticale active et ne sont alors pas concernés par ce problème, ceux qui préfèrent conserver la synchronisation verticale désactivé peuvent utiliser un limiteur de framerate comme ceux intégrés dans MSI After Burner ou Radeon Pro pour le contourner.

La variabilité des latences inter-image est un sujet qui fait débat depuis l'introduction par The Tech Report  d'un protocole de test mesurant cette dernière à l'aide de FRAPS. Ceci a permis fin 2012  de mettre le problème en avant chez AMD sur certains titres DX9 en mono GPU (la source de ces micro-saccades est autre qu'en CFX, et a été corrigée via des pilotes récents, d'autres corrections pour les titres DX10 et plus sont à venir).

Il faut toutefois noter que le fonctionnement même de FRAPS fait que la mesure de latence inter-image ne se fait pas au bon endroit dans le rendu graphique global et n'était donc pas forcément synonyme d'un problème réel à l'affichage (et vice-versa). Fraps mesure en effet le temps qui s'écoule entre deux appels DirectX de rendu de frame, et non le temps entre les deux affichages de l'image.

Source : AnandTech 
Ce sujet refait surface à l'occasion de la mise à disposition de testeurs par Nvidia d'un nouvel outil plus adéquat (présenté par PCPer ici , là  ou encore ici et utilisé là ), le FCAT pour Frame Capture Analysis Tool (présenté par Nvidia sur son blog aujourd'hui ). La publication de l'article d'AnandTech sur le sujet, qui précède donc une vague de publications sur le sujet (en sus de PCPer, AnandTech  et Tom's Hardware  viennent de lui consacrer un dossier) et qui fait suite à un entretien avec les équipes d'AMD, n'est sans doute pas étrangère à ceci : c'est ce qu'on appelle du Damage Control. Reste donc à voir si les paroles seront suivies d'actes, et si ces pilotes résoudront également le comportement souvent très problématique du CrossFireX en tri-écran.

Un temps annulée puis laissée aux mains de quelques partenaires, la Radeon HD 7990 aura connu une gestation longue et compliquée. AMD vient cependant de confirmer qu'un design de référence était actuellement en cours de finalisation

Aucune information concernant les spécifications finales, si ce n'est que la carte est équipée de 2 connecteurs PCI Express 8 broches, mais nous pouvons cependant observer qu'il s'agit d'un design proche de celui présenté à l'AFDS 2012, qui est légèrement différent du design de la FirePro S10000.


Pour accompagner la sortie future de cette Radeon HD 7990 "officielle", AMD prépare une nouvelle démo technologique qui mettra une nouvelle fois en scène Ruby. Cette démo est développée en partenariat avec Crytek, elle repose donc sur le CryEngine 3, et Illfonic (Nexuiz) et a pour but de se rapprocher d'un rendu cinématographique avec une utilisation de nombreux effets de particules, de la tessellation et d'un effet de Depth of Field évolué.

Cette démo est encore en développement et nous n'avons pu en observer qu'un bref extrait sur un petit écran, difficile donc de se faire une idée précise de la qualité du rendu final. Notez que la technologie TressFX, dédiée au rendu des cheveux n'est pas encore de la partie, mais elle est bel et bien en cours d'intégration.

En marge de la Game Developer Conference 2013, AMD vient de présenter sa stratégie pour le cloud gaming qui va permettre à la société de pouvoir toucher les joueurs sur des marchés dont elle est actuellement absente (smartphones) ou peu présente (tablettes), ainsi que toucher un plus large public directement au niveau d'une TV non équipée d'une console ou d'un HTPC.

Pour toucher ce large public à travers le streaming, comme le fait Nvidia avec GRID for Gaming, AMD a développé une plateforme spécifique : RapidFire. Cette plateforme est prévue, à terme, pour supporter plusieurs streams par GPU et est optimisée pour une latence réduite. Pour cela, AMD a mis au point une technologie vidéo spécifique, Frame Grab, qui permet de récupérer directement les images rendues par les GPU et de les encoder en profitant du moteur d'encodage h.264 dédié (VCE) qu'ils intègrent.

Des variantes dédiées des cartes graphiques maisons seront également proposées sous peu : les Radeon Sky 900, 700 et 500. Celles-ci sont respectivement dérivées des FirePro S10000, S9000 et S7000, le plus gros modèle étant équivalent à une bi-Radeon HD 7950.


Comme à son habitude, et contrairement à Nvidia qui vise la commercialisation de serveurs GRID complets, AMD met en avant une approche centrée sur des partenariats avec plusieurs acteurs du cloud gaming : CiiNOW, otoy, ubitus et G-cluster Global. Ceux-ci vont intégrer, ou envisagent de le faire, les Radeon Sky dans leurs plateformes actuelles, en supportant éventuellement RapidFire, ou une partie de cette technologie, certains ayant déjà développé leurs propres solutions.

Nous avons pu observer plusieurs de leurs systèmes en démonstration, mais notre avis actuel est plutôt mitigé. Si la latence n'était pas un problème du tout, forcément quand le serveur est à 2 pas du client, la qualité de compression n'était par contre pas à la hauteur, avec une pixellisation très importante comme nous pouvions l'observer sur les première démonstrations de GRID. La technologie RapidFire n'a de toute évidence pas encore été intégrée, tout du moins sur le plan vidéo, et la compression se fait actuellement en software, avec une qualité réduite (h.264 base profile) pour ne pas trop affecter la latence. Avec RapidFire et l'utilisation du moteur d'encodage du GPU, la compression devrait passer au h.264 high profile et donc atteindre un meilleur niveau de qualité. Reste à voir quand cette intégration pourra se faire en pratique, AMD parle de Q2, et quels seront alors les résultats.