Autodesk lance son propre moteur de jeux, Stingray

Peu après le rachat du moteur bitsquid l’année dernière, Autodesk lance une nouvelle raie dans le monde du jeu vidéo : son propre moteur de jeux Stingray. Cet éditeur de logiciels est d’ores et déjà fort connu pour 3ds Max et Maya, des logiciels de modélisation tridimensionnelle couramment utilisés dans le domaine du jeu vidéo ou le cinéma, moins pour ses autres produits pour le jeu vidéo, rassemblés sous l’étiquette Gameware (proposant de la recherche de chemins avec Navigation, de l’animation d’êtres humains en partant de la biomécanique avec HumanIK, des interfaces graphiques avec Scaleform et d’autres encore) — loin de l’hégémonie de Maya et 3ds Max. Dans un tout autre domaine, Autodesk édite également AutoCAD, un logiciel de dessin technique avec bon nombre de spécialisations.

Le public visé est celui des petits studios de développement, qui n’ont pas les moyens d’une grande équipe : l’objectif est de faciliter les modifications du jeu sans devoir programmer longtemps, dans une interface intuitive — tout en restant compétitif par rapport à d’autres moteurs comme Unreal Engine 4 en termes de fonctionnalités (posttraitement, shaders physiques, réflexions, etc.). Comme d’autres, il propose d’éditer les scripts de manière visuelle, en plus d’un éditeur de code (le langage utilisé étant Lua). Pour ceux qui voudraient plus, le code C++ du moteur est également disponible (à payer séparément).

Depuis bitsquid, la différence fondamentale semble être l’intégration profonde avec les autres logiciels d’Autodesk, en plus d’une refonte de l’interface. L’intégration porte non seulement sur les modeleurs 3D (Maya et 3ds Max), mais également sur les autres produits d’Autodesk (Beast, HumanIK, Scaleform, Navigation) et d’autres (NVIDIA PhysX pour la physique, Audiokinetic Wwise pour l’audio).

L’éditeur se base sur la notion de live link : toute modification effectuée, que ce soit dans un modèle 3D ou un shader, est directement visible, sans attente supplémentaire, sur n’importe quelle plateforme, grâce à une communication entre Stingray et l’appareil par WiFi.

Les jeux développés seront exportables vers différentes plateformes : côté fixe, uniquement Windows (pas d’OS X ou de Linux pour le moment) ; côté mobile, Android et iOS ; côté consoles, les actuelles Xbox One et PlayStation 4 ; en plus, le moteur est compatible la plateforme de réalité augmentée Oculus Rift.

http://on.aol.com/video/stingray-live-link-to-ios-518985101

Le moteur sera disponible dès le 19 août, disponible avec Maya LT (la version du modeleur prévue pour les studios indépendants) pour trente dollars mensuels (le prix actuel pour Maya LT, sans moteur de jeu inclus). D’autres souscriptions devraient être disponibles dans un second temps. En comparaison, Unreal Engine 4 est disponible entièrement gratuitement (mais avec des redevances de cinq pour cent dès que les revenus dépassent un certain seuil) ; de même, une version basique d’Unity est disponible gratuitement.

Sources : Autodesk Finally Releases its Own Game Engine, Capable of Incredibly Stunning Visuals, Autodesk targets small studios with its Stingray game engine, le site officiel.

AMD se lance dans le HPC

Malgré quelques superordinateurs utilisant ses processeurs Opteron (notamment, le deuxième le plus puissant), d’autres plus nombreux ses processeurs graphiques Firepro, AMD est loin d’être une figure proéminente du HPC. Dans un article paru dans la revue IEEE Micro (Achieving Exascale Capabilities through Heterogeneous Computing), le fondeur semble vouloir prendre sa revanche, avec une surenchère sur les annonces récentes d’Intel.

Leur prochain APU (accelerated processing unit), mêlant des parties CPU et GPU, sera nommé EHP, pour exascale heterogeneous processor. En peu de mots, de processeur devrait contenir trente-deux cœurs CPU, plusieurs milliers de cœurs GPU avec une mémoire jusqu’à trente-deux gigaoctets, directement intégrée à la puce. Là où Intel prévoit d’utiliser la technologie HMC, AMD profite de son partenariat avec SK Hynix et intègre HBM2. Ce processeur très spécifique pourrait être disponible en 2016-2017 au plus tôt.

Cette nouvelle puce est exclusivement prévue pour le monde des supercalculateurs, où la course à l’exaflops (un milliard de milliards d’opérations en virgule flottante, avec une précision de soixante-quatre bits) est lancée. La solution conçue par AMD propose des superordinateurs s’étendant sur cent mille nœuds de calcul, chacun fournissant de l’ordre de dix teraflops de puissance de calcul : en comparaison, le superordinateur le plus puissant actuellement, Tianhe-2, s’étend sur seize mille nœuds, chacun fournissant approximativement deux téraflops.

Une telle machine nécessiterait cependant encore beaucoup de recherche, notamment au niveau de l’interconnexion des nœuds, mais également de la consommation énergétique : Tianhe-2 a besoin d’un peu moins de vingt-cinq mégawatts en comptant le refroidissement, un quarantième de la production d’un réacteur nucléaire moyen (utiliser le même système pour atteindre l’exaflops nécessiterait tout un réacteur !). Les projections actuelles font état d’une efficacité de l’ordre de quarante à cinquante gigaflops pare watt pour les nouvelles puces AMD.

Un nouveau paradigme est donc requis. Il est très similaire à celui déjà utilisé : complémenter les CPU avec des accélérateurs. AMD propose d’intégrer ces accélérateurs directement sur la même puce que le processeur principal, afin notamment de partager la même mémoire et de ne pas être limité par les bus disponibles, y compris à l’intérieur d’un nœud de calcul — les déplacements de données forment également une bonne partie de la consommation énergétique d’un supercalculateur. D’autres avantages incluent une meilleure densité de performance, mais également l’absence de recours à un système d’exploitation pour une série de tâches (une tâche exécutée sur le GPU pourrait lancer de nouvelles tâches sur le GPU ou le CPU sans nécessiter d’appel aux pilotes ou au système d’exploitation). Les parties CPU pourraient s’occuper des éléments de calcul difficiles à paralléliser, c’est-à-dire les parties qui ne peuvent pas être lancées efficacement sur les accélérateurs.

Cependant, AMD ne propose pas d’intégrer tous les composants dans la puce elle-même : notamment, elle disposerait de huit canaux DDR4 pour l’accès à de la mémoire supplémentaire, ajoutée sous la forme de barrettes plus traditionnelles, jusqu’à atteindre les besoins actuels en mémoire. Chaque canal pourrait adresser jusqu’à deux cent cinquante-six gibioctets de mémoire (c’est-à-dire deux tébioctets en tout). Au niveau de l’architecture globale, chaque cœur aurait des deux fils d’exécution du cœur, avec un cache cache L2 d’un demi-kibioctet ; chaque groupe de quatre cœurs partagerait un cache L3 de huit mébioctets. La conception globale pourrait s’accommoder de cœurs x86 ou ARM.

Au vu de ces caractéristiques, il semble peu probable, au vu des techniques de lithographie actuelles, que tout ce petit monde tienne sur la même pastille : le processeur serait séparé en deux parties, chacune ayant seize cœurs, plus la partie GPU, rassemblées par un interposeur, d’ores et déjà nécessaire pour intégrer la mémoire HBM2.

Sources : AMD Reveals the Monsterous ‘Exascale Heterogeneous Processor’ (EHP) with 32 x86 Zen Cores and Greenland HBM2 Graphics on a 2.5D Interposer, AMD’s Exascale Strategy Hinges on Heterogeneity, AMD announces EHP (exascale heterogeneous processor), High performance AMD APU

La nouvelle mouture de l’Intel Xeon Phi approche

Pour contrecarrer le mouvement des processeurs graphiques (GPU) dans le domaine du calcul scientifique de haute performance (HPC), Intel a lancé en 2013 ses coprocesseurs Xeon Phi. L’idée principale est de fournir un grand nombre de cœurs (une soixantaine pour la première génération), atout principal des GPU (les modèles actuels montent à plusieurs milliers de cœurs). La première génération de Xeon Phi est notamment utilisée dans le supercalculateur chinois Tianhe-2, le plus puissant au monde depuis sa construction en 2013, selon le classement Top500.

Cependant, comme pour les GPU, ces cœurs sont très différents de ceux des processeurs plus traditionnels (comme les gammes Core i3-7 d’Intel, par exemple) : ils sont nettement moins véloces, avec des fréquences de l’ordre du gigahertz — le parallélisme de ces coprocesseurs est leur principale caractéristique. Néanmoins, contrairement aux GPU, ils peuvent se programmer d’une manière très similaire aux processeurs classiques.

La deuxième génération est sur le point d’arriver, elle devrait être commercialisée cette année. Connue sous le nom de code Knights Landing, cette nouvelle mouture tient du superlatif pour ses caractéristiques : pas moins de septante-deux cœurs, chacun hébergeant deux unités de traitement vectoriel AVX-512 (qui travaillent sur des registres de cinq cent douze bits) ; individuellement, ces cœurs devraient être trois fois plus rapides que précédemment. La puce elle-même est gravée avec un processus à quatorze nanomètres, ce qui se fait de mieux pour le moment, avec notamment de grands gains en termes de puissance consommée (et de chaleur dissipée).

L’architecture prévoit aussi des bus DDR4 pour la mémoire principale, mais surtout seize gigaoctets de mémoire intégrée sur la puce elle-même (avec une bande-passante jusqu’à cinq fois supérieure à celle de la DDR4, quinze fois par rapport à la DDR3, encore majoritaire dans les ordinateurs actuels). Cette mémoire sera à peu près aussi rapide que les caches L3 des processeurs actuels (bien qu’ils soient limités à quelques mégaoctets !), avec une bande passante de cinq cents gigaoctets par seconde.

Cette super-mémoire cache utilisera l’interface HMC (hybrid memory cube), concurrente de HBM (high bandwidth memory) en cours de déploiement sur les processeurs graphiques (les cartes Fury remettent AMD à l’avant-plan en termes de performance). In fine, un tel processeur pourra proposer une puissance de calcul de l’ordre de trois téraflops, c’est-à-dire trois mille milliards d’opérations en virgule flottante par seconde.

Une autre nouveauté par rapport à la génération précédente est que ces coprocesseurs pourront servir de processeurs principaux et faire fonctionner le système d’exploitation de la machine. L’intérêt majeur est de se débarrasser d’une connexion par bus PCI-Express, qui limitait la performance de son prédécesseur (une constatation partagée par le concurrent NVIDIA, qui s’apprête à proposer sa technologie NVLink).

Au niveau de la communication, Intel s’apprête également à communiquer plus d’informations sur son Omni Path, une interface d’interconnexion entre nœuds dans un supercalculateur. Intel s’apprête ainsi à marcher sur les platebandes de géants comme InfiniBand, avec une technologie présentée comme supérieure. Notamment, les latences de communication devraient être de l’ordre de cent nanosecondes, quand InfiniBand monte à presque deux microsecondes, Ethernet à dix à cent microsecondes.

Chaque processeur Xeon Phi Knights Landing aura deux ports Omni Path. L’objectif semble être l’intégration verticale dans les supercalculateurs, Intel ayant annoncé un partenariat avec HP pour la construction de serveurs autour des technologies HPC d’Intel, rassemblées sous le nom de SSF (scalable system framework), dans le contexte de la gamme Apollo de HP.

Sources et crédit images : Intel’s Xeon Phi 14nm ‘Knights Landing’ Co-Processors Detailed – OmniPath Architecture 100 Series and 16GB HMC on a 2.5D Interposer et Quick Note: Intel “Knights Landing” Xeon Phi & Omni-Path 100 @ ISC 2015.

Qt Creator 3.5 Beta 1

La première préversion de Qt Creator 3.5 est maintenant disponible. L’amélioration la plus graphique concerne la barre de défilement vertical, qui indique maintenant tous les signets, les points d’arrêts et les résultats de recherche.

L’analyse du code C++ par Clang a été repensé, avec notamment le déplacement de l’exécution dans un autre processus que Qt Creator (ce qui le met à l’écart de tout problème à l’exécution de Clang). Les binaires ont également été mis à jour pour utiliser Clang 3.6.

Certaines fonctionnalités de Qt Creator ont également été retirées : Qt Quick Designer ne pourra plus éditer de fichiers de l’époque Qt Quick 1 ; les assistants Qt Quick 1 ne sont plus disponibles ; le profilage du code JavaScript avec V8 n’est plus possible. Par contre, toutes les fonctionnalités concernant Qt Quick 2 (ainsi que l’éditeur de code pour Qt Quick 1) sont conservées. Toujours au chapitre des suppressions, Qt Creator n’est plus compatible avec la plateforme Blackberry 10, par manque de mainteneur — QNX, le système d’exploitation en temps réel sous Blackberry 10, principalement utilisé dans l’embarqué, reste d’actualité.

D’autres modifications plus légères ont également été apportées. Pour la gestion d’Android, des corrections de défauts ont eu lieu pour Android M et les éditions 64 bits. Sur OS X, Spotlight est désormais accessible pour la recherche de fichiers.

Source : Qt Creator 3.5 beta1 released

Sortie de CUDA 7.5 RC

La première préversion publique de CUDA 7.5 est disponible pour tous les développeurs CUDA enregistrés auprès de NVIDIA. La principale nouveauté est la gestion des nombres à virgule flottante codés sur seize bits, c’est-à-dire la moitié de l’encodage traditionnel (float sur trente-deux bits). Cette format est principalement utilisée pour du stockage de données quand la précision requise n’est pas très importante, mais aussi pour des calculs sous la même hypothèse.

Calculs sur seize bits

L’effet sur la performance du code peut être énorme : la bande passante requise est divisée par deux, ce qui permet de transmettre deux fois plus de nombres par unité de temps sur les bus existants, d’en stocker deux fois plus sur la même quantité de mémoire. Ils pourront donc se révéler très utiles pour les applications où ces éléments sont limitatifs, comme l’apprentissage de réseaux neuronaux de grande taille ou le filtrage de signaux en temps réel.

L’avantage en temps de calcul n’est disponible que sur les GPU ayant une partie prévue pour l’arithmétique sur seize bits, ce qui n’est pas le cas pour la majorité des processeurs disponibles, sauf sur Tegra. La prochaine architecture de GPU de NVIDIA, connue sous le nom de Pascal, aura des transistors alloués pour les calculs sur seize bits : le nombre de calculs effectués par seconde doublera entre les précisions FP16 et FP32 (le même rapport qu’entre FP32 et FP64). Entre temps, les calculs seront effectués en interne sur les mêmes circuits que précédemment, avec une précision bien plus élevée que des circuits dédiés (bien qu’elle soit en grande partie perdue lors de l’arrondi vers les seize bits).

Réseaux neuronaux

L’un des chevaux de bataille actuels de NVIDIA est l’apprentissage automatique, en particulier par réseaux neuronaux, plus spécifiquement profonds, par exemple pour une utilisation dans les voitures intelligentes. Ils ont par exemple développé la bibliothèque cuDNN (CUDA deep neural network), qui accélère les calculs par un GPU. La troisième version de cette bibliothèque a été optimisée, particulièrement au niveau des convolutions (FFT et 2D), ce qui améliore la performance lors de l’entraînement de réseaux neuronaux (gain d’un facteur deux pour l’apprentissage sur des GPU Maxwell). Elle gère également les nombres en virgule flottante sur seize bits, ce qui est utile pour des réseaux très grands, mais n’améliore pas (encore) les temps de calcul.

Améliorations de performance de cuDNN 3

NVIDIA a aussi développé l’outil DIGITS, un logiciel de bien plus haut niveau que cuDNN pour les mêmes réseaux neuronaux, prévu pour des profils plus scientifiques que pour des programmeurs. L’une des nouveautés est l’apprentissage distribué sur plusieurs GPU : ajouter un deuxième GPU aide à réduire fortement les temps de calcul (d’un facteur légèrement inférieur à deux), nettement moins impressionnant en ajoutant deux autres (facteur de deux et demi). Le gain sera probablement plus important avec les prochaines architectures de GPU, Pascal devant utiliser la technologie NVLink au lieu du bus PCI Express (partagé) pour la communication entre cartes.

DIGITS

Algèbre linéaire creuse

CUDA vient également avec la bibliothèque cuSPARSE pour l’algèbre linéaire sur des matrices creuses accélérée sur GPU. Une nouvelle opération vient d’y être ajoutée, nommée GEMVI, utilisée pour la multiplication entre une matrice pleine et un vecteur creux — la sortie étant évidemment un vecteur plein. Ce genre d’opérations est très utile pour l’apprentissage automatique, plus particulièrement dans le cas du traitement des langues. En effet, dans ce cas, un document rédigé dans une langue quelconque (français, anglais, allemand…) peut être représenté comme un comptage des occurrences de mots d’un dictionnaire ; bien évidemment, tous les mots du dictionnaire (même partiel) ne sont pas présents dans le texte, sa représentation vectorielle contient donc un grand nombre de zéros, il est donc creux. Une fois le dictionnaire défini, pour améliorer l’efficacité des traitements, le dictionnaire peut être réduit en taille pour n’en garder qu’un sous-espace vectoriel qui préserve la sémantique des textes : la transformation de la représentation du texte demande justement un produit entre le vecteur creux initial et une matrice de transformation.

C++11 et fonctions anonymes

La version précédente de CUDA a commencé à comprendre C++11, la dernière itération du langage de programmation. Les fonctions anonymes (lambdas) en font partie et servent notamment à écrire du code plus concis. CUDA 7.0 ne les tolérait que dans le code exécuté côté client, pas encore sur le GPU : ce point est corrigé, mais seulement comme fonctionnalité expérimentale. Par exemple, un code comptant les fréquences de quatre lettres dans une chaîne de caractères pourra s’écrire comme ceci :

void xyzw_frequency_thrust_device(int *count, char *text, int n) {
  using namespace thrust;

  *count = count_if(device, text, text+n, [] __device__ (char c) {
    for (const auto x : { 'x','y','z','w' })
      if (c == x) return true;
    return false;
  });
}

La même fonctionnalité permet d’écrire des boucles for pour une exécution en parallèle, avec une syntaxe similaire à OpenMP, par exemple une somme de deux vecteurs (SAXPY pour BLAS) :

void saxpy(float *x, float *y, float a, int N) {
    using namespace thrust;
    auto r = counting_iterator(0);
    for_each(device, r, r+N, [=] __device__ (int i) {
        y[i] = a * x[i] + y[i];
    });
}

Profilage

La dernière nouveauté annoncée concerne le profilage de code, nécessaire pour déterminer les endroits où les efforts d’amélioration de la performance doivent être investis en priorité. CUDA 7.5 améliore les outils NVIDIA Visual Profiler et NSight Eclipse Edition en proposant un profilage au niveau de l’instruction PTX (uniquement sur les GPU Maxwell GM200 et plus récents), pour détermines les lignes précises dans le code qui causent un ralentissement. Précédemment, le profilage ne pouvait se faire qu’au niveau d’un noyau, équivalent d’une fonction pour la programmation sur GPU (temps pris par le noyau à l’exécution, importance relative par rapport à l’exécution complète).

CUDA 6 avait déjà amélioré la situation en affichant une corrélation entre les lignes de code et le nombre d’instructions correspondantes. Cependant, un grand nombre d’instructions n’indique pas forcément que le noyau correspondant prendra beaucoup de temps à l’exécution. Pour remonter jusqu’à la source du problème, ces informations sont certes utiles, mais pas suffisantes, à moins d’avoir une grande expérience. Grâce à CUDA 7.5, le profilage se fait de manière beaucoup plus traditionnelle, avec un échantillonnage de l’exécution du programme, pour trouver les lignes qui prennent le plus de temps.

Sources et crédit des images : New Features in CUDA 7.5, NVIDIA @ ICML 2015: CUDA 7.5, cuDNN 3, & DIGITS 2 Announced.

NVIDIA HairWorks 1.1, jusqu’à un demi million de cheveux

Il y a un an et demi, NVIDIA présentait HairWorks, sa solution pour la simulation de poils en tout genre. La version 1.1 apporte quelques nouveautés à cette bibliothèque, principalement concernant les cheveux longs, avec des outils pour leur conception en temps réel, leur rendu et leur simulation, avec des résultats très variés. Ci-dessous, quelques exemples livrés avec HairWorks.


NVIDIA en a également profité pour réaliser une vidéo de démonstration, avec cinq cent mille cheveux simulés en temps réel sur une seule carte GTX 980. Les vidéos précédentes faisaient état de vingt mille cheveux, ce qui montre une belle évolution, tant au niveau des processeurs graphiques que du logiciel (bien que cette vidéo ne montre que les cheveux animés, pas une scène complète).

Cet outil fait appel à la tesselation, ce qui lui permet d’avoir un impact en mémoire très faible, même pour de très grands nombres de poils. Cette technique a cependant quelques effets pervers sur des GPU plus anciens ou d’une autre marque (AMD, pour ne pas la citer), la tesselation y fonctionnant nettement moins bien — ce qui a été à la source de problèmes de performance, par exemple pour The Witcher 3.

Pour ceux qui aimeraient tester cette nouvelle version, NVIDIA HairWorks est disponible gratuitement après inscription au programme GameWorks. Une intégration à Unreal Engine 4 est disponible également gratuitement en même temps que le moteur.

Sources : HairWorks 1.1 Release (images), NVIDIA HairWorks Version 1.1 Showcased with 500K Realistic Hair Rendered in Real-Time on a Single GTX 980.

Nouveau, le pilote NVIDIA libre pour Linux, s’ouvre à CUDA

Vulkan est prévue comme la prochaine évolution d’OpenGL, visant principalement à la rendre plus bas niveau, pour exploiter au mieux les possibilités des processeurs graphiques modernes (voir Vulkan : la nouvelle bibliothèque de hautes performances pour le GPU pour plus de détails). L’une de ses améliorations est SPIR-V, une représentation intermédiaire des shaders, une forme d’assembleur indépendant de la carte graphique utilisé pour représenter tout le code qu’un utilisateur peut y envoyer. Cette représentation intermédiaire sera partagée par OpenCL, prévu pour faciliter les calculs génériques sur GPU (comme la simulation de fluides), à l’instar de CUDA, une technologie propriétaire de NVIDIA, antérieure à OpenCL mais à l’évolution plus rapide.

Dans tout ce beau monde, peu d’annonces du côté du logiciel libre, si ce n’est un pilote pour les puces Intel développé par Valve et qui devrait être libéré. Récemment, Pierre Moreau a annoncé avoir commencé à travailler sur une passe de compilation SPIR-V vers la représentation intermédiaire des GPU NVIDIA NV50, déjà relativement anciens (série GeForce 8000, de 2006-2007). Cette étape est l’une des premières requises pour exécuter du code SPIR-V sur ces GPU.

En comptant les efforts actuels pour développer une passe de compilation LLVM IR vers SPIR-V, grâce à laquelle tout langage que LLVM et ses projets annexes (dont Clang) peuvent compiler pourrait être utilisé pour les GPU. En particulier, le code CUDA pourrait être transformé de la sorte et être exécuté sur Nouveau.

NVIDIA explore une autre piste pour exécuter du code CUDA grâce au pilote libre Nouveau. Leur intérêt pour ce pilote n’est pas neuf, mais il s’est focalisé sur leurs systèmes monopuces (SoC) Tegra, négligeant leurs autres GPU. Tout comme les efforts de Pierre Moreau, rien n’est actuellement visible au grand public en ce qui concerne le code ; cette fois, le développeur de NVIDIA est plus détaillé, en demandant des avis sur des modifications à apporter au code de la gestion de la mémoire du GPU.

Plus techniquement, il explique que CUDA a besoin d’avoir les mêmes adresses virtuelles sur le GPU et sur le CPU, ce que Nouveau ne permet pas encore. De plus, une application CUDA traditionnelle a tendance à allouer une grande quantité de mémoire en avance, pour une utilisation plus tardive ; des morceaux de cet espace sont alors alloués au fur et à mesure des besoins à l’exécution. Nouveau fusionne les opérations d’allocation des adresses virtuelles et de correspondance de mémoire, qui devraient être découplées pour ces utilisations.

Sources : Someone Is Already Working On SPIR-V For The Nouveau Driver, [Nouveau] Will nouveau support for cuda?, [LLVMdev] [RFC] Proposal for Adding SPIRV Target, NVIDIA Has Someone Working On Nouveau CUDA Support

Première prévision technologique de Qt 3D

Qt 5.5 inclut une première préversion technologique du module Qt 3D, un framework de haut niveau qui facilite l’ajout de contenu 3D dans des applications Qt, écrites tant en QML qu’en C++. Son statut actuel montre que le module n’est pas encore mature : son API peut continuer à évoluer, plus de fonctionnalités seront ajoutées avant la première version stable.

Qt 3D fournit un grand nombre de fonctionnalités nécessaires pour le rendu 3D actuel, tout en profitant de la performance d’OpenGL sur toutes les plateformes (sauf iOS pour le moment, qui devrait être prochainement disponible). Ce module propose également de modifier l’apparence des objets affichés à l’écran, soit en utilisant des matériaux prédéfinis, soit en créant ses propres shaders. De plus, il donne un contrôle sur le rendu de la scène 3D à l’aide d’une description orientée données. Il est donc possible de créer rapidement des prototypes d’algorithmes de rendu. L’intégration à Qt Quick 2 se fait par le composant Scene3D.

Cette première préversion contient d’ores et déjà un grand nombre de fonctionnalités :

  • un système à entités flexible et extensible, prévu pour le parallélisme ;
  • le chargement de géométries, en utilisant le module d’import OBJ ou assimp s’il est disponible ;
  • un système de passes de rendu pour les matériaux et les effets pour adapter l’apparence aux besoins ;
  • une configuration par les données : il est possible de changer la manière dont le rendu est effectué sans toucher à une ligne de C++ ;
  • un grand nombre de techniques de rendu déjà implémentées : rendu non différé, avec une profondeur, un affichage différé ou d’objets transparents, etc. ;
  • une compatibilité avec tous les types de shaders (sauf les compute shaders) ;
  • une compatibilité avec les UBO (uniform buffer objects) s’ils sont disponibles ;
  • des fonctions simples pour les primitives géométriques de base et les matériaux ;
  • un contrôle de la caméra par la souris ;
  • une intégration aisée dans des interfaces Qt Quick 2.

Au-delà du rendu, Qt 3D fournit également un environnement propice à l’ajout de nouvelles fonctionnalités, comme les simulations physiques, l’animation de squelettes, l’audio 3D, le rendu stéréoscopique, l’intelligence artificielle ou d’autres mécanismes d’entrée.

L’article Aperçu de Qt 3D 2.0 donne plus de détails sur l’organisation et les possibilités de Qt 3D.

Source : Qt3D 2.0 Technology Preview.

Impact des GPU sur la simulation de fluides avec PyFR

La simulation de fluides (plus connue sous le sigle anglophone CFD, computational fluid dynamics) apparaît dans un grand nombre d’applications d’ingénierie : il s’agit de déterminer, par ordinateur, par exemple, l’écoulement de l’air autour d’avions ou de voitures de formule 1. Ainsi, les concepteurs peuvent adapter leurs pièces, notamment pour en améliorer l’aérodynamisme. Les calculs requis sont extrêmement poussés (équations aux dérivées partielles non linéaires) et requièrent une grande puissance de calcul.

Un grand nombre de logiciels existe déjà pour résoudre ces problèmes, comme OpenFOAM dans le monde du logiciel libre. Cependant, ils n’exploitent pas tous les accélérateurs disponibles pour ces calculs (OpenFOAM nécessite des extensions pour ce faire), comme les processeurs graphiques (GPU), à la mode dans le monde du calcul scientifique (HPSC) : l’intérêt est de bénéficier d’un très grand nombre de cœurs. En effet, un processeur traditionnel a au plus une vingtaine de cœurs par processeur : par exemple, dix-huit chez Intel). Un GPU en compte désormais plusieurs milliers (tant chez NVIDIA que AMD), bien qu’avec une architecture radicalement différente.

PyFR est un logiciel de CFD assez récent (sa version 1.0.0 est sortie la semaine dernière), basé sur un concept différent des solveurs actuels, la reconstruction de flux (FR), pour atteindre une précision bien plus élevée que les solveurs existants, même sur des géométries très complexes, tout en étant mieux adaptés à des GPU. (Techniquement, pour la discrétisation spatiale, il s’agit d’un schéma d’intégration à ordre élevé sur une grille non structurée, qui mêle la précision de méthodes d’ordre élevé des méthodes à différences finies et l’adaptabilité géométrique des volumes et éléments finis.)

Les solveurs actuels partent d’hypothèses des années 1980, quand les opérations de calcul sur des nombres réels étaient très coûteuses, mais la mémoire très rapide par rapport au processeur, deux points complètement dépassés par les architectures actuelles, afin de simuler des écoulements stationnaires. Ainsi, pour s’adapter à des simulations non stationnaires, il faut réinventer une série de composants

En pratique, ce nouveau logiciel peut donner des résultats dix fois plus précis dix fois plus rapidement que les techniques précédentes, tout en étant capable d’exploiter la puissance d’une série de GPU. Il s’adapte également à une série de plateformes : des grappes de CPU, formant les superordinateurs les plus courants ; des GPU, peu importe leur fabricant (tant AMD que NVIDIA). La distribution du calcul sur plusieurs nœuds s’effectue par MPI.

Côté technologique, la parallélisation sur un nœud de calcul est possible tant par OpenMP (plusieurs fils d’exécution sur le même processeur) que CUDA ou OpenCL (GPU). Le logiciel lui-même est principalement codé en Python — ce qui ne l’empêche pas d’exceller au niveau des temps de calcul, grâce à la facilité d’appel de code natif, principalement en C et Fortran. L’interpréteur ajoute un surcoût en temps d’exécution inférieur au pour cent : cette perte de performance est négligeable quand le code de calcul ne compte que cinq mille lignes de code !

Tout le côté numérique est extrait dans une série de primitives bien comprises et optimisées. La communication s’effectue par une version de MPI adaptée à du calcul sur GPU, notamment en utilisant la technologie NVIDIA GPUDirect, qui permet la copie de données directement dans la mémoire du GPU, sans passer par la mémoire centrale (RAM). Les surcoûts dus à Python sont effacés en très grande partie grâce à la nature asynchrone de CUDA : le code Python n’est pas obligé d’attendre la fin des calculs sur le GPU avant de passer à autre chose.

Sources : On a Wing and PyFR: How GPU Technology Is Transforming Flow Simulation, PyFR: An open source framework for solving advection–diffusion type problems on streaming architectures using the flux reconstruction approach, PyFR: Technical Challenges of Bringing Next Generation Computational Fluid Dynamics to GPU Platforms – See more at: http://on-demand-gtc.gputechconf.com/gtcnew/on-demand-gtc.php?searchByKeyword=pyfr&searchItems=&sessionTopic=&sessionEvent=&sessionYear=&sessionFormat=&submit=&select=#sthash.CNa7viRf.dpuf (dont l’image).

Voir aussi : le site officiel de PyFR.

Qt et Bluetooth : état actuel et améliorations à venir

Qt 5.2 a apporté le module Bluetooth, initialement très limité : il n’était utilisable que sur Linux par BlueZ 4 et sur BlackBerry 10. Chaque version a amélioré l’état du module : avec Qt 5.3, il devient compatible avec Android ; avec Qt 5.4, il devient compatible avec BlueZ 5 sous Linux et la version basse énergie Bluetooth LE (pour Low Energy) est accessible (uniquement pour BlueZ, en préversion). Avec Qt 5.5, il devrait être compatible avec OS X (y compris la variante LE), WinRT (ARM) pour la 5.6.

L’objectif principal de ce module est de fournir une couche d’abstraction des fonctionnalités Bluetooth de base, utilisable peu importe la plateforme : chercher des périphériques Bluetooth accessibles, leur envoyer des données par OPP (object push profile), s’y connecter par un canal RFCOMM en série (SPP, serial port profile), etc. La déclinaison LE devient de plus importante, dans Qt mais aussi dans ses applications : avec l’habitronique, les divers capteurs connectés, tant pour la santé que l’environnement, les périphériques doivent limiter au maximum leur consommation ; Qt reste utile pour ces applications, grâce à ses fonctionnalités Bluetooth LE.

De nouvelles fonctionnalités sont prévues pour les prochaines versions de Qt : une compatibilité avec Windows (x86), des interfaces Qt Quick, des améliorations pour la détection et la communication des fonctionnalités disponibles, par exemple pour l’interaction avec des périphériques iBeacon (Apple).

Source : Qt Bluetooth and its state of the union, QTBUG-31674.