Une information qui a son importance dans la pile graphique de Linux, le 3 mars 2015, le Khronos Group, un consortium industriel qui gère entre autre les standards OpenGL, OpenGL ES, OpenCL et WebGL a dévoilé l'API qui devrait succéder à OpenGL à savoir Vulkan, , sa prochaine génération d'API de haute performance dédiée au graphisme 3D et au calcul GPU.
- Vulkan - Graphics and compute belong together
- Khronos Reveals Vulkan API for High-efficiency Graphics and Compute on GPUs
- Khronos unveils Vulkan: OpenGL built for modern systems
- Vulkan succédera à l'OpenGL de Khronos
- The Khronos Group's Vulkan, SPIR-V & OpenCL 2.1 Presentations
- Valve Developed An Intel Linux Vulkan GPU Driver
- Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V
- Imagination Already Has A Vulkan Driver In The Works For PowerVR GPUs
- GDC: Vulkan, l'API bas niveau de Khronos
# Changements ?
Posté par Aissen . Évalué à 10. Dernière modification le 06 mars 2015 à 13:45.
J’ai lu pas mal des articles cités, et j’ai du mal à voir les changements au niveau techniques; voici ce que j’ai cru comprendre de
glNextVulkan:- un bytecode commun SPIR-V pour Vulkan et OpenCL. Finit les programmes qui envoie des shaders en C et les différences d’implémentations des frontends de compilo
- plus de différence entre OpenGL, OpenGLES, WebGL; ils sont remplacés par Vulkan
- une API plus bas niveau; l’appli doit maintenant gérer ses buffers elle même; ça donne plus de puissance au développeurs de moteurs, mais pas non plus fait pour être utilisé directement par les devs d’applis comme OpenGL/DirectX.
- possibilité d’envoyer des commandes depuis une stack multi-threadées
D’autres personnes plus expérimentés passent par là pour expliquer les différences? Quelles seraient les inconvénient fassent à Mantle (voué à disparaître?) et Metal ? Est-ce que le rapprochement avec OpenCL va enterrer CUDA ? Comment ça se compare à DirectX12 ?
[^] # Re: Changements ?
Posté par med . Évalué à 3.
J'ai cru comprendre le contraire. Qu'ils continueront à être développés en parallèle.
[^] # Re: Changements ?
Posté par ʭ ☯ . Évalué à 4.
Il seront pas supprimés d'un coup, la base existante étant énorme. Mais Vulkan permet ce que les 3 permettent, et est donc appelé à les remplacer sur les nouveaux développements.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Changements ?
Posté par Albert_ . Évalué à 4.
Est-ce que le rapprochement avec OpenCL va enterrer CUDA ?
Ca va etre difficile d'enterrer CUDA a mon avis. A peu pres 99,9% des applications GPU que je vois sont en CUDA. En fait je n'en ai jamais vu en OpenCL…
[^] # Re: Changements ?
Posté par reynum (site web personnel) . Évalué à 6.
Nvidia Fuck you !!
Pardon je -->[]
kentoc'h mervel eget bezan saotred
[^] # Re: Changements ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Il fusionne openCL et openGl, diminue la complexité de l'api, et essaye d'être réellement portable ce qui n'est pas le cas d'OpenGL, dans les détails.
Peut être que l'on verra plus souvent des applications tirés parti de la vitesse des gpu.
"La première sécurité est la liberté"
[^] # Re: Changements ?
Posté par ʭ ☯ . Évalué à 8.
Mantle va disparaître, parce qu'il a tout simplement servi de brouillon pour Vulkan, auquel AMD participe énormément.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Vraiment un remplacent ?
Posté par Mimoza . Évalué à 4.
En lisant en diagonales les informations et commentaires j'ai plus l'impression que c'est un autre concept qu'un véritable remplacent.
On laisse l'appli gérer bien plus de chose pour en tirer de meilleur performances. Alors que OpenGL est là pour simplifier la vie du développeur en lui gérant un maximum de choses.
[^] # Re: Vraiment un remplacent ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 06 mars 2015 à 15:37.
C'était l'orientation au départ, mais ce n'est plus le cas depuis des années.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Vraiment un remplacent ?
Posté par Troy McClure (site web personnel) . Évalué à 9.
Pour avoir fait un peu d'opengl recemment c'est vraiment pas l'impression que ça m'a laissé ! Déjà toutes les parties "commodes" (mais je pense qu'il faut le dire vite) sont maintenant obsoletes, et ce qui reste c'est une api minimale et autiste, qui est à peu près aussi préatique à utiliser qu'un skateboard avec une seule roue. Tout est difficile, tout est rébarbatif, les messages d'erreur se limitent grosso modo à un laconique "fuck you", c'est vraiment un plaisir à debuguer. Quand j'utilise opengl j'ai l'impression de mâcher du sable.
# Mon analyse.
Posté par GaMa (site web personnel) . Évalué à 10.
Sommaire
Ce journal fait un peu office de journal bookmark, mais je viens de me taper la vidéo d'annonce à la GDC donc voici ma première analyse.
TL;WR
Je viens de finir mon commentaire … et c'est long.
Pour les fainéants : C'est plus bas niveau => Ça à moins de fonctionnalités => C'est plus simple à implémenter => Ça fait des drivers plus performant => C'est cool.
Déjà quelques liens (comme si il n'y en avait pas assez)
À noter que tout cela est très récent. L'annonce à été faite à la GDC (Game Developer Conference) qui n'est toujours pas finie. Les spec de spir-v datent du 2 mars et celles de vulkan ne sont pas encore sorties.
Je parle donc un peu sur le vide. Faudra attendre de voir ce que Khronos va vraiment nous sortir et comment la communauté va adhérer à la techno.
Je décline toute responsabilité si mes prophéties ne se réalise pas :)
Pas de fonctionnalité avancées
Premièrement, Vulkan est très bas niveau. Si vous avez jamais fait d'OpenGL, vous me direz qu'OpenGL l'est aussi. Et je vous répondrai que non. OpenGL arrive avec pas mal de pipeline déjà en place. Le core d'OpenGL3 en a bien moins que les premières versions, mais il en a quand même. Par exemple, le vertex shader, c'est assez libre sur ce qu'il prend en entrée, mais il DOIT prendre au moins un jeu de coordonnées pour chaque vertex, et il DOIT retourné des coord transformées (qui seront obligatoirement traitées par le fragment shader).
Certes OpenGL4 rajoute d'autres types de shaders (geometric shader) mais on reste avec 3/4 types de shader qui traitent les données en séquences. Et comme on veut pas obligatoirement faire des trucs en séquences et qu'on veut quand même utiliser la puissance des gpu, ça donne des trucs assez horrible comme la première page des spec Opengl4.5 (et encore, c'est que le core profile…)
Tout ça pose pas mal de problèmes :
- Les dev veulent plus de contrôles, pour faire des trucs encore plus fou.
- Fournir des fonctionnalités haut-niveau, c'est plus de boulot et c'est du boulot à faire dans les drivers (et de mon avis, ça n'a rien à faire là)
- Ça rajoute aussi de l'overhead. Par exemple la gestion d'erreur : le drivers doit vérifier que les données qu'il manipule sont valide. Hors 99% du temps, on sait qu'elles sont valides (on passe par un moteur 3D qui travaille dans un spectre restreint et validé)
Vulkan prend le parti de revenir à zéro. Il y a aucun état global, aucun pipeline près configurée, pas d'allocation mémoire, pas (moins ?) de gestion d'erreur, …
C'est à l'utilisateur (du driver, donc le dev de l'appli) de définir sa propre pipeline. Quel est le jeu de données en entrée. Quels sont les shaders à appliquer, dans quel ordre et comment les combiner. Quand afficher le buffer.
Ça peut être vu comme plus de travail déporté sur l'appli mais je suis pas sur. Les dev de jeux vidéo passe déjà pas mal de temps à trouver des astuces pour sortir du cadre d'OpenGL. Là ils sont libres, ils font ce qu'ils veulent du hardware.
Après, niveau des shaders, ben on n'en a plus (Ou du moins, c'est plus dans le scope). Vulkan prend du SPIR-V comme code à charger dans le GPU (SPIR-V ayant été développer pour OpenCL à la base). SPIR-V est du bytecode, machine indépendant.
Qui dit plus de shader, dit plus de compilation (dans le drivers). Là aussi moins de boulot pour les drivers.
Et perf ça donne quoi
Vous vous douter bien que c'est mieux. Sinon ça sortirait pas :)
Mais en gros, les implémentations "Work in progress" et les démo montrent un gain assez impressionnant :
- Traduction bourrine opengl=>vulkan : 79% de cycle CPU en moins dans le driver !
- En ayant une architecture multithread vulkan par rapport à monothread opengl (le multithread opengl n'étant pas possible), on à des démo qui tourne plus vite, qui consomme moitié moins niveau GPU et beaucoup moins niveau CPU (je serai pas plus précis, les petits graph ne sont pas très lisible sur la vidéo :) )
Et le libre, bonne ou mauvaise nouvelle ?
Pour moi, c'est clairement une bonne nouvelle.
Les dernières architectures des drivers libres (type Gallium) se basent déjà sur l'idée d'une compilation des shaders en une représentation interne indépendante (en utilisant LLVM). Les drivers spécifiques ayant pour charge de faire tourner cette représentation sur le GPU. Avec Vulkan, c'est une grosse partie des drivers à ne plus implémenter. On prend juste du SPIR-V et on l'envoie sur le GPU. Et il y a fort à parier que dans le futur, le GPU sache directement exécuter du SPIR-V, donc.. quasiment rien à faire (Enfin, bon, il y aura quand même du boulot hein :) )
Moins de travail à faire aussi sur l'allocation de mémoire. C'est à l'appli de le gérer et elle va utiliser les mécanismes déjà en place dans le kernel pour ça.
Le fait qu'il y ai moins de travail à faire, remet aussi les drivers libre dans la course niveau performance. À ma connaissance (et là je suis pas le mieux placé), le gros bottleneck niveau perf dans le drivers, c'est justement la compilation des shaders et la gestion de la mémoire. Là, c'est reporté sur l'appli donc toutes les plateformes se retrouvent "au même niveau".
Niveau API, c'est plus bas niveau, donc c'est plus compliqué. C'est mieux pour les gros dev de jeux vidéo. Pour les "petits dev", je pense que c'est pas trop un pb puisque opengl va continuer d'exister. Il pourrait même "juste" devenir une "simple" bibliothèque basée sur Vulkan et qui s'occupe de compiler du shader et configurer des pipelines.
My 2 cents.
Matthieu Gautier|irc:starmad
[^] # Re: Mon analyse.
Posté par Aissen . Évalué à 3.
Excellente analyse, merci. Juste un point de détail:
Plus exactement, on l’envoie au driver, qui va ensuite traduire (i.e. compiler) le SPIR-V en bytecode GPU.
Effectivement, c’est une possibilité, mais j’en doute vu les investissements lourds pour faire une architecture GPU. On verra !
[^] # Re: Mon analyse.
Posté par glisse . Évalué à 10.
Non les GPU n'implementeront pas SPIR-V tout simplement parceque SPIR-V n'est pas un byte code mais un "intermediate representation langage". Alors a moins d'implementer un compilateur dans le GPU ca ne passera pas. Et comme implementer un compilateur en hard pour ce type de représentation c'est juste une idée complétement loufoque bah conclusion non aucun hardware ne comprendra nativement SPIR-V.
Après je reviens sur les erreurs de GaMa
Vulkan a un pipeline tout comme OpenGL 4. On a donc soit :
1 - (GL2) vertex -> pixel shader
2 - (GL3.1) vertex -> geometry -> pixel shader
3 - (GL4) vertex -> tesselation control -> tesselation evaluation -> geometry -> pixel shader
Vulkan permet aussi d'utiliser des computes shader (aussi disponible dans GL4) dans ce cas il n'y pas de pipeline comme pour les graphics shader.
Au final la manière de faire le rendu sous Vulkan ou sous OpenGL est la même, les deux reposes sur les mêmes principes, les GPU sont toujours conçus de la même manière.
Vulkan c'est avant tout une autre manière de programmer les GPUs. La grosse différence entre Vulkan et OpenGL c'est le context, dans OpenGL le context GL est implicite, à chaque appel de fonctions le libGL utilise un local thread storage pour savoir contre qu'elle context GL la fonction à lieux. Dans OpenGL on peut toujours modifier l'ensemble des paramêtres de pile de rendu.
Dans Vulkan au contraire, tout est explicite, à chaque appel de fonctions Vulkan l'application doit donner explicitement l'objet contre lequel le driver doit opérer. De plus Vulkan favorise les objets constant, ie dont les propriétés sont définis une seul fois à la création de l'objet et ne peuvent jamais changer mais le contenu oui (par exemple une texture on définis une seul fois ses dimensions mais on peut redéfinir ad-vitam-eternam sont contenue ie les pixels).
Cela est beaucoup plus adapté à la manière dont fonctionne les moteurs de jeux vidéos. En général il utilise un nombre limité d'états qu'il est facile de créer une fois pour toute avec Vulkan et de réutiliser plusieurs fois en changeant juste le contenue entre les différentes frames. Là où pour OpenGL chaque changement d'état implique que le driver doit revalider l'ensemble de tous les états avant de pouvoir soummettre un rendu. Au contraire avec Vulkan une fois les différent états crée on peut les réutiliser et changer entre eux sans que le driver n'est besoins de revérifier quoi que ce soit.
Pour le reste, tu ne te trompes pas, c'est bien l'application qui va gérer elle même la mémoire.
[^] # Re: Mon analyse.
Posté par reynum (site web personnel) . Évalué à 2.
Et les erreurs ?
kentoc'h mervel eget bezan saotred
[^] # Re: Mon analyse.
Posté par reynum (site web personnel) . Évalué à 3.
Je pense aussi que des api (moteurs) basés sur Vulkan vont apparaître avec pléthore de tutoriels pour développer plus facilement des applications.
kentoc'h mervel eget bezan saotred
# Des oh et des bah
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Une chose m'inquiète dans l'évolution d'OpenGL/Vulkan:
Si chaque appli a un accès très bas niveau et non contrôlé à ma carte graphique, j'ai peur pour les performances et la stabilité globale de ma machine.
Je le vois déjà aujourd'hui avec WebGL: ouvrir une page web qui fait du rendu 3D c'est jouer à la roulette russe sur beaucoup de PC.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des oh et des bah
Posté par GaMa (site web personnel) . Évalué à 0.
En quoi ça t’inquiète plus que les applis qui ont un accès directe à ton CPU et ta mémoire ?
Les segmentation fault, buffer overflow et autre boucles infinies existent déjà sans le GPU.
On arrive relativement bien à cloisonner (même si c'est pas parfait). Quand mon process plante, mon pc tourne toujours.
On devrait arriver à faire la même chose avec les applis qui utilise le GPU.
Matthieu Gautier|irc:starmad
[^] # Re: Des oh et des bah
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
A part sous Freedos, les applis n'ont plus d'accès direct à la mémoire ou au CPU dans les OS encore en vie.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des oh et des bah
Posté par GaMa (site web personnel) . Évalué à 2.
Oui, évidemment il y a plus d'accès direct de nos jours. Mais rien n'empêche de faire la même chose pour la mémoire graphique.
Il faudra attendre les spec de Vulkan pour en savoir plus, mais il y a déjà un mec qui parle de pagination pour l'allocation mémoire dans les questions/réponses à la fin de la présentation.
Les mecs sont pas des débutants et ils doivent avoir conscience que si ils veulent avoir la moindre chance que leur truc marche, il faut surtout pas qu'ils pètent les notions élémentaires de séparation des processus.
Matthieu Gautier|irc:starmad
[^] # Re: Des oh et des bah
Posté par Martin Peres (site web personnel) . Évalué à 4.
Aucun GPU actuel n'a pas de mémoire virtuelle pour les clients graphiques. Intel essaye encore de l'activer complètement par défaut mais on y arrive. Nouveau supporte ça depuis toujours (ou presque).
# Vulkan ça défonce de l'ours en barre !
Posté par vlamy (site web personnel) . Évalué à 10.
Heuu, juste pour dire que Vulkan : ça claque comme nom !
Les noms avec open, en plus de faire peur aux moldus (si il y a « open » dans le nom, c'est la version abandonnée d'un projet commercial), c'est tellement ordinaire.
Si ! C'est important !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.