Discussion :

[KevinduC]

Bonsoir à tous chers Vulkaniens, cela fait longtemps que je crée des projets OpenGL mais j'ai toujours été confronté à des soucis de performance et je me demande parfois si je ne devrais pas me tourner vers Vulkan. Un exemple tout simple : Dans un récent projet j'ai un terrain constitué de 16 millions de sommets, c'est fluide sauf si je veux ajouter des effets d'ombres, reflets et réfraction car cela nécessite de faire quatre fois le même rendu dans un frame, j'ai essayé et je peux vous dire qu'avec 16 millions de sommets ça devient vite lent. Ceci ajouté au fait que OpenGL n'est plus mis à jour depuis un certain temps suffit à me faire hésiter. Ou alors est-ce mon PC qui n'est pas assez performant ? Est-ce que je devrais acheter un PC plus performant voire un PC de gamer et rester sur OpenGL ?

Je me pose aussi des questions : Est-ce que Vulkan est différent d'OpenGL ? Par exemple y a-t-il des VBO/VAO ? Y a-t-il des FBO pour récupérer le contenu des tampons couleur et profondeur ? Si non existe-t-il d'autres méthodes pour gérer les ombres et les reflets ?

Merci d'avance pour vos réponses, je suis dans le doute, je veux savoir si avant de me lancer dans l'apprentissage de Vulkan je pourrai ensuite retrouver des principes d'OpenGL.
(Au passage je me permets de glisser une petite question : C'est quoi une famille de queues ? Je n'arrive pas à saisir)

[Mat.M]

d'une part même sans le calcul des ombres projetées vous voyez pas que c'est pas la bonne méthode ?
16 millions de polygones en une fraction de secondes on peut avoir un rendu fluide mais ça fait beaucoup à rendre à l'écran donc faut bien comprendre qu'en dessinant une portion de terrain celle qui est inscrite dans le View Frustum les performances seront accrues non ?
Donc vous avez dans un premier temps un problème d'optimisation spatiale je crois que je l'ai écris dans un message précédent mais bon...peine perdue.
Après pour répondre à la question est-ce que vous utilisez du code GPU pour programmer les pixels et vertex shaders ?
Si ce n'est pas le cas oui Vulkan sera plus adaptée

[Bousk]

Je serais surpris que tu atteignes les limites de OpenGL et nécessites un passage à Vulkan. Entendre par là : aucune chance.
Tes problèmes de performances sont à 99.9999999% pas liés à OGL mais à ton code l'utilisant.
Et c'est certainement pas ça qui va rendre magique d'afficher 16 millions de sommets.

[Kannagi]

Je veux savoir si avant de me lancer dans l'apprentissage de Vulkan je pourrai ensuite retrouver des principes d'OpenGL.

Non tout ce qui te servira sur OpenGL , ne te servira pas pour Vulkan , c'est deux approche totalement différente .
En codant sur d'ancienne machine , je me disais déjà que OpenGL pose de sacrée soucis , je pense que c'était une grave erreur de faire une API qui se base sur les SGI de l'époque , dépassant les années 2000 OGL allait poser soucis un moment ou a un autre :p
OpenGL à une logique d'un vieux GPU , tout le soucis vient de là.

[dragonjoker59]

Après pour répondre à la question est-ce que vous utilisez du code GPU pour programmer les pixels et vertex shaders ?
Si ce n'est pas le cas oui Vulkan sera plus adaptée

Tu peux préciser ce que tu appelles du "code GPU" ? Tu parles de GLSL ?
Si c'est le cas, Vulkan ne sera pas plus adapté, ce qui sera plus adapté c'est d'écrire ses shaders soi-même (vu que de toute façon les shaders implicites sont dépréciés depuis au moins OpenGL 3.0).

Sinon, je plussoie la réponse de Bousk ainsi que la première réponse de Mat.M.
Le problème ne vient pas d'OpenGL mais de ton code

Vulkan peut t'apporter quelque chose si tu es CPU bound (c'est à dire que ton CPU est à fond et que ton GPU se touche en l'attendant), car il te permet de découpler les 2 de manière plus précise (mais cette précision vient au prix d'une complexité accrue).

J'ai passé Castor3D sous Vulkan, et j'ai perdu en perfs lors de la première version de ce passage, je suis seulement en train de rattraper (et dépasser) les perfs que j'avais auparavant, 3 ans et 2 versions plus tard.

Pour les différences entre OpenGL et Vulkan, il y en a beaucoup, car Vulkan est plus "bas niveau" qu'OpenGL, dans le sens où l'API ne te mâche pas le travail du tout.
Il est donc du coup bien plus verbeux, mais aussi bien plus logique à mon sens (après avoir fait de l'OpenGL et aimé ça pendant 12 ans, étant maintenant sous Vulkan, je ne reviendrais pour rien au monde sous OpenGL)
Les VAO par exemple, c'est du caca en boîte, inutile mais obligatoire, et ça n'existe heureusement pas sous Vulkan : on a les vertex attributes et les vertex bindings et "c'est tout".
Plus ou moins tous les autres buffers sont là en Vulkan, à part les PBO.
Les FBO existent aussi, mais ont récemment été remplacés par une extension qui permet de s'en passer (on passe donc directement les image views qu'il aurait utilisées).

Grosso modo, si tu passes à Vulkan, tu ne seras pas perdu par le manque des principes de haut niveau, mais par leur utilisation à bas niveau (création, configuration, binding, ...).

[Mat.M]

@dragonjoker59 oui c'est cela le shading language

[LittleWhite]

Bonjour,

Dur d'ajouter après ce que mes compères ont déjà dit.
Afficher 16 millions de sommets, c'est déjà bien. je veux dire, par là, que je pense que mon CPU/GPU intégré Intel ne sera pas capable d'afficher cela de manière fluide. Mais par conséquent, il faut aussi comprendre et se poser les bonnes questions ? En voici quelques unes :

• combien de triangles affichent les applications/jeux actuelles ? (Personnellement, je dirais que cela ne dépasse pas le million.) ;
• Y a t-il un vrai intérêt d'afficher tout cela ?
• si non (et la réponse est déjà connue, c'est : non), comment peut t-on réduire ce nombre ?

Donc, quel intérêt d'afficher autant de triangles (sachant que les autres ne le font pas (et tente d'économiser) ?

Fait amusant, je viens de faire l'opération : 1920 x 1080 et ça fait 2 073 600. Cela veut dire, que vous avez sur un écran classique 2 millions de pixels. Et vous allez me dire que vous avez 16 millions de sommets... soit, 8 sommets par pixels!!! Une hérésie

Bref, j'ai fait un encart car c'était amusant. Mais vous voyez bien que cela se passe pas comme ça dans la vraie vie.

Donc, une technique pour réduire drastiquement (cela dépend) le nombre de sommets qui doit être traité par la carte graphique : le frustrum culling. On ne traite que les sommets dans le champs de la caméra. Les autres, on les oublient, pas besoin que la carte graphique travaille dessus, alors qu'ils ne sont pas sur l'écran.
Ensuite, je me rappelle que vous faites une application qui affiche un terrain. Pour ce faire de rendu, on va faire les choses suivantes :

• utilisation d'une grille de sommets, où chaque sommet/point de la grille à une hauteur différente (pour pas que ce soit une pleine). On utilise généralement une heighmap pour déterminer la hauteur de ces sommets. On utilise des textures pour faire un rendu différent, suivant les zones (de la neige en montagne, du sable au bord de la mer). Tout ces détails (sable, neige), ce ne sont pas des géométries, ce sont juste des textures appliquées sur le terrain.
• on va faire du LOD !!!! (niveau de détail). ce qui est loin, n'a pas besoin d'avoir le niveau de détail de ce qui est proche de la caméra. N'oubliez pas, votre caméra est une caméra avec une perspective, ce qui est loin est petit. Un arbre au loin, c'est un sommet (point sprite). Un arbre à côté du joueur... peut être 1000 sommets

(J'en oublie des techniques)
Ah si : pour ajouter des détails, on utilise des normales map , et ça n'augmente pas le nombre de sommets. C'est magique (et ça existe depuis les années 90 , donc approuvé par Kannagi )

Bref, on peut réduire et vous devez réduire.

Avec OpenGL, on peut avoir un résultat proche de Vulkan, mais avec OpenGL. Juste avant que Vulkan soit une réalité (Mantle d'AMD venait d'être publiée), il y a eu une sorte de tendance qui a été nommée OpenGL Zero Overhead ( https://www.geeks3d.com/20140321/ope...iver-overhead/ ). Mais bon, encore une fois, c'est trop tôt pour vous, vous avez mieux à faire. Lorsque vous pourrez me dire : j'ai appliqué toute les techniques de base pour un tel rendu, j'ai utiliser telle et telle astuce (des trucs reconnus) et j'utilise OpenGL 4.6 et les extensions pour tirer à bout ma machine, alors oui, à ce moment là, on pourra dire que Vulkan pourrait (ou pas, car cela se vérifie) vous aider.

Aussi, vous parlez d'optimisation/performances. Avez vous pris un profileur GPU ? De mémoire, NVIDIA NSight est vraiment sympa pour ça, mais y en a d'autre.

Tout ce que vous pouvez faire en OpenGL, vous pouvez le faire en Vulkan. Juste, Vulkan, c'est plus bas niveau (vous avez plus de contrôle sur la carte graphique).

Les familles de queue sont des catégories de listes dans lesquelles ont y met des opérations qui doivent être traités par la carte graphique. Vous pouvez avoir une queue pour le rendu, une pour les update et je ne sais plus quoi. Cela fait deux familles (exemple bourrin).

Bref, dites nous:

• quelles sont les optimisations que vous avez mis en place ;
• quelles sont les techniques que vous utilisez ;
• (pour le fun), c'est quoi votre carte graphique ?

Vous voulez de la doc :

• les GPU Gems que NVIDIA a mis publiquement accessible ( https://developer.download.nvidia.co...ms_part01.html ).

[Kannagi]

[*]combien de triangles affichent les applications/jeux actuelles ? (Personnellement, je dirais que cela ne dépasse pas le million.) ;

Pour répondre :

Final Fantasy XV uses 100,000 polygons for its characters. Overall, Final Fantasy XV uses 5 million polygons per frame, pushing 150 million polygons per second.[2] This is one of the highest polygon counts known for a video game.

sinon la demo utilise elle aussi des millions de triangles :

Après ,c'est deux exemples sont pas forcément les plus pertinent , vu la qualité de rendu (et les années de dev derrière abattu par une armées d'ingénieur ).

Et on a pas dit ce qui fait 16 millions de triangle : par frame ou par seconde ?
Parce que par seconde une Wii peut le faire , par contre par frame ,doit pas y'avoir un jeu qui fait 16 millions de triangles par frame avec des triangles sans effets :p

Ah si : pour ajouter des détails, on utilise des normales map , et ça n'augmente pas le nombre de sommets. C'est magique (et ça existe depuis les années 90 , donc approuvé par Kannagi )

j'approuve