IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La spécification de Vulkan est disponible !
Le successeur d'OpenGL est disponible avec des outils et des exemples open source

Le , par LittleWhite
30 commentaires

60PARTAGES

8  1 
Cela fait plus d'une année que nous en parlions. Vulkan est enfin là. Vulkan est le successeur d'OpenGL, la spécification ouverte d'une bibliothèque pour les applications utilisant les ressources des cartes graphiques. Son but : repartir de zéro afin de se débarrasser de l'héritage d'OpenGL (créé il y a plus de 20 ans !). Ainsi, Vulkan propose une nouvelle bibliothèque :
  • plus légère ;
  • compatible avec les applications multithread ;
  • assure un comportement homogène des shaders et leur précompilation.



Le but est d'alléger l'utilisation du CPU et de permettre une meilleure utilisation du GPU. En effet, le CPU est souvent l'élément ralentissant le rendu, notamment car celui-ci ne peut pas communiquer avec le GPU en utilisant plusieurs fils. La raison est que le pilote n'expose pas assez d'éléments de la carte graphique, du coup, le pilote fait tout son possible pour assurer la cohérence des objets exposés. La méthode la plus simple est d'éviter que plusieurs fils interagissent avec les objets. Mais du coup, les CPU multicœurs sont sous-utilisés. La réponse qu'apporte Vulkan est d'exposer l'intégralité de la carte graphique et de permettre de les utiliser en parallèle. C'est au développeur de prendre ses précautions.
Une fois que tout se combine, il est possible d'accélérer le rendu.

Dès 2015, Developpez.com vous a proposé une introduction de la nouvelle spécification que vous pouvez consulter à tout moment.

Au jour de la sortie de la spécification, les constructeurs proposent dès à présent le support de Vulkan. Pour NVIDIA, les cartes
  • Quadro Series: Quadro M6000, Quadro M5000, Quadro M4000, Quadro K6000, Quadro K5200, Quadro K5000, Quadro K4000, Quadro K4200, Quadro K2200, Quadro K2000, Quadro K2000D, Quadro K1200, Quadro K620, Quadro K420 ;
  • Quadro Series (Notebooks): Quadro K5100M, Quadro K5000M, Quadro K4100M, Quadro K4000M, Quadro K3100M, Quadro K2200M, Quadro K2100M, Quadro K3000M, Quadro K2000M, Quadro K1100M, Quadro K1000M, Quadro K620M, Quadro K610M, Quadro K510M, Quadro K500M ;
  • GeForce 900 Series: GeForce GTX TITAN X, GeForce GTX 980 Ti, GeForce GTX 980, GeForce GTX 970, GeForce GTX 960, GeForce GTX 950 ;
  • GeForce 700 Series: GeForce GTX TITAN Z, GeForce GTX TITAN Black, GeForce GTX TITAN, GeForce GTX 780 Ti, GeForce GTX 780, GeForce GTX 770, GeForce GTX 760, GeForce GTX 760 Ti (OEM), GeForce GTX 750 Ti, GeForce GTX 750, GeForce GTX 745, GeForce GT 740, GeForce GT 730, GeForce GT 720, GeForce GT 710, GeForce GT 705 ;
  • GeForce 600 Series: GeForce GTX 690, GeForce GTX 680, GeForce GTX 670, GeForce GTX 660 Ti, GeForce GTX 660, GeForce GTX 650 Ti BOOST, GeForce GTX 650 Ti, GeForce GTX 650, GeForce GTX 645, GeForce GT 645, GeForce GT 640, GeForce GT 630
sont supportées.
Pour AMD :
  • AMD Radeon™ R9 Series graphics ;
  • AMD Radeon™ R7 Series graphics ;
  • AMD Radeon™ R5 240 graphics ;
  • AMD Radeon™ HD 8000 Series graphics pour les systèmes OEM (HD 8570 et supérieur) ;
  • AMD Radeon™ HD 8000M Series graphics pour notebooks ;
  • AMD Radeon™ HD 7000 Series graphics (HD 7730 et supérieur) ;
  • AMD Radeon™ HD 7000M Series graphics pour notebooks (HD 7730M et supérieur) ;
  • AMD A4/A6/A8/A10-7000 Series APUs (nom de code “Kaveri”) ;
  • AMD A6/A8/A10 PRO-7000 Series APUs (nom de code “Kaveri”) ;
  • AMD A6/A8/A10/FX™ 8000 Series APUs (nom de code “Carrizo”) ;
  • AMD E1/A4/A10 Micro-6000 Series APUs (nom de code “Mullins”) ;
  • AMD E1/E2/A4/A6/A8-6000 Series APUs (nom de code “Beema”) ;
  • AMD A4-1200, A4-1300 et A6-1400 Series APUs (nom de code “Temash”) ;
  • AMD E1-2000, E2-3000, A4-5000, A6-5000, et A4 Pro-3000 Series APUs (nom de code “Kabini”).

De même, Intel, Imagination Technologies, Qualcomm ont leur solution.

Mais ce n'est pas tout. Vous pouvez accéder à des exemples et des démonstrations :


En résumé, tout est prévu pour démarrer tout de suite. Vous pouvez consulter la spécification sur le site officiel, la documentation de toutes les fonctions, en ligne et un aide-mémoire.

Votre opinion

Aimez-vous la spécification ?
Pensez-vous que la bibliothèque est facile à utiliser ? Avez-vous déjà eu l'occasion de l'utiliser ?
Croyez-vous que Vulkan est au même niveau que Direct3D 12 ?

Ressources

Les ressources Developpez.com sur Vulkan
Connectez-vous au flux RSS de la rubrique 2D/3D/Jeux, de nouvelles ressources sont en préparation !

Source

Site officiel Khronos

Une erreur dans cette actualité ? Signalez-nous-la !

30 commentaires
Commenter Signaler un problème
Avatar de
https://www.developpez.com
Le 16/02/2016 à 20:32
Citation Envoyé par Aurelien Plazzotta Voir le message
Le titre est erroné comme à chaque fois que LittleWhite utilise Google Translate au lieu d'apprendre l'anglais; ça devient vraiment pénible.
Tu devrais peut-être faire le boulot à sa place au lieu de critiquer alors.

Pour en revenir à Vulkan, tout le monde semble présenter cela comme la nouvelle merveille du monde mais pour les développeurs c'est un retour en arrière avec une API plus bas-niveau qui va donc demander plus de travail. Avec un peu de chance, on va voir apparaitre des bibliothèques pour corriger ce problème mais ça risque de prendre encore du temps avant qu'on ait un écosystème satisfaisant pour cette technologie.
7  1 
Mc geek
Avatar de Mc geek
Membre habitué https://www.developpez.com
Le 16/02/2016 à 21:21
Citation Envoyé par groharpon42 Voir le message

Pour en revenir à Vulkan, tout le monde semble présenter cela comme la nouvelle merveille du monde mais pour les développeurs c'est un retour en arrière avec une API plus bas-niveau qui va donc demander plus de travail. Avec un peu de chance, on va voir apparaitre des bibliothèques pour corriger ce problème mais ça risque de prendre encore du temps avant qu'on ait un écosystème satisfaisant pour cette technologie.
Et c'est le but de Vulkan justement : proposer une API bas-niveau alternative à DirectX pour permettre de mieux exploiter les capacités de la machine en étant plus proche du matériel, quitte à perdre en facilité d'écriture.
4  0 
seeme
Avatar de seeme
Membre éclairé https://www.developpez.com
Le 17/02/2016 à 15:09
My two cents sur Vulkan.
(Background: programmeur rendu bas niveau dans l'industrie du jeu vidéo).

Vulkan est une autre API, ni plus ni moins. Elle se pose en concurrence avec DX12, Metal, OpenGl, openGl es... .

Pourquoi Vulkan a été démarré?
OpenGL propose une API assez haut niveau et gère beaucoup de choses en arrière plan pour le programmeur. OpenGL va vérifier que tout est cohérent au fur et à mesure. Ce n'est plus acceptable en terme de performance. Le moteur de rendu fini par utiliser beaucoup de CPU pour vérifier et corriger à la volée des erreurs du programmeur (et ça scale avec le nombre de drawcall typiquement).
Un autre soucis est le fait qu'avec le temps, l'API ne reflète plus vraiment la réalité des GPU modernes. Il y a beaucoup de choses qui sont laissées à la responsabilité du driver qui ne ressemble plus à grand chose.
De même, OpenGL n'est pas taillé à la base pour du multithread qui a explosé depuis la génération ps3.

Vulkan propose une alternative en prenant la forme d'une API explicite. C'est à la charge du programmeur de vérifier la cohérence et d'assurer la stabilité du système (fence mémoire, sémaphore pour la synchro CPU/GPU...). Vulkan casse aussi le support avec les anciennes API, ce qui devrait rendre les drivers beaucoup plus simples et efficaces.
Vulkan propose une approche similaire à DX12, Mantle et Metal (dans une moindre mesure) avec des commandEncoder qui écrivent dans un command buffer qui sera ensuite envoyé (kick) au GPU pour exécution.
C'est un modèle qui facilite le multithreading (au dépend d'une gestion des ressources plus complexe) qui existe depuis DX10 ou les API des consoles plus moderne (GNM, GNMX...).

Pour résumer, Vulkan a nettement moins d'overhead CPU et facilite le multithreading (je rentre pas dans le détail, mais il y a aussi des avantages à SPIR-V et à la couche de validation customisable) au prix d'une gestion plus complexe de la mémoire et d'une difficulté de programmation généralement plus élevée (vs opengl).

Même si je pense qu'OpenGL est voué à mourir lentement, il n'est pas pertinent de passer à Vulkan (tout comme c'était le cas pour Metal il y a deux ans) pour 90% des gens.
C'est surtout taillé pour le jeu et les application qui poussent le CPU. Pour la plupart des gens/entreprise, ça représente un coût non négligeable pour très peu de gain.

Du coup, si votre application est GPU bound ou si globalement votre rendu ne bouffe pas trop votre CPU, ne perdez pas de temps sur Vulkan.
Si vous développez un jeu et que l'utilisation CPU est critique (beaucoup de draw call typiquement), ça vaut le coup.
4  0 
codec_abc
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 16/02/2016 à 21:30
Citation Envoyé par Aurelien Plazzotta Voir le message
Bonjour,

Le titre est erroné comme à chaque fois que LittleWhite utilise Google Translate au lieu d'apprendre l'anglais; ça devient vraiment pénible.

Vulkan n'est pas le successeur mais une alternative à OpenGL car c'est une marque déposée. Le "tm" pour Trade Mark indique que le format est propriétaire. Il y aura donc une licence à payer pour ceux qui veulent commercialiser des applications graphiques en utilisant Vulkan.

Pour l'anecdote, OpenGL était hybride, un mélange de licence open source BSD et de licence propriétaire (source : http://www.sgi.com/tech/opengl/?/license.html).

A noter que les pilotes Vulkan pour chipsets graphiques AMD sont en bêta et compatibles Windows uniquement ( source : http://support.amd.com/en-us/kb-arti...lkan-Beta.aspx).
Je suis assez prompt à signaler aux rédacteurs quand ils se trompent mais sur ce coup il n'y a pas grand chose à redire. Alors, oui officiellement Vulkan est une alternative à OpenGL mais dans les faits c'est plutôt son successeur car :
  • C'est fait par le Khronos group qui se charge d'OpenGL. Or pourquoi il ferai une nouvelle spec si l'ancienne n'était pas d'une certaine façon obsolète ?
  • OpenGL ne permettait pas de répondre de façon satisfaisante à la programmation parallèle. Or le besoin se fait de plus en plus ressentir sur les grosses applications.


Ensuite, je veux bien que tu me cites une source qui dit qu'il y aura des licences à payer pour faire une application qui utilise l'API vulcan. Le trademark s'applique sur le logo et la spec. Ça m'étonnerai qu'il porte sur autre chose.
Enfin, parler d'open source avec OpenGL n'a pas vraiment de sens puisque OpenGL est une API et c'est les fabricants de hardware qui doivent implémenter l'interface (ce qui se traduit par l'écriture de drivers). Après certains sont open source (comme ceux d'Intel) et d'autres sont fermés (ceux d'AMD par exemple).
4  1 
dancingmad
Avatar de dancingmad
Membre confirmé https://www.developpez.com
Le 18/02/2016 à 15:49
Vulkan ça va surtout servir aux grosses boîtes qui font des AAA et aux développeurs de moteurs. En effet, avec OpenGL et DirectX, c'est très difficile de tirer le meilleur parti des cartes graphiques car ces API font tout un tas de choses pour essayer de simplifier et de prédire ce qu'on veut afficher. Et ce n'est pas qu'un problème d'overhead CPU: lorsqu'on développe un gros jeu ou un moteur, le seul moyen pour pousser la carte graphique dans ses retranchements est d'utiliser des extensions non standard des drivers, voir même de demander aux constructeurs de développer des features juste pour un jeu. Du coup les drivers deviennent de plus en plus compliqué, ce sont des usines à gaz qui contiennent du code spécifique juste pour certains jeux, avec des branchements en dur dans le code :

Code : Sélectionner tout 
1
2
3
4
if (nomDuJeu == "Super Conflit Armé 3")
{
    // tout plein de code non standard
}
Cette pratique est très compliquée à mettre en place, autant pour le constructeurs que pour le développeur (rappelez-vous du lancement catastrophique de Rage, les gens conseillaient d'utiliser une ancienne version du driver ou de renommer son .exe en 'Rage2.exe", justement pour éviter d'utiliser le code du driver spécifique), et donc les gens se sont mis à proposer la création d'une API bas niveau pour déporter le travail du constructeur vers le développeur: Vulkan. Cela a donc plusieurs avantages pour les devs:
- Ils n'ont plus besoin de demander aux constructeurs de faire des extensions, tous le pipeline est entièrement géré en interne
- Ils peuvent beaucoup plus facilement débugger leurs jeux. Un driver est une boîte noire, et trouver pourquoi un triangle ne s'affiche pas correctement peut demander des jours de debug. Avec Vulkan (et DX12), debugger la chaîne de rendu revient à débugger un programme classique puisque tout est fait explicitement dans le code du jeu.
- Ils gagnent en perf à cause de toutes les raisons évoqués plus haut (moins d'overhead, etc).

Evidemment pour un "petit" jeu qui n'est pas à la pointe de la techno, il est souvent inutile de quitter OpenGL.
3  0 
seeme
Avatar de seeme
Membre éclairé https://www.developpez.com
Le 17/02/2016 à 16:58
Il faut vraiment se poser la question en terme de performance CPU vs GPU.
En général, ce qui prend du CPU sur 3dsmax (je n'utilise que très rarement maya, mais ça doit être similaire), c'est des calculs de topologie et du setup de scène. En gros Vulkan est là pour les scènes qui affichent beaucoup d'objets (c'est pour ça que la plupart des démos c'est des bancs de poissons ou des montagnes de nains de jardin...).
Je ne pense pas que ce soit le cas type des logiciels de CAO.

Je sais aussi que Dassault est dans la board, donc je suppose qu'il y a un intérêt.

Pour simplifier:
CPU bound (parce que beaucoup de draw call) => Vulkan c'est bien
Multi core pour du rendu (typiquement xeon octo core) => Vulkan c'est bien (si vous êtes pas déjà sur dx12)
Besoin de libérer du CPU pour faire autre chose (IA? Réseau? Gameplay? ...) => Vulkan c'est bien

Pour préciser ce que disait quelqu'un au dessus: pour être dans les discutions depuis pas mal de temps autour de l'élaboration de Vulkan, il n'est pas du tout dans les plans ou dans l’intérêt du moindre acteur Khronos de faire payer quoi que ce soit.
Le but c'est que tout le monde l'utilise.

Pour les fondeurs de cartes ou les devs de jeux, l’intérêt économique est évident: on pourra afficher plus de choses ou faire de la place pour faire des choses sur CPU => effet Wahou => $$$$
Il y a un petit intérêt multiplateforme (j'écris mon renderer une fois, il marche sur pc (AMD/Nvidia), mobile...), mais pour du AAA ça ne compte pas vraiment (le coup est minime).

Ce serait juste complètement anti économique (complètement con?) de faire payer quelque chose...

J'insiste vraiment:
Dans un cas général,
Vulkan n'apporte pas/peu de gain GPU!
2  0 
math_lab
Avatar de math_lab
Membre éprouvé https://www.developpez.com
Le 17/02/2016 à 18:35
Le probleme d'OpenGL c'est que les drivers sont generalement assez mauvais (ce qui est causé par le manque de jeux en GL, et du coup, cause aussi le manque de jeux GL...). Avec Vulkan, il y a une chance que les drivers soient un peu mieux puisque toutes les optimisations sont maintenant a la responsabilité du developpeur.
2  0 
seeme
Avatar de seeme
Membre éclairé https://www.developpez.com
Le 18/02/2016 à 12:31
Citation Envoyé par Dabou Master Voir le message
Du tout, et on ne me le rabâche pas personnellement, j'ai lu plusieurs fois des conversations qui faisaient état de ça.
Après je ne dis pas que j'ai forcément compris où ils voulaient en venir, je nage à mon niveau (c'est-à-dire la pataugeoire) pour essayer d'y voir un peu plus clair.
Faut aussi reconnaître que ce qu'on nous sort est souvent accompagné d'un argument marketing "tourne en dx12" sous-entendu que le framerate se trouvera amélioré (dans les jeux) et je n'ai jamais vu un argument "tourne sous openGL", alors je ne dis pas que je ne me fourvoie pas dans des conclusions grotesques mais un cheminement intellectuel a fini par se former malgré moi. Je ne suis pas fou, je ne suis pas le seul à avoir entendu dire qu'OpenGL est à la traîne si ? Que la tesselation n'est pas du tout au même niveau que celle de D3D etc.
Je n'ai aucune preuve ou quoi que ce soit de ce que j'avance, j'essaie juste d'être un peu moins paumé dans ce domaine, c'est juste pour mon enrichissement personnel, mais avec les détracteurs et les fans, c'est difficile d'avoir une idée objective de la situation.
Enfin bon, je vais arrêter de polluer le topic parce que ça pourrait bien finir en débat OpenGL vs D3D ^^.
D'après moi ça dépend déjà de la plate forme.
Sur mobile, c'est OGL ES, point. Metal est pas mal, mais à cause de la perte de perf dues à l'objectif C et vu que ça ne tourne que sur ios...
Sur PC, ça dépend. L'avantage de directx, c'est que c'est plus simple à faire marcher. C'est très bien intégré avec Windows et normalement quand un GPU te dis qu'il fait du "DX10", il fait tout ce qui est dans DX10 (après tu ne sais pas si c'est émulé ou si les perf seront là).
Sur console, ça dépend. Pour la génération précédente, OpenGL te permettait de faire directement PC, PS3, et Directx9 (bidouillé) pour la 360. Pour la wii c'est une autre API (GX je crois).
Pour la Ps4, c'est GNM/GNMX, pour la One, c'est DX11/DX12, pour la wiiU c'est GX2...

Il existe plein d'API. Elles sont plus ou moins simples, plus ou moins pratiques, mais au final, tout finit par marcher.

J'ai tendance à préférer DX parce que je déteste le système d'extensions d'OGL par exemple.
En terme de performance, il faut voir. Ca dépend des jeux, des GPU, des drivers...
2  0 
LittleWhite
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 16/02/2016 à 21:37
Citation Envoyé par sazearte Voir le message
Je pense que dans mon cas, ils vas falloir attendre quelques mois/années avant que mes bibliothèques (Panda3D, PyOpenCL...etc) soient compatibles.
Les développeurs de GLFW (une bibliothèque pour ouvrir une fenêtre et contexte OpenGL) commence déjà à avoir le support initial (commit GIT de ce soir, un peu après ou avant ma news).
Donc, je pense que cela sera plus une question de mois, pour les développeurs proche de ces technologies.

Parfois je fais des calcules sur gpu avec PyOpenCL, j'ai pas trop compris le problème de fil évoqué ?
Pour le calcul GPU, c'est pas le problème, car de mémoire, le calcul GPU n'est pas nourri par le CPU. Ce qui n'est pas le cas dans les programmes de rendu graphique. D'ailleurs, la suite de votre message donne argument à l'explication de la news.

EDIT : un petit outil en plus VulkanCapsViewer
1  0 
Avatar de
https://www.developpez.com
Le 17/02/2016 à 0:01
Citation Envoyé par Mc geek Voir le message
Et c'est le but de Vulkan justement : proposer une API bas-niveau alternative à DirectX pour permettre de mieux exploiter les capacités de la machine en étant plus proche du matériel, quitte à perdre en facilité d'écriture.

Oui mais la performance pure n'est pas toujours le critère principal. Quand j'ai besoin d'écrire une appli 3D toute simple, je me fiche pas mal d'avoir 400 fps au lieu de 200 (surtout quand c'est finalement synchronisé à 60 à l'écran); par contre, s'il me faut deux fois plus de temps pour l'écrire, ça devient gênant.

D'ailleurs, kronos conseille de continuer à utiliser OpenGL si on a plus besoin de facilité d'écriture que de performances. Cependant, je crains qu'à plus ou moins court terme les constructeurs ne développent plus du tout les drivers OpenGL; d'autant plus que les drivers Vulkan sont censés être beaucoup plus simples pour eux à écrire.
1  0 
Commenter Signaler un problème