Le successeur d'OpenGL s'appelle Vulkan

Version imprimable

03/03/2015, 14h28
LittleWhite

Le successeur d'OpenGL s'appelle Vulkan
Le successeur d'OpenGL s'appelle Vulkan
Découvrez ce que sera la nouvelle bibliothèque de hautes performances pour les GPU

http://jeux.developpez.com/public/im...ulkan-logo.png

Au cours de la Game Developers Conference 2015 (GDC), Khronos a dévoilé le nom et le contenu de la nouvelle spécification pour les GPU, qui succédera OpenGL. Jusqu'à présent, on l'appelait GLNext, le nom définitif est Vulkan.

À l'instar de Mantle, Metal et Direct X 12, cette refonte complète de la spécification permet de réduire la dépendance du GPU avec le CPU. Pour cela, le pilote est allégé et la préparation des commandes GPU peut être multithreadée. De plus, les applications auront bien plus de contrôle sur le GPU, simplifiant ainsi le travail du pilote.

Une autre nouveauté est l'utilisation d'un langage intermédiaire pour les shaders (code exécuté sur le GPU). Ce langage intermédiaire n'est autre que SPIR, dont la spécification est aussi fournie par Khronos. C'est d'ailleurs cette même spécification qui sera utilisée dans OpenCL 2.1. L'utilisation d'un langage intermédiaire a plusieurs attraits :
- n'importe quel compilateur peut générer des programmes exécutables sur le GPU ;
- le pilote n'a plus besoin de gérer la compilation des shaders ;
- le code des shaders peut être caché.
En plus de cela, Khronos fournira des tests de conformité à la spécification et même une implémentation de base pour le compilateur de shaders.
Bien entendu, tout comme OpenGL, Vulkan sera compatible avec tous les systèmes d'exploitation et cela sera encore plus vrai que du temps d'OpenGL. En effet, la séparation OpenGL et OpenGL ES n'existera plus.

Les différents acteurs tels que AMD, ARM, Imagination Technologies, NVIDIA supportent et contribuent à la spécification de Vulkan. Actuellement, la spécification n'est disponible qu'en aperçu technologique, mais les premières implémentation et support devraient être disponibles au cours de l'année ainsi que la spécification finalisée.

Votre opinion

:fleche: Est-ce que cette spécification vous intéresse ? Pourquoi ?
:fleche: Allez-vous développer avec Vulkan dès que le support par les constructeurs sera disponible ?
:fleche: Pensez-vous que c'est une évolution notable ou craignez-vous que les problèmes qu'a eu OpenGL réapparaissent ?
:fleche: Aimez-vous le nom choisi ?

Source

Vulkan sur Khronos.org
03/03/2015, 14h53
Invité

Hello.

Citation:

Le successeur d'OpenGL s'appelle Vulkan

J'ai vu ça ce matin en apprenant la mort de Mantle.

Citation:

Aimez-vous le nom choisi ?

J'avais voté pour qu'il y ai le nom Open dans le nom, mais c'est pas grave. C'est bien sans aussi.
Cependant, Vulkan, je n'aime pas du tout.
04/03/2015, 10h42
seeme

Quand on voit la segmentation des API graphiques avec OES 2.0, 3.0, 3.1, OGL 3/4, DX11, DX12, Metal, Gnm, Gx..... ça commence à devenir un cauchemar de maintenir un moteur de rendu multi platform. Il y a des choses vraiment cool avec Vulkan:

- Une vision en pipeline
- Un langage de shader intermediaire (on va pouvoir générer/injecter directement dans le bytecode)
- Possibilité de créer ses propres layers de debug
- Un peu d'air frais sur le CPU

entre autres choses.
Vraiment hâte :D
04/03/2015, 11h42
Traroth2

Un hommage subtil à Leonard Nimoy ?
04/03/2015, 11h51
seeme

1 pièce(s) jointe(s)

Citation:

Envoyé par Traroth2

Un hommage subtil à Leonard Nimoy ?

Pièce jointe 170772
06/03/2015, 08h36
Invité

2 pièce(s) jointe(s)

Apparemment, non.

Selon Joshua Barczak (Civilization), le mot «Vulkan» (Volcan en français) correspond au fait qu'un volcan prend naissance lorsque le «manteau» (terrestre) brise la «croûte» (terrestre).

Le manteau (ici francisé) ou encore «Mantle» en anglais, correspond au nom de l'API de AMD qui a donné les bases à cette API (Vulkan). C'est donc en quelque sorte un clin d'œil à l'API d'AMD sans le nommé explicitement.
«OpenMantle» comme nom aurait fait beaucoup trop de pub pour AMD et ça n'aurait pas été juste pour Intel, Nvidia, Qualcomm et bien d'autre.

En tout cas, Mantle peut reposer en paix maintenant, ses gênes seront transmise via Vulkan.

Pièce jointe 170998 Pièce jointe 171000
09/03/2015, 13h31
SkyZoThreaD

Je ne suis pas fan du nom mais on s'en contrefout ! Enfin un successeur à OpenGL qui promet de faire bouger les choses !
Car ne nous voilons pas la face: OpenGL n'arrivait pas à suivre les performances de DX. Peut-être que les besoins de garder la rétro-compatibilité bloquaient l'évolution de l'architecture de l'API, mais avec une nouvelle API, plus de contraintes. Le fait que Valve s'implique autant est un très bon signe aussi car ils sont de loin les leaders du jeux sous Linux et ont un talent certain. Bref, dès la dispo, je m'y mets ! Source2, Unity ou l'API en directe, Je suis vraiment impatient de voir tourner ça :D
10/03/2015, 18h55
LittleWhite

Vous pouvez retrouver toutes les informations sur Vulkan dans cet article. J'y ai notamment fait un rapide historique pour comprendre les raisons de la création de Vulkan. Aussi, vous pouvez découvrir les premières expérimentations de Valve et Imagination Technologies sur la bibliothèque.

Lire l'article sur Vulkan
19/03/2015, 08h57
GPPro

Juste un bémol, j'ai lu quelque part (par contre je ne sais plus où, désolé :oops:) que pour le moment que la quantité de code "boilerplate" (i.e. des lignes superflues dues uniquement à des initialisations, préparations d'envois, etc.) était plutôt impressionnant...

Par exemple ici

Citation:

- About 600 lines of code are needed to write a basic triangle program in Vulkan. However, much of that line count will be boiler-plate code that can be re-used or setup for the programmer by various libraries.

Donc probablement qu'il va falloir patienter quelques temps avant d'avoir quelque chose de vraiment abouti...
19/03/2015, 09h21
LittleWhite

Oui, c'est ce qui a été dit dans les questions à la fin de cette présentation : http://vulkan.developpez.com/videos/GDC/2015/
On voit aussi, dans les exemples de code, qu'il y a pas mal de travail de préparation.

Mais au final, déjà avec l'OpenGL moderne, il fallait beaucoup de code, aussi avec DirectX.
De plus, celui qui répond à la fin, dit : oui, mais ce sont 600 lignes qui font déjà beaucoup de choses et gère beaucoup de chose. Dans l'idée, il souhaite dire : "Oui, mais voilà, ce sont les 600 lignes de base d'un moteur, et non juste du HelloWorld".
10/04/2015, 17h04
kkim01

WebGL et Vulkan

Salut. Je m'inquiète un peu, moi qui commence à peine le développement avec Webgl. Sachant que webgl est basé sur la spécification ES de OpenGL, est-ce que l'abandon de cette API au profit de Vulkan ne va pas remettre en cause les acquis avec webgl ? J'avoue que je ne sais pas encore jusqu'à quel point se situe la rupture entre les deux API. Le WebGL va-t-il continuer son développement en s'appuyant sur Vulkan ?
10/04/2015, 18h25
LittleWhite

Les acquis, non. Ce qui est appris avec OpenGL sera et est toujours utile.
De plus, OpenGL n'est pas abandonné. Il sera toujours supporté, certainement grâce à une sorte d'implémentation recouvrant Vulkan.
13/04/2015, 18h46
LeGreg

Citation:

Envoyé par kkim01

Salut. Je m'inquiète un peu, moi qui commence à peine le développement avec Webgl. Sachant que webgl est basé sur la spécification ES de OpenGL, est-ce que l'abandon de cette API au profit de Vulkan ne va pas remettre en cause les acquis avec webgl ?

C'est toujours une question délicate. En pratique, les techniques évoluent en permanence et en tant qu'ingénieur informatique il est nécessaire de toujours se maintenir à niveau tout en gardant en tête que les choses ne deviennent pas soudainement obsolètes. Après le degré d'implication dépend des projets sur lesquels tu travailles plus que de l'actualité des constructeurs.

Les nouveautés apportées par Vulkan (et D3D12) sont surtout sur la nécessité de paralléliser son code (si l'on veut en tirer parti, puisque si l'on n'a pas de problème de performance rien n’empêche d'écrire du code sériel). Ainsi que la nécessité de prendre en main soi-même sa gestion mémoire et les gestion des hazards (liés à la concurrence des accès à l'intérieur du GPU et gestion des caches.. de manière abstraite bien entendu). L'approche webgl ne semble pas aller dans cette direction (privilégie la portabilité sur la performance), mais je peux me tromper. Quelqu'un va peut-être écrire une surcouche webgl par dessus une nouvelle API, qui sait.
Il n'y aura pas forcément de changement de paradigme en terme d'algorithmes de rendu (calculs d'éclairage, gestion des modèles 3D, animations, matériaux, niveaux de détails) par rapport aux précédentes APIs.