Durant la GDC il y a quelques semaines, AMD a précisé ses plans concernant Mantle, son API bas niveau. Pour résumer en quelques mots, ils laissent tomber. Ils vont sortir la 1.0 et continuer de supporter les projets en cours comme Battlefield Hardline mais les efforts vont s'arrêter là. Ils n'ouvriront pas leur API et ne la porteront pas sur des cartes autre que les AMD. La raison est simple : DirectX 12 et Vulkan (le nom officiel de glNext, le successeur d'OpenGL) ont rendu Mantle inutile puisqu'ils fonctionnent de manière similaire et proposent des performances similaires. C'est un peu comme quand ATI avait abandonné Close to Metal au profit d'OpenCL.

En clair, Mantle a servi d'expérience pour valider l'approche de Vulkan et de DirectX 12. Mantle a même été la base de travail pour le développement de Vulkan et a été publiquement remercié pour son support et ses conseils par le Khronos Group. Si vous voulez en savoir plus sur Vulkan, on vous conseille de lire cet excellent article d'AnandTech. En gros, voici les principales caractéristiques : des drivers réduits au strict minimum : en plus de réduire l'overhead, cela devrait éviter de devoir installer des nouveaux drivers pour chaque nouveau jeu la majorité du boulot auparavant effectué dans les drivers est transféré dans le moteur 3D. Ecrire un moteur 3D risque d'être sacrément plus complexe qu'avant et les devs vont surement se tourner encore plus vers le middleware (Unity, Unreal...) la possibilité d'écrire des shaders dans de nombreux langages, Vulkan via sa composante SPIR-V se chargeant de traduire le tout en instructions bas niveau une API unique pour toutes les plateformes (PC, Mac, Mobiles...) une compatibilité avec la plupart des GPU récents (pour les mobiles il faut qu'ils supportent OpenGL ES 3.1) Mais tout cela est loin d'être prêt. Le Khronos Group et ses partenaires veulent sortir une API en mettant l'accent sur ce qui fait une différence énorme : les outils de debugging. En attendant, le gros concurrent de Vulkan, DirectX 12, est au coin de la rue.

3D Mark a sorti un nouveau benchmark qui compte le nombre de draw calls (appels à l'API graphique) par seconde que les cartes graphiques peuvent encaisser avant que le framerate ne tombe en-dessous de 30 FPS. Grosso modo, vous multipliez le nombre d'objets 3D rendus à l'écran par le nombre de matériaux utilisés par chaque objet 3D et vous obtenez le nombre de draw calls. Plus vous pouvez balancer de draw calls et plus vous pouvez afficher de choses. Ce nouveau benchmark compare à machine égale les perfs de DX 11 et DX 12. Les premiers chiffres sont tombés et les résultats sont délirants.

Geforce GTX 750 Ti /  Intel I7-5960x / 1920x1080 DX11 : 1 081 530 draw calls par seconde DX12 : 7 653 465 draw calls par seconde
Geforce Titan X /  Intel I7-5960x / 1920x1080 DX11 2 524 794 draw calls par seconde DX12 14 545 096 draw calls par seconde
AMD Radeon R7 200 Series /  Intel I7-5960x / 1920x1080 DX11 955 796 draw calls par seconde DX12 13 268 733 draw calls par seconde
Intel 5200 Iris Pro / Intel i7-4770R / 1920x1080 DX11 645 940 draw calls par seconde DX12 2 126 150 draw calls par seconde D'autres chiffres sont disponibles ici. Evidemment tous ces tests sont effectués sur des CPUs velus donc on aimerait voir les mêmes benchs sur des processeurs plus modestes. Le nombre de cœurs est très important : le gain de perf entre 2 et 4 coeurs et 4 et 6 coeurs est quasiment linéaire. Par contre il est négligeable quand on passe de 6 à 8 coeurs.

Concluons cette news par une rumeur assez folle : Samsung aurait des vues sur AMD selon un site coréen. Samsung produit ses propres puces mais elles ne sont destinées qu'au mobile. En s'offrant AMD, ils pourraient pénétrer le marché des PCs et des consoles. Avec Windows 10 qui sort dans quelques mois et qui devrait donner un coup de boost aux ventes de PC, le calcul est loin d'être idiot.

Lire la suite sur le site : Adieu Mantle et bonjour Vulkan.

Ecrire un moteur 3D risque d'être sacrément plus complexe qu'avant
Je pari que Carmack quite la VR et retourne faire des moteurs si ce truc marche.

Avec Windows 10 qui sort dans quelques mois et qui devrait donner un coup de boost aux ventes de PC
Windows est un argument de vente de PC ?

Je suis toujours sceptique sur l’intérêt réel de cette optimisation. Dans l'absolu oui, ça va plus vite, mais en pratique on en fait des caisses sur le cout des drawcalls alors que ça reste une part négligeable dans le temps total d'un rendu. Du coup les benchmarks centrés Mantle/DX12 montrent des scènes qui n'ont rien de réaliste en terme de représentation et d'optimisation, juste dans le but de charger les drawcalls un max, alors que les scènes classiques de JV (quel que soit le genre) utilisent en réalité beaucoup moins de drawcalls que ça pour une complexité apparente proche.
Par exemple dans le cas de bench generateur de ville ou de champs d'asteroides, il n'y a aucun intérêt à ce que le CPU se tape manuellement le calcul et l'envois de toute la géométrie alors que le GPU pourrait génerer et gérer ça en grande partie en interne, donc avec un nombre de drawcalls CPU->GPU dérisoire. De la même manière que les micros détails des surfaces s'obtiennent bien plus intelligement via des maps de displacements qu'en demandant au CPU de subdiviser et d'envoyer tout ça de son coté, c'est complètement contre-productif.
En pratique sur les jeux classiques ça m'étonnerait qu'on voit un gain moyen supérieur à 10% grâce au passage sur DX12/Vulkan.

Concernant l'écriture de moteurs avec Vulkan, j’espère bien que non, ça ne sera pas plus compliqué qu'OpenGL qu'il est censé remplacer... Ou qu'au moins, ça n'obligera pas à écrire des routines spécifique à chaque constructeur, auquel cas je préfère rester sur OpenGL :/

Au pire c'est toujours 10% de pris, et c'est sur les jeux qui ont été architecturés "à l'ancienne". Peut-être que les suivants pourront faire des choses qui étaient impensables avec les techno précédentes.

'y a aussi les améliorations du "pipline" général concernant les drivers et les shaders, et la potentielle API unique. C'est sympa tout ça.

Perso je pense que c'est un passage nécessaire.

Pour que ce bench soit totalement parlant, il faudrait une comparaison DirectX11 + deferred context / DirectX12 sur NVidia (à mon avis ce test utilise du DirectX11 "classique" en immediate context sur un seul thread).
Car NVidia a beaucoup travaillé sur les deferred context DirectX 11 depuis quelques temps dans leur driver ( http://www.hardware.fr/news/13626/gdc-nvidia-met-avant-son-pilote-direct3d-11.html ) qui permettent de faire des choses avec DirectX11 qu'AMD ne s'est jamais donné la peine de supporter correctement.

CBL a écrit :
Ecrire un moteur 3D risque d'être sacrément plus complexe qu'avant

Oui et non. Écrire un bon (lire optimisé) moteur 3D est déjà sacrément complexe, mais une partie de cette complexité vient justement des API utilisées, celles-ci ne faisant pas forcément bon ménage avec la tendance actuelle qui est de diviser au maximum le boulot sur le plus de threads possibles. Écrire un moteur correctement threadé est extrêmement délicat et même si des API comme DX11 ont apporté certaines facilités à ce niveau-là, le design d'un moteur reste généralement contraint par des limitations inhérentes à ces dernières.

DX12/Vulkan peuvent apporter la flexibilité nécessaire pour outrepasser ces limitations.

wata_ : c'est le cas à chaque nouveau Windows.

divide : certe les draw calls ne font pas tout mais c'est quand meme le gros frein actuel. Le gain de perf dépendra beaucoup du type de jeu mais pour les open world ca va etre la grosse fete.

DZ : justement le bench teste DX11 dans un rendu mono-thread et dans un rendu multi thread


hiroshimacc : disons que quand tu vois tout ce qui a ete transfere des drivers au niveau applications, ca ajoute une sacre charge de travail qui est il est vrai compense par le fait que l'API devrait etre bien plus solide.

Il faut différencier les utilisateurs qui programment des moteurs 3D et les utilisateurs qui sont des grouillots de base pour des applis scientifiques ou des petites applis non optimisées. Je ne pense pas que le passage à Vulkan va compliquer beaucoup le taf' d'intégration dans un bon moteur, peut-être même que ça va le simplifier vu qu'une grosse partie du taf' d'intégration classique est déjà de rajouter une couche pour faire ressembler l'API DirectX/OpenGL à un truc qui se rapproche de Vulkan/Mantle.
Par contre pour le grouillot de base et sa petite appli merdique, ben il a toujours OpenGL pour faire joujou.

Je suis perso un user super lambda qui n a pas regretté l absence de directx 10 en restant sur xp alors je le demande aux tekos tres simplement:

"Est ce que directx 12 tue la bite?"

Certains annonçaient la fin des APIs et des drivers, mais en réalité le rôle des drivers a été pérennisé par les nouvelles API. (pérennisé dans le sens où le modèle avec un driver complexe a montré qu'il pouvait être simplement réorganisé pour limiter l'overhead). Je ne mettrais donc pas ma main au feu sur la fin des updates régulières des drivers de cartes graphiques..

Vulkan ne cible pas aujourd'hui toutes les plateformes notamment mobiles et Mac.

Il faut relativiser le test 3dmark qui est évidemment un scénario tout à fait irréaliste pour un jeu vidéo. Du au fait qu'il fait tout pour ne pas être gpu limité ("In order to ensure that the API is the bottleneck in this test, the scene is built procedurally with unique geometries that have an indexed mesh of 112-127 triangles. There is no post-processing and the shaders are very simple to make sure the GPU is not a primary bottleneck"). Mais il n'y arrive pas tout à fait entièrement (encore des variations à l'intérieur d'une même famille de GPUs).
Le gain dans la vraie vie est YMMV (combinaison CPU/GPU et complexité de ce qu'il y a à afficher).

y a la présentation version longue ici :
PDF

L'API ressemble à du OpenCL, ça a l'air très sympa.

"Cross-platform, cross-vendor
- Not tied to single OS (or OS version)
- Not tied to single GPU family or vendor
- Not tied to single architecture
- Desktop + mobile, forward and deferred, tilers all first class citizens"

Ça a été affirmé explicitement que Vulkan ne cible pas les mobiles et Mac ? Je trouve ça étonnant. Apple fait partie du consortium Vulkan d'ailleurs.

MrPapillon a écrit :
Ça a été affirmé explicitement que Vulkan ne cible pas les mobiles et Mac ? Je trouve ça étonnant. Apple fait partie du consortium Vulkan d'ailleurs.

Il y a la théorie.. et la pratique.
En théorie Vulkan cible toutes les plateformes. En pratique, il y a trois principales plateformes iOS, Windows Mobile (RT ou 10 suivant le flavor du jour), et Android. Ensuite vous faites les maths.

Okay pour Android c'est plus complexe.. Puisque c'est un OS ouvert (en théorie), un constructeur peut y mettre l'API qu'il veut. Par exemple la tablette Shield supporte OpenGL (la version complète, pas la version ES).. Mais OGL n'est pas présent dans la Nexus..

(c'est plus ou moins pareil sur PC et Linux, en théorie Vulkan est présent sur ces plateformes, en pratique c'est plus ou moins comme OpenGL qui est présent sur ces plateformes. Ce qui veut dire que l'avenir, wait and see, sera sans doute un peu plus clair sur ce que cela signifie.).

LeGreg a écrit :
Okay pour Android c'est plus complexe.. Puisque c'est un OS ouvert (en théorie), un constructeur peut y mettre l'API qu'il veut. Par exemple la tablette Shield supporte OpenGL (la version complète, pas la version ES).. Mais OGL n'est pas présent dans la Nexus..

Je ne joue pas avec Android et compagnie, mais j'imagine qu'il y a de l'OpenGL ES partout. Donc Vulkan étant une sorte de plus petit dénominateur commun, Vulkan ne devrait pas avoir du mal à être supporté, avec des extensions en plus ou en moins. Ou alors ça serait une volonté politique de nuire à la portabilité, mais là ça serait vrai pour tout standard à visée universelle, pas juste Vulkan (standards Web, standard C++, standard câble d'alim', etc...)

Après la différence avec OpenGL, c'est que beaucoup de code repose côté driver. Pour Vulkan, le code repose côté dev, ce qui limite le potentiel de nuisance d'un mauvais driver, et encore plus d'un driver à sources fermées. La grosse différence selon les plateformes se fera sûrement sur les outils et libs annexes je pense, il est grand temps qu'on arrête ces conneries avec les API graphiques qui sont complexes pour pas faire grand chose au final.

CBL > oui mais ça un moteur un minimum sérieux l'a déjà, son système d'allocation, de gestion d'erreur et Cie. La main mise sur la gestion du threading c'est justement ce qu'on veut (et pas avoir à cohabiter avec ce que veut faire le driver, contre notre gré).

LeGreg > Android assure une compatibilité minimum avec OpengGL ES, en fonction de la version. Par exemple, la dernière version de l'OS, Lolipop (5.0) supporte OpenGL ES 3.1. Après le hardware peut limiter les fonctionnalités disponibles, mais c'est pareil sur PC, avoir Windows 7 et une carte graphique qui ne supporte que DX9 ne permet pas de profiter des fonctionnalités DX11 qu'apporte l'OS.

MrPapillon a écrit :
il est grand temps qu'on arrête ces conneries avec les API graphiques qui sont complexes pour pas faire grand chose au final.

Je crois surtout qu'il faut qu'on arrête de tout simplifier de manière caricaturale.

LeGreg a écrit :
Je crois surtout qu'il faut qu'on arrête de tout simplifier de manière caricaturale.

Les devs au pouvoir ! LeGreg collabo !