Les contenus liés aux tags Nvidia et AMD

Jon Peddie Research  vient de publier ses chiffres pour le marché graphique au second trimestre. Comme d'habitude Intel domine largement les débats puisqu'il dispose de 75,2% du marché grâce à ses iGPU (pas toujours utilisés !) contre 14,1% pour Nvidia et 10,7% pour AMD. Ce dernier voit une nouvelle fois ses ventes baisser, il y a un an il était à 17,9% et il y a deux ans à 21,9%, alors qu'Intel était à 67,3% et 62% et Nvidia à 14,7% et 16.1%.

En termes de volume le marché graphique ne se porte pas au mieux puisque les ventes de GPU par rapport au second trimestre 2014 sont en baisse de 18,8%, avec 21,7% de moins côté desktop et 16,9% côté mobile.

A l'origine de cette baisse on retrouve un marché PC en baisse combiné à une part des PC vendus avec carte graphique (et donc généralement combinant iGPU et GPU) moindre : 26,4% des PC étaient livrés avec un GPU additionnel au trimestre précédent, contre 32% un an auparavant. Une évolution on ne peut plus logique vu la progression des iGPU ces dernières années face aux GPU d'entrée de gamme.

JPR donne également des chiffres par rapport au premier trimestre, là encore les ventes d'AMD étaient meilleures avec 12,9% du volume de GPU/iGPU. C'est Intel qui en a profité puisqu'il était alors à 72,2%, contre 14,9% pour Nvidia qui est donc en léger recul. Dans le détail chez AMD les ventes d'APU ont augmenté de 25% sur desktop et ont baissé de 53,5% sur portable, alors que côté GPU on note des baisses de 33.33% et 9.1%. Chez Intel les ventes d'iGPU sont en baisse de 7.4%, de manière équilibrée sur desktop et portables. Côté Nvidia ce sont les GPU pour portables qui souffrent le plus avec -21,6%, contre -12% sur desktop.

Alors que certains pouvaient s'attendre à une opposition tendue entre AMD et Nvidia durant le Computex, le match n'a tout simplement pas eu lieu. Au grand dam des fabricants taiwanais, AMD et les Radeon étaient à peu près invisibles sur le Computex.

Certes, AMD y a tenu une conférence de presse lors de laquelle l'APU Carrizo a été officiellement lancé. Le packaging du GPU Fiji a même pu y être aperçu furtivement. Mais en dehors de ce petit évènement réservé aux journalistes, la marque n'avait pas de réelle visibilité sur le salon et n'a pas cherché à y mettre en avant ses solutions graphiques. Il y a plusieurs raisons à cela, que ce soit en terme de budget, d'orientation plutôt vers les marchés OEM pour les APU…

Mais dans le cas présent, il y a une raison de plus. Les responsables de la communication d'AMD avaient décidé de garder toutes les informations sur les nouvelles Radeon pour un autre évènement qui aura lieu à l'E3 ce soir. AMD y a annoncé un évènement d'envergure dédié au jeu PC et compte tenter de l'exploiter pour marquer les esprits.

Les Radeon profitaient d'une forte visibilité au Computex... 2003. En 2015, la situation a bien changé.
AMD a du coup fait le forcing auprès de ses partenaires taiwanais pour qu'ils ne montrent aucune Radeon de la série 300 et encore moins les Radeon Fury équipées du GPU Fiji. Si nous pouvons comprendre qu'AMD préfère garder le secret aussi longtemps que possible concernant ces dernières, pour ne pas permettre à Nvidia de se positionner précisément trop à l'avance, le blackout concernant les Radeon R9/R7 300 n'était peut-être pas une très bonne idée.

Plusieurs partenaires d'AMD n'étaient d'ailleurs pas tendre envers certains responsables de la société qui « ne pensent qu'à faire leur show » alors qu'eux « sont là pour vendre des cartes ». Développant son idée, l'un d'eux nous explique avoir tout essayé pour convaincre AMD d'autoriser l'exposition des Radeon R9/R7 300, quitte à ne pas indiquer de spécifications, voire même le nom des cartes graphiques. Une approche qui aurait permis à ce partenaire d'obtenir une couverture de ses designs personnalisés avant la déferlante de gros titres qui vont à priori s'orienter sur l'aspect renommage de la nouvelle gamme. Car certains partenaires ne s'attendent pas à ce que cette nouvelle gamme soit couverte d'éloges.

Les partenaires n'avaient donc le droit d'exposer que leurs « vieux » designs de la famille Radeon R9/R7 200. Quand ils le faisaient, il fallait aller les chercher dans un petit recoin de leur stand, alors que les solutions Nvidia étaient largement exposées et monopolisaient toute la visibilité directe, que ce soit au niveau des murs d'exposition ou des systèmes de démonstration.


Le jeu sur GeForce, mis en avant par exemple chez Thermaltake.
Et pas uniquement au niveau des fabricants de cartes graphiques. De toute évidence, Nvidia est allé trouver tous les fabricants taiwanais qui proposent des solutions « gaming ». Des souris gaming ? Un système de démo aux couleurs Nvidia. Des boîtiers gaming ? Un système de démo aux couleurs Nvidia. Sans disposer de stand directement sur le salon, Nvidia affichait clairement sa domination actuelle dans le monde des cartes graphiques.

Mais même si les fabricants taiwanais n'ont que très peu apprécié la stratégie d'AMD lors de ce Computex, tous espèrent le retour d'une concurrence acharnée entre les deux spécialistes du GPU. Un fabricant qui supporte les deux marques nous expliquait ainsi que si la récente traversée du désert d'AMD face aux solutions plus efficaces de Nvidia lui a permis de se développer sur les marchés émergents, son chiffre d'affaire sur ses gros marchés historiques que sont l'Europe et l'Amérique du Nord, a souffert de la situation. Les ventes ne se porteraient jamais aussi bien que quand les deux marques sont au coude à coude.

Au fond, tout le monde semble donc être d'accord sur l'intérêt d'une concurrence plus active. Reste à voir ce dont sera réellement capable le GPU Fiji, AMD étant sur ce point parvenu à garder le suspens. Durant le Computex, aucun partenaire n'a voulu se risquer à faire un pronostic entre Radeon Fury et GeForce GTX 980 Ti mais tous espèrent un résultat qui par effet d'association pourra donne un coup du boost à l'ensemble de la gamme.

A ce niveau, nous devrions avoir quelques pistes en fin de journée, le PC Gaming Show d'AMD, en direct de l'E3, étant programmé pour 18h, heure française.

AMD et Nvidia affûtent leurs armes pour la bataille de l'été qui verra s'affronter d'un côté le GPU Fiji et sa HBM et de l'autre la GTX 980 Ti utilisant le GM200.

Côté AMD en sus de la présentation consacrée à la HBM il y a quelques jours, Johan Andersson le directeur technique du moteur Frostbite de DICE / Electronic Arts vient carrément de poster une photo  d'un échantillon qu'il a reçu de la part d'AMD. Elle semble relativement courte ce qui est attendu du fait de l'intégration de la HBM, alors que le refroidissement se fait très probablement par watercooling. Le lancement de cette nouvelle Radeon est prévue pour dans un mois environ, AMD semble vouloir occuper le terrain à coup de teasing d'ici là pour ne pas laisser le champ libre à Nvidia.


En effet on devrait voir débarquer un peu avant la GeForce GTX 980 Ti de NVIDIA. Elle intégrera le GPU GM200 de Nvidia qu'on a déjà vu au sein de la Titan X, mais devra se "contenter" de 6 Go de GDDR5 alors que le GPU sera légèrement bridé d'après HWbattle.com  puisqu'il est question de 2816 unités de calculs contre 3072 sur GM200. 2 des 24 SMM seront donc inactifs, un écart qui sera peut-être compensé par une fréquence plus élevée.

En bas de page, nous avons mis à jour cette actualité initialement publiée le 16 mars. AMD nous a transmis une nouvelle présentation sur le sujet et Nvidia nous a précisé ce dont étaient également capables ses GPU en terme de traitement simultané des tâches.

De nombreuses sessions dédiées à Direct3D 12 étaient organisées à la GDC. Après celle de Microsoft consacrée à Direct3D, lors de laquelle les niveaux de fonctionnalités ont été mentionnés et des démonstrations ont été faites sur du matériel Nvidia, nous avons assisté à la session d'AMD. Lors de celle-ci, il a été question d'une nouvelle opportunité d'optimisation : améliorer les performances GPU en profitant du traitement simultané de certaines tâches liées au rendu 3D.

Si l'intérêt des API de plus bas niveau est avant tout d'optimiser les performances au niveau du CPU, en réduisant le surcoût des commandes des rendus et en profitant mieux de tous les cœurs, des gains peuvent également être obtenus au niveau du GPU. Dans la plupart des démonstrations auxquelles nous avons pu assister jusqu'ici, les gains mis en avant concernaient avant tout les GPU intégrés dont l'enveloppe thermique limite les performances. Si la charge CPU est réduite, le GPU a plus de marge au niveau de sa fréquence turbo et c'est ce qui permet de faire grimper ses performances.

Mais il y a d'autres possibilités au potentiel important. AMD a ainsi mis en avant l'opportunité d'améliorer les performances GPU en profitant du traitement concomitant de certaines tâches. Avec les API classiques, toutes les étapes du rendu sont traitées en série par le GPU. Par exemple, le calcul de la physique, la préparation des ombres dynamiques, le remplissage du G-Buffer, l'éclairage et le post processing sont traités l'un après l'autre, aussi vite que possible par les GPU, mais en série.

Chacune de ces tâches n'exploite cependant pas la totalité des capacités d'un GPU. Par exemple, la préparation des ombres et le remplissage du G-Buffer vont plutôt saturer le sous-système mémoire alors que la physique, l'éclairage et le post processing ont plutôt tendance à saturer les unités de calcul. Il semble ainsi logique que traiter en même temps certaines de ces tâches représente une optimisation intéressante pour mieux exploiter les GPU.

Et ça tombe bien, Direct3D 12, l'autorise. L'API de Microsoft semble reprendre exactement la base de Mantle sur ce point et prévoit 3 types de files d'attentes, également appelées "moteurs", dont les tâches peuvent être traitées en concomitance : Graphics, Compute et Copy. Au niveau des fonctionnalités prises en charge, Graphics est un superset de Compute qui est un superset de Copy. Cela veut dire que par défaut seul le moteur Graphics peut être exploité, puisqu'il est polyvalent. Il revient aux développeurs de spécifier l'utilisation des autres moteurs pour potentiellement optimiser les performances.

Il faut noter que ce type d'optimisation permet d'exploiter les ACE (Asynchronous Compute Engines) des GPU Radeon de la génération GCN. Pour rappel, AMD a implémenté ces processeurs de commandes secondaires justement pour pouvoir exécuter efficacement des tâches de type Compute en même temps que des tâches de type Graphics. D'autres GPU ne disposent pas de files d'attentes spécifiques au niveau matériel pour tous ces types de tâches et doivent alors les traiter de manière classique, en série. Ainsi, il n'est pas certain que les GPU Nvidia puissent profiter autant que ceux d'AMD de ce type d'optimisation. A notre connaissance, ils ne peuvent pas traiter les opérations de type Compute et Graphics en concomitance, et seules les GeForce les plus récentes (GTX 900) peuvent le faire avec les opérations de type Copy, une fonctionnalité auparavant réservée aux Quadro et Tesla.


Une bonne compréhension des architectures GPU et un profilage avancé des demandes de chaque tâche sont nécessaires. Il est également crucial de mettre en place correctement les barrières de synchronisation nécessaires, sans quoi des tâches dépendantes l'une de l'autre pourraient être exécutées en parallèle et causer des problèmes. AMD a insisté lourdement sur ce point, précisant que l'absence de barrières de synchronisation adéquates pourra passer inaperçue dans l'immédiat, sans bug visible, mais être source de gros problèmes avec de futurs GPU dont l'augmentation des performances profitera plus à certaines tâches qu'à d'autres. Comme le sait très bien AMD, les développeurs seront peu enclins à proposer un patch 2 ou 3 ans après la sortie d'un jeu, et appliquer un correctif au niveau des pilotes sera alors un véritable casse-tête, voire impossible dans certains cas.


Mais avec un code robuste et un bon profilage, les gains peuvent être conséquents. Il est question de 20 à 25% dans des situations réalistes et avec des GPU capables d'en profiter. Deux exemples ont été mentionnés. Le premier, accompagné d'une démonstration, découple le remplissage du G-Buffer du calcul de l'éclairage qui est réalisé à travers un compute shader. Au lieu de traiter ces 2 opérations l'une après l'autre, elles sont effectuées en parallèle et de manière asynchrone : pendant que l'éclairage est calculé pour l'image 1, les opérations sur le G-Buffer sont traitées pour l'image 2 et ainsi de suite.

[ Concomitance OFF ]  [ Concomitance ON ]  

Sans traitement concomitant des tâches Graphics et Compute, le temps de rendu total prend 3.346ms (299 fps), ce qui est la somme des 2.551ms de la partie Graphics (remplissage du G-Buffer) et des 0.747ms de la partie Compute (calcul de l'éclairage). En activant le traitement concomitant dans cette démonstration, le remplissage du G-Buffer prend 2.659ms, et le calcul de l'éclairage 2.822ms. Ces deux tâches prennent plus de temps à être traitées, mais elles le sont en même temps et le rendu total ne prend plus que 2.863ms (349 fps), ce qui représente un gain de 17%. La latence peut par contre être légèrement plus élevée.



Dans un autre exemple, AMD explique que streamer les textures et animer les particules via les moteurs Copy et Compute permet un petit gain puisque ces opérations sont alors traitées en concomitance avec les ombres et l'éclairage. Mais il est possible d'aller plus loin en constatant qu'il est plus efficace d'animer les particules en même temps que la préparation des ombres et de streamer les textures en même temps que le calcul de l'éclairage que de faire l'inverse. En évitant d'exécuter en même temps des tâches qui ont des demandes similaires en termes de ressources GPU, les gains sont plus importants. D3D12 offre des mécanismes aux développeurs pour pouvoir gérer cela.

Les GPU modernes doivent en général faire face à des limites de consommation directes ou indirectes (via la température) et mieux exploiter la totalité de leurs capacités revient bien entendu à les pousser plus souvent ou plus loin dans ces limites. La fréquence GPU des cartes graphiques est alors réduite quelque peu, ce qui impacte les performances, mais dans des proportions bien moins élevées que les gains liés à ce type d'optimisations. Elles restent donc totalement légitimes. A voir par contre si de tels moteurs graphiques seront qualifiés de "power virus" par AMD et Nvidia, comme c'est le cas de Furmark et d'OCCT qui font également en sorte de saturer toutes les unités des GPU…

Le set de slides de la session d'AMD à la GDC : (nous avons profité de la mise à jour pour remplacer nos clichés par des screenshots plus propres)




Mise à jour du 31/03 :

Quelques semaines après la GDC, AMD a décidé de mettre en avant ces possibilités d'optimisations auprès de la presse technique. Une présentation simplifiée nous a ainsi été distribuée il y a quelques jours. A noter que, bizarrement, elle était par contre accompagnée d'un embargo qui prenait fin ce matin… alors même que la présentation plus complète, dont nous vous avions parlé ci-dessus, est publique depuis la GDC. Peu de médias s'y étaient cependant intéressés et le département de marketing technique d'AMD a probablement voulu mettre en place une communication synchronisée sur le sujet.


Il n'y pas pas d'information supplémentaire dans cette présentation, mais elle est plus simple à comprendre et mieux finie que celle adressée aux développeurs, nous l'avons donc ajoutée à cette longue actualité. A noter que le marketing technique d'AMD parle d'Asynchronous Shaders pour faire référence à l'exécution concomitante de différentes tâches (même si les opérations de type Copy ne sont pas des shaders). Vous pourrez également observer le résultat obtenu sous une autre démo, que nous avions pu observer également pendant la GDC durant la présentation de LiquidVR. L'utilisation du traitement concomitant du rendu (Graphics) et du post processing (Compute) y permet un gain de performances de 46%.

Si cette stratégie de communication d'AMD ne nous en a pas appris plus, elle a par contre eu le mérite de pousser Nvidia à enfin communiquer sur le même sujet. L'occasion de faire le point sur ce dont sont capables tous les GPU récents, notre première supposition n'étant pas tout à fait correcte concernant les derniers GPU Maxwell.


Du côté d'AMD :

Tous les GPU de type GCN supportent le traitement concomitant des tâches Graphics/Compute/Copy. En plus d'un processeur de commande principal polyvalent, ils disposent au moins de 2 ACE (Asynchronous Compute Engine), dédiés aux tâches de type Compute, et de 2 DMA Engines dédiés aux tâches de type Copy.

Il y a par contre des limitations pour les GPU GCN 1.0 (Tahiti, Pitcairn, Cape Verde, Oland). Leurs DMA engines ne supportent pas toutes les fonctions de synchronisation avec le CPU, ce qui impose probablement des limites au niveau du traitement concomitant des tâches de type Copy. Ensuite, les GPU plus récents, GCN 1.1, supportent plus de files d'attente par ACE (8 au lieu de 1), qui peuvent par ailleurs être présents en plus grand nombre. Ils sont ainsi adaptés au traitement concomitant de nombreuses petites tâches de type Compute (par exemple pour la physique ?), contrairement à leurs prédécesseurs.

AMD a implémenté dans ses pilotes Direct3D 12 un support complet de traitement concomitant de tous les types de tâches, exactement comme c'est le cas sous Mantle. Par contre, nous ne savons pas si les pilotes AMD sont capables de profiter de certaines de ces possibilités pour apporter des optimisations sous certains jeux Direct3D 11.


Du côté de Nvidia :

Les GPU Fermi et Kepler se contentent d'un seul processeur de commandes qui ne peut pas prendre en charge simultanément des commandes de type Graphics et de type Compute. Soit il est dans un mode, soit dans l'autre, un changement d'état relativement lourd à opérer.

Par ailleurs, à l'exception des GK110/GK210, ces anciens GPU ne disposent que d'une seule file d'attente au niveau de leur processeur de commande qui doit traiter les tâches dans l'ordre dans lequel elles sont soumises. Cela limite fortement la possibilité d'en traiter plusieurs simultanément à l'intérieur du mode Compute lorsqu'il y a des dépendances entre elles.

Avec le GK110, Nvidia a introduit un processeur de commandes plus évolué, qui supporte une technologie baptisée Hyper-Q. Elle représente la capacité de prendre en charge jusqu'à 32 files d'attente, mais uniquement en mode Compute. Ce GPU, et les GM107/GM108 qui reprennent cette spécificité, sont ainsi adaptés au traitement concomitant de nombreuses petites tâches de type Compute (par exemple pour la physique ?). Le GK110 a également introduit un second DMA Engine, mais il est réservé aux déclinaisons Tesla et Quadro.

Enfin, avec les GPU Maxwell 2 (GM200/GM204/GM206), Nvidia a fait sauter toutes ces limitations, contrairement à ce que nous pensions. Tout d'abord, le second DMA Engine est bien actif sur les déclinaisons GeForce. Mais surtout, quand Hyper-Q est actif, une des 32 files d'attente peut être de type Graphics.

Au niveau de l'implémentation logicielle, un traitement concomitant complet de tous les types de tâches est supporté sous Direct3D 12 pour les GPU Maxwell 2. Il n'est par contre pas possible d'effectuer une exécution concomitante entre Direct3D 12 et CUDA, qui repose sur un pilote différent.

Nvidia a également implémenté dans ses pilotés un support limité de l'exécution concomitante sous Direct3D 11, pour les tâches compute uniquement. L'API ne permet pas d'y accéder explicitement, mais quelques astuces permettent aux pilotes d'activer un tel mode pour optimiser les performances (dans le cas de GPU PhysX ?). Nvidia nous a précisé que la question d'y ajouter le support d'un traitement concomitant complet de tous les types de tâches, comme sous Direct3D 12, restait en suspens. Ce n'est pas impossible si cela avait une utilité, mais aucun jeu Direct3D 11 actuel n'est prévu pour en profiter. Sans support explicité dans l'API il est très difficile pour les développeurs de faire en sorte que cela puisse fonctionner.


En résumé :

HD 7000 & Rx 240/250/270/280 : processeur de commandes x1 queue + 2 ACE x1 queue + 2 DMA engines
->Graphics/Compute/Copy avec limitations

HD 7790 & R7 260 : processeur de commandes x1 queue + 2 ACE x8 queues + 2 DMA engines
->Graphics/Compute/Copy

R9 285/290 : processeur de commandes x1 queue + 8 ACE x8 queues + 2 DMA engines
->Graphics/Compute/Copy

GTX 400/500/600/700 : processeur de commandes x1 queue + 1 DMA engine
->Pas de support

GTX 750/780/Titan : processeur de commandes x32 queues (limité) + 1 DMA engine
->Compute/Compute

GTX 900/Titan X : processeur de commandes x32 queues + 2 DMA engines
->Graphics/Compute/Copy

Au final, c'est surtout au niveau des anciens GPU que se différencient AMD et Nvidia, le premier ayant un support en place au niveau matériel depuis plus longtemps. Au niveau des cartes graphiques plus récentes, les GeForce GTX 900 pourront profiter pleinement des optimisations liées au traitement concomitant des tâches, tout comme le feront les Radeon R9 290 par exemple.

Par contre, il reste à voir ce qu'en feront les développeurs. Les gains ne seront pas automatiques et il faudra que les différentes étapes du rendu 3D s'y prêtent. Ce n'était de toute évidence pas le cas pour Battlefield 4 et le Frostbite Engine par exemple, dont la version Mantle ne profite pas réellement de ce type d'optimisation.