Comment nous avons overclocké CAD COMPASS-3D → Partie 1

20 ans se sont écoulés depuis la sortie de la première version 3D de KOMPAS - V5.11. Pendant ce temps, nous avons réalisé que les besoins de nos utilisateurs croissaient proportionnellement aux capacités de KOMPAS-3D, tout comme la fonctionnalité de KOMPAS augmentait proportionnellement aux besoins des utilisateurs. Un seul hic: construire la partie technologique pendant de nombreuses années, nous avons rencontré le problème de performance lors de la réalisation de grands projets complexes. Maintenant, cette ligne a été dépassée et nous sommes prêts à dire comment nous avons réussi à accélérer KOMPAS-3D dans plus de 30 opérations de base.



La patience ne peut pas être accélérée


Comment avons-nous compris qu'il était temps «d'accélérer»?


S'il y a 12 ans, il y avait suffisamment de travail avec des assemblages pouvant aller jusqu'à plusieurs milliers de composants, les utilisateurs de KOMPAS veulent maintenant réaliser des projets complexes impliquant 300 000 composants dans un assemblage, et quelques millions seront peu.



L'évolution des projets utilisateurs KOMPAS-3D: à gauche les équipements de fraisage et de rotor de déneigement des tracteurs K-700A, K-703MBA , à droite l' installation Steam-Gas PGU-410 MW . Si c'est difficile à voir, cliquez sur l'image.

Dans ServiceDesk - support technique - nous avons reçu des demandes dans le style "Je ne peux pas ouvrir mon usine le matin" et "le modèle a ouvert, mais il ne tourne pas".

Il n'y a qu'une seule conclusion - COMPAS a nécessité une révision sérieuse.

Premiers changements


La tâche principale consiste à augmenter les performances du système lorsque vous travaillez avec de grands assemblages. Et d'augmenter non pas de 10-30% conditionnel, mais plusieurs fois.

Pour résoudre ces problèmes, nous avons formé en 2015 un groupe de travail pour accélérer KOMPAS-3D. Une sorte d'escouade de réponse rapide de programmeurs, testeurs et analystes.

Notre équipe de vitesse

AIDE: nous avons travaillé sur l'accélération auparavant - ce sont à la fois des optimisations et de nouvelles fonctions qui nous permettent de résoudre certains des problèmes lors du travail avec de grands assemblages. Cependant, les tâches n'étaient pas aussi ambitieuses qu'elles le sont actuellement et le travail n'était pas si volumineux.


Comment avez-vous choisi les critères d'accélération?


Nous avons choisi 5 directions d'accélération:

  • rendu (rotation, mouvement et zoom de l'image du modèle),
  • ajout de composants à un grand assemblage
  • ouverture de l'assemblage
  • édition dans les assemblages,
  • projection.

Lors du choix de ces domaines, nous nous sommes appuyés sur plusieurs sources:

  • propre expérience et recherche,
  • analyse des demandes d'assistance technique et analyse de la base d'erreurs (dans nos outils il y a un label spécial «performance», où sont notés les problèmes critiques de performance),
  • les résultats du sondage auprès des utilisateurs (les utilisateurs remplissent généralement ces questionnaires lors des événements ASCON),
  • des pouvoirs supérieurs .


Ici, nous discutons de quelque chose.

Parallèlement à la formation du groupe de travail, nous avons créé notre propre espace d'information - une base de connaissances - nous y avons noté toutes les tâches, collecté et systématisé des idées dans les domaines d'accélération possibles. En conséquence, des exigences ont commencé à se former avec des scénarios de travaux futurs, grâce auxquels il était possible de contrôler les performances.

Un autre axiome que nous avons adopté en travaillant sur la version: la productivité ne peut pas être simplement prise et améliorée, puis oublié. Il était nécessaire de mesurer et d'enregistrer l'état actuel, à partir duquel nous pouvions ensuite repousser. À cette époque, le point de départ était la version V16 (notre histoire est toujours en 2015), qui devait être contrôlée par des scripts de nos savoirs traditionnels. La performance de plusieurs points clés a été contrôlée manuellement, mais maintenant ce processus est automatisé grâce au POI.
Anton Sidyakin, programmeur, chef d'équipe:

«Nous avons automatisé les processus grâce au système introduit - POI (Points of Interest). Ce sont des balises spéciales situées dans le code source. Selon eux, en exécutant des scripts dans KOMPAS-3D décrits par le langage utilisateur, vous pouvez obtenir un rapport compréhensible non seulement pour le programmeur, mais aussi pour les analystes avec des testeurs et aide à découvrir ce que KOMPAS-3D fait à un certain moment et combien de temps y est consacré. Ces informations peuvent ensuite être traitées automatiquement et comparées aux données source. "


Résultats des tests de performances automatiques. Au fait, qui a lu à cet endroit sait maintenant que la dalle KDPV est un symbole de notre équipe d'accélérateurs. Ils considèrent le code lent comme du code lent)


Quels modèles ont été utilisés pour la comparaison?


Nous avons décidé de nous concentrer sur de véritables modèles utilisateurs répondant aux critères des «grands ensembles».

La base de données des modèles du concours Aces de modélisation 3D par ordinateur a été très utile.

Voici des captures d'écran de nos modèles préférés. Bien sûr, ce n'est pas tout, et, en outre, nous sommes convaincus que les meilleurs modèles de ces dernières années deviendront bientôt familiers et que KOMPAS travaillera avec eux non pas à la limite, mais dans son mode régulier à haute vitesse.

TrolleybusUnité vapeur-gaz CCP-410 MW
Boîte de vitesse de centrale marineInstallation technologique sous vide


Lorsqu'il était nécessaire de charger le système encore plus, en plus de ces modèles, un «méli-mélo préfabriqué» particulier était également utilisé, par exemple:



Nous avons également utilisé des modèles synthétiques: dans certains cas, certains problèmes sont plus prononcés sur eux et ils sont plus pratiques à utiliser pour le débogage et les tests.

À propos du développement et des résultats obtenus


Dessin


Tout d'abord, ils ont essayé d'accélérer le rendu (ce qui a également été demandé par la majorité des utilisateurs qui ont participé à l'enquête).

La vitesse de rendu est critique dans tous les processus où le modèle est positionné ou son affichage change. Et ce n'est pas seulement la rotation, le mouvement ou le zoom du modèle. La vitesse de rendu est également importante dans les processus où l'image du modèle est mise à jour:
  • Ajout d'un composant à un assemblage
  • sélection d'objets de base pour les partenaires (faces, arêtes, etc.),
  • mise en évidence des parties sélectionnées du modèle (composants, faces),
  • modifier la visibilité des objets (masquer / afficher le composant).

Et ce sont loin de tous les cas où le sous-système de visualisation est utilisé. Par conséquent, il est clair pourquoi l'accélération du rendu est devenue une priorité pour nous.

Dans le même temps, il était important non seulement d'utiliser les capacités des cartes vidéo modernes et productives, mais aussi de ne pas oublier ceux qui utilisent un matériel pas si solide et moderne.

Le résultat du travail a été la mise en œuvre de deux options de rendu:
  • De base - Active les extensions Open GL 2.0. Moins exigeant sur les performances de la carte vidéo. Donne une bonne accélération de rendu,
  • «Amélioré» - utilise les extensions modernes d'OpenGL 4.5. Exigeant sur les caractéristiques de la carte vidéo. Donne une accélération de rendu maximale sur les cartes modernes


Indice:

Paramètres de rendu pour v18.

Par défaut, "Détection automatique" fonctionne - l'option souhaitée est sélectionnée en fonction des extensions OpenGL prises en charge.


Yuri Korchagin, programmeur:

«Dans le problème des performances d'affichage de grandes scènes, il est clair que beaucoup de ressources sont dépensées pour faire le tour de la scène et calculer les paramètres avec lesquels la primitive doit être affichée.

Un autre problème est associé à un grand nombre d'appels de tirage (appels à l'API OpenGL, qui conduisent à la sortie de la géométrie dans le tampon de trame).

L'état initial supposait également le transfert de toutes les données vers la carte vidéo à partir de la RAM. Et ce sont des millions de triangles dans le cas d'un grand assemblage.

Les corrections cosmétiques ne pouvaient pas être supprimées ici, car une augmentation multiple de la productivité était nécessaire. Par conséquent, il a été décidé de réécrire en grande partie le module de visualisation.

La première étape a été d'utiliser la mémoire vidéo pour mettre en cache les données de dessin (triangulation, filaire, faces). En déplaçant ces données vers le GPU, nous avons réussi à obtenir une augmentation de 2 à 3 fois du FPS.

Cela a été suivi par la création d'un modèle de données adapté à la visualisation. Autrement dit, nous nous sommes débarrassés des demandes de modèle 3D, qui peuvent être assez gourmandes en ressources, ce qui a également donné son effet positif.

L'étape suivante consistait à étudier la qualité et le volume de la triangulation. Souvent, de petits détails étaient affichés avec une précision excessive, et vice versa - dans certaines situations, au lieu de surfaces lisses, l'utilisateur voyait un modèle «haché» à l'écran.

Nous avons décidé d'utiliser plusieurs niveaux de détail et d'appliquer l'approximation des primitives en tenant compte de l'écart angulaire. De cette façon, deux oiseaux avec une pierre ont été tués: ils ont amélioré la qualité et éliminé la charge excessive sur le GPU. "

Spoiler: A propos de la triangulation

Spécifié par Nikita Batyanov, un ingénieur analytique:

«Pour un affichage des modèles plus correct et généralement agréable, nous avons décidé de compléter les paramètres de triangulation par une déviation angulaire maximale. Auparavant, nous utilisions uniquement le paramètre d'écart linéaire maximal.

Permettez-moi de vous rappeler: pour que la carte vidéo dessine nos représentations théoriques des objets, il faut les décomposer en triangles. Plus il y a de tels triangles, plus l'image aura l'air «idéale», mais plus la charge sur la carte vidéo sera forte.

L'algorithme de triangulation utilisant la déviation angulaire maximale vous permet d'afficher plus précisément certains modèles, sans augmenter le nombre de triangles autant que si seule la déviation linéaire maximale était utilisée.

"Nous pouvons dessiner des objets plus petits par rapport aux dimensions de l'ensemble du modèle, tout en surestimant légèrement le nombre de triangles."


Yuri Korchagin, programmeur:

«Eh bien, l'affichage du modèle est devenu plus rapide, mais pas autant que nous le souhaiterions. À ce stade, nous avons réalisé que nous ne pouvions pas tirer le meilleur parti de cette approche.

D'autre part, l'utilisation des dernières approches nécessitera les cartes vidéo les plus récentes, ce qui contredit les exigences de compatibilité et certains utilisateurs ne l'apprécieront manifestement pas. Par conséquent, les améliorations décrites ci-dessus sont devenues disponibles en tant qu'option de rendu «de base».

Et puis le plaisir a commencé ... "


Dans la partie suivante, nous continuons notre histoire sur le rendu, et montrons également les résultats de la mesure de la vitesse de rendu pendant la rotation de l'assemblage, les calculs MTC, l'ajout de composants à l'assemblage et parlons de l'apparence d'un type de charge partielle.

Et pour le dessert, ils vous ont laissé une vidéo pour comparer la vitesse de rendu pendant la rotation, la mise à l'échelle et le décalage du réducteur d'une centrale marine.



La fin de la première partie. À suivre .

Source: https://habr.com/ru/post/fr444714/


All Articles