Les derniers contenus liés aux tags GDC et Vulkan

GDC: Wave programming pour booster les perfs

Publié le 28/02/2017 à 19:40 par Damien Triolet

Comme chaque année, la journée d'ouverture de la GDC est l'occasion pour AMD et Nvidia de s'associer pour parler des nouvelles API et aider les développeurs à mieux les exploiter. Premier sujet du jour : le wave programming qui sera introduit prochainement sous DirectX 12 et Vulkan pour permettre de nouvelles optimisations des performances.

Les nouvelles API telles que Direct3D 12 ou DirectX 12 et Vulkan permettent d'optimiser les performances à différents niveaux. Elles ont été introduites avec des promesses au niveau d'une baisse drastique du surcoût CPU lié au rendu 3D mais également avec des opportunités de gains de performances côté GPU via l'exécution concomitante de certaines tâches ("async compute"). Une nouvelle possibilité d'optimisation au niveau du GPU va bientôt être standardisée : le wave programming.

Qu'est-ce que c'est ? Fondamentalement il s'agit d'exposer le comportement vectoriel des GPU de manière à permettre aux développeurs de mettre en place des optimisations spécifiques. Jusqu'ici, pour ce qui concerne le rendu 3D, les API font une abstraction totale du modèle d'exécution vectoriel des GPU. Un vertex représente un thread, un pixel représente un autre thread et les GPU exécutent cette masse de threads comme ils l'entendent.

Comme vous le savez probablement, les unités de calcul des GPU sont en réalité de larges unités vectorielles ou SIMD qui travaillent par ailleurs sur plusieurs cycles. Du côté des GeForce ce sont des vecteurs de 32 threads (warp) qui sont pris en charge par les unités d'exécution. Du côté des Radeon les GPU GCN travaillent avec des vecteurs de 64 threads (wavefront). Idéalement tous les threads d'un warp/wavefront vont suivre un même chemin prédéfini. Mais ce n'est pas toujours le cas, il peut y avoir des divergences dans les accès mémoires et les shaders.

Exposer ce fonctionnement aux développeurs apporte de nouvelles possibilités d'optimisations au niveau du contrôle des branches, des accès mémoire ou du partage de données entre threads. Cela fait partie des optimisations qui sont accessibles pour le GPU computing et qui sont exploitées par les développeurs sur console. C'est également ce qu'AMD a commencé à mettre en place via des extensions propriétaires et autres backdoors propriétaires pour DirectX 12. AMD y faisait référence jusqu'ici en tant que fonctions intrinsèques.

Pour donner un exemple du wave programming, c'est en grande partie ce qui permet aux Radeon d'obtenir leurs très bonnes performances dans Doom. Sur le GPU GCN de la PS4, le gain est de 43% au niveau de la passe de rendu principale et une technique similaire a pu être portée sur PC. C'est également ce à quoi Nvidia fait appel pour booster les performances de certaines de ses librairies dont Optix.

Un support standardisé au niveau des shaders est en préparation pour Vulkan mais également pour DirectX 12. Microsoft travaille depuis l'an passé sur une mise à jour de son API qui va apporter les Shader Model 6. Ces SM6 seront spécifiques à Direct3D 12 mais seront compatibles avec les GPU déjà existants. Nvidia parle d'un support pour tous ses GPU depuis Kepler et AMD depuis GCN 3.

Le wave programming ne sera cependant pas simple à exploiter de manière optimale, notamment parce que les développeurs devront prévoir directement dans les fonctions de leurs shaders au moins deux cas de figure vu les différences majeures d'architectures entre AMD et Nvidia.

Pas mal d'expérimentations et de tests seront ainsi nécessaires pour s'assurer que ces optimisations apportent réellement un bénéfice sur tous les GPU. Une optimisation de ce type pour GPU AMD sera contreproductive sur GPU Nvidia ou encore pourra poser problème sur un GPU qui serait équipé de moins de registres physiques. Par contre les meilleurs développeurs pourront pousser très loin l'optimisation des shaders et c'est évidemment une bonne nouvelle pour le jeu PC.

Vous pourrez retrouver l'intégralité de la présentation commune d'AMD et Nvidia ci-dessous :

 
 

Vulkan en novembre pour le CryEngine

Publié le 14/09/2016 à 17:36 par Guillaume Louel

Nos confrères d'Overclock3D  ont noté que Crytek a mis à jour sa roadmap  concernant son moteur graphique CryEngine. Pour rappel, Crytek propose désormais son moteur sous licence .

La version 5.2 lancée en août avait déjà apporté le support de DirectX 12, la version 5.3, prévue pour le mois de novembre apportera cette fois ci le support de Vulkan, l'API bas niveau du Khronos Group.

La roadmap indique également que la version 5.4, prévue pour la GDC, apportera un support du multi GPU sous DirectX 12. Si précédemment le multi GPU était géré par le pilote (avec plus ou moins de mal), les API de bas niveau redonnent désormais la main aux développeurs de jeux et de moteurs pour qu'ils implémentent eux même correctement la gestion de plusieurs GPU, ouvrant pour le coup des possibilités d'asymétrie y compris dans des marques différentes.

Du côté des autres gros moteurs proposés sous licence, on notera qu'Unity a ajouté le support de DirectX 12 cet été, et que le support de Vulkan a été annoncé comme en développement. L'Unreal Engine propose déjà de son côté le support de DX12 et Vulkan.

GDC: Vulkan trop compliqué ? Imagination a une solution

Publié le 25/03/2016 à 08:59 par Damien Triolet

Maîtriser les API de plus bas niveau telles que Direct3D 12 et Vulkan représente un challenge pour les développeurs, celles-ci ajoutant à leur travail un niveau de complexité supplémentaire. Mais à travers son nouveau framework, Imagination va essayer de leur simplifier la tâche.

A l'occasion de la GDC 2016, Imagination a rendu disponible la version 4.1 de son SDK  et à l'intérieur de celui-ci un nouvel outil a fait son apparition : le PowerVR Framework. Il représente une couche intermédiaire entre un moteur graphique et une API moderne.

Le niveau de complexité des API de plus bas niveau, que ce soit Direct3D 12 ou Vulkan, va amplifier le besoin de middlewares et de moteurs de jeu prêts à l'emploi. Mais il y a malgré tout encore pas mal de développeurs qui préfèrent mettre en place leur propre solution et pourraient profiter d'un accès simplifié aux nouvelles API. C'est en partant de ce constat qu'Imagination a développé le PowerVR Framework.

Le but est simple : aider les développeurs. Pour cela, ce framework est basé sur un ensemble de bibliothèques statiques qui vont permettre de simplifier les tâches courantes telles que la création des objets, les transferts de données, la gestion du multi-threading etc. Il représente une réintroduction d'un certain niveau d'abstraction là où il n'impacte pas la flexibilité et les performances.

A titre d'exemple, Imagination nous explique que sa démonstration Gnome comprenait à l'origine plusieurs milliers de lignes de code qui ont pu être résumées en centaines de lignes en les réécrivant contre ce nouveau framework. De quoi rendre le code plus abordable et plus facile à maintenir, deux arguments qui ne devraient pas laisser les développeurs indifférents.

Ce framework permet également de supporter plus facilement différentes API et différents types de plateformes. Il peut ainsi viser autant OpenGL ES que Vulkan. Par ailleurs, en plus d'un back-end pour les GPU PowerVR, il en propose actuellement deux autres pour les GPU AMD et Nvidia. Suivant les retours des développeurs, Imagination n'est pas contre l'ajout de back-ends supplémentaires pour les GPU Qualcomm et ARM. L'objectif principal étant que les développeurs exploitent cet outil qui permet de tirer plus aisément le meilleur de ses GPU.

Il n'est par contre pas prévu de l'étendre pour supporter Direct3D 12, les GPU PowerVR n'ayant actuellement pas de présence sur la plateforme Windows. Mais compte tenu des difficultés rencontrées par les développeurs, Imagination s'attend à ce que quelqu'un d'autre propose un outil similaire, peut-être directement Microsoft.

Mise à jour de 19h30: Nvidia nous indique avoir sorti discrètement le mois passé un outil qui a des objectifs similaires : l'API open source Vulkan C++ . Il s'agit également d'une couche intermédiaire qui permet de passer l'API Vulkan C classique vers une approche de type C++ plus simple à manipuler.

Vous pourrez retrouver l'intégralité de la présentation d'Imagination ci-dessous :

 
 

GDC: Quelle API de bas niveau va s'imposer ?

Publié le 16/03/2015 à 07:00 par Damien Triolet

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: Mantle a rempli son rôle et est réorienté par AMD

Publié le 04/03/2015 à 10:30 par Damien Triolet

Avec Mantle, AMD entendait faire bouger les lignes et démontrer qu'une API de plus bas niveau était quelque chose de réaliste, de réellement exploitable et non une source de complications insensée pour les jeux AAA. Il ne fait aucun doute que cet objectif a été atteint. Face à l'engouement des développeurs, Microsoft a rapidement annoncé prendre une voie similaire avec Direct3D 12 et le groupe Khronos a fait de même. Du coup, quel est l'avenir pour Mantle ?


Lors de l'annonce de Mantle, AMD avait indiqué avoir pour objectif, à termes, d'ouvrir son API à d'autres acteurs, si ceux-ci étaient intéressés. Toutes les options étaient alors sur la table, mais AMD avait bien insisté dès le départ sur le fait que son intention était d'apporter une solution à un problème et non de tenter de forcer l'utilisation d'une API propriétaire pour en obtenir un avantage stratégique.

Un premier billet  publié sur le blog d'AMD il y a quelques jours a pu laisser penser que Mantle était abandonné au profit de DirectX 12. AMD y expliquait en effet l'arrivée sous peu d'un guide de programmation de 450 pages pour Mantle, mais l'abandon du projet de rendre public le SDK complet. Mantle reste totalement supporté par AMD pour les développeurs qui l'utilisent déjà, mais AMD réoriente les autres vers les API telles que Direct3D 12 et ce qui était alors connu sous le nom de GLnext. L'API Vulkan n'ayant pas encore été annoncée, AMD n'était pas très clair dans sa communication.

Un second billet  publié après l'annonce de Vulkan a clarifié quelque peu la situation. De notre côté, à la GDC, nous avons pu aborder la question avec AMD et plus particulièrement avec Raja Koduri, Corporate Vice President Visual Computing, et Richard Huddy, Chief Gaming Scientist. Grossièrement, pour AMD, Vulkan est ce qu'aurait été un éventuel "open Mantle", et ce dernier n'a du coup plus aucune raison d'être.

AMD a offert Mantle comme base de travail au groupe Khronos, ce qui lui a permis d'avancer plus vite qu'à l'accoutumée. Il n'y avait bien entendu pas de raisons de réinventer la roue et de nombreux aspects de Vulkan sont très proches, voire identiques, à Mantle. Selon AMD, les modifications les plus importantes qui ont été apportées sont liées aux spécificités des GPU de type TBDR (PowerVR etc.). Nvidia, qui semble plutôt de mauvaise foi sur ce coup, voit les choses sous un autre angle et tente de rabaisser Mantle autant que possible, en ironisant sur l'inévitabilité de sa disparition. Pas simple d'admettre l'influence du travail de son concurrent.

Si Mantle 1.0 n'a plus réellement de raison d'être, excepté pour les jeux déjà en développement et qui vont arriver sous peu, le concept de Mantle est loin d'être mort. AMD explique ainsi qu'il y a d'autres demandes des développeurs au niveau de l'évolution des API et que ses équipes sont prêtes à essayer d'y apporter des réponses. Il ne faut pas insister beaucoup pour que Mantle 2.0 soit prononcé, et bien que nous n'avons pas pu savoir ce qu'AMD avait en tête, il nous a semblé évident que quelque chose est déjà en préparation. AMD s'est contenté de nous dire que sa stratégie reste d'expérimenter en vue d'apporter une solution concrète à un problème donné avec pour objectif d'ouvrir à tous le résultat de ce travail, pour peut-être influencer à nouveau la formation des futures API.

Top articles