Qu'est-ce que Vulkan et en quoi diffère-t-il d'OpenGL?

Le groupe Khronos (l'organisme de normalisation derrière OpenGL) vient d'annoncer Vulkan :

Vulkan est la nouvelle génération d'API standard ouverte pour un accès très efficace aux graphiques et au calcul sur des GPU modernes. Cette conception inédite, précédemment appelée Initiative OpenGL de nouvelle génération, permet aux applications de contrôler directement l'accélération du processeur graphique pour optimiser les performances et la prévisibilité.

Leur page est assez marchande / jargon lourd, comme le communiqué de presse … En termes simples, que signifie Vulkan pour les développeurs de jeux? (Gabe Newell est cité comme étant fortement en faveur, sans autre explication.)

Quelle est exactement la relation entre Vulkan et OpenGL? Son ancien nom "glNext" (abréviation de "Next Generation OpenGL Initiative") lui donne l’impression de le remplacer.

Mise à jour: La spécification Vulkan 1.0 a été publiée le 16-02-2016.

Vulkan est une nouvelle API pour les graphismes à accélération matérielle (et le calcul général) via des GPU classiques. OpenGL continuera d'être développé, car il s'agit d'une API de niveau supérieur à celle que Vulkan est censée être. A l'origine appelé "glNext", on peut en déduire que Vulkan allait probablement devenir "OpenGL 5", mais que l'organisme de normalisation a finalement décidé qu'un nouveau nom coïnciderait mieux avec la rupture relativement nette que l'API prétend apporter aux systèmes existants. Paradigmes OpenGL.

Les avantages pratiques de Vulkan pour les développeurs de jeux sont principalement liés au contrôle (en permettant davantage, permettant potentiellement de meilleures optimisations au prix de beaucoup plus de travail en amont de la part du développeur). Plus précisément:

• L'API s'articule autour de la génération asynchrone de mémoires tampon de commandes sur plusieurs threads et du traitement séquentiel de ces mémoires tampons vers un pipeline de commandes. Cela reflète les réalités du matériel moderne. La plupart des logiciels haut de gamme et / ou hautes performances basés sur OpenGL appliquent aujourd'hui ce type de comportement. le fait que l'API prenne en charge cette fonctionnalité signifie en soi que les développeurs n'ont pas besoin de mettre en œuvre et de gérer ce framework eux-mêmes, ou qu'ils peuvent le faire avec moins d'effort.
• Les tâches de gestion des threads et de la mémoire sont laissées à l'application, et non au pilote, ce qui permet aux développeurs de jeux de mieux contrôler ces comportements et donc de les adapter plus précisément aux besoins de leurs jeux respectifs.
• Les couches de validation et de diagnostic peuvent être activées indépendamment, ce qui permet théoriquement une meilleure intégration des outils dans l'API (quelque chose dont OpenGL a été victime) et la désactivation d'une validation excessive, permettant en théorie à " les graphiques de niveau trois " d'être encore plus performants.
• Il n'y a pas de différence API matérielle entre les versions mobile et de bureau, ce qui facilitera théoriquement le portage de jeux multi-plateformes et, si rien d'autre, ne réduit les problèmes de vérification de version que tout le monde déteste.

La structure superficielle de Vulkan est très semblable à celle du C / OpenGL (l'apparence des appels d'API, etc.). Elle est toutefois mieux typée (en ce sens que tout n'est pas nu int; il y a des typedefs pertinents, etc.).

Il est beaucoup plus bas que OpenGL. On peut s'attendre à un saut dans la configuration opérationnelle et la complexité entre OpenGL et Vulkan, comme cela a été observé dans la transition D3D9 à D3D10, qui a exposé beaucoup plus de détails cachés du fonctionnement du périphérique GPU au client API. En réalité, la transition s'apparente davantage à celle de D3D11 à 12, car D3D12 est en soi une API très similaire à Vulkan, en ce qui concerne les capacités.

Pour élaborer sur l'avenir d'OpenGL:

OpenGL pourrait atteindre des performances comparables à celles de Vulkan, en appels d’appel par seconde, mais également en ce qui concerne les frais généraux des pilotes:

• Les extensions OpenGL les plus récentes suppriment beaucoup de temps système en rendant tout ce qui est sans liaison (par exemple, ARB_direct_state_access (4.5 core)ARB_bindless_texture ...).
• Avec mappage persistant (ARB_buffer_storage noyau dans 4.4), la CPU peut accéder directement à la mémoire tampon. La synchronisation avec le GPU est également explicite, tout comme Vulkan.
• Des extensions futures telles que NV_command_list(voir la présentation de Tristan Lorach sur Siggraph Asia 2014 ) fourniront probablement à OpenGL le même "paradigme d'alimentation par GPU" que Vulkan.

Khronos a récemment annoncé la publication de la toute nouvelle API Vulkan, qui viendra compléter (et dans certains cas, remplacer) OpenGL et OpenGL ES. Vulkan est une API peu coûteuse conçue pour rapprocher le code du métal, en améliorant les performances et l'efficacité. Il est basé sur l'API Mantle d'AMD et la spécification finale est attendue plus tard cette année.

Dans cet article - Un bref aperçu de l'API Vulkan - Nermin Hajdarbegovic, rédacteur technique de Toptal, explique pourquoi Vulkan pourrait être une grosse affaire à long terme. Cela peut prendre un certain temps, mais cette API multiplate-forme pourrait considérablement améliorer les performances 3D de certains appareils, notamment les processeurs d'applications multicœurs utilisés dans des milliards de smartphones et de tablettes.