La nouvelle API graphique Vulkan

Posté par  . Édité par Lucas, palm123, Benoît Sibaud, Thomas Debesse, Nÿco, Highlander et esdeem. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes : aucune
61
25
mai
2016
Technologie

Logo Vulkan

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

  • # MacOSX / iOS

    Posté par  . É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  . Évalué à 10.

      La liste n a pas vocation a être exhaustive il me semble. Les petites entreprises ne sont pas citées.

    • [^] # Re: MacOSX / iOS

      Posté par  . É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  . É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  . É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  . É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  . É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  (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  . Évalué à 5.

      Merci pour cette précision sur SPIR-V.

    • [^] # Re: SPIR-V

      Posté par  (site web personnel) . Évalué à 4.

      L'avantage, c'est que c'est plus facile à décoder pour le driver (plus besoin d'embarquer un compilateur !)

      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  (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  (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  (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  (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  (site web personnel) . Évalué à 4.

      SPIR-V

      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  (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  (site web personnel) . Évalué à 5.

    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.

    Un peu quand même, j'ai l'impression :

    Avant de s'appeler Vulkan, l'API était connue sous le nom d'Open GL Next.

    • [^] # Re: Remplaçante

      Posté par  . Évalué à 3.

      Le consortium Kronos a dit qu'il continuerai a soutenir OpenGL.

      • [^] # Re: Remplaçante

        Posté par  (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  . Évalué à 7.

          Au pire, il doit y avoir moyen d'implémenter OpenGl en Vulkan.

          • [^] # Re: Remplaçante

            Posté par  (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  . É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  . É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  (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  (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  . É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  . Évalué à 1.

          Oui, et ça a l'air en état de mort cérébrale avancée.

  • # OpenCL

    Posté par  . Évalué à 4.

    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.

    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  . É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.