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.
# Mon analyse.
Posté par GaMa (site web personnel) . En réponse au journal Vulkan le successeur d'OpenGL. É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