Les contenus liés au tag AMD
Afficher sous forme de : Titre | Flux
Les 5 contenus précédentsGDC: Mantle a rempli son rôle et est réorienté par AMD
GDC: AMD mise sur la VR, annonce LiquidVR
AMD lève le voile sur Carrizo côté technique
La HBM 128 Go /s fait bien 1 Go, quid d'AMD Fiji ? MAJ
GPU, 71% pour Intel et 76% pour Nvidia
Mantle : guide de programmation disponible
(0) Réaction
AMD vient de rendre disponible, comme promis, le guide de programmation de son API propriétaire Mantle. Ce guide est avant tout fourni à titre d'information puisqu'AMD conseille dorénavant aux développeurs de s'orienter vers les autres API de bas niveau, telles que Direct3D 12 ou Vulkan, face auxquelles sa propre API n'a plus réellement d'utilité.
Mantle est cependant totalement fonctionnel pour les développeurs qui seraient intéressés, et ce guide de programmation sera l'occasion d'en apprendre en peu plus sur le fonctionnement des GPU modernes ou de se faire la main sur les API graphiques de plus bas niveau, en attendant que Direct3D 12 et Vulkan, similaires, soient disponibles. A la lecture rapide de ce document on réalise d'ailleurs, si cela était encore nécessaire, à quel point Mantle les a influencées.
Parmi les petits détails, nous avons noté qu'AMD n'a pas implémenté toutes les fonctionnalités des GPU dans Mantle, soit parce qu'elles sont trop complexes avec un intérêt limité, soit parce qu'elles peuvent être remplacées par d'autres techniques. C'est par exemple le cas du Stream-Out, qui avait été introduit par DirectX 10 avec les Geometry Shaders, ou encore du Line AA, forme d'antialiasing utilisée par certaines applications professionnelles.
AMD explique également avoir intégré un paramètre qui permet de demander aux pilotes d'essayer, sans garantie, d'uniformiser la qualité du rendu quand deux GPU différents sont utilisés. L'utilisation principale qui est visée est ici un APU avec un GPU d'entrée de gamme, dont la qualité du filtrage des textures peut varier par défaut.
Pour ceux que ça intéresse, le guide est téléchargeable par ici .
Quelques infos sur Fiji et les R9 390X ?
Alors que le lancement de la Titan X se rapproche, VideoCardz.com a publié hier des diapositives qui seraient issus d'une présentation AMD concernant la future R9 390X. Comme d'habitude ce genre de fuite est à prendre avec des pincettes, mais si c'est un faux le faussaire s'est donné beaucoup de mal.
Il est question d'un GPU intégrant 64 Compute Units et donc 4096 unités de calculs, soit 45% de mieux qu'Hawaii, cadencé à une fréquence maximale de 1050 MHz ce qui augmente l'écart de puissance de calcul à 53% en faveur du nouveau venu. Côté fonctionnalité il est notamment question d'un support complet de Direct3D 12 avec un Ressource Binding Tier 3 (cf. cette actualité), d'un décodage H.265/HEVC matériel et d'une amélioration de la fonctionnalité ZeroCore, sans plus de détails.
Côté mémoire la HBM dont nous avions déjà parlé il y a peu est de la partie mais AMD aurait trouvé un moyen d'utiliser deux puces HBM 1 Go par canal 1024-bits, de quoi passer à un total maximal de 8 Go en 4096-bits. Si la présentation met l'accent sur le gain en efficacité énergétique de la HBM il est également question d'une vitesse de 1,25 Gbps supérieure à celle mise en avant officiellement par Hynix. Cela correspond à 640 Go /s de bande passante en HBM 4096-bits, soit le double d'une R9 290X et sa GDDR5 5 Gbps en 512-bits.
Cette capacité est surprenante car si les spécifications JEDEC de la GDDR5 prévoient clairement la possibilité d'avoir deux puces par canal (mode clamshell), nous n'en avons pas trouvé trace dans celles de la HBM . Des versions 4 Go ne semblent pas exclues vu que cette capacité est précédée d'un "up to". Sachant que jusqu'alors les informations que nous avions nous laissaient penser que ces cartes seraient limitées à 4 Go, il faudra voir quel serait le timing pour la sortie de ces versions 8 Go. Dans tous les cas une telle capacité VRAM serait la bienvenue pour cette carte ultra haut de gamme dont le tarif pourrait dépasser les 700$ d'après nos confrères de Heise .
Deux versions seraient prévus, une R9 390X "classique" et une R9 390X / WCE avec watercooling (AIO probablement). Il est question d'une alimentation 6-pin + 8-pin dans le premier cas, soit une consommation maximale de 300 Watts en prenant en compte les 75W pouvant être délivrés par le port PCIe, et de 2x8-pin dans le second cas soit 375 Watts. Côté performance par rapport à une R9 290X en 4K les gains estimés varient entre entre 50 et 65% sous Battlefield 4, Far Cry 4, Tomb Raider et Alien Isolation.
Il est maintenant temps de ravaler votre salive puisque, il faut le repréciser, même si le tout semble très crédible sur la forme et assez crédible sur de nombreux éléments sur le fond rien n'est confirmé jusqu'alors, notamment sur ce dual-link interposing permettant de passer à 8 Go. Aux dernières rumeurs les R9 390X sont attendues pour le second trimestre, plus précisément durant sa seconde moitié.
GDC: Quelle API de bas niveau va s'imposer ?
Au cours de la semaine de la GDC, nous avons demandé à la plupart de nos interlocuteurs quel était leur pronostic officiel dans la bataille qui s'annonce entre les différentes API de bas niveau. Vulkan va-t-il avoir une chance sous Windows ? La réponse a été quasi unanime : non. Explications.
Avec Mantle, AMD et Frostbite ont démontré qu'exploiter des API graphiques de plus bas niveau dans les moteurs de jeu PC était tout à fait réaliste et n'avait pas de raison d'être une exclusivité des consoles. Depuis, la liste de ces API s'est allongée :
- Mantle supporté par les Radeon sous Windows 7/8/10
- Direct3D 12 supporté par tous les GPU sous Windows 10 et par la Xbox One
- Metal supporté par les SoC Apple sous iOS
- Vulkan supporté par tout type de GPU sous tout type de plateforme
- et nous pouvons y ajouter GNM, l'API de la PS4
Sur le papier, Vulkan a un avantage important puisqu'il va permettre à un moteur graphique de supporter de nombreuses plateformes et notamment Android et Linux/SteamOS. Pourquoi ne pas supporter Windows au passage ? Si les spécialistes du moteur de jeu prévoiront probablement cette possibilité, personne ne s'attend à ce qu'elle soit exploitée.
Microsoft ne compte pas proposer de support de Vulkan pour la Xbox One, ce qui va forcer les développeurs à exploiter Direct3D 12. Vu la proximité avec la plateforme Windows, il n'y aura pas d'intérêt à y proposer Vulkan sur PC.
Mais ce n'est pas tout. Vulkan pourrait avoir des difficultés sur d'autres fronts. Alors que nous l'imaginions en bonne position sous Android, la plupart de nos interlocuteurs ont émis un avis plus mitigé. A la question de savoir pourquoi, nous avons en général reçu un sourire gêné en guise de réponse car une autre API est embusquée. C'est un secret de polichinelle dans le milieu des spécialistes de la 3D : Google prépare sa propre API graphique de bas niveau. Une annonce qui pourrait avoir lieu fin mai lors de la conférence Google I/O ou un peu plus tard cette année.
Cette API devrait être ouverte dans le sens où ses spécifications seront fixées par Google, mais son implémentation pourra se faire sur d'autres plateformes. De quoi venir concurrencer directement Vulkan, par exemple si elle était portée sous Linux et SteamOS.
Cela ne veut pas dire pour autant que Vulkan est mort-née. Il y aura vraisemblablement toujours des développeurs qui voudront profiter de son support multiplateformes, surtout dans le monde mobile. Mais à terme, il semble évident que chaque plateforme voudra contrôler sa propre API graphique de bas niveau, ce qui est naturel pour les acteurs concernés. Les spécialistes des moteurs graphiques, tels que l'Unreal Engine, l'Unity, le Cry Engine ou encore le Frostbite, y trouveront probablement leur compte, mais le développement de moteurs "indépendants" risque de devenir difficile à supporter pour de plus en plus de studios.
GDC: D3D12: Une guerre des specs en vue ?
Comme nous l'expliquions il y a peu, Microsoft a dévoilé à la GDC les 2 nouveaux niveaux de fonctionnalités de Direct3D 12 : 12_0 et 12_1. Mais d'autres segmentations plus subtiles existent, de quoi nous laisser penser que les départements communications d'AMD et de Nvidia pourraient se battre à coups de niveaux de support de DirectX 12.
De toute évidence, Microsoft avait demandé à AMD et Nvidia de ne pas lancer de polémique à la GDC sur le niveau de support des spécifications de Direct3D 12 de leurs GPU. Il n'y a ainsi eu aucune communication officielle à ce sujet mais nous avons pu gratter quelques détails lors de discussions informelles ou en posant des questions à la fin des différentes sessions.
Tout d'abord, nous pouvons confirmer que les GeForce Maxwell de seconde génération (GTX Titan X, 980, 970 et 960) supportent bien le niveau de fonctionnalité le plus élevé : 12_1. Il a de toute évidence été modelé d'après les spécifications de l'architecture de Nvidia. Nous ne savons par contre toujours pas s'il existe des GPU actuellement commercialisés de niveau 12_0.
Cela ne veut pas dire pour autant que les dernières GeForce GTX supportent la totalité des possibilités de Direct3D 12. Ainsi, en plus des niveaux de fonctionnalités, des niveaux de support appelés Tiers existent pour différents points.
Le principal concerne les capacités de gestion des différentes ressources (Resource Binding) qui augmente en passant du Tier 1 au Tier 2 et atteint un niveau presqu'illimité au Tier 3. Microsoft a précisé que sur base des dernières statistiques de Steam, et en ne prenant en compte que le matériel compatible avec Direct3D 12, 39% du parc installé est limité au Tier 1, 44% au Tier 2 et 17% supporte le Tier 3. Mais quel GPU supporte quel Tier ?
Selon nos informations, les GPU Maxwell sont en fait limités au Tier 2, qui est nécessaire au support des niveaux 12_0 et 12_1 et qui a probablement lui aussi été modelé autour de leurs capacités. Une des différences les plus importantes avec le Tier 3 concerne la gestion des Constant Buffer Views (CBV) : ceux-ci ne sont pas virtualisés et sont limités en nombre à 14. Il est probable que l'architecture Maxwell soit capable de virtualiser les CBV, mais que l'implémentation logicielle/matérielle de Nvidia profite d'un mode plus performant avec une gestion "fixe" des Constant Buffers. Un compromis qui limite quelque peu la flexibilité accordée aux développeurs pour s'assurer que les GPU GeForce restent dans un mode optimal sur le plan des performances.
Mais alors à qui correspond les 17% de GPU compatibles Tier 3 ? Toujours selon nos informations, il s'agit des Radeon de type GCN qui profitent d'une architecture très flexible à ce niveau. D'un côté les GeForce GTX 900 supportent le niveau 12_1, d'un autre les Radeon R9 200 supportent le Resource Binding Tier 3. Un combat de spécifications en perspective ? Difficile pour AMD d'attaquer les GTX 900 sur base de cela pour l'instant… mais cela risque de changer avec Fiji. Si ce futur GPU supporte le niveau 12_1 et le Tier 3, nul doute que vous en entendrez parler ! Si par contre Fiji est limité au niveau 12_0 et Tier 3, chacun devra préparer ses arguments.
Au final, voici comment le support des Resource Binding Tiers est de toute évidence réparti sur PC :
Tier 1 : Nvidia Fermi, Intel Haswell et Broadwell
Tier 2 : Nvidia Kepler et Maxwell 1/2
Tier 3 : AMD GCN
A noter que pour les fonctionnalités spécifiques au niveau 12_1, les Raster Ordered Views et la Conservative Rasterization, il existe également des Tiers 1 et 2 dont les spécificités nous sont pour l'heure inconnues. L'implémentation de Nvidia se limiterait au Tier 1 et il pourrait être possible là aussi pour AMD d'essayer de se démarquer. Affaire à suivre.
Pilotes AMD FreeSync le 19 mars, CrossFire en avril
Alors que le BenQ XL2730Z commence à débarquer en Europe et est donc le premier écran compatible VESA Adaptive-Sync et certifié AMD FreeSync disponible, il faut préciser que pour l'instant les pilotes AMD ne supportent pas cette fonction contrairement à ce qui avait été indiqué lors du lancement des Catalyst Omega.
Comme indiqué par AMD au revendeur Overclockers.co.uk , c'est le 19 mars prochain qu'un premier pilote public permettant d'utiliser FreeSync sur une configuration mono-GPU sera mis en ligne. AMD déclare par ailleurs que FreeSync sera disponible en CrossFire avec un autre pilote qui arrivera en avril. Il est donc inutile de se jeter sur ce 27" 2560*1440 144 Hz à dalle TN, d'autant qu'il n'est pas donné avec un tarif variant entre 650 et 700 €.
Pour rappel seuls les GPU AMD les plus récents sont compatibles avec FreeSync dans les jeux, c'est le cas de ceux utilisés dans les R9 295X2, 290X, 290, 285, R7 260X et R7 260 ainsi qu'au sein des APU Kaveri et Kabini.
Les 5 contenus précédents
