Discussion :

[bubuche87]

Bon, je suppose que mon message peut être assimilé à du troll. Ce n'est pas le cas. Je me pose des questions, je me fais des réflexions et j'ai l'impression d'être la seule personne à se les poser.

Est-ce que Vulkan est vraiment une bonne idée ?
La première fois que j'en ai entendu parler je me suis dit que c'était une idée horrible. Depuis, Vulkan est sortit et il ne s'agit plus d'une théorie mais d'une réalité en face de nous. Pourtant, je continue de penser qu'il s'agit d'une mauvaise idée.

Vulkan est une API bas niveau. Contrairement aux API précédentes ( comprendre : opengl), Vulkan est adapté aux architectures des cartes graphiques modernes. Bien que plus verbeux, il permet à l'utilisateur de spécifier précisément ce qu'il souhaite et évite ainsi les états cachés et les comportements inconsistants d'une carte graphique à l'autre.

Est-ce que ce paragraphe vous semble injuste envers Vulkan ?

Parce que si ce n'est pas le cas, alors ça confirme ce que je pense.

Il est acté ( et acté par kronos ) que les architectures des cartes graphiques changent. Et donc face à ce constat que les architectures évoluent, ils décident de ... Faire une API hautement spécifique à l'architecture moderne.

Donc une API qui vieillira bien plus et plus vite que les anciennes.

Ils décident de la faire bas niveau, ce qui implique qu'en cas de changement d'architecture il faudra émuler le bas niveau de Vulkan.

Et émuler du bas niveau est ce qu'il y a de pire pour les performances.

Aujourd'hui en 2022 mon ordinateur peut afficher une page HTML écrite dans les années 90. Il me permet également de jouer à Doom 1&2, et ce sur des moteurs qui peuvent ne pas partager une ligne de code avec l'original.

Je peux également afficher des images PNG et jpg datant de ces mêmes années.

Ce qui fait la pérennité en informatique, c'est le déclaratif, c'est dire ce qu'une chose EST, non pas ce qu'elle fait où comment elle doit être interprétée. C'est ce qui permet de régulièrement jeter à la poubelle ce qu'il y a autour de la donnée, et de recréer une interprétation complètement différente de celle-ci.

Les fichiers obj traversent les époques, les exe ne le font pas.

Constater que les temps changent et, en réponse, faire une API ancrée dans son époque est un non-sens.

On vante les performances de Vulkan. Mais c'est bien normal qu'il soit performant _dans son époque_. C'est la moindre des choses j'ai envie de dire.

La question c'est comment il va se comporter dans dix ans, quand les architectures auront encore évolué. Il ne serait pas surprenant de voir l'OpenGL haut niveau repasser devant Vulkan.

Mais ce n'est que la moitié du problème que j'ai.

Vulkan, en dépit de tout ce que j'ai dit, aurait pu avoir un intérêt : en donnant accès au bas niveau, il aurait pu permettre à d'autres API , d'un niveau similaire à OpenGL, d'apparaître. Dès API avec des approches radicalement différentes, des approches auxquelles on ne pense même pas aujourd'hui, aussi "alien" pour nous que peut l'être du LISP pour un développeur assembleur.

Parmi ces API, certaines auraient finit par devenir populaires et bénéficier d'un support natif dans les cartes graphiques ultérieures.

Mais pour cela, il aurait fallu que Vulkan tienne ses promesses et fournisse un accès vraiment bas niveau, une sorte de langage exposant le SIMD, où on ne parlerait plus de texture, de buffer, de shader ou de queue ( concepts trop hauts niveau alors ), mais de mémoire, de blocs d'instructions SIMD et d'interruptions/de sémaphores.

Sauf que non. Passé le vomit de mettre en place les trucs bateaux, on arrive sur ... Les fixed functions.
C'est-à-dire que le coeur dur, l'essentiel, le truc qui compte vraiment, là où on aurait pu s'amuser et innover : NON !
Non, c'est du fixed function, passez votre chemin il n'y a rien à voir. Vous resterez bien dans les clous, avec les mêmes possibilités et limitations qu'avant. Il ne s'agirait pas de faire de l'ombre à Vulkan, après tout.


Voilà.
Pour moi Vulkan est un échec pour ces deux raisons. Trop bas niveau pour être futur-proof, trop haut niveau pour être un pont vers l'avenir. Il est et restera efficace tant que l'architecture des cartes graphiques ne changera pas, puis deviendra un cauchemar.

Ais-je tort ? Si oui, où ?

Merci pour la lecture, et j'espère lire vos commentaires et réponses.

[LittleWhite]

Bonjour,

Je pense que la première chose sur lequel j'aimerai revenir est que : OpenGL n'est pas haut niveau. OpenGL c'est du bas niveau. OpenGL, c'est du bas niveau car vous aviez accès aux textures, aux zones mémoires (les VBO et autres buffer), (si je me rappelle correctement) des mécanismes de synchronisation (avec OpenGL 4) et j'en passe des meilleurs. La problématique alors d'OpenGL, c'est que cela a été créé dans les années 1990 et qu'à l'époque, les possibilités et l'architecture prévue pour le rendu était complètement différente. En bref, OpenGL 1 est une hérésie depuis les années 2010. De cela, OpenGL 2, puis OpenGL 3 et finalement OpenGL 4 ont été construit tout en gardant une compatibilité (un héritage), plutôt lourd et surtout, qui ne correspondait en rien aux cartes graphiques "modernes" (notamment, disparition du pipeline fixe, les cartes graphiques embarquent processeurs génériques (privilégiant le calcul des nombres flottants et la haute parallélisation) que l'on peut reprogrammer avec des shaders).

Donc, dire que OpenGL est haut niveau : non. C'est un peu plus haut niveau que Vulkan, mais la différence est faible. Ce n'est pas du haut niveau, c'est plus que les fonctionnalités exposées ne sont pas 100 % adéquate à la réalité sous jacente.

Si vous voulez vous en convaincre, regardez les conférences avant Vulkan (et Mantle). On parlait à cette époque de réduire à mort la surcharge des pilotes (induites par l'API d'OpenGL) ->

Les fichiers obj traversent les époques, les exe ne le font pas.

Aujourd'hui en 2022 mon ordinateur peut afficher une page HTML écrite dans les années 90. Il me permet également de jouer à Doom 1&2, et ce sur des moteurs qui peuvent ne pas partager une ligne de code avec l'original.

Je ne suis pas d'accord. Lorsque vous voulez supporter des trucs des années 90, vous avez une surcharge de milliers de lignes de code pour supporter un truc totalement obsolète et inadéquate, mais qu'il faut supporter pour pas casser la compatibilité. Dans l’extrême, on peut parler de l'architecture x86, du support des vieilles API de Windows, du support des pages HTML des années 90 où le standard n'était pas encore en place et que la moitié des balises sont mal placées/manquantes. Tout ça, à un coût, et ce coût, c'est du temps de programmation, des bogues possibles et du temps de calcul pour rien. Car oui, la balise HTML manquante, elle nécessite un bloc if juste pour ce cas, qui sera traité par le CPU et qui faut que les devs laissent.
Bref, Doom dans un navigateur, c'est le summum de la surcharge et de l'inefficacité. Réimplémenté en Vulkan, c'est l'accès aux dernières technologies (raytracing) et une performance cohérente à la configuration de la machine.

La question c'est comment il va se comporter dans dix ans, quand les architectures auront encore évolué. Il ne serait pas surprenant de voir l'OpenGL haut niveau repasser devant Vulkan.

Si vous voulez du haut niveau pour avoir un support sur 100 ans, prenez un vrai truc haut niveau : Unreal Engine/Unity/Godot. C'est haut niveau et il y aura un gars qui fera la couche qui permet d'utiliser l'API adéquate au moment adéquat. Vulkan est bas niveau pour donner aux développeurs l'accès à la puissance de la machine. Ce n'est pas nécessairement pour vivre 10 ans et suivre une évolution. Ils ont arrêter OpenGL qui avait un héritage de 20 ans, afin de s'adapter aux évolutions. Lorsque les cartes graphiques évolueront à nouveau, il y aura une nouvelle API (disons, du lancer de rayon à la place de la rastérisation) et Vulkan deviendra "obsolète". Et si vous ne voulez rien sentir de tout ça, utilisez un moteur haut niveau, comme ceux mentionnés précédemment.

Je peux également afficher des images PNG et jpg datant de ces mêmes années.

Est-ce vraiment adapté ? Je veux dire, le JPEG a évolué ou autrement dit, maintenant de nouveau algorithmes existent permettant de meilleure compression avec moins de perte. Pour les images, vous sentez pas trop le problème, mais imaginez que j'encode un film 4K, HDR 10+ avec un codec des années 2000. Déjà, je ne peux pas , de deux, je vais sûrement remplir un disque dur de 20 To. Youpi.
Vous le pouvez, car comme dit précédemment, il y a un développeur qui a fait un programme, compatible avec l'architecture moderne, de charger un format spécifique.
Qu'est ce qui facilite/permet un tel processus : les formats ouverts et les spécifications. Pour revenir à Doom, c'est porté sur toutes les machines, car c'est ouvert. Par contre, le jeu/programme qui supporte un format inconnu et que la société à l'origine de ce format est morte, je vous dis bon courage pour espéré son support dans 10 ans.

Revenons à Vulkan

Mais pour cela, il aurait fallu que Vulkan tienne ses promesses et fournisse un accès vraiment bas niveau, une sorte de langage exposant le SIMD, où on ne parlerait plus de texture, de buffer, de shader ou de queue ( concepts trop hauts niveau alors ), mais de mémoire, de blocs d'instructions SIMD et d'interruptions/de sémaphores.

Vous oubliez aussi le début des shaders (vers les années 2000). Vous oubliez que les constructeurs de cartes graphiques ne font pas la même chose. Vulkan vous offre une interface unifiée pour programmer un rendu 3D, peu importe si la carte graphique est construite par NVIDIA, AMD, Intel ou tartenpion. Cela veut dire qu'avec Vulkan (ou DirectX, ou OpenGL), vous ne vous souciez pas du tout de l'implémentation... et heureusement !
Dans les années 2000, les shaders c'était en assembleur. Enfin, en assembleur spécifique NVIDIA, spécifique à telle ou telle carte graphique. Et au purée, vous ne voulez pas vivre cela. Même avec OpenGL, un shader pouvait fonctionner/compiler sur une carte NVIDIA, mais pas une carte AMD (voir ce que l'on écrivait en 2010 : https://www.geeks3d.com/20101002/tip...nvidia-system/ ). Vulkan a amélioré cet état de fait.

Sauf que non. Passé le vomit de mettre en place les trucs bateaux, on arrive sur ... Les fixed functions.
C'est-à-dire que le coeur dur, l'essentiel, le truc qui compte vraiment, là où on aurait pu s'amuser et innover : NON !
Non, c'est du fixed function, passez votre chemin il n'y a rien à voir. Vous resterez bien dans les clous, avec les mêmes possibilités et limitations qu'avant. Il ne s'agirait pas de faire de l'ombre à Vulkan, après tout.

J'ai un peu du mal à suivre vos propos. Il n'y a pas de pipeline fixe dans Vulkan (ni OpenGL moderne (> 3)). Simplement, actuellement la méthode de rendu c'est la rasterization. Maintenant, avec OpenGL (moderne) et Vulkan et DirectX > 9, vous avez le choix complet de ce que vous voulez faire de votre rasterization. Vous voulez des ombres, c'est possible. Vous voulez faire de l'éclairage, du forward rendering, du defered rending, du hybrid rendering, vous avez le choix. Car oui, depuis 2005, les calculs effectués sur les cartes ont totalement changé.
Vous vouliez un truc 100 % nouveau ? Un rendu complet en lancer de rayon ? De une, vous pouvez (car oui, on vous a fournit une API assez bas niveau pour pouvoir en faire avec votre carte graphique (pensez raymarching), mais bon, la vérité, c'est que c'est une chimère depuis 30 ans .
Vous voulez un truc autre que la rasterization... ok, je veux bien voir de quoi vous parlez


Note : vous pensez que OpenGL/Vulkan sont seuls dans cette évolution, mais n'oubliez pas que DirectX a suivi le même chemin.

[Mat.M]

Les fichiers obj traversent les époques, les exe ne le font pas.

oui d'accord mais vous n'avez pas remarqué qu'entre un ordinateur PC des années 80 et un PC de 2020 y'a eu beaucoup d'évolutions technologiques niveau hardware, non ?
En tout cas je ne comprends pas bien la problématique de ce sujet

Aujourd'hui en 2022 mon ordinateur peut afficher une page HTML écrite dans les années 90. Il me permet également de jouer à Doom 1&2, et ce sur des moteurs qui peuvent ne pas partager une ligne de code avec l'original.
Je peux également afficher des images PNG et jpg datant de ces mêmes années.

oui d'accord.Et puis ?
Rien ne prouve que Doom 1 première distribution puisse tourner sur un OS récent je sais pas j'en ai pas fait l'essai.

Ce qui fait la pérennité en informatique, c'est le déclaratif, c'est dire ce qu'une chose EST, non pas ce qu'elle fait où comment elle doit être interprétée.

comment voulez-vous avoir de la pérennité en informatique ?
La techno ça évolue au cours du temps,l'architecture des cartes graphiques et des chipsets évolue donc faut bien que les API évoluent non ?
Quant à différencier une chose qui est et une chose qui fait ça finit par déboucher sur des spéculations métaphysiques qui dépassent le cadre de ce forum.
Si vous voulez considérer une chose qui est et non pas ce qu'elle fait à ce moment-là faut se reconvertir dans la géologie.
Parce qu'en prenant le rocher d'une montagne là oui le rocher c'est du solide c'est de la matière qui ne bouge pas au cours du temps
Après vous voulez une API pérenne faut prendre DIRECT X 11/12 ; heureusement comme programmeur/créateur de jeu c'est une API qui évolue relaitvement lentement maintenant

[bubuche87]

En bref, OpenGL 1 est une hérésie depuis les années 2010. De cela, OpenGL 2, puis OpenGL 3 et finalement OpenGL 4 ont été construit tout en gardant une compatibilité (un héritage), plutôt lourd et surtout, qui ne correspondait en rien aux cartes graphiques "modernes"

Je comprends ce que vous dîtes, mais la réponse a déjà été trouvée avec opengl 3.1: supprimer les fonctions trop vieilles, et laisser les concepteurs de cartes graphiques motivés faire un profil compatibilité si ça leur chante.


( Et je suis assez d'accord pour dire qu'opengl n'est pas exactement du haut niveau. )

Bref, Doom dans un navigateur, c'est le summum de la surcharge et de l'inefficacité. Réimplémenté en Vulkan, c'est l'accès aux dernières technologies (raytracing) et une performance cohérente à la configuration de la machine.

Que ce soit inefficace je ne le conteste pas. Je dis que c'est faisable parce qu'on a ce que Doom _signifie_ ( si vous trouvez que le mot être est trop philosophique ).
En gros, on sait que tel THING ( terme technique dans Doom ) est un fusil à pompe. Pas "tel sprite avec tel son joué sur tel hardware avec ces commandes spécifiques de l'époque". Du coup on peut fournir une implémentation avec des modèles 3D et un moteur entièrement différent.

On peut changer intégralement la couche basse.
De la même façon qu'on peut changer intégralement les humains constituants une société sans changer la société.

De la même façon qu'on peut changer intégralement le code assembleur et compiler le même code C: en s'éloignant de "comment" on fait pour dire "ce" qu'on fait on rend le programme perein.

Est-ce que c'est philosophique ? Oui.
Est-ce que c'est inabordable ? Je ne pense pas.

Et même si c'était le cas pour ici, il me semble que c'est le genre de questions qu'on doit se poser quand on fait un truc aussi important qu'opengl/Vulkan.

Si vous voulez du haut niveau pour avoir un support sur 100 ans, prenez un vrai truc haut niveau : Unreal Engine/Unity/Godot. C'est haut niveau et il y aura un gars qui fera la couche qui permet d'utiliser l'API adéquate au moment adéquat.

Je ne dis même pas ça. Je dis que c'est l'une des deux options.

Le hardware qui change, c'est pas nouveau ( les processeurs ). La bonne réponse n'a jamais été "+ de bas niveau".
Au contraire, la bonne réponse c'est de proposer du haut niveau qui ne change pas trop ( ou qui change vers de l'encore plus haut niveau ), et des outils pour compiler vers le bas niveau qui évolue sans cesse.



[QUOTE=LittleWhite;11861210] Vulkan est bas niveau pour donner aux développeurs l'accès à la puissance de la machine. [QUOTE]

Sauf qu'il échoue même à ça, cf mon commentaire sur les fixed functions ( et je dis bien "functions", pas "pipeline", quelqu'un s'est trompé plus bas ).

Vous oubliez aussi le début des shaders (vers les années 2000). Vous oubliez que les constructeurs de cartes graphiques ne font pas la même chose. Vulkan vous offre une interface unifiée pour programmer un rendu 3D, peu importe si la carte graphique est construite par NVIDIA, AMD, Intel ou tartenpion. Cela veut dire qu'avec Vulkan (ou DirectX, ou OpenGL), vous ne vous souciez pas du tout de l'implémentation... et heureusement !

Oui, une interface bas niveau. Donc quand cette interface ne collera plus au vrai bas niveau, il faudra l'émuler. Et émuler du bas niveau est ce qu'il y a de pire pour les performances.

Je reprends ce que j'ai dit pour les problèmes d'architecture qu'on a déjà rencontré par le passé. La solution n'est pas de créer un langage assembleur unifié collant à l'architecture de l'époque et après de se trimballer de l'émuler pendant les 50 ans qui suivent. La solution c'est le C, c'est le haut niveau ( relativement ) qui est traduit vers le bas niveau.
Quand le bas niveau change on change la traduction.
Et plus c'est haut niveau, plus ça laisse de liberté pour cette traduction, et plus ça permet de générer du code ultra performant.

Plus on se contente de dire CE qu'on fait plus on laisse de liberté sur comment le faire.

La page HTML ne décrit pas le rendu logiciel qui était utilisé à l'époque. Elle se contente de dire "met du texte en gras par là-bas".
C'est plus concis et surtout ça permet de changer intégralement l'approche utilisée pour le rendu.
Ça peut être lu à un malvoyant, ça peut-être affiché dans une console, on peut faire de la recherche de texte et l'indexer dans un moteur de recherche.

D'ailleurs, justement, il y a eut une époque où les gens se sont mit à utiliser des images pour faire l'intégralité de leur site.
Ils ont arrêté de décrire CE que leur site était et se sont mit à décrire comment il était.
Résultat c'est une galère niveau accessibilité, ça ne s'adapte pas du tout aux mobile et il est impossible de changer le style de la page.

Vous dîtes que c'est philosophique, mais la séparation syntaxe/sémantique est un problème récurrent en informatique.

Vulkan est un retour en arrière de vingt+ ans.

J'ai un peu du mal à suivre vos propos. Il n'y a pas de pipeline fixe dans Vulkan (ni OpenGL moderne (> 3)).

Je ne parle pas de fixed pipeline mais de fixed functions. Je peux vous rediriger vers les sections de la documentation parlant de ça, ou même vers le tuto ( officiel, je pense ).

Vous vouliez un truc 100 % nouveau ? Un rendu complet en lancer de rayon ?

Ça c'est pas nouveau. C'est même plus vieux que l'approche par projection par matrice. Ça remonte au moins au début des années 80.

Non, je parle de ( par exemple ): faire de la synthèse audio ( pas juste lire un MP3: du midi sous stéroïdes ), de la simulation physique, du rendu mathématique ( avec une scène décomposée en transformées de Fourier qu'on échantillonent ensuite avec la précision souhaitée en virant plus ou moins d'amplitudes ), du voxel, une vraie API 2D ( et la fin des glyphes rastérisés et du bidouillage avec une caméra ortho )...

Je ne sais pas, tout et n'importe quoi comme traitement parallèle, ainsi que l'intersection de tous ces traitements ( les différentes combinaisons et interactions possibles ).

ok, je veux bien voir de quoi vous parlez

J'ai travaillé avec des unités de calcul très nombreuses mais très limitées ( en puissance de calcul et en mémoire ). Il y a tout un champ de recherche dans ce domaine.
Le calcul parallèle, en général, c'est LE truc depuis un moment.
Il est dommage de devoir bidouiller pour cacher ses données dans les canaux rgba d'une texture.

[Mat.M]

Non, je parle de ( par exemple ): faire de la synthèse audio ( pas juste lire un MP3: du midi sous stéroïdes )

j'ai l'impression que vous voulez faire des milliers de choses en même temps.
Tout cela est-ce dans l'optique de créer un jeu ?
Si vous faites plusieurs choses à la fois vous risquez vite de tourner en rond.
Donc comme Littlewhite conseille il faut prendre Godot,Unity si vous voulez créer un jeu.

[Kannagi]

Alors pour te répondre :
Déjà OpenGL difficile de le mettre sur du bas niveau , , ça reste une API qui se basait sur le rendu d'ancien IRIX , donc dire que c'est bas niveau (et je parle aussi pour Littlewhite).
Au début pas mal de CG s'éloignais des specs de OpenGL , c'est après que Nvdia puis ATI on fait des CG pour que ça tourne assez bien avec OpenGL.
bref pour dire que Vulkan est nécessaire pour avoir une API plus conforme au GPU actuel.

La question ,c'est est ce que ,c'est pas à trouble tranchant ?
Ben oui , mais si on m'écoutait , ça devrait être toujours comme ça, vouloir une "rétrocompatibilité'" , c'est se tiré une balle dans le pied !
Donc il y'a Vulkan qui est bas niveau , et ensuite tu as des moteurs qui se base sur cela.
si tu fais un programme qui utilise Vulkan , oui , tu dois faire en sorte que Vulkan soit "transparent" , et que tu puisse changer d'API quand ça viendra.

Et si tu veux du "haut niveau" rien n’empêche de faire une API haut niveau qui utilise en interne Vulkan/DX ou Metal suivant la plateforme !

Le hardware qui change, c'est pas nouveau ( les processeurs ). La bonne réponse n'a jamais été "+ de bas niveau".

Justement ,c'est un des gros soucis avec le X86 , sa volonté de rétrocompatibilité à tuer pas mal d'innovation dans les tech des processeurs.
On a voulu aller plus bas niveau (voir Itanium) , on mettant explicitement la pipeline , la parallélisation des instruction ,le renommage de registre etc etc.
Mais le x86 étant tellement ancrée que ça n'a pas marché.

Pour moi ,je ne partage pas ton avis , parce que je ne suis pas un fervent défenseur de la rétrocompatibilité pour une bonne raison : "Adapter de vieux programmes à de nouvelles machines signifie habituellement adapter les nouvelles machines pour qu’elles se comportent comme les anciennes." (Alan Perlis).

[Bousk]

Avec des raisonnements pareils, on aurait jamais amélioré les vitesses d'exécution, qui nécessitent des changements hardwares et software.
La rétrocompatibilité est souvent ce qui bloque quand on veut enfin améliorer les choses. L'avoir c'est bien, mais doit-on se passer de 20% de vitesse parce que la roue précédente ne tourne pas aussi vite et qu'il faut la supporter coûte que coûte ?
Du coup on abandonne multicoeur, hyperthreading et autres SIMD pour revenir à un hardware et jeu d'instructions plus simples mais qui permette pas d'atteindre les performances auxquelles on est maintenant habitué ?

Et si les changements te rebutent tant, oritente-toi vers un job où tu écris des datas et non du code ?
Ou un truc plus haut niveau pour que d'autres se fassent les noeuds pour créer la couche basse. C'est le principe de Java, C# et leurs VM non ? Et de la majorité / tous les langages de script ? (quoi que, même Python a eu des cassures entre 2.7 et 3.1).
Puis bon, les data c'est vite limitées, comparer un JPG à Doom, c'est un peu abusé imo.

[LittleWhite]

Je comprends ce que vous dîtes, mais la réponse a déjà été trouvée avec opengl 3.1: supprimer les fonctions trop vieilles, et laisser les concepteurs de cartes graphiques motivés faire un profil compatibilité si ça leur chante.

Vous en parlez dans la suite dans la fin de votre message. Une des raisons du pourquoi Vulkan existe au lieu de OpenGL 5: c'est le multithread.

De la même façon qu'on peut changer intégralement le code assembleur et compiler le même code C: en s'éloignant de "comment" on fait pour dire "ce" qu'on fait on rend le programme perein.

Je pense que vous oubliez une chose. Pourquoi le C est compilable depuis 50 ans ? Car il est standardisé. Pour peu que vous ayez un standard, alors il est assez "facile" de créer un programme pouvant interpréter ce standard, de faire un émulateur suivant le standard, bref de lire une documentation explicitant ce que l'on va trouver.
N'oubliez pas que Vulkan, c'est avant tout une spécification (ou un standard). Les programmeurs sont contents, car ils savent à quoi s'en tenir car les cartes graphiques suivent le standard (enfin, ça c'est la théorie ). Les implémenteurs sont contents car ils savent quoi implémenter et pourront faire un pilote compatible avec énormément de programmes ayant suivi le standard. L'avenir : les émulateurs, les nouveaux pilotes offrant le support de Vulkan savent ce qu'ils doivent implémenter pour que dans 100 ans, vous pouvez encore faire tourner votre programme grâce à la couche qui offre le support du standard.
C'est pour ça, que votre programme C, il est encore compilable. Cela aurait été un programme dans un langage proprio, bah, bon courage. Doom est aussi compilable, car son code a été ouvert. Et finalement, comme vous le dites, le code de DOOM est modulaire et offre assez d'abstractions pour permettre aux bidouilleurs d'en faire ce qu'ils en veulent. Pourquoi cela ne se fait pas tout le temps : car l'abstraction, cela a aussi un coût sur le développement et que les programmes sont maintenant bien plus compliqués qu'il ne l'était à l'époq

Et même si c'était le cas pour ici, il me semble que c'est le genre de questions qu'on doit se poser quand on fait un truc aussi important qu'opengl/Vulkan.

Possible qu'il faille se poser des questions, mais là, cette question ne concerne pas une spécification offrant une manière standardisée d'utiliser une carte graphique.

Quand le bas niveau change on change la traduction.

Oui, regardez Wine et Proton. Regardez les trucs comme ANGLE. On peut toujours y arriver. Si cela a un coût, on peut aussi miser sur les meilleures performances que l'on aura au futur.

Et plus c'est haut niveau, plus ça laisse de liberté pour cette traduction, et plus ça permet de générer du code ultra performant.

Non. Pas nécessairement. Avec un truc haut niveau, on ne tire pas parti des spécificités d'une machine donnée (par exemple une PS3, ou même une console plus ancienne). Tant qu'il n'y a pas quelqu'un pour bosser sur une adaptation de la couche haut niveau pour tirer (autant que faisable) des avantages de son matériel, vous n'aurez pas un truc optimisé. Et pour avoir un truc optimisé, il faut avoir des API pour manipuler la machine comme on le souhaite.

Je ne parle pas de fixed pipeline mais de fixed functions. Je peux vous rediriger vers les sections de la documentation parlant de ça, ou même vers le tuto ( officiel, je pense ).

N'hésitez pas à donner le lien car j'ai un trou de mémoire .

Non, je parle de ( par exemple ): faire de la synthèse audio ( pas juste lire un MP3: du midi sous stéroïdes ), de la simulation physique, du rendu mathématique ( avec une scène décomposée en transformées de Fourier qu'on échantillonent ensuite avec la précision souhaitée en virant plus ou moins d'amplitudes ), du voxel, une vraie API 2D ( et la fin des glyphes rastérisés et du bidouillage avec une caméra ortho )...

Vous pensez à ce qui existe du côté de la demoscene ?
Un peu dans ce style :

Ou ça:

C'est une façon de faire, mais une façon qui garde ses limites.

Le calcul parallèle, en général, c'est LE truc depuis un moment.
Il est dommage de devoir bidouiller pour cacher ses données dans les canaux rgba d'une texture.

Car les cartes graphiques sont disponibles et disposent d'une puissance de calcul parallèle plutôt immense. Ce qui fait que vous en ayez une, c'est son côté grand public, grâce aux joueurs. Si vous voulez votre puce, dédiée à faire le travail spécifique que vous voulez, vous allez devoir payer bien plus cher (en sous et en temps). Du coup, il vous est nécessaire de vous adapter sur le truc qui est disponible.

[dragonjoker59]

Et émuler du bas niveau est ce qu'il y a de pire pour les performances.

D'où la naissance des API Vulkan/D3D12/Metal, pour arrêter d'émuler les API OpenGL/D3D11 sur du matos fonctionnant complètement autrement...

Il y a un truc très important dans les API 3D modernes : elles simplifient drastiquement l'implémentation des drivers, implémentation qui était devenue infernale avec OpenGL et une source de bugs continuelle (Je ne compte plus le nombre de fois qu'une update de driver a pu péter mes rendus, et me forcer à implémenter des workarounds...).

[bubuche87]

(petite parenthèse: ce message, contrairement aux précédents, n'a pas été
écrit sur Android mais sur Ubuntu (et Kate plus précisément). Du coup pas de correction syntaxique, mais moins de stress de faire une fausse manip et de voir une heure de laborieuse rédaction partir dans le néant)

@ tout le monde


Je ne suis pas un défenseur de la rétrocompatibilité. Je ne sas pas à quel
moment les gens se sont mit à croire ça.
En revanche je suis un défenseur du fait d'avoir de la vision, de préparer à long terme.

Je suis contre ça:

Sam Newman has even started the process of institutionalizing that approach with the BFF pattern that suggests that it’s ok to develop specific APIs per type of device, platform and of course versions of your app. Daniel Jacobson explains that Netflix has been cornered to use a new qualifier for its “Experience APIs”: ephemeral.

(source: "Why I No Longer Use MVC Framewords", Jean-Jacques Dubray)
Faire une API qui colle à l' "architecture actuelle" des cartes graphiques ce n'est pas avoir de la vision. C'est suivre, pas mener, c'est être dans l'instant présent et dans l'éphémère, pas dans le futur et la durabilité.

Je ne suis pas un défenseur de la rétrocompatibilité. C'est _justement_ pour cette raison que je suis contre Vulkan, qui va vieillir comme s'il était atteint de progéria et demander une rétrocompatibilité inefficace parce qu'étant explicite sur tout il ne laisse aucune liberté d'adaptation aux nouvelles (=du futur) carte graphiques.


@Mat.M

j'ai l'impression que vous voulez faire des milliers de choses en même temps.<br>
Tout cela est-ce dans l'optique de créer un jeu ?

Heu, alors non, pas du tout. Pour ce que j'essaie de faire OpenGL 3.1 suffirait.
Je ne suis pas en train de défendre mon bout de gras, même si ça peut paraître étrange.

Après, mon problème n'est pas spécialement Vulkan. Ca fait des années que je facepalm
à toutes les décisions prisent par Khronos, je commence à avoir mal à la tête à force
de me taper dessus.


@Bousk:

Tu ne m'as pas compris: je n'ai rien contre le changement. Pour être tout à fait franc je n'utilise qu'une petite partie d'OpenGL et je trouve qu'on pourrait/devrait se débarasser du reste. Je dis même qu'ils savaient comment faire en citant le passage à OpenGL 3.1 qui retire des fonctions (et brise
la rétrocompatibilité, preuve que ça ne me tient pas à coeur).
C'est une API plus qu'imparfaite. Mon post ne dit pas qu'ils ont eut tort de _faire Vulkan_, il dit qu'ils n'auraient pas du faire ce qu'ils ont fait.

Je ne compare pas non plus un JPG à Doom. Je compare le JPG et Doom (et le HTML
etc) à d'autres choses. Je dis que tous ces éléments (JPG, Doom, HTML ... ) ont pu survivre parce que justement c'étaient des datas (pour reprendre tes termes).
Les datas survivent, le traitement non.


@LittleWhite

N'oubliez pas que Vulkan, c'est avant tout une spécification (ou un standard).

Je ne pense pas que ça soit la partie "standard" qui soit importante.
Si vous avez un rendu logiciel (le bon vieux truc à base de boucles "for" de partout, si c'est pas assez clair) vous pouvez le standardiser, ça ne fera pas des miracles.
Maintenant, si à la place d'avoir votre triple boucles for imbriquées (une pour parcourir les images, une pour les y et une pour les x) vous avec une ligne qui dit "afficher toutes les images", cette ligne peut être implémentée en multithreading (ou ultrathreading ou gigathreading puisque c'est la mode d'en faire des caisses) avec toutes les optimisations qui vous passent par la tête.

La différence ? Dans le premier cas on décrit comment le faire ("avec une triple
boucle") dans le second on décrit ce qu'on fait. Le premier est voué à mourir, le deuxième survivra.
Vous noterez que le premier est très verbeux et laisse peu de place à l'adaptation, à l'inverse du deuxième.

Et finalement, comme vous le dites, le code de DOOM est modulaire et offre assez d'abstractions pour permettre aux bidouilleurs d'en faire ce qu'ils en veulent.

J'ai du mal m'exprimer, parce que je ne parle pas du code de Doom. Je parle des fichiers du jeu, des fichiers ".WAD". Le code décrit comment on fait Doom, et va forcément inclure plein de parties hautement spécifiques à l'architecture des ordinateurs de l'époque. Mais le fichier WAD décrit CE qu'est Doom.


Pour les fixed functions:
https://vulkan-tutorial.com/Drawing_...ixed_functions

C'est paramétrable mais comme l'était la fixed pipeline en son temps.
Impossible de faire sa propre sauce, on nous bassine comme quoi Vulkan est bas niveau mais quand il s'agit de passer à la caisse il n'y a plus personne.

[dragonjoker59]

Pour les fixed functions:
https://vulkan-tutorial.com/Drawing_...ixed_functions

C'est paramétrable mais comme l'était la fixed pipeline en son temps.
Impossible de faire sa propre sauce, on nous bassine comme quoi Vulkan est bas niveau mais quand il s'agit de passer à la caisse il n'y a plus personne.

Que souhaiterais-tu faire "à ta propre sauce", concernant le pipeline de rastérisation ?

Tu peux déjà éviter toute la partie vertex inputs en faisant du vertex pulling plutôt que du HW vertex fetching.

[Kannagi]

Je suis contre ça:

(source: "Why I No Longer Use MVC Framewords", Jean-Jacques Dubray)
Faire une API qui colle à l' "architecture actuelle" des cartes graphiques ce n'est pas avoir de la vision. C'est suivre, pas mener, c'est être dans l'instant présent et dans l'éphémère, pas dans le futur et la durabilité.

Je ne suis pas un défenseur de la rétrocompatibilité. C'est _justement_ pour cette raison que je suis contre Vulkan, qui va vieillir comme s'il était atteint de progéria et demander une rétrocompatibilité inefficace parce qu'étant explicite sur tout il ne laisse aucune liberté d'adaptation aux nouvelles (=du futur) carte graphiques.

écoute ,si tu as l'API parfaite qui peut durer 50 ans et qui en plus est suffisamment "précise" pour être performante et qui exploite le hardware n'hésite pas !

Pour ma part en codant sur console , il est toujours obligatoire de recoder les fonction "bas niveau" , y compris ceux du rendu.

Je ne vois pas comment faire une API à la fois performante/modulaire et bas niveau et qui peut durer 50 ans , ou alors faudra m'expliquer comment

[bubuche87]

Que souhaiterais-tu faire "à ta propre sauce", concernant le pipeline de rastérisation ?

Tu peux déjà éviter toute la partie vertex inputs en faisant du vertex pulling plutôt que du HW vertex fetching.

Alors perso ( juste moi quoi ) il m'arrive régulièrement d'avoir sur chaque vertex un attribut décrivant à quel objet ce vertex appartient. C'est un entier, et il permet d'avoir accès à la matrice de transformation de l'objet en question, au matériau qu'il utilise etc.

Maintenant, ça signifie que chaque vertex d'un objet va devoir aller chercher toutes ces informations. Si, par exemple, la caméra est stockée dans un uniform, le vertex va devoir faire une multiplication de matrice ( la transformation de l'objet * la caméra, je passe les détails sur l'ordre et la différence caméra/projection, ainsi que sur l'extraction de la matrice de la texture où elle est stockée).
Sauf que cette information est uniforme pour l'ensemble de l'objet. Tous les vertex appartenant à cet objet auront le même résultat.

Perso, je préférerais avoir une première passe où j'aurais X unités de calcul ( jusqu'à une par objet avec une approche triviale, plus sinon ) chacune faisant ce calcul et le stockant a un endroit puis émettant un nombre VARIABLE de vertex.
J'insiste sur le variable pour la raison suivante: je sais combien de vertex chaque objet va émettre. Je sais donc quel indices seront écrits par chaque objet et je peux donc tout générer en parallèle sans mutex ou autres sémaphores.

La seconde chose c'est le depth test.
J'ai déjà posté sur le sujet ailleurs sur internet mais je vais me répéter ici.

Je suppose que tu sais ce qu'est le depth buffer ( j'ai commencé trois fois à décrire ce que c'était avant de l'effacer parce que je suis tiraillé )

, mais juste pour que ce soit clair: c'est un tableau qui la garde la distance de chaque pixel affiché par rapport à la caméra.
Quand on essaie d'afficher un pixel, on test sa distance par rapport à celle qu'on a dans le depth buffer. Si le nouveau pixel est plus loin que ce qu'on a dans le depth buffer, on jette le nouveau pixel. Sinon, on met à jour la couleur et la distance.
La distance est un _ réel _ et est calculée par interpolation à partir des sommets du triangle ( ou de la primitive )

Ça c'est la théorie.
En pratique, on peut ( et les cartes graphiques le font ) optimiser ça : on peut détecter qu'un pan entier de pixels est plus loin qu'un autre pan et jeter tout le pan d'un coup. C'est bien et j'approuve.

Maintenant, j'aimerais avoir une version modifiée de ça : deux depth buffers.

L'un des deux est celui qu'on connait, avec les propriétés qu'on connait.
L'autre est un buffer contenant des entiers ( et pas des réels ). La valeur de ces entiers n'est pas interpolée mais est déclarée explicitement par un vertex, et vaut pour l'ensemble du triangle ( ou " est déclarée et vaut pour l'ensemble d'un objet" si on combo avec l'autre idée ).

Le fonctionnement est le suivant: quand on veut afficher un nouveau pixel, on commence par comparer les valeurs entières.
Si elles sont différentes on a la réponse ( le pixel est gardé/jeté si sa valeur est plus grande/plus petite que ce qui est déjà là)

Si les valeurs entières sont égales, on se rabat sur l'ancien buffer.

Pourquoi ? L'exemple que je donne est une scène avec un ciel étoilé, deux lunes sur des orbites différentes, des nuages dans le ciel, une cabane, des mains tenant une arme à la vue FPS et un HUD.
Les étoiles sont derrière tout le reste.
La lune sur l'orbite grande est derrière tout ( sauf les étoiles ).
La lune sur l'orbite petite est derrière tout ( sauf les étoiles et l'autre lune ).
Les nuages sont derrière tout ( sauf ... )
La cabane est derrière tout ( sauf ... ) Même derrière l'arme, parce qu'on ne veut pas que l'arme clip avec le reste de la scène.
L'arme est derrière le HUD.
Le HUD est devant tout.

Et je n'ai pas rajouté un casque de type heaume entre l'arme et le HUD, mais j'aurais pu.

Chacun de ces objets est sur une couche différentes. Le depth buffer entier dont je parle permet de représenter ça. Et en y appliquant la même optimisation que celle du depth buffer classique, on peut virer quantité de pixels inutiles. ( Sachant que les valeurs n'étant pas interpolées et étant entières on simplifie grandement les calculs et on évite les erreurs d'arrondit).

Ça offre aussi une excellente base pour le rendu 2D puisqu'on peut avoir explicitement les layers et l'optimisation qui va avec ( en fait la même optimisation que celle qui était faite à l'époque des rendus logiciels et qui visaient à éviter de peindre des rectangles de pixels masqués ).

Je peux bien sûr avoir le même rendu avec OpenGL 1, en nettoyant le depth buffer entre deux couches, mais on oublie l'optimisation.
Là je parle d'une situation où mettre un heaume augmente les perfs, pas les diminue.

Enfin, l'approche qu'opengl m'oblige à avoir est de pull ( d'aller chercher ) les informations dont j'ai besoin ( cf le cas 1 de ce post, le transformation de l'objet ) alors que dans pas mal de cas je vois parfaitement comment je pourrais avoir une approche push plus efficace.

Et je n'ai pas parlé de la synthèse audio. Parfaitement descriptible avec plein de trucs hautement parallélisables ( un "échantillons shader" avec le temps en entrée et une amplitude en sortie, même pas forcément appelé pour chaque échantillon parce qu'on peut rajouter une interpolation et ... et ... et mille trucs ! ) et qui bénéficieraient des fonctions approximées et optimisées des cartes graphiques.

Mais "fixed functions" ...

( C'est mon d'écrire sur téléphone)

[dragonjoker59]

Alors perso ( juste moi quoi ) il m'arrive régulièrement d'avoir sur chaque vertex un attribut décrivant à quel objet ce vertex appartient. C'est un entier, et il permet d'avoir accès à la matrice de transformation de l'objet en question, au matériau qu'il utilise etc.

Maintenant, ça signifie que chaque vertex d'un objet va devoir aller chercher toutes ces informations. Si, par exemple, la caméra est stockée dans un uniform, le vertex va devoir faire une multiplication de matrice ( la transformation de l'objet * la caméra, je passe les détails sur l'ordre et la différence caméra/projection, ainsi que sur l'extraction de la matrice de la texture où elle est stockée).
Sauf que cette information est uniforme pour l'ensemble de l'objet. Tous les vertex appartenant à cet objet auront le même résultat.

Perso, je préférerais avoir une première passe où j'aurais X unités de calcul ( jusqu'à une par objet avec une approche triviale, plus sinon ) chacune faisant ce calcul et le stockant a un endroit puis émettant un nombre VARIABLE de vertex.
J'insiste sur le variable pour la raison suivante: je sais combien de vertex chaque objet va émettre. Je sais donc quel indices seront écrits par chaque objet et je peux donc tout générer en parallèle sans mutex ou autres sémaphores.

J'ai cette notion d'object ID aussi dans mon moteur, mais par contre, la passer en vertex attribute n'a pas de sens, vu que comme tu le dis, c'est une uniform, du coup de mon côté je la passe dans une push constant (qui correspondrait plus ou moins à un scalar uniform en OpenGL)...
Pour la prétransformation des sommets, je le fais pour les objets qui ont des animations (morph targets et/ou skinning, dans un compute shader), ce qui me permet de ne le faire qu'une seule fois par frame, plutôt qu'une fois par passe (deferred, shadows, voxelisation...).
Je ne le fais pas pour les autres objets, mais rien ne l'empêche...


Pour ton second soucis, ça pourrait être résolu avec le stencil buffer, mais (et c'est un truc que je regrette moi aussi) on ne peut pas écrire nous-même dedans.
Pour les erreurs d'arrondi, elles peuvent être amoindries en faisant un reverse depth buffer (les objets lointains ont comme depth 0, les objets proches ont comme depth 1), qui permet de profiter d'une meilleure précision pour les objets éloignés (https://developer.nvidia.com/content...ion-visualized)
Par contre, pour la 2D, rien ne t'empêche d'écrire cette layer en tant que depth de ton pixel, et donc de profiter du depth buffer en 2D aussi...

Et je n'ai pas parlé de la synthèse audio. Parfaitement descriptible avec plein de trucs hautement parallélisables ( un "échantillons shader" avec le temps en entrée et une amplitude en sortie, même pas forcément appelé pour chaque échantillon parce qu'on peut rajouter une interpolation et ... et ... et mille trucs ! ) et qui bénéficieraient des fonctions approximées et optimisées des cartes graphiques.

Et... tu as pensé aux compute shaders ?
Parce que les fixed functions c'est uniquement pour la rastérisation (ou le ray tracing qui a ses propres fixed functions), mais les compute shaders n'ont pas ces limitations.

[daerlnaxe]

...

salut, je ne programme pas des jeux, des ihm uniquement donc je ne vais pas parler sur le point programmation. Par contre je suis un joueur depuis la fin 80 début 90, je m'intéresse fortement au rétrogaming au point d'avoir cherché des solutions régulièrement et fait un tuto récemment pour pouvoir jouer avec d'excellentes conditions aux jeux win9x, entre l'accès à la mémoire, le début des cartes 3d c'est une période compliquée...

bref...

Je pense que tu as l'impression d'une compatibilité, or elle ne l'est pas. J'avais aussi cette impression des jeux pc qui traversaient le temps, après tout.. j'ai mon exe et mon pc sait toujours lancer les exe. On a des couches de compatibilité avec les windows etc etc... mais tout ça malheureusement c'est une lourde erreur. Pour vouloir non pas m'affranchir totalement de gog, steam mais avoir le choix de lancer à tout moment MES isos, de MES jeux en boite... en fait c'est une galère sans nom le plus souvent. Je ne dis pas que c'est insurmontable mais en réalité s'il est super simple de lancer un vieux jeu gog ou steam, c'est que du travail a été fait en amont.

Un super bon exemple c'est de lancer command and conquer gold, donc avec une résolution un peu améliorée etc etc... Le protocole réseau n'existant plus si tu le colles dans un wrapper tu prends une erreur, si tu le mets en mode compatibilité tu prendras aussi une erreur... et ainsi de suite. En fait bien souvent la communauté passe par là et va refaire quand c'est possible, un moteur de jeu (diablo, baldur's gate en repiquant sur le second opus ) etc... Personnellement moi ça ne me va pas car ça s'accompagne souvent de "qos" qui changent des détails du gameplay et je veux préserver mon expérience de jeu c'est pourquoi je me suis rendu compte rapidement des soucis. et pour revenir sur C&C, le remaster tombe vraiment à pic... Mais là aussi on n'aura pas la garantie sur tous les jeux, un bel exemple avec ff7, plus de sources donc remake et en fait tout est changé de A à Z.

Récemment pour le glide et opengl j'ai utilisé un proof of work basé sur mesa sur qemu, il faut recompiler (et le mec voulant tirer monnaie de ça le laisse en libre mais explique le minimum et surtout ne répond à rien dès qu'il y a des soucis pour compiler, et bon sang il y en a énormément... Enfin je suis même gentil quand je dis qu'il explique, il a expliqué à d'autres avant moi certains détails et entre expérimentation, tâtonnements multiples j'ai enfin réussi à boucler). Et ça tourne correctement avec une pseudo 3DFX via un accès direct au gpu, et je vais pas relancer la machine en y collant une pièce, j'ai fait du comparatif sur 86box, dosbox et un max de choses j'ai même 2-3 vidéos online avec QEMU, là où des mecs te montrent de jolies images sous 86box en te parlant de 200mmx et plus mais sans mettre le son... moi tu as le son et la vidéo. Et pourquoi pas le son, et bien parceque ça foire totalement. Et w98 sur dosbox et forks et bien c'est parfois/souvent un bon bosd dans les gencives sans prévenir. Et quand tu creuses tout ça, et bien ça s'explique car les jeux avaient une autre manière d'être développés etc etc.. même si opengl existe encore.

J'ai même tiré la sonnette d'alarme et visiblement peu s'en rendent compte et faire le nécessaire:
- Via les plateformes nous n'vaons plus aucune garantie de préservation du jeu
- L'absence de physique peut être nuisible pour le futur
- Le fait que les jeux en physique ne passent plus au profit d'$etre tributaire pour les vieux jeux de plateformes est en train de massacrer le patrimoine et ça va aller vers bien pire. Si tu regardes dans les détails tu as des jeux dont la langue n'est plus disponible, d'autres dont on a pris la version censurée.. et encore heureusement qu'encore une fois la communauté fait le nécessaire, quand c'est possible et quand elle a encore la flamme, mais ça disparait de plus en plus.


je t'invite donc en fait à reprendre contact non avec l'image que tu te fais, mais l'image réelle et de dresser un bilan, je ne dis pas que tu as tort ou raison et sincèrement j'aimerai vraiment avoir la certitude que des jeux vont traverser les ages mais en réalité c'est très très mal barré. ET pour ma part étant largement plus fan des rpgs US façon Fallout, de certains jeux Japonais comme Shadow Of Colossus, j'ai vraiment peur de voir disparaître des chefs d'oeuvre, si c'était que du FIFA ça me serait un peu égal, même si je ne devrais pas juger. Et c'est fou car à côté il est dix fois plus simple de jouer à un jeu ps1 via un émulateur et sa galette que de lancer un jeu pc de l'époque sans passer par les artifices dont j'ai parlé. En fait on a tous surfé sur une certitude, qui était valable un temps mais qui ne l'est plus, un jeu pc contrairement aux jeux consoles supportait que les générations changent, du moins après les jeux DOS car tout le monde se souvient un peu de la galère que c'était mine de rien avec des jeux qui était en mode hyperespace en raison des fréquences trop élevées des processeurs..
.Sauf qu'en fait on se trompe.

Je me souviens aussi d'une prise de tête avec un des participants c'est pas parti de lui, mais justement en ce qui me concerne j'aimerais pouvoir remettre au gout du jour de vieilles architectures , ne serait ce que miniaturisée pour permettre cette fameuse compatibilité, ce qui serait largement plus simple.