IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les évolutions programmées de Qt 3D avec Qt 5.14 et Qt 6
L'amélioration de la performance au programme, notamment grâce à Vulkan

Le , par dourouc05

174PARTAGES

10  0 
Qt 3D est le moteur 3D de Qt, dont l’histoire n’a pas été un long fleuve tranquille. Les premières préversions ont commencé à circuler du temps de Qt 4, il a ensuite fallu quelques années pour voir le travail sur ce moteur achevé, en même temps que Qt 5.5. Pour Qt 6, son avenir semble légèrement menacé, puisque la Qt Company travaille sur une autre intégration de la 3D dans les interfaces Qt Quick. Les deux moteurs n’ont pas les mêmes objectifs : Qt 3D est accessible tant en C++ qu’en QML, contrairement à Qt Quick 3D (même si un API C++ n’est pas impossible) ; Qt 3D travaille en parallèle avec le moteur d’exécution de Qt Quick, alors que Qt Quick 3D en est la prochaine évolution majeure : Qt Quick 3D sera disponible uniquement sous licence GPL (ou commerciale), alors que Qt 3D l’est aussi sous la LGPL.

En fait, la différence entre les deux est plus fondamentale : Qt 3D est prévu d’abord comme un moteur 3D extrêmement flexible, avec aussi peu d’hypothèses que possible sur ses utilisations (techniques de rendu, intégration dans les scènes Qt Quick, etc.). Cela étant, il faut certaines connaissances en 3D pour arriver à l’utiliser correctement : pour éviter de limiter les possibilités, on doit assez vite descendre dans les détails du graphe de scène. Au contraire, Qt Quick 3D est prévu pour être bien plus simple d’emploi, quitte à limiter ses possibilités : adapter le rendu à ses besoins sera bien plus compliqué qu’avec Qt 3D.

[h=2]KDAB Kuesa[/h]

Pour tenter de trouver un terrain d’entente entre les deux mondes, KDAB a travaillé sur Kuesa, dont l’objectif principal est de faciliter le chargement de données 3D à destination de Qt 3D. Kuesa contient notamment des outils d’exportation des modèles 3D depuis Blender et 3DS Max, mais aussi un module d’importation de fichiers gtTF 2 (format de description de scènes et de modèles à base de JSON). La version 1.1 (pas encore sortie) apportera notamment une implémentation complète de la norme glTF 2, notamment pour la gestion des animations et des matériaux.



[h=2]Qt 3D dans Qt 5.14 et 5.15[/h]

À court terme, Qt 3D continuera d’évoluer, notamment pour améliorer sa performance. L’utilisation de processeur par image affichée devrait être significativement réduite, mais aussi la quantité de synchronisation entre les fils d’exécution.

Le premier axe de développement est l’architecture multifil du moteur. Il est nativement prévu pour utiliser plusieurs fils d’exécution, mais au détriment d’un certain nombre de complications dans l’implémentation à cause de l’exécution asynchrone de tâches. Ainsi, Qt 3D fonctionne de manière suboptimale sur du matériel embarqué, notamment à cause de l’allocation de mémoire ou de la gestion des sémaphores. Pour limiter les conséquences, l’aspect Thread disparaît avec Qt 5.14. Il sera toujours possible de gérer le set de fils d’exécution, mais à l’aide d’une variable d’environnements.

Qt 3D utilise le rendu dans des FBO, y compris pour les cas les plus courants. Cela signifie que l’interface est d’abord affichée dans une texture, pas directement à l’écran. Pour la plupart des plateformes, ce système fonctionne bien et s’intègre facilement à Qt Quick (qui n’a qu’à lire cette texture et à l’afficher sur un composant). Cependant, certains périphériques ont une implémentation poussive des FBO : cette architecture pose de gros problèmes de performance. C’est pour cela que Qt 3D proposera bientôt de désactiver le rendu par FBO dans les cas où il n’est vraiment pas nécessaire, grâce à la propriété compositingMode du composant Scene3D.

La troisième zone de changements majeurs est le système de notifications de changements. Le travail continue toujours pour améliorer la performance, puisqu’il faut reconstruire ce système de zéro. Il sert à diffuser les informations de changement de propriété entre les aspects de Qt 3D. Jusqu’à présent, l’implémentation passait un message pour chaque changement, ce qui devient vite une limite de performance quand il y a des milliers d’entités. La nouvelle implémentation sera plus simple sur les principes, avec une synchronisation directe entre les aspects au moindre changement. Toutes les propriétés d’un objet peuvent alors être changées en même temps, plutôt que de devoir envoyer un message par propriété changée : pour des scènes comprenant plusieurs milliers d’entités, la distribution des changements prend deux à trois fois moins de temps.

[h=2]Qt 3D dans Qt 6[/h]

Pour Qt 6, les développeurs de Qt 3D prévoient des changements plus profonds. Notamment, Qt 6 apportera une nouvelle couche d’abstraction du matériel pour gérer le rendu avec n’importe quelle API de bas niveau : OpenGL, Vulkan, Metal, DirectX 12… et pourquoi pas d’autres. Qt 5 est implémenté uniquement par-dessus OpenGL, ce qui limite sa performance sur du matériel récent. Qt RHI est le nom de cette nouvelle abstraction, par-dessus laquelle Qt 3D fonctionnera.

Cette solution permettra d’améliorer la performance de l’implémentation de Qt 3D, puisque les nouvelles API sont de plus bas niveau : certaines choses étaient effectuées par le pilote graphique et devront être gérées par Qt 3D (notamment les allocations de mémoire), mais cela permettra d’améliorer l’implémentation (tant en performance brute qu’en consommation d’énergie). Par exemple, avec OpenGL, toutes les commandes de rendu doivent être soumises à chaque image à afficher : avec Vulkan, on peut stocker des listes de commandes à effectuer pour le rendu.

De plus, la génération des commandes de rendu peut se faire en parallèle (tant avec Vulkan, Direct3D 12 que Metal), ce qui permet d’exploiter mieux les fils d’exécution de Qt 3D. Une restructuration du graphe de scène (pour le rendre plus linéaire) facilitera la génération des changements entre deux images, grâce à une mise en cache agressive.

Les premiers résultats sont intéressants. Avec l’état actuel de Qt RHI, sur certaines scènes de test, il est possible de monter à six cents images par seconde, avec mille entités, sur un PC de bureau de moyenne gamme. En visant soixante images par seconde, la charge CPU ne monte qu’à un pour cent sur un seul cœur.

Sources : The Future of Qt 3D, What about Qt 3D in Qt 6?, KDAB releases Kuesa.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de MaximeCh
Membre éprouvé https://www.developpez.com
Le 17/01/2020 à 17:12
J'ai cru voir des slides disant que QPainter allait passer sur RHI : ça voudrait dire qu'on pourra faire de l'accélération GPU avec le framework Graphics View ? (plus simplement qu'avec QOpenGLWidget)
0  0