Discussion :

[LittleWhite]

Vulkan : premiers retours sur les bénéfices de la nouvelle bibliothèque


Dès les premières informations sur Vulkan, la bibliothèque avait été annoncée bénéfique pour les performances de rendu 3D (tout comme pour DirectX 12). Toutefois, après la publication de la première spécification de la bibliothèque, il fallait encore convaincre le public des apports de cette technologie et surtout, pourquoi cette bibliothèque était aussi intéressante pour les développeurs que pour les joueurs.
NVIDIA, tout en annonçant la nouvelle série de cartes graphiques (GeForce GTX 1070, GeForce GTX 1080) a aussi dévoilé une vidéo de gameplay du jeu DOOM (iD Software). Le jeu supporte Vulkan et sur la GTX 1080, le jeu maintient les 60 FPS aisément. Une fois la limitation de la fréquence de rafraîchissement enlevée, le jeu est monté à 150 FPS, avec des pics à 200 FPS et des baisses ne descendant pas en dessous de 120 FPS.

La version YouTube a été capturée avec une GeForce Titan X (et vous pouvez récupérer la vidéo sans compression ici)

La bibliothèque est aussi disponible sur les plateformes mobiles. Samsung avait déclaré prendre en charge Vulkan sur le Galaxy S7. On comprend facilement qu'une bibliothèque plus proche du matériel et donnant un meilleur contrôle aux développeurs sur le GPU, tout en réduisant le surcoût des vérifications effectuées par les pilotes OpenGL puisse être bénéfique pour dégager de la puissance brute et donc plus efficace dans les rendus, mais cet aspect est loin d'être primordial pour les plateformes mobiles. C'est au cours de la Samsung Developers Conference (SDC) que le constructeur a dévoilé un autre intérêt pour la bibliothèque.
En effet, Samsung a redéveloppé TouchWiz (le lanceur d'application) pour utiliser Vulkan. Dès les premiers essais, il a été noté que la nouvelle implémentation permettait de réduire la consommation électrique (gain de 6 % par rapport à la version OpenGL ES). En d'autres termes plus quantifiables, cela peut augmenter la charge de 40 minutes.

Vulkan est bien là et la bibliothèque apporte bien les avantages attendus.


Votre opinion

Étiez-vous convaincu, dès le début, des intérêts de Vulkan ? Pourquoi ?
Quelles sont les choses qu'il reste à faire pour améliorer les performances des jeux et des applications mobiles ?


Voir aussi

Les ressources Developpez.com sur Vulkan


Source

Android Central
Tom's hardware

[Dabou Master]

Moi j'en dis surtout que le nouveau Doom a fusionné avec les anciens Quake ... Sérieux le shotgun double canon avec visée laser, le plasma gun, le rail gun, le quad damage ... C'était dans Doom ça avant ? Et puis la façon de sauter partout comme un lièvre sous acides, y'a du Q3 dans l'air non ?

[Aiekick]

si je comprends bien, le speedup de vulkan se situe au niveau de la supression des check.
donc ca ce situe au niveau du driver. ca ne change rien pour tout ce qui est traité dans le gpu, je pense par exemple aux shaders ?

je me fait un editeur pour faire des shaders comme ceux de shadertoy mais offline et pas limité donc a opengl es ou webgl. est ce que vulkan, peut me permettre de faire tourner les shader avec un meilleur fps ?

[CrankFlash]

Oui, Vulkan, comme DX12 permettent de meilleurs perfs CPU. Au niveau GPU ya rien qui change.

[vampirella]

Il serait intéressant de noter que l'optimisation du compilateur de shader est encore dans les choux côté Vulkan : si certaines équipes de dév comme celles de Doom4 ou Dota2 puvent se permettre de dédier 2-3 dévs pour régler le souci, ce ne sera peut-être pas le cas pour toutes les boites.

En rapport : la comparaison sur Talos principle.

[math_lab]

Talos principle est un très mauvais exemple, les développeurs ont admis que le moteur n’était pas du tout optimisé pour vulkan et que c'est juste un portage rapide pour prouver que vulkan marche. Si le moteur est basé sur un modèle a la d3d11, faire un version vulkan/d3d12 sans une refonte complète du moteur n'apportera rien au niveau perfs. Si après on rajoute le fait que les drivers sont encore très jeunes, on arrive a des performances moindres. Il faut aussi savoir que les drivers de nvidia (et probablement amd) 'trichent' énormément et vont jusqu’à changer le renderer des jeux (shaders speciaux, formats differents, ordre d'execution différent) pour améliorer les performances (c'est pour ça qu'il y a toujours une grosse release de driver a la sortie d'un gros jeu). Il est donc fort probable qu'aucune de ces optimisations soient sur le driver vulkan.

J'avais vu une nouvelle analyse de Talos il y a quelque jours qui montrait que Vulkan était maintenant un poil plus rapide que les autres renderers, mais je me souviens plus du tout ou...

[LittleWhite]

Oui, Vulkan, comme DX12 permettent de meilleurs perfs CPU. Au niveau GPU ya rien qui change.

Il ne faut pas oublier que c'est le CPU qui, dernièrement, ralentit le GPU. D'une part, OpenGL n'est pas prévu pour une utilisation multithread, alors que c'est la norme sur nos machines actuelles. D'une autre part, c'est le CPU qui envoie les données à jour (modèles 3D, scène, et tout un tas de trucs mis à jour fréquemment) au GPU. Si le CPU peine à nourrir le GPU, alors le GPU est sous utilisé. C'est de cette problématique que Vulkan et Direct3D 12 sont sortis (et apportent la solution d'un meilleur contrôle du GPU (contrôle plus bas niveau) et une surcouche pilote moins lourde (car, il y avait de sérieux problème aussi à ce niveau là et pas que de perfs).

[Dabou Master]

Par rapport à ton message LittleWhite, j'en déduis qu'une application de modélisation 3D qui tourne sur OpenGL comme Blender aurait fort à gagner là dessus (après j'interprète peut-être mal).
J'imagine qu'un gros, très gros modèle 3D (disons au dessus de 2M de triangles) qu'on sculpte, avec une topologie dynamique en plus (au passage de la brosse on peut soit diminuer soit augmenter la concentration de triangles à un endroit donné), il doit y avoir énormément de données que le CPU a à envoyer au GPU. Or il s'avère que la plupart du temps le viewport semble bien plus malmener le CPU que le GPU, je me dis que c'est peut-être un goulot d'étranglement ?
Comme je pars peut-être dans un non-sens terrible, ma question serait :
à puissance CPU égale, vulkan apporte-t-il vraiment un plus non négligeable par rapport à OpenGL ?

Et pour les autres questions d'un type qui patauge complètement dans ce sujet habituellement :
- Est-ce que les logiciels de 3D sont un cas particulier ? (après tout le viewport a toujours un rendu vieillot par rapport aux jeux je ne comprends pas toujours pourquoi)
- Quand est-ce qu'OpenGL (ou dx) laisse place à "autre chose" ? (Dans le sens où j'imagine que quand on entre dans le renderer en "pré-calcul" on n'a plus vraiment affaire à ces bibliothèques ?)



PS. J'imagine que je suis pénible à tout rapporter à Blender ^^, mais pour ma défense j'essaie juste de comprendre pourquoi les développeurs semblent vouloir faire migrer des parties vers Vulkan (pareil ce que je dis n'a peut-être aucun sens et qu'on ne peut pas migrer des "parties") alors que j'avais cru (peut-être mal) comprendre que les bénéfices seraient quasi-inexistants pour ce logiciel, d'après des réponses à mes questions (peut-être mal posées ...) sur d'autres sujets parlant de Vulkan.

[foetus]

Regardes ici : Découvrir Vulkan et son architecture

En gros tu passes d'une pile d'instructions (machine à états globale) à un modèle où les développeurs se débrouillent avec la mémoire (avec un ensemble de tampons, de buffers et autres) et avec les synchronisations CPU-GPU.

[super_navide]

Hello je suis le développeur d'un moteur 3D donc je sais forcement de quoi je parle cf

L'apport de vulkan est surtout bien c'est vrai pour le multithread et surtout pour les compute shader et tous ce qui est calcul non lie directement a la 3D.
Mais c'est réellement pas indispensable avec l'augmentation du nombre de coeur sur les CPU tous les calculs de simulation physique et autre finiront par rivaliser en terme de performance avec les cartes graphique en plus il plus facile de développer des programme C++ sur le CPU que des shaders ... (qui sont des usine à gaz ).
Opengl bien maitrisé sera suffisant encore tres longtemps a encore beau jours devants lui.

La seul chose que serait efficace s'est de briser la barierre GPU et CPU et avoir un seul de type de processeur en quantité importante et non spécialisé.
Donc pour conclure Vulkan aurait pu être beaucoup mieux.... et OpenGL reste un standard eprouvé...

[math_lab]

Je pense pas que blender ait beaucoup a y gagner dans ce cas: envoyer de la géométrie au gpu, c'est pareil pour OpenGL et Vulkan. L’intérêt de Vulkan c'est pour tout ce qui est de paramétrer le rendu (quel objet afficher avec quel mode de rendu, avec quel paramètres), parce que le driver n'a plus a attendre le résultat de 40 commandes avant de pouvoir commencer a bosser (on envoi un gros buffer avec tout dedans, et on le réutilise d'une image a l'autre, donc le gros du travail n'est fait qu'une fois).

Dans cette vidéo on voit qu'Opengl s'en sort aussi bien que Vulkan jusqu’à ce que la camera recule et que le nombre d'objets augmente:

[vampirella]

l'augmentation du nombre de coeur sur les CPU tous les calculs de simulation physique et autre finiront par rivaliser en terme de performance avec les cartes graphique

Sans vouloir (trop) te vexer, ton argument contient autant de poids que l'affirmation
"Je vais garder un simple 'for each' pour calculer la suite '1+2+...+N' puisque la puissance de calcul va bien finir par augmenter, plutôt que d'optimiser par une formule mathématique bien connu qui est '(N*(N+1))/2' ".

Les paradigmes mathématiques ne sont pas les même selon si l'on considère des calculs généralistes, comme pour les CPU, de calculs matricielles, comme pour les GPU.

De toute façon, il était temps de faire évoluer OpenGL et Vulkan semble être le meilleur candidat sur le long terme. Je ne demande qu'à voir la solution finale pour l'optimisation des compilations des shaders, car si j'ai bien compris, Vulkan a décidé de laisser cette partie en dehors du moteur.

[super_navide]

Il n'y pas que problème de la puissance de calcul il y a aussi la maintenabilité et la facilité de développer.
Les shaders sont tres difficile a développer et l'absence de gestion librairie est un gros problème.
Il serait envisageable d'avoir des carte graphique entièrement programmable avec un niveau d'abstraction plus élevé.
genre que l'API texture2D(t , point ) soit une fonction développé dont le source peut etre modifié et présent dans une librairie.
L'idée c'est d'avoir un seul type de programme avec des entrée et des sorties sachant que la sortie peut être réinjecter dans un ou plusieurs programmes pour un traitement paralleles.
Les evolutions des shaders la syntax in/out , les computes shader , les geometries shader montre une certaine volonté d'allé vers un tel model.

Donc comme je le dis vulkan n'est pas terribles car il aurait mieux fallu de faire un bon mix openCL et openGL pour faire une librairie de calcul parallèle pour toute sorte de problème (3D physique etc ... )
Et de toute façon c'est ce qui arrivera des machines avec énormément de coeurs pour tout faire.

[LittleWhite]

Par rapport à ton message LittleWhite, j'en déduis qu'une application de modélisation 3D qui tourne sur OpenGL comme Blender aurait fort à gagner là dessus (après j'interprète peut-être mal).

Pas nécessairement et c'est une réflexion qui n'est pas aussi immédiate que cela.
Dans cette vidéo, il y a le schéma qu'il faut retenir absolument pour savoir dans quel cas il est bon d'utiliser Vulkan :


Ce qu'il faut bien comprendre (et le consortium le répète souvent) c'est que Vulkan n'est pas une solution miracle et que beaucoup de développeurs ne gagneront rien à l'utiliser. C'est moche à dire lorsque l'on essaie de défendre la bibliothèque, mais ceci est la réalité.

J'imagine qu'un gros, très gros modèle 3D (disons au dessus de 2M de triangles) qu'on sculpte, avec une topologie dynamique en plus (au passage de la brosse on peut soit diminuer soit augmenter la concentration de triangles à un endroit donné), il doit y avoir énormément de données que le CPU a à envoyer au GPU.

Oui et non. Il n'y a pas besoin d'envoyer l'intégralité du modèle en haute définition à chaque image/modification. Les jeux et les logiciels de ce genre sont optimisés avec des techniques du style : partitionnement de l'espace, frustrum culling ....
Comme toujours en informatique, on ne peux pas faire d'approximation sur ce qui prend ou pas du temps. Il faut étudier ce qui se passe (profiling) puis améliorer la chose. Seul un développeur de Blender pourrait nous en parler.

Or il s'avère que la plupart du temps le viewport semble bien plus malmener le CPU que le GPU, je me dis que c'est peut-être un goulot d'étranglement ?

Oui, cela peut malmener le CPU tout en étant non lié au rendu. Et dans ce cas, le GPU ne "sert" à rien. Par exemple, l'algorithme qui permet de modeler la forme est, disons, intensive côté CPU pour calculer les nouveaux points à afficher. Une fois le calcul fait, le GPU doit afficher. Mais tant que le calcul n'est pas fait, le GPU ne sert à rien et que ce soit OpenGL ou Vulkan, cela ne fait pas de différence, vu que c'est juste du calcul brut.
(J'ai un peu simplifié )

à puissance CPU égale, vulkan apporte-t-il vraiment un plus non négligeable par rapport à OpenGL ?

Oui, mais que dans un cas Que si le rendu est limité par le fait que le CPU met trop de temps à nourrir le GPU (mais dans le sens, il met trop de temps à nourrir et non à calculer les données).

Est-ce que les logiciels de 3D sont un cas particulier ? (après tout le viewport a toujours un rendu vieillot par rapport aux jeux je ne comprends pas toujours pourquoi)

Le besoin n'est pas le même que les jeux (et donc la problématique surement différente)

Quand est-ce qu'OpenGL (ou dx) laisse place à "autre chose" ? (Dans le sens où j'imagine que quand on entre dans le renderer en "pré-calcul" on n'a plus vraiment affaire à ces bibliothèques ?)

OpenGL et Direct3D n'ont pas à laisser place à autre chose. Ce sont des bibliothèques bas niveau pour effectuer un rendu. Après, s'il ne vous convient pas, c'est autre chose
Vous semblez plus vouloir quelque chose d'autre que la rasterization ?

[abriotde]

La seul chose que serait efficace s'est de briser la barrière GPU et CPU et avoir un seul de type de processeur en quantité importante et non spécialisé.

Ah oui, c'est sur avoir un seul processeur c'est plus simple, Avoir aussi un seul langage de programmation le Python;, Pourquoi on s'embêtte avec le C++ et pire le C l'assembleur... c'est trop compliquer....

Non mais sans rire il y a de grosses différence technique entre un CPU et un GPU et c'est n'est pas parce que l'un se rapproche de l'autre qu'ils peuvent fusionner. Si en théorie avec des processeur programmable ou pourrait (ce qui existe mais est bien plus complexe a programmé, coûte cher et est beaucoup moins rapide pour des instructions changeante)...