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.

Nouveauté de Qt 5.5 : Canvas3D, une API 3D bas niveau compatible avec WebGL pour Qt Quick

Avec Qt 5.5, le module Canvas3D sort de sa période d’incubation. Il se propose comme un équivalent à WebGL à l’intérieur de Qt Quick (donc accessible en JavaScript depuis une interface QML), en tant qu’API 3D de bas niveau inspirée d’OpenGL. L’objectif est de faciliter le portage d’applications depuis WebGL vers Qt Quick — voire de partager du code entre les deux.

La compatibilité avec WebGL n’est pas encore parfaite, la différence principale étant que WebGL est défini pour des pages HTML. Les écarts par rapport à la norme sont corrigés au fur et à mesure de leur détection ; la conformité complète ne sera pas forcément atteinte, à cause de la forte dépendance de WebGL envers le modèle de données de HTML, inexistant dans Qt Quick. Ceci n’empêche pas le portage facile ou le partage de code entre des applications WebGL-HTML et Qt Quick.

En même temps, l’API de Canvas3D s’inspire fortement de QOpenGLWidget, la manière actuellement conseillée d’intégrer de la 3D dans des applications Qt en C++. Par exemple, le code suivant peint l’écran avec une couleur aléatoire.

import QtCanvas3D 1.0
 
Canvas3D {
    id: canvas3d
    anchors.fill: parent
    focus: true
    property var gl
 
    onInitializeGL: {
        gl = canvas3d.getContext("experimental-webgl");
 
        // Setup clear color to be a random color
        gl.clearColor(Math.random(), Math.random(), Math.random(), 1.0);
 
        // Setup viewport
        gl.viewport(0, 0, canvas3d.width * canvas3d.devicePixelRatio, canvas3d.height * canvas3d.devicePixelRatio);
    }
 
    onPaintGL: {
        // Clear background to current clear color
        gl.clear(gl.COLOR_BUFFER_BIT);
    }
 
    onResizeGL: {
        var pixelRatio = canvas3d.devicePixelRatio;
        canvas3d.pixelSize = Qt.size(canvas3d.width * pixelRatio, canvas3d.height * pixelRatio);
        if (gl)
            gl.viewport(0, 0, canvas3d.width * canvas3d.devicePixelRatio, canvas3d.height * canvas3d.devicePixelRatio);
    }
}

Tout comme WebGL, Canvas3D est de très bas niveau. Pour débuter, il peut être préférable d’utiliser une couche d’abstraction comme three.js : la version WebGL a été portée vers Canvas3D, avec une série d’exemples et d’utilitaires couramment utilisés. Par exemple, une application 3D de visualisation d’une voiture a pu être portée de WebGL vers Canvas3D en quelques jours.

Ce nouveau module arrive en même temps que les premières préversions de Qt 3D 2.0. Ces deux modules, bien qu’ils aient le même objectif — ajouter du contenu 3D dans une application Qt Quick —, recouvrent des besoins différents : Qt Canvas3D est une API de bas niveau, tandis que Qt 3D est beaucoup plus proche du moteur 3D, avec un graphe de trame complet (une description orientée données de la scène et des transformations à y appliquer lors du rendu). Qt Canvas3D n’est pas accessible en C++, puisque ces fonctionnalités sont d’ores et déjà accessibles par QOpenGLWidget (qui facilite l’utilisation directe d’OpenGL), contrairement à Qt 3D.

Source : Introducing Qt Canvas3D

Qt 5.5 RC et plans pour les prochaines versions

La version RC vient de sortir, corrigeant uniquement des défauts par rapport aux préversions précédentes. L’objectif actuel est d’avoir une version finale le premier juillet (avec un retard de plusieurs mois sur les plans).

Qt 5.6 devrait être la dernière compatible avec une série de combinaisons de plateformes et de compilateurs : plus de GC 4.6, d’OS X 10.7, de Windows Embedded Compact 7, de QNX 6.5 — Qt 5.7 devrait faire le ménage dans sa compatibilité, pour ne garder que les versions les plus récentes, ce qui ira de pair avec une migration complète vers C++11 (le code n’aura plus l’obligation de compiler en mode C++98). Cette version 5.6 aura cependant un support à long terme de deux ans pour tous ceux qui ne peuvent pas encore effectuer de migration, tandis que la 5.7 laissera plus de temps pour modifier le code plus en profondeur.

Cependant, les modules Qt Quick 1 et Qt WebKit ne seront plus inclus dans les binaires distribués, la relève étant déjà assurée (Qt Quick 2 et Qt WebEngine, même si ce dernier n’est pas exempt de débats). Qt Script devrait faire ses adieux avec Qt 5.7.

Sources : [Development] QtCS: Long Term Release discussion, [Development] Qt LTS & C++11 plans