Sujet résolu
L'auteur a trouvé une solution à son problème.
il y a 2 ans
Sponsorisé
Connectez-vous pour masquer les pubsil y a 2 ans
SoniaMabrouk
2 ans
C'est de la merde
Ceci
¡Esta serpiente marina MATÓ a un Celestino! https://streamable.com/fmjgjb
il y a 2 ans
Vulkan c'est cool non ?
Vulkan c'est l'API qui te donne un contrôle total au prix de ta santé mentale. Opengl simplifie beaucoup de choses en cachant les détails bas niveau et en fournissant des fonctions pour la configuration et le rendu. Vulkan, en revanche, offre un contrôle extrêmement granulaire,, obligeant le dev à gérer explicitement presque tous les aspects du rendu, de la gestion de la mémoire à la synchronisation des opérations.
Voilà à quoi ressemble généralement une boucle de rendu avec opengl :
Initialisation
- configurer le contexte opengl, charger et compiler les shaders
- créer et configurer les buffers (VBO, VAO)
- définir les états (opengl fonctionne un peu comme une state machine en ce qui concerne la profondeur, le culling)
Boucle de rendu
- clear de buffers
- activation des shaders et lisaison avec les VAO
- mettre à jour les uniformes si nécessaire
- dessiner les objets
- swap les buffers de la fenêtre pour afficher l'image rendue
Avec vulkan
Initialisation
- créer l'instance vulkan
- sélectionner le périphérique physique et créer le périphérique logiciel
- configurer et créer la swapchain
- créer les semaphores et fences pour la synchronisation
- créer les buffers de commande
- créer et configurer les pipelines graphiques
- créer les framebuffer et render passes.
Boucle de rendu
- acquérir l'image de la swapchain
- réinitialiser le buffer de commandes/enregistrer les commandes de rendu (laison des pipelines, des buffers de vertex, des descriptions de vertex, etc.)
- envoi des commandes à la queue graphique en utilisant les semaphores pour la synchronisation
- présenter l'image de rendu en synchronisant encore une fois avec les semaphores
Pour afficher un triangle, tu en as pour +1000 lignes de code avec vulkan
Voilà à quoi ressemble généralement une boucle de rendu avec opengl :
Initialisation
- configurer le contexte opengl, charger et compiler les shaders
- créer et configurer les buffers (VBO, VAO)
- définir les états (opengl fonctionne un peu comme une state machine en ce qui concerne la profondeur, le culling)
Boucle de rendu
- clear de buffers
- activation des shaders et lisaison avec les VAO
- mettre à jour les uniformes si nécessaire
- dessiner les objets
- swap les buffers de la fenêtre pour afficher l'image rendue
Avec vulkan
Initialisation
- créer l'instance vulkan
- sélectionner le périphérique physique et créer le périphérique logiciel
- configurer et créer la swapchain
- créer les semaphores et fences pour la synchronisation
- créer les buffers de commande
- créer et configurer les pipelines graphiques
- créer les framebuffer et render passes.
Boucle de rendu
- acquérir l'image de la swapchain
- réinitialiser le buffer de commandes/enregistrer les commandes de rendu (laison des pipelines, des buffers de vertex, des descriptions de vertex, etc.)
- envoi des commandes à la queue graphique en utilisant les semaphores pour la synchronisation
- présenter l'image de rendu en synchronisant encore une fois avec les semaphores
Pour afficher un triangle, tu en as pour +1000 lignes de code avec vulkan
La meilleure façon de châtier les hommes est de toujours donner ce qu'ils réclament.
il y a 2 ans
Vulkan c'est l'API qui te donne un contrôle total au prix de ta santé mentale. Opengl simplifie beaucoup de choses en cachant les détails bas niveau et en fournissant des fonctions pour la configuration et le rendu. Vulkan, en revanche, offre un contrôle extrêmement granulaire,, obligeant le dev à gérer explicitement presque tous les aspects du rendu, de la gestion de la mémoire à la synchronisation des opérations.
Voilà à quoi ressemble généralement une boucle de rendu avec opengl :
Initialisation
- configurer le contexte opengl, charger et compiler les shaders
- créer et configurer les buffers (VBO, VAO)
- définir les états (opengl fonctionne un peu comme une state machine en ce qui concerne la profondeur, le culling)
Boucle de rendu
- clear de buffers
- activation des shaders et lisaison avec les VAO
- mettre à jour les uniformes si nécessaire
- dessiner les objets
- swap les buffers de la fenêtre pour afficher l'image rendue
Avec vulkan
Initialisation
- créer l'instance vulkan
- sélectionner le périphérique physique et créer le périphérique logiciel
- configurer et créer la swapchain
- créer les semaphores et fences pour la synchronisation
- créer les buffers de commande
- créer et configurer les pipelines graphiques
- créer les framebuffer et render passes.
Boucle de rendu
- acquérir l'image de la swapchain
- réinitialiser le buffer de commandes/enregistrer les commandes de rendu (laison des pipelines, des buffers de vertex, des descriptions de vertex, etc.)
- envoi des commandes à la queue graphique en utilisant les semaphores pour la synchronisation
- présenter l'image de rendu en synchronisant encore une fois avec les semaphores
Pour afficher un triangle, tu en as pour +1000 lignes de code avec vulkan
Voilà à quoi ressemble généralement une boucle de rendu avec opengl :
Initialisation
- configurer le contexte opengl, charger et compiler les shaders
- créer et configurer les buffers (VBO, VAO)
- définir les états (opengl fonctionne un peu comme une state machine en ce qui concerne la profondeur, le culling)
Boucle de rendu
- clear de buffers
- activation des shaders et lisaison avec les VAO
- mettre à jour les uniformes si nécessaire
- dessiner les objets
- swap les buffers de la fenêtre pour afficher l'image rendue
Avec vulkan
Initialisation
- créer l'instance vulkan
- sélectionner le périphérique physique et créer le périphérique logiciel
- configurer et créer la swapchain
- créer les semaphores et fences pour la synchronisation
- créer les buffers de commande
- créer et configurer les pipelines graphiques
- créer les framebuffer et render passes.
Boucle de rendu
- acquérir l'image de la swapchain
- réinitialiser le buffer de commandes/enregistrer les commandes de rendu (laison des pipelines, des buffers de vertex, des descriptions de vertex, etc.)
- envoi des commandes à la queue graphique en utilisant les semaphores pour la synchronisation
- présenter l'image de rendu en synchronisant encore une fois avec les semaphores
Pour afficher un triangle, tu en as pour +1000 lignes de code avec vulkan
Pour un dev peut-être que c'est horrible. Mais moi je suis pas dev
Si j'avais pas vulkan, je pourrais juste pas jouer sous linux.
Si j'avais pas vulkan, je pourrais juste pas jouer sous linux.
il y a 2 ans
Pour un dev peut-être que c'est horrible. Mais moi je suis pas dev
Si j'avais pas vulkan, je pourrais juste pas jouer sous linux.
Si j'avais pas vulkan, je pourrais juste pas jouer sous linux.
La meilleure façon de châtier les hommes est de toujours donner ce qu'ils réclament.
il y a 2 ans
Sponsorisé
Connectez-vous pour masquer les pubs
proton c'est les jeux via steam. Mais même avec les jeux steam avec proton, je peux avoir des soucis sans DXVK. Sinon j'ai des prgrammes qui tournent pas sans vulkan. Je vois souvent opengl et vulkan activé dans les paramètre de Lutris. Souvent le programme a besoin des deux pour fonctionner.
il y a 2 ans
En ligne
147
Sur ce sujet0



















