Vulkan arrivera en 2016
Le projet prend un peu de retard pour assurer une meilleure bibliothèque
Le 2015-12-19 15:31:08, par LittleWhite, Responsable 2D/3D/Jeux
La bibliothèque était prévue pour l'année 2015, mais la fin de l'année arrivant, on pouvait facilement se douter que cela ne serait pas le cas. Les plus optimistes espéraient que la bibliothèque aurait été prévue en même temps que DirectX 12 et cela semblait logique : les deux bibliothèques (Direct3D 12 et Vulkan) ont les mêmes objectifs : réduire le surcoût côté CPU de la bibliothèque graphique, améliorer le support du multithread, donner plus de liberté et un meilleur contrôle aux développeurs.
Bien sûr, Vulkan n'est pas une exacte copie de Direct3D 12. En premier, la bibliothèque est multiplateforme, mais aussi un effort remarquable est réalisé pour proposer des applications de débogages ainsi qu'un support plus uniformes entre les constructeurs et les plateformes.
Sur le site officiel, un nouveau message s'est ajouté pour nous donner des nouvelles sur la bibliothèque : la spécification est prête ! Seules une finalisation et la résolution du cadre légal sont à faire. Les tests de conformité sont en cours de finalisation ! Les constructeurs préparent leur pilote. En réalité, il ne reste plus que le retour des constructeurs par rapport à l'implémentation et tout est bon. La spécification sera d'ailleurs publiée lorsque les pilotes seront conformes.
Le consortium travaille actuellement sur les SDK Windows, Linux et Android. Google s'intéresse énormément à cette nouvelle bibliothèque et aide à ce que le support pour les téléphones mobiles soit assuré.
Finalement, lors de la mise à disposition de Vulkan pour le grand public, il y aura des démonstrations et des séminaires organisés par Khronos au travers des différents événements de l'industrie (certainement GDC, SIGGRAPH...).
Donc, la sortie de Vulkan est très proche même si elle ne sera pas en 2015.
Votre opinion ?
Voir aussi
Présentation de Vulkan
Compte rendu sur Vulkan à la GDC 2015
Source
Site officiel
-
LittleWhiteResponsable 2D/3D/JeuxCompiler un code intermédiaire en code natif est bien plus simple et rapide que de compiler un code source (texte à la C ou autre) en natif. Notamment, le compilateur qui transforme le code source en code intermédiaire peut faire des simplifications, des pré traitement, des optimisations et je ne sais pas quoi d'autre et la dernière transformation (code intermédiaire vers code natif) en est nettement simplifiée et donc plus rapide.
Par rapport au code qui ne fait pas la même chose sur chaque plateforme, cela sera partiellement corrigé par le fait qu'il y a des tests de conformité, mais aussi par le fait que la spécification SPIR-V précise comment gérer le code intermédiaire. De plus, un compilateur standard sera fournit par Khronos.le 23/12/2015 à 20:17 -
jopopmkMembre expertle 19/01/2016 à 8:08
-
dragonjoker59Expert éminent séniorPlus vite! Plus vite!
J'ai vraiment hâte de pouvoir faire joujou avec!le 20/12/2015 à 0:14 -
dragonjoker59Expert éminent séniorAMD, toujours à la ramasse...le 19/01/2016 à 11:43
-
Ça c'est de la Newsle 20/12/2015 à 1:37
-
AiekickMembre extrêmement actifca va impacter le langage GLSL pour les shaders ?le 20/12/2015 à 13:11
-
dragonjoker59Expert éminent séniorC'est surtout que les shaders GLSL vont être d'abord passés en SPIR-V, si je ne me trompe pasle 20/12/2015 à 13:59
-
AiekickMembre extrêmement actifoui mais le SPIVR est une sorte de bytecode non ?le 22/12/2015 à 23:52
-
dragonjoker59Expert éminent séniorOui, une représentation intermédiaire standardisée.le 23/12/2015 à 0:53
-
AiekickMembre extrêmement actifmais si je comprend ce langage intermédiaire ne sera pas directement traduite en code asm GPU par le gpu?
ce sera encore le role du driver de "compiler" en code binaire GPU ?
Donc le porbleme de code qui ne fait pas la même chose sur toute les carte va encore ce poser ? ou vulkan résoud le problème ?le 23/12/2015 à 20:00