Actualités informatiques du 16-03-2015
- Kodati AM1 chez Scythe
- GDC: Quelques statistiques pour Nvidia GRID
- GDC: Nvidia fournit le code source de PhysX
- GDC: Crysis 3 sous Android: CPU limited
- GDC: Quelle API de bas niveau va s'imposer ?
- GDC: D3D12: Une guerre des specs en vue ?
- GDC: D3D12: Ashes of the Singularity et la BP mémoire
Flux XML avec la liste des 20 dernières actualités.
| Mars 2015 | ||||||
|---|---|---|---|---|---|---|
| L | M | M | J | V | S | D |
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||
Actualités précédentes - Samedi 14 Mars 2015
Kodati AM1 chez Scythe
Scythe lance la version Rev.B de son petit ventirad Kodati. On retrouve des dimensions de 82.5x94x34mm pour 180g et deux caloducs alors que le ventilateur est toujours un Slip Stream Slim 80mm PWM pouvant fonctionner entre 800 et 3300 tpm.
La différence se situe au niveau de la compatibilité puisque l'AM1 est cette-fois de la partie ce qui est assez rare pour être signalé. Pour rappel il s'agit du Socket de la plate-forme AMD d'entrée de gamme à base de Kabini (cf. dossier). Les Socket AM2/AM3/FMx et LGA775/115x restent également supportés. Il faudra compter environ 24 € pour ce Kodati Rev.B.
GDC: Quelques statistiques pour Nvidia GRID
En fin de GDC, Nvidia organisait plusieurs sessions consacrées à son service de cloud gaming GRID, dont une qui a particulièrement attiré notre attention puisqu'il était question de mesures et d'analyses des données issues de la phase de beta test proposée gratuitement aux utilisateurs de la tablette Shield ou de la console portable du même nom.
Nous y apprenons que 40 jeux sont dorénavant proposés sur GRID et que Saints Row 3 est celui qui rencontre le plus de succès, ce que Nvidia mesure par le pouvoir d'attraction et de fidélisation des joueurs.
Certains joueurs ont profité du service dans pas moins de 27 villes situées dans 9 pays différents, plus de 500 sessions de plus de 8 heures de jeu ont été observées, et plusieurs joueurs ont dépassé les 400 heures de jeu. De quoi permettre à Nvidia d'accumuler des statistiques très utiles sont mesurées la fluidité, la résolution (elle peut être réduite en cas de gros ralentissement), la latence, la qualité du signal audio et la qualité des vidéos (quantization process). En tout ce sont 39 millions de mesures par heure qui sont enregistrées par les serveurs GRID.
Si Nvidia parle de l'objectif d'une latence totale, Click-to-Photon, de 150ms, malheureusement aucune statistique n'a été présentée à ce sujet. C'était bien entendu le point le plus intéressant mais il nous a été répondu qu'il s'agissait de données stratégiques que Nvidia ne compte pas communiquer à la concurrence. Par contre, Nvidia nous a précisé que ses statistiques avaient mis en évidence une corrélation entre la latence, le temps de jeu et la fidélisation des joueurs. Au-delà de 150ms, ces derniers ont tendance à rapidement déserter la plateforme, ce qui explique que Nvidia mette tout en œuvre pour essayer de ne pas dépasser cette valeur.
Nvidia va mettre à dispositions des développeurs qui le désirent un accès en ligne à une partie des données mesurées par ses serveurs. De quoi leur permettre d'analyser directement les performances de leur jeu et son niveau de succès auprès des joueurs.
GDC: Nvidia fournit le code source de PhysX
Depuis son annonce il y a 3 ans, l'Unreal Engine 4 intègre PhysX de Nvidia. Rappelons qu'il s'agit d'un moteur de prise en charge de la physique, multiplateformes. Il est proposé gratuitement sur PC et sous licence pour les consoles. Il offre la possibilité, optionnellement, d'accélérer via le GPU le traitement de certains effets qui n'affectent pas la simulation du monde.
PhysX évolue régulièrement et ses mises à jour sont progressivement intégrées par Epic dans l'UE4 qui en supporte actuellement la version 3.3.2. Changement important, à la GDC, Nvidia a annoncé qu'à partir de la version 3.3.3, le code source C++ de PhysX pour l'Unreal Engine 4 sera fourni à travers GitHub à tous les développeurs qui en feront la demande.
Une révolution pour Nvidia ? Oui mais pas totalement puisque cette orientation nouvelle garde malgré tout ses limites. Ainsi ce n'est pas tout PhysX qui est ouvert mais uniquement deux de ses modules, certes probablement les plus importants pour la conception des jeux vidéo : les librairies de gestion des destructions et de simulations des tissus. A noter qu'il s'agit dans les deux cas de librairies 100% CPU, la simulation des tissus sur GPU n'en fait pas partie et reste un élément stratégique sur PC pour Nvidia. Il ne faut donc pas voir dans cette annonce une opportunité pour AMD de porter PhysX sur Radeon par exemple.
A terme cela devra permettre une meilleure utilisation de PhysX et probablement des possibilités nouvelles suivant ce que les développeurs vont construire autour de ces librairies. Ils pourront d'ailleurs proposer leurs évolutions à Nvidia qui pourra éventuellement les intégrer dans la branche principale de PhysX qui se retrouvera ensuite dans les futures versions de l'Unreal Engine.
Vous pourrez retrouver plus d'informations par ici .
GDC: Crysis 3 sous Android: CPU limited
Nous avons pu nous entretenir avec Crytek au sujet du portage de Crysis 3 sous Android. Un portage qui a été réalisé en partie avec Nvidia sur base du SoC Tegra X1 et qui a été mis en avant lors de la présentation de la console/box Shield basée sur Android TV.
Actuellement, seule une partie du jeu a été portée, avec un résultat impressionnant sur le plan graphique. Certes, quelques ralentissements se font sentir sur Tegra X1 et on peut remarquer que le niveau de détail a été réduit, notamment la qualité des textures, mais il s'agit bien d'un rendu de premier plan qui n'a strictement rien avoir avec la version de Crysis 1 pour Android.
Crytek nous explique être totalement satisfait des possibilités graphiques d'un SoC tel que le Tegra X1. Par contre là où ça coince c'est au niveau des performances CPU des SoC : le portage actuel est en fait 100% limité par le CPU du Tegra X1 qui est pourtant ce qui se fait de mieux pour l'instant. C'est pour cette raison que la complexité de la scène a été réduite et dans l'immédiat Crytek n'y voit pas de solution puisqu'une grosse partie du rendu repose sur un seul thread. Une API de plus bas niveau sera bien entendu une aide précieuse.
Mais sera-t-il réellement possible de jouer un jour à Crysis 3 sur Android ? Pas sûr. Crytek nous a expliqué que la question des droits va se poser avec EA et qu'il n'est pas certain qu'une existence commerciale soit réaliste et possible pour ce titre. Mais le développeur entend bien terminer le portage complet du jeu malgré tout. Tant mieux si une commercialisation est possible, au pire cela fera office de référence pour le Cry Engine qui nourrit de nouvelles ambitions sous Android.
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.
GDC: D3D12: Ashes of the Singularity et la BP mémoire
Ashes of the Singularity, développé par Oxide Games et Stardock fait partie des premiers jeux conçu pour exploiter les avantages d'une API de plus bas niveau. A la base du jeu, on retrouve le Nitrous Engine, qui a pour rappel été utilisé pour mettre en avant Mantle à travers la démonstration technologique Star Swarm.
Les développeurs d'Oxide Games expliquent que pour profiter des nouvelles API, et particulièrement de la possibilité d'exécuter un nombre bien plus élevé de commandes de rendu, c'est l'ensemble du moteur de jeu qui doit être adapté. Et il faut évidemment que le gameplay en profite. Dans Ashes of the Singularity, des milliers d'unités pourront ainsi être gérées par chaque joueur et affichées à l'écran.
Cela représente une quantité énorme de données. Toutes ces unités et leurs projectiles sont simulés par le CPU et évidemment le résultat de ces simulations doit être transféré au GPU. Dans les scènes lourdes du jeu, il faut compter 40 à 50 Mo de données par image, soit 3 Go/s à 60 fps. Le bus PCI Express encaisse la charge sans trop de problème, mais c'est une partie importante de la bande passante de la mémoire système qui est ainsi monopolisée par cette seule tâche.
C'est un aspect qui a son importance pour les systèmes d'entrée de gamme, car peu importe si le jeu est rendu en basse résolution avec peu de détails, toutes ces informations devront quand même être transférée au GPU vu qu'elles font partie du gameplay. Et avec un GPU intégré, qui devra également lire ces mêmes données à partir de la mémoire centrale, c'est 6 Go/s qui seraient monopolisés. De quoi devenir une limitation potentielle aux performances.
Oxide Games rappelle ainsi que de nouveaux goulets d'étranglements pourront apparaître si les développeurs cherchent réellement à exploiter toutes les possibilités des API de bas niveau.
