La nouvelle API 3D Vulkan annoncée en mars 2015, prévue pour sortir fin 2015 est finalement sortie en version stable le 16 février 2016. Cette API est issue du consortium Khronos Group. L'API Vulkan ne se veut pas une remplaçante à OpenGL une autre API du Khronos Group, mais une alternative plus orientée vers la programmation bas-niveau.
Origine
Vulkan se base sur les travaux effectués sur l'API Mantle, lancés en 2013 par AMD et soumis en 2014 au consortium Khronos, ainsi que sur le logiciel Gallium 3D. Avant de s'appeler Vulkan, l'API était connue sous le nom d'Open GL Next.
Caractéristiques
Langage SPIR-V
Vulkan utilise le langage intermédiaire SPIR-V, développé par le consortium Kronos Goup, basé sur SPIR développé à l'origine pour être utilisé dans OpenCL. SPIR-V prend en charge nativement les shaders et les fonctionnalités propres aux noyaux présents dans les divers systèmes d’exploitation. Cependant, le langage SPIR-V est plus complexe à maîtriser, mais il permettra aux développeurs de réaliser des moteurs 3D plus optimisés.
Gestion du processeur
Vulkan a une meilleure gestion des processeurs multi-cœur et du multi-processeur. Le processeur est moins sollicité et est utilisé de manière beaucoup plus optimale, au profit de la carte graphique. Il permet une amélioration des performances et une baisse de la consommation.
Pilote simplifié
Vulkan possède un pilote simplifié, permettant d'utiliser d'avantage les commandes et la gestion de la mémoire du GPU.
Multiplate-forme
L'API est multiplateforme contrairement à DirectX 12, qui est uniquement présent sur Microsoft Windows 10. Elle tourne aussi bien sur les ordinateurs avec des distributions GNU/Linux ou Microsoft Windows (XP à 10), les smartphones et tablettes sous Android, les consoles de jeux comme la PS4 ou la future NX. Elle possède les mêmes fonctionnalités sur smartphone ainsi que sur ordinateur, car il n'y a qu'une seule version, là où Open GL est la version pour les ordinateurs de bureau et Open GL ES pour les smartphones.
Plus bas niveau
L'API est plus bas niveau et donc plus difficile à manier qu'OpenGL, car elle impose une plus grande gestion des ressources par les développeurs. L'avantage à contrario est que cela permet une optimisation plus importante du code, là où OpenGL le permettait moins ce qui demande beaucoup plus de travail de maintenance du code.
Quelques jeux et logiciels qui vont prendre en charge l'API
Jeux
- Doom
- Dota 2
- The Talos Principle
Logiciel
- TouchWiz
- Mir
Entreprises partenaires
De nombreuses entreprises participent à l’élaboration de cette norme, parmi lesquelles nous pouvons trouver : AMD, Apple, ARM, Blizzard, Broadcom, Codeplay, Continental, DMP, Electronic Arts, Epic Games, Imagination Technologies, Intel, Lucasfilm, Mediatek, Oculus VR, Oxide, Pixar, RTT, Samsung, Sony, TransGaming, Unity, Valve, Vivante.
Pilotes graphiques
Des pilotes graphiques sont déjà disponibles chez AMD (GPU et APU) et Nvidia, ainsi que chez Intel pour les puces Haswell, Brodwell. Sandy Bridge et Skylake.
Aller plus loin
- Site de présentation de Vulkan (563 clics)
- Site du groupe Khronos (126 clics)
- Site de présentation de Vulkan par Nvidia (234 clics)
- Site de présentation de Vulkan par AMD (513 clics)
# MacOSX / iOS
Posté par Arkem . Évalué à 3.
Bien que n'utilisant pas ces systèmes, je suis surpris qu'ils n'apparaissent pas dans la liste alors qu'Apple est bien cité parmi les entreprises participantes. Est-ce un oubli, ou le support de ces systèmes n'est pas encore finalisé?
[^] # Re: MacOSX / iOS
Posté par abriotde (site web personnel, Mastodon) . Évalué à 10.
La liste n a pas vocation a être exhaustive il me semble. Les petites entreprises ne sont pas citées.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: MacOSX / iOS
Posté par DerekSagan . Évalué à 3.
<3
[^] # Re: MacOSX / iOS
Posté par Narishma Jahar . Évalué à 10.
Vulkan n'est pas supportée par Apple qui a sa propre API propriétaire nommée Metal sur iOS et MacOS X.
[^] # Re: MacOSX / iOS
Posté par Nico7as . Évalué à 3.
On espère qu'Apple le supportera un jour….
En attendant, des middleware faisant le pont entre Metal et Vulkan commencent à pointer le bout de leur nez, notamment chez Molten.
https://moltengl.com
[^] # Re: MacOSX / iOS
Posté par Uther Lightbringer . Évalué à 10. Dernière modification le 25 mai 2016 à 20:55.
En effet Apple, bien qu'il fasse partie du Kronos group qui a établi la spécification de Vulkan, n'a pour le moment rien annoncé a propos d'un éventuel support par iOS et MacOS X.
Depuis le succès des iBudules la politique globale de Apple et de dire autant que possible merde au cross plateforme. Et comme ils possèdent leur propre API graphique : Metal, il est probable qu'ils n’implémenteront pas Vulkan, à moins d'y être obligé par un échec de Metal et un succès fulgurant de Vulkan.
[^] # Re: MacOSX / iOS
Posté par memz . Évalué à 7.
Comme dit précédemment, Apple a sa propre API, Metal, mais a effectivement fait partie du groupe de travail avant de s'en retirer. Par contre elle fait toujours partie du consortium:
"[…] Khronos was quick to note that while Apple pulled out of participating in the Vulkan working group, they are still a member of the Khronos consortium overall"
http://www.anandtech.com/show/10035/vulkan-10-released
[^] # Re: MacOSX / iOS
Posté par Albert_ . Évalué à 4.
De la a penser qu'ils faisaient de la pioche aux idees avant de faire un truc dans leur coin a eux tout seul (donc de facon beaucoup plus simple) je saute allegrement le pas et je trouve que c'est meme a la limite de l'espionnage industriel mais c'est que mon opinion naturellement et je suis tres impertinent…
# SPIR-V
Posté par rewind (Mastodon) . Évalué à 10.
SPIR-V n'est pas un langage, c'est une représentation intermédiaire entre les langages de shader (qui ne vont absolument pas disparaître) et le code compilé pour la carte graphique. L'avantage, c'est que c'est plus facile à décoder pour le driver (plus besoin d'embarquer un compilateur !), et en plus, on pourra utiliser d'autres langages (comme C ou C++) qui cibleront SPIR-V. Un avantage pour les logiciels propriétaires, c'est qu'ils peuvent maintenant embarquer un fichier binaire plutôt qu'un fichier texte pour les shaders. Un dernier avantage, c'est qu'il est possible de construire tout un éco-système d'outils autour de SPIR-V (optimiseur, analyseur, etc), et c'est Khronos qui a pris les choses en main en faisant tout en open-source.
Enfin, notons que SPIR-V a été très largement inspiré par la représentation intermédiaire de LLVM.
[^] # Re: SPIR-V
Posté par gusterhack . Évalué à 5.
Merci pour cette précision sur SPIR-V.
[^] # Re: SPIR-V
Posté par Martin Peres (site web personnel) . Évalué à 4.
Ah ah! Tu rêves :p La seule chose que ca fait c'est simplifier le frontend et simplifier la spec vis-à-vis du packing des structures et autres trucs que tout le monde faisait légèrement différemment.
Un driver GPU moderne est majoritairement un gros compilo et un chti runtime :p
[^] # Re: SPIR-V
Posté par rewind (Mastodon) . Évalué à 2.
c'est quand même plus facile de parser un truc binaire bien spécifié et déjà prémâché qu'un texte, non ? Après, oui évidemment, il faudra toujours produire le binaire pour la carte…
[^] # Re: SPIR-V
Posté par Martin Peres (site web personnel) . Évalué à 4. Dernière modification le 29 mai 2016 à 11:20.
Oui, mais le front-end GLSL est ridiculement petit comparé au reste du compilateur. Je pense vraiment que la seule amélioration ici et que SPIR-V ne demande plus aux pilotes de gérer les indices des ressources ce qui permet de simplifier grandement la spec et diminuer les différences entre les pilotes. Je pense aux UBO si tu as eu l'occasion de t'amuser avec :D
[^] # Re: SPIR-V
Posté par rewind (Mastodon) . Évalué à 3.
Moi j'avais compris qu'avec SPIR-V, toute la partie optimisation était sorti du pilote et réalisée hors ligne et que, en gros, on n'avait plus qu'à traduire les opcodes SPIR-V dans le dialecte de la carte graphique choisie.
[^] # Re: SPIR-V
Posté par Martin Peres (site web personnel) . Évalué à 4.
Le code est meilleur en entrée, mais y'a beaucoup d'optimisations faite liées à l'architecture et c'est vraiment le plus gros du travail. C'est d'autant plus le cas que la plupart des compilateurs utilisent LLVM maintenant dans le monde proprio ce qui veut dire que toutes les optis génériques sont là.
[^] # Re: SPIR-V
Posté par reynum (site web personnel) . Évalué à 4.
Moi je vois le coup venir ! Dans 25 ans un illuminé créera un nouveau langage nommé SPIRD et ça engendrera un cataclysme dans la communauté Hurd :-D
kentoc'h mervel eget bezan saotred
# Question de noob
Posté par yoho (site web personnel) . Évalué à 2.
Pour les newbies comme moi, c'est pas hyper clair. Ça veut dire concrètement que si je veux programmer un jeu 3D et utiliser vulkan, devrais-je utiliser un autre compilateur que mon compilateur C++ préféré? Une autre API?
Pourquoi y a t il besoin de nouveaux pilotes pour les cartes graphiques?
[^] # Re: Question de noob
Posté par ʭ ☯ . Évalué à 5.
Pas besoin de changer de compilateur, il te faut juste les headers Vulkan.
Il te faut un nouveau pilote car il faut traduire SPIR-V en instructions assembleur de la carte graphique.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Remplaçante
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Un peu quand même, j'ai l'impression :
[^] # Re: Remplaçante
Posté par gusterhack . Évalué à 3.
Le consortium Kronos a dit qu'il continuerai a soutenir OpenGL.
[^] # Re: Remplaçante
Posté par Narann (site web personnel) . Évalué à 5.
Je rajouterai: Jusqu’à ce que écosystème Vulkan soit stable et bien établie et qu'OpenGL meure de lui même.
En gros: Ils ne prennent pas la responsabilité de tuer OpenGL, continueront d'accepter des extensions mais OpenGL est voue a mourir au profit d'API plus haut niveau mais s'appuyant sur vulkan.
[^] # Re: Remplaçante
Posté par KiKouN . Évalué à 7.
Au pire, il doit y avoir moyen d'implémenter OpenGl en Vulkan.
[^] # Re: Remplaçante
Posté par Narann (site web personnel) . Évalué à 2.
Plus le temps passe, moins les drivers OpenGL seront présents (Ils sont en effet beaucoup plus long a développer et a optimiser) et plus une surcouche OpenGL s'appuyant sur Vulkan va être nécessaire, mais uniquement pour faire tourner les anciennes applications, un peu comme les wrapper Glide (l'API graphique de 3DFX qui n'existe plus).
Ça peut être un très beau projet même si les premiers retours concernant cette idée (j'ai plus les sources dsl) semble dire que ce n'est pas quelque chose de forcement simple a faire et que ça amènera de mauvaises performances.
[^] # Re: Remplaçante
Posté par KiKouN . Évalué à 4.
Si c'est pour faire tourner des appli de maintenant sur les cartes de demain, les pertes de l'implémentation seront compensés par la montée en puissance des cartes graphiques.
Au final, on aura les appli d'aujoud'hui avec des perf d'aujoud'hui.
[^] # Re: Remplaçante
Posté par Laurent A. . Évalué à 2.
Mais il va falloir les écrire ces API de haut niveau. Pour l'instant, on peut compter sur l'inertie de l'industrie pour ne voir aucun changement avant plusieurs années.
De plus, pour des petits programmeurs de rendu 3D, Vulkan représente une API difficile à prendre en main alors qu'OpenGL est relativement accessible. Je reconnais toutefois que les styles récents de programmation en OpenGL, c'est-à-dire avec des gros buffers et des shaders, ne sont pas simples non plus.
# Wayland
Posté par Sytoka Modon (site web personnel) . Évalué à -3.
Au final, Wayland a t-il encore un intérêt, ne faudrait-il pas faire du natif Vulkan ? Cela avait été envisagé un moment pour X11…
[^] # Re: Wayland
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Je pense qu'un compositeur a toujours un intérêt, oui, d'un part parce qu'il ne gère pas que l'affichage mais aussi l'entrée, et d'autre part parce qu'il faut bien quelque chose pour fenêtrer et tout ce qui va avec, bien que je n'y connaisse pas grand chose.
Sinon, autant se demander si X11 avait bien un intérêt plutôt que d'écrire directement dans la mémoire vidéo non ?
[^] # Re: Wayland
Posté par dinomasque . Évalué à 8.
Certains se sont posé la question il y a 15 ans : https://fr.wikipedia.org/wiki/DirectFB
Et effectivement, ils ont du ré-implémenter toute la gestion des inputs et d'autres trucs qui font un serveur d'affichage.
BeOS le faisait il y a 20 ans !
[^] # Re: Wayland
Posté par DerekSagan . Évalué à 1.
Oui, et ça a l'air en état de mort cérébrale avancée.
# OpenCL
Posté par barmic . Évalué à 4.
Du coup elle peut servir de base à une implémentation d'OpenCL ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Un avenir radieux pour linux
Posté par gusterhack . Évalué à 1.
En tout cas Vulkan va permettre d'améliorer l'offre de jeux sous GNU/Linux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.