Imaginons que vous développiez un moteur de jeu multiplateformes. Vous allez utiliser une API graphique qui tourne sur toutes les plateformes. OpenGL est le choix logique vu que l'API est disponible quasiment partout. Mais OpenGL est lent et daté. Vulkan (le successeur d'OpenGL) est moderne et tourne sur Windows, Linux, Android et Switch. Mais pas sur iOS et macOS. Apple ne supporte pas Vulkan et se concentre sur sa propre API, Metal.

Pour contourner le problème, The Brenwill Workshop a développé MoltenVK, une librairie qui transcode les appels Vulkan en appels Metal. En clair, vous codez votre jeu/moteur avec Vulkan et MoltenVK se charge de le faire tourner sur Metal. Petit soucis : MoltenVK était payant. Mais Valve et ses milliards est passé par là et MoltenVK est maintenant open source. Le studio n'est pas désinteressé et compte utiliser la solution pour ses propres jeux vu que le Source 2 tourne avec Vulkan. Valve a fait des tests avec Dota 2 sur macOS et le jeu tourne entre 30% et 50% plus vite sous Vulkan que sous OpenGL.

La prochaine étape est de créer une solution similaire pour DirectX 12. En théorie Windows supporte de manière native Vulkan sauf pour les applications Windows Store à cause de cette pourriture qu'est UWP. Accessoirement, une fois que le pont Vulkan-DX 12 existe, les jeux Vulkan pourront aussi tourner sur Xbox One.

Lire la suite sur le site : Vulkan croque la pomme.

Génial ! \o/

"OpenGL est lent et daté" C'est assez débattable, surtout que Vulcan est plus bas niveau qu'OpenGL. C'est sympa pour les studios AAA mais je pense pas qu'on est près de voir OpenGL détrôné pour apprendre la programmation graphique et pour les studios indépendants (sauf s'ils utilisent un moteur qui utilise Vulcan). Aussi concernant les performances Vulcan n'est pas toujours intéressant. Les performances sont toujours meilleurs mais des fois elles sont assez anecdotiques (de l'ordre de 5% plus rapide).

L'implémentation OpenGL d'Apple est datée elle n'accepte aucune extension récente notamment celles qui permettent de réduire l'overhead graphique. (contrairement à d'autres plateformes comme sur Windows, c'est Apple qui programme sa couche OpenGL).

Certes, maintenant Apple promeut Metal mais il y a eu une longue période creuse entre les deux :).

Dota 2 est aussi caractéristique par sa grande dépendance au CPU (plus que le jeu AAA typique).

Donc c'est bien pour Dota sur MacOs, mais attention à ne pas forcément généraliser les gains obtenus.

Pour ce qui est du pont Vulkan vers DirectX12.. euh historiquement il y a toujours eu des wrappers mais ils ont plus tendance à être dans l'autre sens (gros studio développe en premier sous Windows et DirectX puis demande à une compagnie X ou Y de faire le portage sur Mac/Linux ou le joueur configure soi-même son wine/cedega/cider/ou ce que les joueurs Linux utilisent en ce moment).

(et sur les consoles : pas typiquement de wrappers mais un port natif Direct3D-Xbox, libGCN, NVN, PSGL, etc)

codec-abc a écrit :
"OpenGL est lent et daté" C'est assez débattable, surtout que Vulcan est plus bas niveau qu'OpenGL. C'est sympa pour les studios AAA mais je pense pas qu'on est près de voir OpenGL détrôné pour apprendre la programmation graphique

Il a dit que c'était lent et daté, ce qui veut dire que les alternatives récentes sont plus rapides.

Il a jamais été fait mention de "OpenGL c'est inutile et il faut que ça meurt".

LeGreg a écrit :
Pour ce qui est du pont Vulkan vers DirectX12.. euh historiquement il y a toujours eu des wrappers mais ils ont plus tendance à être dans l'autre sens (gros studio développe en premier sous Windows et DirectX puis demande à une compagnie X ou Y de faire le portage sur Mac/Linux ou le joueur configure soi-même son wine/cedega/cider/ou ce que les joueurs Linux utilisent en ce moment).

L'histoire nous montre surtout que les choses peuvent changer au cours de l'histoire. :)

Par exemple la news fait bien mention de Vulkan vers Metal, et non de DirectX12 vers Metal.

Ton argument est valide pour les gros studio et les gros jeux AAA, mais pour les plus petits jeux s'attaquant dès le départ au cross-platform Windows/Mac/Linux/Switch/Android/iOs, je doute que Windows/DirectX 12 soit développé en premier.

Un wrapper pour DirectX12 me semble pas super délirant.

Bah oui les choses peuvent changer, il était un temps où OpenGL était la seule API graphique non (hardware) propriétaire :). (Pepperidge Farm Remembers)

Mais il y a des dynamiques et contrairement aux discussions sur les forums Internet, les choses sont plus rarement idéologiques dans les boites de jeu.

Muchacho a écrit :

codec-abc a écrit :
"OpenGL est lent et daté" C'est assez débattable, surtout que Vulcan est plus bas niveau qu'OpenGL. C'est sympa pour les studios AAA mais je pense pas qu'on est près de voir OpenGL détrôné pour apprendre la programmation graphique

Il a dit que c'était lent et daté, ce qui veut dire que les alternatives récentes sont plus rapides.

Il a jamais été fait mention de "OpenGL c'est inutile et il faut que ça meurt".

Pour moi c'est un peu sous-entendu: on a 2 technos qui servent à faire les mêmes choses et on nous en présente une comme nouvelle et plus rapide. Du coup, aux yeux des néophytes la première n'a plus de raison d'être utilisée. Aussi, dire que OpenGL est lent et daté c'est présenté les choses sous un certain angle qui ne représente pas totalement la réalité. Pour avoir fait tourné Doom 2016 en OpenGL et en Vulcan j'ai eu un gain très minime en Vulcan (par contre j'ai eu des crashs). Et pour avoir vu des benchmarks je ne suis pas un cas isolé. Aussi pour le coté vieillot, la dernière version d'OpenGL (4.6) date de Juillet 2017. Bref, tout ça pour dire que l'article gagnerait soit à évité la comparaison OpenGL/Vulcan ou alors à la faire plus en détail. Mais bon de toute facon je suis pas d'accord avec la première phrase (et pas que par esprit de contradiction même si c'est une seconde nature chez moi). Les moteurs multiplateformes que je connais supportent généralement plusieurs APIs graphiques et je les vois pas se limiter à une seule.

En tous les cas, si on peut se débarrasser une bonne fois pour toute de directx.... Car franchement ça fait déjà deux fois que microsoft oblige les joueurs pour passer au prochain directx à changer d'os. Peut être que vulcan va calmer leur ardent.

codec-abc a écrit :
Pour moi c'est un peu sous-entendu: on a 2 technos qui servent à faire les mêmes choses et on nous en présente une comme nouvelle et plus rapide. Du coup, aux yeux des néophytes la première n'a plus de raison d'être utilisée. Aussi, dire que OpenGL est lent et daté c'est présenté les choses sous un certain angle qui ne représente pas totalement la réalité.

Certes il y a eu OpenGL 4.6 en juillet. Et c'était une mise à jour plutôt costaud. Mais cela ne change pas le fait qu'OpenGL 4 a huit ans. Et puis avec OpenGL il fallait aussi composer avec la branche mobile, OpenGL ES. En théorie la compatibilité est assurée. En pratique tu as toujours deux différentes cibles. En plus de cela tu dois gérer les extensions. Vulkan a remis les choses à plat et a proposé une vraie API unifiée. Donc oui OpenGL est daté, aussi bien dans le temps que dans sa conception.

Et pour l'aspect lent, au pire Vulkan propose des perfs similaires et au mieux (cela dépend des jeux) tu as un gain de perfs assez conséquent. Et ce n'est pas uniquement une question de framerate. Vulkan consomme moins de temps CPU et le consomme de manière plus consistante ce qui permet d'éviter les micro-sacades.

Le truc c'est que Vulkan peut proposer des surcouches en open source. Une fois qu'on aura un équivalent d'OpenGL sur ce modèle, j'imagine qu'OpenGL perdra en valeur ajoutée.

CBL a écrit :
En pratique tu as toujours deux différentes cibles. En plus de cela tu dois gérer les extensions.

Et c'est bien ça le soucis principal. Certes OGL est censé être un standard multiplateforme, en pratique, t'as tellement de patch propriétaires à utiliser que ça en devient un sac de noeud où chaque plateforme (OS et CG) fini par avoir son propre codepath.

Et maintenant, tu en as trois. Euh quatre. Ah non cinq.

Je sais pas. Les problèmes de la prog multiplateforme ne sont pas vraiment nouveaux. Et en pratique les boites de dev font leur beurre tout de même.

Ou alors, gasp, il faut tout standardiser sous Windows et DirectX :D ne supportez pas la fragmentation avec vos iphones, ps4 ou superordinateur power pc.

OpenGL = marre d'écrire 15 ko de code pour afficher un triangle. (J'en ai codé pendant 2 ans au taf ca m'a suffit, ok c'était de l'OpenGl 3.1...)

Soren a écrit :
OpenGL = marre d'écrire 15 ko de code pour afficher un triangle. (J'en ai codé pendant 2 ans au taf ca m'a suffit, ok c'était de l'OpenGl 3.1...)

Tu pourras venir faire un commentaire quand tu auras essayé un triangle sous Vulkan ? De préférence à chaud et avec quelques grammes dans le sang, parce que le Hello World sous Vulkan c'est du lourd.

Ark effectivement je viens de check. Ca reste moins pire que de l'OpenGL 3.1.

«Vulkan: what it takes to draw a triangle».

MrPapillon a écrit :
«Vulkan: what it takes to draw a triangle».

Quelle imbécilité, mélange de paresse intellectuelle et de malhonnêteté... Le plus triste, c'est qu'il semble que certains programmeurs professionnels gobent ce genre d'âneries bien volontiers. Rendre le premier triangle avec Vulkan demande certes davantage de code qu'OpenGL ou D3D11 (et encore, une grande partie de ce qui est montré sur ce diagramme n'est absolument pas nécessaire), mais passé ce stade, et parlant d'expérience, il est bien plus aisé au quotidien de travailler avec Vulkan pour diverses raisons (pas besoin de jouer aux devinettes avec le hardware, documentation extrêmement complête et bien organisée), indépendemment même des avantages intrinsèques à sa modernité, que partage en partie D3D12.

Pour un retour de non-expert en rendu mais avec un peu plus de curiosité intellectuelle que l'auteur de ce tweet ou quiconque le prenant pour argent comptant, un collègue a rédigé une petites séries d'article faisant le compte-rendu de son portage de Doom 3 sous Vulkan : https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and-so-can-you-part-1

Ttask a écrit :

MrPapillon a écrit :
«Vulkan: what it takes to draw a triangle».

Quelle imbécilité, mélange de paresse intellectuelle et de malhonnêteté... Le plus triste, c'est qu'il semble que certains programmeurs professionnels gobent ce genre d'âneries bien volontiers. Rendre le premier triangle avec Vulkan demande certes davantage de code qu'OpenGL ou D3D11 (et encore, une grande partie de ce qui est montré sur ce diagramme n'est absolument pas nécessaire), mais passé ce stade, et parlant d'expérience, il est bien plus aisé au quotidien de travailler avec Vulkan pour diverses raisons (pas besoin de jouer aux devinettes avec le hardware, documentation extrêmement complête et bien organisée), indépendemment même des avantages intrinsèques à sa modernité, que partage en partie D3D12.

Pour un retour de non-expert en rendu mais avec un peu plus de curiosité intellectuelle que l'auteur de ce tweet ou quiconque le prenant pour argent comptant, un collègue a rédigé une petites séries d'article faisant le compte-rendu de son portage de Doom 3 sous Vulkan : https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and-so-can-you-part-1

Le mec a l'air un spécialiste de directx... Ceux-ci explique peut être cela...

Je suis spécialiste DX et le code pour faire fonctionner DirectX n'est pas forcément trivial (et encore moins pour DirectX12).

Le truc c'est que les gens ignorent ce que sont des systèmes complexes et des APIs qui doivent "optimiser l'utilisation du hardware". C'est ce que les gens qui réclamaient Vulkan et D3D12 voulaient ! Ceci dit tout le monde peut écrire un wrapper qui va cacher un peu de complexité. Microsoft par exemple a écrit un mini moteur d3d12 open source. Mais pour avoir bouffé pas mal de code mal écrit ou fonctionnant par accident, cacher la complexité d'une API complexe a des gros inconvénients surtout quand on introduit le multithreading et les race conditions.

Ttask a écrit :
pas besoin de jouer aux devinettes avec le hardware

Je dirais plutôt que les devinettes sont différentes..