Un nouveau moteur de simulation de liquides pour Unreal Engine 4 : NVIDIA Cataclysm

L’annonce n’est pas encore officielle, mais le code source est déjà disponible et les vidéos en ligne : NVIDIA propose un nouveau solveur physique généraliste pour la simulation de liquides dans Unreal Engine (en sus de Flex).

Unreal Engine 4 est un moteur de jeu bien implanté dans le domaine, notamment chez les professionnels, avec un rendu très léché, même si les premiers développements ont eu lieu en 2005 et les premières démos publiques en 2012. De son côté, NVIDIA a une très bonne expérience dans le développement de simulations physiques, notamment avec son moteur physique PhysX ou la suite GameWorks.

Dernièrement, le code source d’une nouvelle démo est apparu sur les dépôts de NVIDIA, intégrant le solveur FLIP dans Unreal Engine 4.12.5. Les calculs s’effectuent sur le processeur graphique et leurs résultats s’intègrent dans la gestion des particules d’Unreal Engine. En temps réel, FLIP peut simuler jusque deux millions de particules.

Le code de simulation utilise une approche hybride (d’ailleurs, FLIP signifie fluid implicit particle) : l’information générée par la simulation est stockée au niveau de particules (comme Flex), tandis que les calculs sont réalisés selon une approche plus classique à base de grille.

Télécharger le code source de la démo. (enregistrement du compte GitHub nécessaire auprès d’Epic).
Source, image et vidéo : NVIDIA presents Cataclysm liquid solver for Unreal Engine 4.

Sortie de GammaRay 2.5

GammaRay est un puissant outil d’introspection pour les applications Qt, il sert notamment lors du débogage. (Une présentation plus complète en a été faite pour la précédente version.) KDAB décrit la version 2.5 comme la plus importante en termes de fonctionnalités : GammaRay est maintenant compatible avec Qt 5.7, permet l’introspection dans des scènes Qt 3D ; côté Qt Quick, il devient possible d’accéder aux chaînes de propriétés contextuelles et aux informations de type ; partout, GammaRay offre des statistiques sur les métaobjets.

L’interface de GammaRay a aussi été quelque peu revue, notamment pour la navigation dans le code source (tant C++ que QML), dans les objets et dans les fichiers de ressources. L’inspection à distance a également été améliorée, avec la possibilité de sélectionner des éléments Qt Quick et Qt Widgets, de rediriger les stimuli vers des widgets distants, de mesurer des distances dans une vue Qt Quick distante, de zoomer dans une interface distante.

Côté réseau, la communication peut maintenant se faire par IPv6. Il est aussi maintenant possible d’accéder aux informations sur le chiffrement SSL et sur les certificats utilisés par QSslSocket. Les témoins de connexion sont explorables par un outil dédié.

Télécharger GammaRay 2.5.0.
Sources : GammaRay 2.5 release, [Gammaray-interest] [ANNOUNCE] GammaRay 2.5.0.

Qt WebBrowser 1.0

Qt WebBrowser est un navigateur Web prévu spécifiquement pour les plateformes embarquées. Il exploite plus particulièrement Qt WebEngine, c’est-à-dire le moteur d’affichage derrière Google Chrome. Il gère donc les toutes dernières fonctionnalités de HTML5, tout en ayant une interface minimale prévue pour les écrans tactiles. L’utilisateur est relativement limité, mais les besoins de base sont assouvis : recherche dans une page, favoris, onglets, affichage de vidéos en plein écran et audio (selon les codecs disponibles), mode de navigation privée.

Pour le compiler, les besoins sont minimaux : ce navigateur exploite Qt Quick, Qt WebEngine et Qt VirtualKeyboard. Tous ces modules sont disponibles dans l’édition libre de Qt dès la version 5.7. Pour des performances acceptables, l’accélération OpenGL est requise, avec un gigaoctet de mémoire — même si les développeurs indiquent qu’il reste beaucoup de chemin à parcourir au niveau de l’utilisation des ressources.

Jusqu’à présent, Qt WebBrowser n’était qu’une démo livrée avec Qt for Device Creation, une version propriétaire de Qt ciblée pour les développeurs embarqué. Maintenant, il est disponible sous les licences GPL 3 et commerciale.

Source et image : Qt WebBrowser 1.0.
Voir aussi : la documentation, les sources.

Sortie de OpenMPI 2.0

MPI (message passing interface) est une norme très utilisée pour programmer des superordinateurs. De manière plus générale, l’API sert à distribuer des calculs sur plusieurs machines (jusque des centaines de milliers de processeurs), sans forcément l’architecture lourde d’un superordinateur ou d’un centre informatique (quelques machines sur un réseau Ethernet suffisent, pas besoin de connexions spécifiques comme InfiniBand). De manière générale, MPI lance le même programme sur tous les ordinateurs du réseau ; ces derniers peuvent alors communiquer en envoyant (MPI_Send) et en recevant des messages (MPI_Recv) de manière synchronisée — pour les fonctionnalités de base.

Cette norme compte principalement deux implémentations libres : MPICH, l’historique, dont beaucoup de versions commerciales dérivent (comme Intel ou Microsoft), l’implémentation de référence ; OpenMPI, qui a débuté comme une implémentation alternative par plusieurs universités et centres de recherche, parfois plus rapide à l’exécution. Cette dernière vient de voir une nouvelle version majeure, OpenMPI 2.0. Celle-ci apporte bon nombre de changements par rapport à la version précédente, 1.10 : la compatibilité binaire est d’ailleurs cassée, il faudra recompiler les applications pour profiter d’OpenMPI 2.0.

Au niveau normatif, cette nouvelle version est compatible avec MPI 3.1, la dernière version, parue en juin 2015. Elle n’apporte que des changements mineurs par rapport à la précédente.

Plus important, l’accès à la mémoire des autres ordinateurs coordonnés à travers MPI (RMA) a été largement amélioré. Ces fonctionnalités servent à lire directement de la mémoire sur un autre ordinateur du réseau, sans besoin de communication synchrone supplémentaire entre les deux machines : seul l’ordinateur qui a besoin des informations est bloqué en les attendant, celui qui est censé les envoyer n’a aucun traitement spécifique à effectuer (tout est géré par MPI). Ces opérations étant assez courantes à effectuer, des interfaces de communication comme InfiniBand proposent des opérations similaires : OpenMPI peut maintenant les exploiter.

OpenMPI améliore sa gestion des ressources pour exploiter à leur plein potentiel des supercalculateurs d’un exaflops (actuellement, ils plafonnent à quelques dizaines de pétaflops). Ainsi, la consommation de mémoire au lancement des processus est limitée pour de très grands nombres de machines en évitant d’initialiser trop tôt des structures de données coûteuses (paramètre mpi_add_procs_cutoff). La communication entre les ordonnanceurs des superordinateurs et les applications pourra se faire avec l’interface PMIx — ce qui représente une étape importante pour gérer au mieux la puissance de calcul disponible.

Sources : [Open MPI Announce] Open MPI v2.0.0 released, Open MPI gets closer to exascale-ready code.
Merci à Claude Leloup pour ses corrections.

Simulation en temps réel de grandes déformations élastoplastiques

La simulation des objets déformables est un problème difficile à résoudre, plus encore quand il l’est en temps réel, par exemple dans un jeu vidéo. Il s’agit d’animer des objets (un ballon, par exemple) qui se déforment quand ils sont soumis à une force — au contraire des objets indéformables, comme un mur, sur lequel on peut s’appuyer sans qu’il se plie de manière perceptible. Dans le cas où ces déformations sont relativement limitées, la situation est gérable de manière relativement efficace — nettement moins pour des déformations importantes, où les résultats ne sont pas visuellement plausibles. Cela limite actuellement la créativité des développeurs, notamment de jeux vidéo, lorsqu’ils veulent intégrer des matériaux comme de la mousse ou de la pâte — ô combien utiles.

On distingue deux catégories de déformations : d’abord élastiques, le matériau se déforme puis revient à sa position d’origine (comme un élastique ou un ressort) ; puis plastiques, il ne revient pas à sa forme initiale (comme une latte en plastique que l’on plie). La simulation concerne surtout les matériaux qui passent d’un comportement à l’autre : ils s’appellent élastoplastiques. La simulation, actuellement, peut se faire pour des déformations élastiques importantes, mais pas dans le régime plastique.

C’est là qu’intervient une équipe de chercheurs (travaillant chez NVIDIA pour leur moteur PhysX), en poursuivant leurs travaux sur la dynamique par positions (PBD), déjà appliquée avec grand succès sur des fluides. Les problèmes de déformation élastoplastique sont souvent résolus par correspondance des formes, un algorithme dont les racines sont très géométriques : à partir d’une position initiale et de points objectifs qui minimisent l’énergie, la méthode déplace, à chaque pas de temps, les points en direction des objectifs.

Les apports de l’équipe font le lien entre cette technique et leur cadre de dynamique par position. Dans cette dernière, tous les objets sont représentés comme une série de points liés par des contraintes. Par exemple, un objet solide comme une brique pourra être représenté par une série de points, avec des distances imposées entre chaque paire de points de la brique : elle restera solide et ne se déformera pas. Ici, les solides déformables sont également représentés par un nuage de points. Cependant, les contraintes ne porteront pas sur des distances à conserver, mais une forme plus légère qui garantit une certaine cohésion de la forme. Les particules sont alors filtrées et redistribuées pour continuer la simulation.

De par le formalisme employé (dynamique par positions), cette technique permet des interactions faciles avec d’autres éléments simulés, comme des corps rigides, des fluides, des tissus. Cependant, l’approche n’a pas forcément un sens physique : elle ne cherche pas à conserver la masse totale des objets déformés, mais seulement le volume visible par l’utilisateur — ce qui est une approximation raisonnable pour bon nombre de cas.

Sources : Real-time Simulation of Large Elasto-Plastic Deformation with Shape Matching, Meshless Deformations Based on Shape Matching.
Merci à Claude Leloup pour ses corrections.

Sortie de Qt Creator 4.0.3

Une nouvelle version corrective de Qt Creator 4.0 vient de sortir. La 4.0.3 corrige quelques défauts mineurs. Notamment, sous OS X 10.8 et FreeBSD, le bouton pour lancer un programme était parfois désactivé. Quand Clang se chargeait de l’analyse du code C++, Qt Creator remplaçait parfois les points en tant que séparateurs décimaux par des flèches. L’ouverture de projets CMake depuis des liens symboliques ne fonctionnait pas toujours. Dans les projets QMake, l’EDI détecte maintenant l’ABI à utiliser pour NetBSD et OpenBSD.

Télécharger Qt Creator 4.0.3.
Source : Qt Creator 4.0.3 released.

FUJITSU passe à l’architecture ARM pour ses prochains superordinateurs

Dans le dernier classement des superordinateurs les plus puissants, FUJITSU classe une de ses machines à la cinquième position, la plus puissante au monde en dehors de la Chine et des États-Unis (elle était la plus puissante lors de sa construction, en 2011) ; elle est installée chez RIKEN, le plus grand institut de recherche japonais. K utilise des processeurs avec une architecture SPARC64, quand la majorité des supercalculateurs listés utilise la plus conventionnelle x86, la même qui équipe la majorité des ordinateurs personnels.

Cependant, FUJITSU abandonne le SPARC64 pour ses prochains superordinateurs : la société japonaise passera à l’ARM, architecture actuellement reine dans les applications embarquées, notamment les téléphones portables. Cette annonce a été faite à la conférence ISC, lors de la présentation sur le futur des superordinateurs de la marque, dont le remplaçant du K installé chez RIKEN. Il vise l’échelle de l’exaflops (comme les Américains) pour 2020.

Au niveau technologique, la microarchitecture de ces futurs processeurs (qui sert à implémenter les instructions accessibles en assembleur) devrait être similaire à l’actuelle, mais l’architecture ARM devrait mieux l’exploiter, selon les dires de FUJITSU. Actuellement, peu de détails sont cependant disponibles au niveau technique, le projet devant aboutir d’ici à peu près quatre ans.

La stratégie de FUJITSU semble se réorienter : alors que leur avantage compétitif s’amenuise, ils devaient réagir et exploiter un écosystème déjà existant (afin de limiter en partie leurs coûts, vu la faible production en systèmes HPC de FUJITSU). Trois architectures principales coexistent dans le secteur HPC : x86 (Intel et AMD), POWER (IBM) et ARM. La gamme de serveurs FUJITSU inclut les PRIMERGY, qui utilisent des processeurs Intel x86 : il restait à faire un choix entre ARM et POWER.

Le côté ARM est nettement moins développé que POWER pour du calcul scientifique de très haute performance, ce qui laisse une chance à FUJITSU de se différentier (seul Cavium est présent sur ce marché, avec ses ThunderX). De plus, la communauté ARM a une grande expérience quand il s’agit de diminuer la consommation énergétique, à cause des besoins des applications mobiles. Cependant, l’architecture ARM aura besoin d’extensions pour les applications HPC, notamment pour vectoriser les opérations de calcul : FUJITSU travaille main dans la main avec ARM.

Le marché HPC semble récemment se dynamiser, la position dominante d’Intel étant mise à mal : tant par IBM et son architecture POWER que les accélérateurs NVIDIA ou FUJITSU, avec l’arrivée d’AMD sur ce marché.

Source et image : Fujitsu Switches Horses for Post-K Supercomputer, Will Ride ARM into Exascale.

Qt Creator 4.1 Beta

La prochaine version de Qt Creator, numérotée 4.1, s’approche : une préversion Beta est maintenant disponible. La fonctionnalité la plus visible est, à nouveau, purement esthétique, avec deux nouveaux thèmes plats : l’un sombre, l’autre clair. Ils sont disponibles dans les options de l’EDI.


En coulisses, Qt Creator gère mieux les ressources disponibles : les documents qui n’ont pas été modifiés ni au premier plan pendant un certain temps ne seront plus gardés en mémoire. L’outil dispose d’une optimisation similaire depuis belle lurette lors de la restauration d’une session : seuls les documents visibles sont chargés. Les autres documents restent accessibles comme s’ils étaient chargés en mémoire. Ce comportement peut être configuré, bien évidemment.

Toujours dans les options, il est maintenant possible d’indiquer à Qt Creator s’il doit insérer les guillemets et les parenthèses par paire de manière séparée : les deux ne sont plus fusionnés en une seule option. Cette même distinction se fait dans le cas où l’utilisateur entre un tel caractère manuellement, pour indiquer à Qt Creator s’il remplace le caractère inséré automatiquement ou non.

Côté analyse de code, le moteur Clang a été mis à jour vers la version 3.8, ce qui lui permet d’analyser sans problème les fichiers d’en-tête de Visual C++ 2015.

L’outil de conception graphique d’interfaces Qt Quick a vu sa performance améliorée, avec un travail sur le processus de mise à jour du document QML pendant l’édition. Il est aussi maintenant possible de choisir le style des composants Qt Quick Controls 2.

Les projets CMake sont mieux gérés depuis la version 4.0, de nouvelles options sont apparues : CMake peut ne plus être lancé automatiquement, un choix à faire outil par outil ; par défaut, CMake n’est d’ailleurs plus lancé automatiquement quand Qt Creator n’est pas l’application active. Les erreurs de CMake sont mieux analysées et présentées à l’utilisateur.

Filippo Cucchetto, créateur de NimQml, qui permet d’exploiter des interfaces Qt Quick depuis le langage Nim, a contribué une extension pour ce langage dans Qt Creator, à activer manuellement. Elle propose la coloration syntaxique, l’indentation, la configuration des styles de code, la compilation, l’exécution et le débogage.

Télécharger Qt Creator 4.1.0 Beta.
Source : Qt Creator 4.1.0 Beta released.

Qt et WinRT : quoi de neuf ?

Windows Runtime (WinRT) est une plateforme logicielle qui tend à homogénéiser l’interface des applications Windows universelles (UWP, universal Windows platform), notamment imposée sur le Windows Store. Cette bibliothèque vise à remplacer l’API Win32, qui commence à montrer son âge, notamment parce que cette API n’est pas du tout orientée objet et provient de l’époque Windows 95 : au contraire, WinRT s’inscrit dans le futur. Cet cadre logiciel, arrivé avec Windows 8, exploite les concepts orientés objet et s’étend sur bon nombre de plateformes, tant de bureau (Windows 8, 8.1, 10) que mobiles (pour téléphones — Windows Phone 8.1, Windows 10 Mobile — ou non — Windows 10 IoT, Hololens, Xbox One). Qt est, bien évidemment, compatible avec WinRT et permet de développer des applications UWP, en profitant des dernières avancées de Microsoft (comme le glisser-déposer).

État actuel avec Qt 5.6 et 5.7

Qt 5.6 a nécessité pas mal de travail côté WinRT. En effet, depuis cette version, toute l’interface est dessinée dans une couche XAML, afin de s’intégrer au mieux à la plateforme. Actuellement, le code permet d’échanger pas mal d’informations internes avec le moteur d’exécution XAML, notamment afin d’intégrer du contenu XAML dans une application Qt : Qt WebView en profite pour utiliser le navigateur local (Microsoft Edge) dans une application Qt Quick.

Qt 5.6 est arrivé avec d’autres fonctionnalités intéressantes, comme la gestion de la caméra dans Qt Multimedia ou la reconnaissance du stylet (notamment pour les Microsoft Surface). Qt 5.6.1 améliore le confort de vie pour développer des applications UWP au niveau des fichiers de projet qmake : il n’est plus nécessaire de préciser CONFIG += windeployqt pour créer une solution Visual Studio, cela est fait automatiquement ; de même, en précisant QT += multimedia, bon nombre de fonctionnalités sont activées, comme l’accès à la webcam ou au micro (qu’il est bien sûr possible de désactiver).

Qt 5.7 n’est pas resté en retrait pour les améliorations. Ainsi, l’audio passe maintenant par WASAPI, qui garantit une latence moindre que précédemment — également accessible sous Windows, pour du développement d’interfaces classiques. L’inconvénient est alors que WASAPI synchronise le taux d’échantillonnage avec celui du pilote audio, sans donner la possibilité au développeur de convertir automatiquement le flux audio. Cette fonctionnalité n’est pas activée par défaut et doit être compilée séparément.

Aussi, côté Qt Quick, le code JavaScript peut être compilé à la volée (JIT), comme sur la plupart des autres plateformes. Initialement, comme Apple, Microsoft avait interdit toute génération de code pour des applications Windows Store, comme mesure de sécurité. Cependant, cette interdiction semble avoir été levée, même s’il n’y a pas encore eu de communication officielle à ce sujet. Grâce à cela, les applications Qt Quick peuvent être sensiblement accélérées, certains fonctions s’exécutant plus de cent fois plus vite. Au vu des incertitudes à ce sujet, cette fonctionnalité doit être activée manuellement et pourrait être retirée d’une prochaine version de Qt.

Fonctionnalités en cours de développement

Dans le futur, les développeurs espèrent que le module JIT pourra être activé pour les plateformes ARM : de par leur puissance, toute accélération possible du code est bonne à prendre. Cependant, toutes les fonctionnalités requises ne sont pas encore disponibles dans les API fournies par Microsoft, même si l’implémentation a déjà commencé côté Qt.

Les fonctionnalités de Qt 5.8 seront arrêtées d’ici un mois, WinRT aura droit à son lot. Notamment, le Bluetooth basse énergie sera accessible (comme sous Android et iOS actuellement) et le module Qt Purchasing sera étendu au Windows Store pour fournir des achats à l’intérieur des applications. Qt Speech arrivera en préversion technologique, avec côté WinRT la mise à disposition de l’API de synthèse vocale de Microsoft. De même, les travaux de découplage de Qt Quick par rapport à OpenGL ne serviront pas qu’à implémenter certaines parties sur Vulkan : ces applications pourront être affichées avec DirectX 12.

Source : Status Update on Qt for WinRT / UWP.
Merci à Claude Leloup pour ses corrections.

IBM annonce sa feuille de route pour son architecture POWER9

Dans le monde des serveurs, Intel règne à peu près sans partage en ce qui concerne les processeurs utilisés, notamment avec sa gamme de Xeon. Cependant, sa place est convoitée dans ce marche lucratif : d’un côté par ARM, des processeurs bien plus simples et qui permettent de stocker plus de processeurs avec plus de cœurs (bien plus lents) pour la même consommation énergétique ; de l’autre par IBM et son architecture POWER, concurrent de longue date d’Intel (une architecture de la même famille que les PowerPC chers à Apple, avant de passer chez Intel il y a dix ans).

Après avoir lancé l’OpenPOWER Foundation en 2013 avec la nouvelle version de son architecture POWER8, voici venu, pour IBM, le temps des premières annonces sur sa prochaine architecture, dénommée POWER9. La caractéristique mise en avant est que ces processeurs POWER9 auront vingt-quatre cœurs (par rapport aux vingt-deux proposés récemment par Intel dans ses Xeon E5 v4), soit le double de la génération actuelle POWER8 ; ils devraient arriver dans la seconde moitié de 2017 et seront utilisés pour le supercalculateur américain Summit.

Quelques détails plus croustillants sont d’ores et déjà disponibles sur le processeur lui-même : la gravure se fera en 14 nm (comme les processeurs Intel de dernière génération, par exemple) par GlobalFoundries. Il utilisera de la mémoire vive DDR4 et profitera d’un grand cache à faible latence de type eDRAM (comme certains processeurs Intel actuels). Au niveau communication, les entrées-sorties se feront par PCIe 4.0, les accélérateurs seront connectés par NVLink 2.0 (technologie propriétaire NVIDIA — une version améliorée par rapport aux GPU actuels Pascal) ou CAPI 2.0 (technologie ouverte du consortium OpenPOWER, notamment pour utiliser des FPGA). Chaque processeur aura des parties spécifiques pour la compression et la cryptographie, afin d’accélérer ces parties du traitement (ce qui donne des indications sur les marchés visés, comme les serveurs Web). Les serveurs seront prévus pour accueillir deux de ces processeurs.

Pendant la présentation d’IBM, Google est venu présenter son utilisation de cette architecture, en remplacement des processeurs Intel. Bon nombre de leurs services Web ont migré vers des systèmes POWER, ce qui a été une opération somme toute assez mineure au niveau logiciel pour eux : Google garde ses logiciels indépendants de la plateforme d’exécution, ce qui permet d’effectuer des tests sur d’autres architectures rapidement (comme des processeurs ARM ou POWER).

Google doit garder son matériel toujours à la pointe, afin de rester dans la compétition pour ses différents services et répondre à une demande toujours croissante. Par exemple, sur une dizaine d’années, le nombre de pages Web indexées a été multiplié par un facteur soixante. Depuis 2012, Gmail a vu son nombre d’utilisateurs actifs multiplié par deux ; quand YouTube recevait sept heures de vidéo chaque minute, il doit maintenant en traiter quatre cents chaque minute, à encoder de différentes manières pour les offrir aux visiteurs plus tard.

La société doit en plus limiter ses coûts : la technologie avançant, il est de plus en plus cher de réduire la taille des transistors… et donc d’augmenter la performance fournie pour chaque dollar investi dans l’infrastructure (de la construction à la maintenance). L’architecture POWER semble leur permettre d’atteindre ces objectifs. Google travaille justement avec Rackspace au développement de baies POWER9, sous le nom de Zaius. Intel ne sort pas complètement de leur infrastructure, mais une bonne partie utilise maintenant les processeurs d’IBM, compétitifs avec la solution d’Intel.

Sources : Power9: Google gives Intel a chip-flip migraine, IBM tries to lures big biz (dont l’image), IBM Fires a Shot at Intel with its Latest POWER Roadmap.