Découvrir Vulkan et son architecture

Designer une API bas niveau qui satisfasse les besoins des débutants est un contre sens.

Développer et comprendre tous ces concepts est un voyage long et ardu, ça semble inévitable.

Peut être je suis trop dans ma bulle et pardonnez le moi. Croyez que j'essaie toujours de faire de mon mieux pour que ce site héberge des ressources approprié pour les gens qui veulent débuter et progresser afin d'en devenir expert.
Pour Vulkan, la bibliothèque est aussi bas niveau que Direct3D 12. C'est même plus bas niveau que OpenGL. Je pense donc qu'il faudra comprendre le pipeline de la carte graphique (d'ailleurs, ce n'est pas le meilleure graphique ... ), comment on configure un rendu (ce qui rentre en action dans un rendu) pour mieux comprendre ce qu'apporte/permet Vulkan.
Si OpenGL n'est pas votre tasse de café, ou si ce que fait un GPU est obscure en tout point, alors Vulkan sera loin de vous intéresser ou encore, de parler à vous.

Pour les shaders, on peut trouver des tutoriels spécifiques (le premier que j'ai écrit et pas le mieux), qui ne nécessite presque pas de comprendre OpenGL et pas du tout Vulkan.

Il y a une série de vidéo que j'aurai voulu retranscrire, mais je n'ai jamais eu le temps de le faire (pour le moment).

Cette bibliothèque, aussi bien qu'elle soit est vraiment poussée. C'est comme si je parlais d'un outil de rotopo ultra avancé (enfin, je choisis surement mal mon exemple, je connais que trop peu ce milieu ). Sans base de 3D et d'utilisation du logiciel approprié, je risque de très mal m'en sortir avec.

Il ne faut pas confondre comprendre, voire même "appréhender" et utiliser ...
Je n'ai jamais dit que je voulais comprendre comment l'utiliser, je n'ai franchement pas que ça à faire au cas où certains croiraient que le graphisme c'est juste une grande poilade à kikooland ... (pour faire clair, chacun sa spécialité et j'ai déjà choisi la mienne).
Par contre un graphiste se doit de comprendre bien plus de choses qu'on pourrait le penser, aussi la vulgarisation est bien souvent insuffisante pour ces pauvres hères sans logique qui cherchent désespérément à saisir l'essence des choses sans devoir y passer des mois pour ne même pas connaître les bases.

Ce n'était sans doute pas clair quand j'ai posé ma question mais je répondais surtout au titre qui n'implique pas nécessairement une utilisation de ladite architecture.

Oui le travail nécessaire pour écrire des tutoriels facile d'accès est souvent sous-estimé . Et les gens qui pourraient les écrire n'ont pas forcément le temps ni l'envie. Après il faut aussi cerner la cible de ces tutoriels et l'intersection des gens qui veulent apprendre Vulkan pour développer dessus et celui des gens qui n'ont qu'une connaissance de base du matériel (et veulent rester à cette connaissance de base) est une petite cible. Il y a des articles pour le grand public dans la presse spécialisée mais ils n'abordent pas le côté technique ou de manière très survolée (en expliquant certains enjeux mais pas les trade-offs, le code à écrire etc).

Je comprends (enfin, car au premier message je n'avais pas compris) votre point de vue et en effet, la cible de cet article est mal définie.
Actuellement, nous avons deux (trois) articles sur Vulkan.

• La présentation (de haut niveau), de Vulkan ;
• et maintenant, les premier pas pour mieux comprendre l'architecture (la découverte, mais dans le sens, réelle découverte de ce qu'est Vulkan) (c'est cet article ).

Je tiens à rappeler que Vulkan est une bibliothèque (comme OpenGL). Du coup, la découverte de son fonctionnement, ou la découverte de ce que c'est vraiment, ne peut intéresser que les développeurs, je pense. Seule la présentation, qui explique son but, son objectif, ce que c'est sensé être. Je pense (j'espère) que cela donne assez de description (et assez vulgarisé) pour les non programmeurs, mais je ne vois pas l'intérêt d'aller plus loin (sauf si vous êtes programmeur).

En conclusion, il faut savoir ce qu'est Vulkan lorsque l'on en parle dans les milieux hype (la salle des devs quoi ). Savoir que c'est une nouvelle spécification/bibliothèque, pour "gérer" la carte graphique, tout comme OpenGL.

Pour être encore plus clair, ce que je veux dire c'est que je trouve dommage que tout reste trop élitiste, c'est plus un défaut conventionnel qu'un réel problème de temps de la part des initiés.
Il y a plein d'autres domaines comme ça qui sont très fermés à ceux qui n'ont pas des bases solides, le son par exemple (côté ingénieur son, pas compositeur), et sans doute bien d'autres. Et d'un autre côté il y a les explications vulgarisées qui ne sont même pas des explications, la plupart du temps juste de la régurgitation d'arguments marketing qui n'apportent rien et sont parfois même "fausses" (dans le sens où l'inexactitude est telle qu'on en perd le sens réel des composantes).
Mais je vois à votre attitude, je ne vous critique pas c'est une simple constatation, que le milieu va rester fermé pendant encore un long moment. Je ne suis pas un grand passionné de la mécanique interne des jolis shaders et de l'optimisation des performances mais je suis supposé m'y connaître bien plus qu'on ne le penserait. Je m'éparpille peut-être parce que tout cela est flou pour moi, mais il n'est pas rare de voir dans les offres d'emploi la demande de compétences en codage de shaders pour des infographistes. Sans compter que bien souvent (disons 50% des cas) quand il y a de la 3D, il y a un développeur qui va devoir en faire quelque chose après, ce qui nécessite que le graphiste soit un peu moins manche et visualise un peu mieux le "tout" de la chaîne de production. Plusieurs articles sont déjà sortis pour tenter de réduire le fossé entre développeurs et infographistes, dans un simple but de compréhension (et non pas que les compétences de l'un déborde sur l'autre). Ici je prends juste les devants en disant, apparemment de façon très malhabile ^^, que si jamais il vous arrivait de tomber sur un article explicatif relativement accessible pour un néophyte, sans tomber dans le piège de répéter de simples arguments vendeurs, qui est plus à but théorique que pratique, ça pourrait bien m'intéresser.

Mes excuses pour le débat stérile involontaire ^^.

(PS J'espère par contre que cette fois ce que je dis est moins flou oO, j'ai fait des efforts sur l'expression vous noterez).