Non les GPU n'implementeront pas SPIR-V tout simplement parceque SPIR-V n'est pas un byte code mais un "intermediate representation langage". Alors a moins d'implementer un compilateur dans le GPU ca ne passera pas. Et comme implementer un compilateur en hard pour ce type de représentation c'est juste une idée complétement loufoque bah conclusion non aucun hardware ne comprendra nativement SPIR-V.
Après je reviens sur les erreurs de GaMa
Vulkan a un pipeline tout comme OpenGL 4. On a donc soit :
1 - (GL2) vertex -> pixel shader
2 - (GL3.1) vertex -> geometry -> pixel shader
3 - (GL4) vertex -> tesselation control -> tesselation evaluation -> geometry -> pixel shader
Vulkan permet aussi d'utiliser des computes shader (aussi disponible dans GL4) dans ce cas il n'y pas de pipeline comme pour les graphics shader.
Au final la manière de faire le rendu sous Vulkan ou sous OpenGL est la même, les deux reposes sur les mêmes principes, les GPU sont toujours conçus de la même manière.
Vulkan c'est avant tout une autre manière de programmer les GPUs. La grosse différence entre Vulkan et OpenGL c'est le context, dans OpenGL le context GL est implicite, à chaque appel de fonctions le libGL utilise un local thread storage pour savoir contre qu'elle context GL la fonction à lieux. Dans OpenGL on peut toujours modifier l'ensemble des paramêtres de pile de rendu.
Dans Vulkan au contraire, tout est explicite, à chaque appel de fonctions Vulkan l'application doit donner explicitement l'objet contre lequel le driver doit opérer. De plus Vulkan favorise les objets constant, ie dont les propriétés sont définis une seul fois à la création de l'objet et ne peuvent jamais changer mais le contenu oui (par exemple une texture on définis une seul fois ses dimensions mais on peut redéfinir ad-vitam-eternam sont contenue ie les pixels).
Cela est beaucoup plus adapté à la manière dont fonctionne les moteurs de jeux vidéos. En général il utilise un nombre limité d'états qu'il est facile de créer une fois pour toute avec Vulkan et de réutiliser plusieurs fois en changeant juste le contenue entre les différentes frames. Là où pour OpenGL chaque changement d'état implique que le driver doit revalider l'ensemble de tous les états avant de pouvoir soummettre un rendu. Au contraire avec Vulkan une fois les différent états crée on peut les réutiliser et changer entre eux sans que le driver n'est besoins de revérifier quoi que ce soit.
Pour le reste, tu ne te trompes pas, c'est bien l'application qui va gérer elle même la mémoire.
[^] # Re: Mon analyse.
Posté par glisse . En réponse au journal Vulkan le successeur d'OpenGL. Évalué à 10.
Non les GPU n'implementeront pas SPIR-V tout simplement parceque SPIR-V n'est pas un byte code mais un "intermediate representation langage". Alors a moins d'implementer un compilateur dans le GPU ca ne passera pas. Et comme implementer un compilateur en hard pour ce type de représentation c'est juste une idée complétement loufoque bah conclusion non aucun hardware ne comprendra nativement SPIR-V.
Après je reviens sur les erreurs de GaMa
Vulkan a un pipeline tout comme OpenGL 4. On a donc soit :
1 - (GL2) vertex -> pixel shader
2 - (GL3.1) vertex -> geometry -> pixel shader
3 - (GL4) vertex -> tesselation control -> tesselation evaluation -> geometry -> pixel shader
Vulkan permet aussi d'utiliser des computes shader (aussi disponible dans GL4) dans ce cas il n'y pas de pipeline comme pour les graphics shader.
Au final la manière de faire le rendu sous Vulkan ou sous OpenGL est la même, les deux reposes sur les mêmes principes, les GPU sont toujours conçus de la même manière.
Vulkan c'est avant tout une autre manière de programmer les GPUs. La grosse différence entre Vulkan et OpenGL c'est le context, dans OpenGL le context GL est implicite, à chaque appel de fonctions le libGL utilise un local thread storage pour savoir contre qu'elle context GL la fonction à lieux. Dans OpenGL on peut toujours modifier l'ensemble des paramêtres de pile de rendu.
Dans Vulkan au contraire, tout est explicite, à chaque appel de fonctions Vulkan l'application doit donner explicitement l'objet contre lequel le driver doit opérer. De plus Vulkan favorise les objets constant, ie dont les propriétés sont définis une seul fois à la création de l'objet et ne peuvent jamais changer mais le contenu oui (par exemple une texture on définis une seul fois ses dimensions mais on peut redéfinir ad-vitam-eternam sont contenue ie les pixels).
Cela est beaucoup plus adapté à la manière dont fonctionne les moteurs de jeux vidéos. En général il utilise un nombre limité d'états qu'il est facile de créer une fois pour toute avec Vulkan et de réutiliser plusieurs fois en changeant juste le contenue entre les différentes frames. Là où pour OpenGL chaque changement d'état implique que le driver doit revalider l'ensemble de tous les états avant de pouvoir soummettre un rendu. Au contraire avec Vulkan une fois les différent états crée on peut les réutiliser et changer entre eux sans que le driver n'est besoins de revérifier quoi que ce soit.
Pour le reste, tu ne te trompes pas, c'est bien l'application qui va gérer elle même la mémoire.