Malaise dans la communauté Qt par rapport à l’édition commerciale

À ses débuts en 1991, Qt était un projet exclusivement commercial, avant de voir ses sources disponibles en 1995 sous une licence presque libre (la redistribution des sources modifiées n’était pas autorisée). La situation n’a posé de problème qu’en 1998, quand KDE est devenu un environnement de bureau majeur : la licence alors adoptée était la QPL, libre mais incompatible avec la GPL. En même temps, les développeurs de KDE ont obtenu que, si plus aucune version libre de Qt ne sortait en un an, la dernière tomberait automatiquement sous une licence très permissive, de type BSD — un accord toujours valable. L’histoire de Qt l’a alors porté vers la GPL, puis plus récemment vers la LGPL et, dernièrement, une mise à jour vers la dernière version de ces licences.

En d’autres termes, Qt a depuis longtemps baigné dans le logiciel libre, en acceptant les contributions de l’extérieur. Depuis cinq ans, cette organisation s’est même formalisée autour du Qt Project : tout le développement a lieu en public, toute personne externe peut prendre part au développement et même à la gouvernance du projet.

Digia a lancé un programme d’unification de l’offre Qt, en rapprochant les éditions libres et commerciales de Qt. Ce mouvement a notamment libéré bon nombre de fonctionnalités commerciales de Qt. Un autre impact a été la fusion des sites Web : qt.io est censé présenter les deux éditions. C’est actuellement la pierre d’achoppement : la partie libre est de moins en moins présente sur le site officiel, en présentant plus Qt pour les utilisateurs que pour les potentiels contributeurs.

Les griefs ne s’arrêtent pas à ce manque de visibilité : le site met en avant les éditions commerciales, en reléguant le côté libre de côté. Pire encore, quand les aspects libres se présentent, le site n’hésite pas à pointer du doigt les possibles problèmes légaux avec les licences libres… même si ces soucis ne pourraient concerner qu’une très faible minorité des utilisateurs.

Source : [Development] Qt-Project misrepresented on qt.io.

Sortie de PyQt 5.6

Riverbank a publié la dernière version de sa couche de liaison Qt pour Python, PyQt, en version 5.6. L’amélioration principale est une pleine compatibilité avec Qt 5.6. De plus, la distribution se fait maintenant préférentiellement par wheels, sur toutes les plateformes (les installateurs sous la forme d’EXE ne seront plus disponibles pour Windows après cette version).

Plus en détail, le module Qt WebEngine Core a été ajouté pour donner un accès plus direct au moteur Chromium de Qt WebEngine, avec une API de plus bas niveau. Quelques fonctions manquantes par rapport à Qt ont été ajoutées : qt_set_sequence_auto_mnemonic() dans Qt GUI, MouseLock dans QWebEnginePage.Feature, WA_DontShowOnScreen.

Plus intéressant pour les utilisateurs d’environnements de développement intégrés, des fichiers PEP 484 sont maintenant générés. Ils intègrent une indication sur les types attendus par les fonctions lors de leur appel, ce qui permet de détecter bon nombre d’erreurs avant même d’exécuter son application.

Source : PyQt v5.6 Released

Sortie de GCC 6.1 : C++14 activé par défaut, OpenMP 4.5

GCC vient de sortir sa version majeure annuelle, numérotée 6.1. Elle cumule les développements d’une année entière, avec des évolutions dans tous les domaines : côté C++, le compilateur se positionnera sur la norme C++14 par défaut, au lieu de C++98 auparavant, quelques fonctionnalités de C++17 ont été implémentées ; pour le domaine HPC, OpenMP 4.5 est complètement implémenté, les calculs peuvent être déportés sur des coprocesseurs Intel Xeon Phi « Knights Landing » et sur du matériel AMD par HSAIL ; l’implémentation de OpenACC 2.0a a été améliorée, avec une possible déportation sur du matériel NVIDIA par PTX. Au niveau matériel, les prochains processeurs d’AMD, basés sur l’architecture Zen, sont déjà pris en charge ; les plateformes ARM ont été le théâtre de bon nombre d’améliorations ; l’architecture PowerPC a reçu la compatibilité avec POWER9, la prochaine itération des processeurs d’IBM.

Côté C++

La précédente version majeure de GCC, numérotée 5.1, apportait les dernières touches à l’implémentation de C++14, en apportant des fonctionnalités comme la désallocation d’une partie d’un tableau, des constexpr plus généraux, des fonctions anonymes génériques.

Cette nouvelle version de GCC s’arme déjà pour C++17, avec par exemple, la définition d’attributs sur les énumérateurs ou encore des expressions utilisant l’opérateur fold (aussi nommé reduce ou autre, selon les modes) :

// Cette fonction somme tous ses arguments.
template<typename... Args>
  bool f(Args... args) {
    return (true + ... + args);
  }

Plus de détails dans la documentation.

Une nouvelle optimisation en C++ casse du code existant

Une nouvelle optimisation fait parler d’elle : la propagation de valeurs considère désormais que le pointeur this en C++ (qui pointe vers l’objet courant) est toujours initialisé (sa valeur n’est jamais nullptr). Ce point particulier n’a jamais été précisé dans une norme, les compilateurs sont donc libres quant à son interprétation — même si Qt 5 ou Chromium exploitaient l’implémentation précédente. Ce cas peut arriver pour des structures, comme un arbre binaire :

struct Node {
  Node * left;
  Node * right;
};

Pour traverser cet arbre en C, la manière la plus naturelle d’écrire l’algorithme est récursive. Pour traiter le cas d’une branche absente, la fonction commence par vérifier que le pointeur passé en argument est bien valide :

void in_order(Node* n) {
  if (! n) return;
  in_order(n->left);
  in_order(n->right);
}

En C++, la syntaxe est plus plaisante avec une fonction membre. Dans ce cas, l’argument de la fonction est passé de manière implicite, à travers le pointeur this :

void in_order() {
  if (this == nullptr) return;
  left->in_order();
  right->in_order();
}

Cependant, avec cette optimisation (permise par le standard C++), le premier test sera toujours faux, puisque, par hypothèse, this est toujours un pointeur valide… et ce code plantera lamentablement à l’arrivée d’une feuille. Heureusement, cette optimisation peut être désactivée avec un simple paramètre lors de la compilation (-fno-delete-null-pointer-checks) et l’absence de tel code peut aussi être vérifiée (-fsanitize=undefined).

Bien évidemment, une meilleure manière d’écrire le code vérifie directement chacun des deux pointeurs contenus dans la structure avant de continuer la récursion — ce qui évite en passant les problèmes potentiels avec cette optimisation :

void in_order() {
  if (left)   left->in_order();
  if (right) right->in_order();
}

Sources : GCC 6.1 Released, Why does the enhanced GCC 6 optimizer break practical C++ code?, GCC 6 Release Series: Changes, New Features, and Fixes, C++ Standards Support in GCC.
Merci à Winjerome pour ses conseils à la rédaction.

PySide 2 : de retour sous l’ombrelle du Qt Project

Qt est un framework C++ principalement connu pour la création d’interfaces graphiques, c’est notamment ce qui lui a valu bon nombres de couches d’accès depuis d’autres langages, principalement Python. Il en existe deux : PyQt et PySide. Historiquement, PyQt est arrivé en premier, mais sous licence GPL ou commerciale — ce qui ne convient pas à bon nombre de projets, la famille de licences GPL étant prévue pour empoisonner tout le code qui l’utilise (copyleft). Nokia a donc lancé le développement de PySide, qui est disponible sous une licence bien plus permissive : la LGPL.

Cependant, dès 2011, les développeurs avaient des doutes sur la viabilité de PySide : Nokia venait d’arrêter de les financer. Le projet n’a plus pu avancer à un bon rythme les années d’après, même en rejoignant l’infrastructure du Qt Project. En 2015, il a été déclaré officiellement abandonné. Au niveau technique, PySide n’a jamais pu être porté tel quel vers Qt 5, il s’est limité à Qt 4, à cause notamment de la nouvelle architecture modulaire.

Peu après l’annonce de mort cérébrale, un développeur indépendant a repris le travail vers un PySide 2. Le projet revit petit à petit.

Depuis lors, la Qt Company a vu son intérêt grandir dans le projet et s’apprête à y consacrer plusieurs développeurs à temps plein, ainsi que d’investir dans l’infrastructure nécessaire, de telle sorte que PySide devienne une partie intégrante des nouvelles versions de Qt. L’intérêt principal est de fournir une couche de liaison Python sous une licence libre — la LGPL —, en accord avec les derniers changements à ce sujet dans Qt. Évidemment, l’objectif est aussi de fournir PySide sous une licence commerciale, ce qui nécessite l’accord des développeurs existants de PySide.

Pour la technique, l’avenir de PySide passera probablement par une grande réécriture de son code. En effet, une bonne partie utilise Shiboken, un générateur de code qui doit analyser une bonne partie de la syntaxe C++ du code de Qt, un exercice qui deviendra de plus en plus difficile avec Qt 5.7 et l’exploitation plus importante de C++11. Une possibilité serait d’exploiter Clang, plus particulièrement sa partie d’analyse syntaxique et sémantique du code C++.

Source : Bringing pyside back to Qt Project.

Sortie de Qt 5.7 Beta

Pas loin d’un mois et demi après la première préversion, Qt 5.7 Beta pointe le bout de son nez. En quelques mots, elle apporte bon nombre de nouveaux modules, exploite C++11 dans le code de Qt et dans son API, tout en proposant une unification au niveau des fonctionnalités entre les versions libre et commerciale.

Qt existe dans sa forme actuelle uniquement grâce à C++, tant dans ses fondations (parfois décriées) que dans sa performance à l’exécution. Le langage évolue, Qt le suit pour profiter des dernières fonctionnalités — avec un certain délai, pour ne pas abandonner en route ceux qui ne peuvent pas mettre à jour leur compilateur (notamment en gardant une version avec un support à long terme). Ainsi, dès Qt 5.7, la compatibilité avec C++98 est abandonnée, laissant place à un minimum de C++11. Des fonctionnalités comme le mot clé auto ou les fonctions anonymes trouvent maintenant place dans le code de Qt et dans son API.

Au niveau des modules, certains préversions technologiques atteignent leur maturité : Qt Quick Controls 2 et Qt 3D (pour ce dernier, après des années de développement !). De nouvelles préversions font également leur apparition : Qt Wayland Compositor, Qt SCXML, Qt SerialBus et Qt Gamepad.

Les changements de licence ont déjà fait couler pas mal d’encre. En résumé, la plupart du code de Qt sera disponible sous licence LGPLv3 ou GPLv2, les derniers modules libérés seront sous licence LGPLv3 ou GPLv3, Qt Creator et d’autres outils sous GPLv3 uniquement — ou, comme toujours, sous licence commerciale. Malgré la complexification de l’offre qui donnera du fil à retordre aux services juridiques, ces licences donnent suffisamment de garanties à Digia pour libérer plus de fonctionnalités dans l’édition libre de Qt.

Cette fois, contrairement à la précédente préversion, cette version est livrée avec des binaires prêts pour les tests. Elle est aussi intégrée aux installateurs de Qt Creator 4.0 RC.

Source : Qt 5.7 Beta Released.

Sortie de Qt Creator 4.0 RC 1

Selon ses développeurs, la version finale de Qt Creator 4.0 ne tardera plus : la RC 1, sortie aujourd’hui, s’occupe de corriger un bon nombre de défauts détectés depuis la sortie de Beta, il y a à peu près un mois.

Les principaux changements depuis la dernière préversion concernent l’interface, avec un thème plat lustré : il est maintenant le thème par défaut de Qt Creator, les utilisateurs n’ayant jamais changé de thème le verront par défaut lors de la mise à jour. L’ancien thème est bien sûr toujours disponible, dans le menu Outils, Options, Environnement, Interface (option Classique).

Les binaires de cette nouvelle préversion sont disponibles sur la page des téléchargements de Qt.

Source : Qt Creator 4.0 RC1 released.

Les transistors nanomagnétiques atteignent les limites fondamentales

Les processeurs actuels sont principalement limités par leur consommation énergétique : il n’est pas possible de garder tous les transistors d’une même puce allumés simultanément, car la densité d’énergie est beaucoup trop importante — chaque millimètre carré consomme trop d’énergie, la puce brûlerait à coup sûr sans désactiver des parties. Ce phénomène a conduit à la notion de silicium noir, c’est-à-dire les parties qui ne peuvent pas être utilisées à un instant donné dans un processeur. Un domaine de recherche dans les semiconducteurs concerne donc la création de transistors qui consomment nettement moins d’énergie (et donc dissipent moins de chaleur).

En 1961, des chercheurs d’IBM ont déterminé une limite absolue dans la consommation d’énergie d’un transistor (la limite de Landauer) : en effet, d’un point de vue thermodynamique, la bascule d’un transistor n’est pas réversible, ce qui s’accompagne inévitablement de pertes d’énergie (en application de la seconde loi de la thermodynamique). Cette valeur a été déterminée comme trois zeptojoules (3 10^-21 joules). A contrario, des transistors actuels optimisés pour la consommation d’énergie se placent au niveau de la picojoule, c’est-à-dire 10^-12 joules, soit un milliard de fois plus que le minimum théorique (!), pour la réalisation de puces mémoire magnétiques par transfert de spin (STT-MRAM). Les transistors plus courants consomment encore plus d’énergie.

En 2012, une équipe allemande a, pour la première fois, démontré expérimentalement que cette limite inférieure de consommation pouvait être atteinte. Ils ont, pour ce faire, utilisé une pince optique pour déplacer des perles de verre de deux microns de large (similaires à des bits) entre deux puits de potentiel. Une équipe américaine vient de montrer un résultat similaire, mais bien plus directement applicable à l’électronique : ils ont directement manipulé des bits faits d’aimants à l’échelle nanométrique. Ce genre d’aimants est déjà à la base des disques durs magnétiques actuels, mais également des mémoires de type STT-MRAM.

Des aimants nanométriques stockent l’information par la direction du champ magnétique de l’aimant. Avec un champ magnétique externe, les chercheurs ont pu inverser l’orientation du champ des aimants. En mesurant très précisément l’intensité et l’orientation du champ de l’aimant en fonction du champ extérieur, ils ont pu déterminer que cette opération consommait en moyenne six zeptajoules à température ambiante, soit le double de la limite de Landauer (sans compter, donc, la génération du champ utilisé pour manipuler les aimants). L’équipe estime que la différence par rapport à la limite théorique est principalement due à de légères variations dans l’orientation des nanoaimants : en effet, selon des simulations numériques, des nanoaimants idéaux atteignent exactement cette limite.

Cependant, ces progrès n’auront aucun impact sur les transistors utilisés dans les processeurs grand public à court terme, ni probablement à moyen terme : cette expérience marque un pas dans le passage entre la recherche fondamentale en physique et la recherche appliquée dans les transistors, mais il reste encore de nombreuses années avant une arrivée sur le marché.

Source (y compris l’image) et plus de détails : Zeptojoule Nanomagnetic Switch Measures Fundamental Limit of Computing.

NVIDIA annonce son architecture Pascal et CUDA 8

NVIDIA en parle depuis un certain temps et dégaine, peu après AMD, sa nouvelle générations de processeurs graphiques, dénommée Pascal, un nom qui fait référence à Blaise Pascal, mathématicien et physicien français du XVIIe siècle. Les chiffres bruts donnent déjà le tournis : un tel GPU est composé de dix-huit milliards de transistors (huit milliards pour la génération précédente, Maxwell).

Sur la technique, ce GPU (nommé GP100) est le premier gravé en 16 nm, avec la technologie FinFET+ de TSMC, les précédents l’étaient en 28 nm. Pour un processus aussi récent, la puce est énorme : 610 mm², à comparer au 600 mm² de Maxwell sur un processus bien maîtrisé. Cette surface est utilisée pour les 3840 cœurs de calcul (3072 pour Maxwell), ayant accès à un total de 14 Mo de mémoire cache (6 Mo pour Maxwell). Les cœurs ont aussi augmenté en fréquence : 1,5 GHz au lieu de 1,1 pour Maxwell. Au niveau de la mémoire principale, la technologie HBM2 est utilisée au lieu de la mémoire traditionnelle GDDR5. Une puce Pascal dispose de seize gigaoctets de mémoire (contre douze, il n’y a pas si longtemps, chez Maxwell, maintenant vingt-quatre).

NVIDIA peut donc en profiter pour intégrer bon nombre de nouvelles fonctionnalités, tournées vers le segment HPC, comme sa connectique NVLink. L’une des fonctionnalités très utiles pour monter en performance concerne les nombres à virgule flottante : contrairement à Maxwell, les unités de calcul de Pascal traitent nativement des nombres sur soixante-quatre bits et seize bits ; ainsi, une telle puce peut monter jusque vingt et un mille milliards d’opérations par seconde (21 TFlops) en seize bits, cinq mille milliards en soixante-quatre bits (avec un facteur d’à peu près quatre entre les deux : les unités sur soixante-quatre bits sont grosso modo composées de quatre unités sur seize bits).

Toujours dans le HPC, la mémoire unifiée, entre la mémoire principale de l’ordinateur et celle du processeur graphique, a aussi vu quelques améliorations. Elles se comptent au nombre de deux. Tout d’abord, l’espace d’adressage a été considérablement élargi, ce qui permet d’adresser toute la mémoire centrale et celle du GPU (et non seulement un espace équivalent à la mémoire du GPU). Ensuite, les GPU Pascal gèrent les défauts de page : si un noyau de calcul tente d’accéder à une page mémoire qui n’est pas encore chargée sur le GPU, elle le sera à ce moment-là, elle ne doit plus être copiée dès le lancement des calculs sur le GPU.

L’apprentissage profond, le cheval de bataille de NVIDIA

Toutes ces avancées sont jusque maintenant principalement prévues pour le marché du HPC, plus particulièrement de l’apprentissage de réseaux neuronaux profonds, à l’origine de miracles récents dans le domaine de l’intelligence artificielle.

NVIDIA avance un facteur d’accélération de douze dans un cas d’apprentissage d’un réseau neuronal avec sa nouvelle architecture par rapport à ses meilleurs résultats l’année dernière. Ce facteur est énorme en seulement une année, mais il faut remarquer que la comparaison proposée n’est pas toujours équitable : les nouveaux tests utilisent deux fois plus de GPU que l’année dernière, de nouvelles fonctionnalités ont fait leur apparition sur les GPU spécifiquement pour accélérer ce genre de calculs (les nombres à virgule flottante sur seize bits). Il n’empêche, le résultat reste impressionnant.

Ces avancées réunissent cinq « miracles », selon la terminologie de Jen-Hsun Huang :

  • la nouvelle architecture Pascal ;
  • la technologie de gravure de puces de TSMC ;
  • la nouvelle génération de puces mémoire empilées (HBM2) ;
  • la technologie d’interconnexion entre GPU NVLink ;
  • des améliorations algorithmiques pour tirer parti des progrès précédents.

NVIDIA DGX-1, un supercalculateur dans une boîte

Les tests de performance ont été effectués sur une machine assemblée par NVIDIA, dénommée DGX-1, un monstre de puissance. Elle couple deux processeurs Intel Xeon E5-2698 v3 et huit processeurs NVIDIA Pascal avec 512 Go de mémoire vive et 1,92 To de stockage en SSD. Globalement, la machine peut fournir 170 TFlops pour la modique somme de 129 000 $. NVIDIA la résume comme deux cent cinquante serveurs rassemblés dans un boîtier. Elle est d’ores et déjà en vente, mais les livraisons devraient débuter en juin. Des bibliothèques existantes ont été adaptées pour cette machine pour en tirer le meilleur parti, comme TensorFlow de Google.

CUDA 8 et autres avancées logicielles

Pascal vient avec des améliorations matérielles accessibles par CUDA 8, la nouvelle version de l’API de calcul sur GPU de NVIDIA. Par exemple, les opérations atomiques en mémoire, utiles pour les opérations en parallèle sur une même case mémoire sans risque de corruption, gèrent plus d’opérations sur les entiers (en parallèle avec une implémentation matérielle plus complète). Les développeurs peuvent exploiter une structure d’interconnexion NVLink explicitement depuis CUDA.

Le profilage d’applications est encore amélioré, notamment au niveau de la répartition de la charge entre le CPU et le GPU, pour déterminer les parties où l’optimisation serait la plus bénéfique globalement. Pour ce faire, le profileur visuel montre maintenant les dépendances entre les noyaux de calcul du GPU et les appels à l’API CUDA, afin de faciliter la recherche d’un chemin critique d’exécution.

De nouvelles bibliothèques font également leur apparition au sein de l’écosystème, comme nvGRAPH pour l’analyse de graphes : la planification du chemin d’un robot dans un graphe énorme (comme une voiture dans le réseau routier), l’analyse de grands jeux de données (réseaux sociaux, génomique, etc.). NVIDIA IndeX, une bibliothèque de visualisation de très grands jeux de données (répartis sur plusieurs GPU), est maintenant disponible comme extension à ParaView. cuDNN arrive en version 5, avec d’importantes améliorations de performance.

Sources : Pascal Architecture (images d’illustration), Nvidia Pascal Architecture & GP100 Specs Detailed – Faster CUDA Cores, Higher Thread Throughput, Smarter Scheduler & More, NVIDIA DGX-1 Pascal Based Supercomputer Announced – Features 8 Tesla P100 GPUs With 170 TFLOPs Compute, NVIDIA GTC 2016 Keynote Live Blog (transparents NVIDIA), Inside Pascal: NVIDIA’s Newest Computing Platform, CUDA 8 Features Revealed.

Quelques mythes sur moc

Qt est un framework C++ complet, parti des interfaces graphiques dans les années 1990 (avant la normalisation de C++) et maintenant extrêmement généraliste. L’un de ses points forts est probablement la connexion entre signaux et slots pour écrire des applications interactives : lorsqu’il se passe quelque chose dans l’application (l’utilisateur appuie sur un bouton, un paquet arrive du réseau, etc.), un signal est émis ; ensuite, le programmeur peut connecter un slot à ce signal : ce bout de code sera exécuté chaque fois que le signal sera émis. Pour implémenter cette fonctionnalité, dans les années 1990, vu l’état disparate des compilateurs, utiliser les templates C++ était impossible : les développeurs de Qt ont alors utilisé un générateur de code, nommé moc (metaobject compiler), qui sert d’autres objectifs (l’introspection et la réflexion, notamment). Avec les années, le système a été conservé, malgré le bon nombre de critiques : son importance a encore un peu grandi lors de l’arrivée de Qt Quick. Olivier Goffart, actuel mainteneur de l’outil, tente de remettre les pendules à l’heure.

Quelques mythes

moc ne réécrit pas le code qui lui est passé, il ne le réécrit pas : il l’analyse et génère de nouveaux fichiers C++, qui sont ensuite compilés de manière totalement indépendante. Sans l’outil, pour utiliser l’architecture actuelle de Qt, il serait nécessaire d’écrire de grandes quantités de code pour les tables d’introspection et d’autres détails nécessaires pour le fonctionnement des signaux et slots.

Il se concentre sur une série de macros définies par Qt pour générer son code : Qt ne définit pas de « nouveaux mots clés » C++. Pour définir une classe héritant de QObject, la macro Q_OBJECT évite au programmeur d’écrire une série de déclarations de fonctions (dont le code est généré par moc). Les signaux sont définis dans un bloc signals:, qui n’est autre qu’une macro qui correspond à public:. Bon nombre d’autres macros utilisées par le moc ne génèrent aucun code. Globalement, le code Qt reste du code C++, ce qui fait que tous les outils C++ traditionnels restent utilisables.

Son utilisation ne complique pas la compilation ou le débogage : la plupart des systèmes de compilation traitent de manière native moc ; de toute façon, il s’agit simplement d’une commande supplémentaire à appliquer sur les fichiers d’en-tête. En cas d’erreur à la compilation (ce qui est très rare), le code généré est plus facile à comprendre que l’embrouillamini généré par les templates C++.

Certains ont tenté de supprimer moc, comme CopperSpice, en promettant notamment une amélioration de performance. Cependant, cette affirmation n’est pas sous-tendue par des chiffres : le graphique ci-dessous indique que la taille des exécutables générés est bien plus grande avec CopperSpice (sans moc) que Qt (4 ou 5, avec moc). De manière générale, le code généré par moc est très efficace : il est entièrement statique et évite toute allocation dynamique de mémoire, ses données sont stockées dans les segments de données en lecture seule — là où CopperSpice génère ces mêmes données à l’exécution.

Finalement, moc évolue : depuis Qt 5, il gère complètement les macros, ce qui permet de les utiliser pour définir des signaux, des slots, des classes de base, etc. Q_PROPERTY n’autorisait pas, jusqu’il y a peu, les virgules dans ses arguments (par exemple, en lui passant un QMap), ce qui a été réglé en un rien de temps.

Des fonctionnalités absentes

Finalement, la plus grande critique de moc est probablement qu’il ne gère pas les classes avec des templates, des classes imbriquées ou l’héritage multiple. Cependant, si elles ne sont pas implémentées, c’est principalement parce qu’elles ne sont pas jugées importantes. Par exemple, une implémentation des templates a été rejetée il y a trois ans ; moc-ng, une implémentation de moc sous la forme d’extension du compilateur Clang, gère sans problème les templates et les classes imbriquées. L’héritage multiple reste possible à condition que QObject soit la première classe de base — ce qui permet bon nombre d’optimisations, de telle sorte que qobject_cast est bien plus rapide que la version standard dynamic_cast.

Et donc ?

moc n’est pas vraiment un problème, ses plus grands pourfendeurs sont généralement ceux qui le connaissent le moins. L’API et notamment le système de métaobjets et la connexion entre signaux et slots sont à la base du succès de Qt. Les avantages des autres solutions sont loin d’être clairs et moc n’est pas une limitation pour les développeurs.

Source : Moc myths debunked.

NVIDIA GameWorks : du code source libéré, de nouveaux modules

Comme NVIDIA l’avait annoncé il y a peu, de grandes nouvelles traversent son programme GameWorks, avec de l’ouverture de code source sous licence libre et la mise à disposition de nouveaux modules. Cette boîte à outils est composée d’une série d’effets utilisables très facilement par les développeurs dans leurs jeux.

De nouvelles technologies

Trois nouvelles bibliothèques font maintenant partie du programme GameWorks, après avoir été testées dans des jeux déjà en vente, principalement pour l’éclairage et la gestion des ombres (toutes sont d’ores et déjà disponibles au téléchargement) :

  • NVIDIA Volumetric Lighting simule le trajet de la lumière et sa dispersion dans l’atmosphère et l’air, un effet utilisé dans Fallout 4, plus particulièrement dans les rayons crépusculaires ;
  • NVIDIA Hybrid Frustum Traced Shadows (HFTS) traite plus particulièrement les ombres et assure une transition plus douce entre les ombres bien droites à proximité de l’objet qui bloque la lumière et les ombres bien plus douces au loin, un effet utilisé dans Tom Clancy’s The Division ;
  • NVIDIA Voxel Accelerated Ambient Occlusion (VXAO) gère l’éclairage au niveau d’une scène avec une occlusion ambiante en temps réel : la différence par rapport aux techniques plus traditionnelles est l’utilisation de toute la géométrie de la scène, pas seulement la zone visible par la caméra ; cet effet a été utilisé dans Rise of the Tomb Raider.


NVIDIA Volumetric Lighting pour le rendu d’un rayon crépusculaire dans Fallout 4


NVIDIA Hybrid Frustum Traced Shadows pour le rendu des ombres dans The Division


NVIDIA Voxel Accelerated Ambient Occlusion pour l’éclairage global dans Rise of the Tomb Raider

De nouveaux solveurs physiques

À un autre niveau, dans la simulation physique pure, de nouvelles extensions ont été annoncées (des préversions privées sont actuellement disponibles) : l’une pour les corps rigies, NVIDIA PhysX GRB (GPU rigid body) ; l’autre pour les fluides combustibles, NVIDIA Flow.

NVIDIA PhysX GRB simule des corps rigides sur des processeurs graphiques, mais peut aussi exploiter le processeur principal en simultané (sans aucun écart en fonctionnalité selon la combinaison de processeurs choisie) : par rapport au code traditionnel, les calculs peuvent être accélérés d’un facteur six pour des simulations relativement lourdes ; une préversion privée est actuellement disponible, une version plus avancée devrait être rendue disponible dans les semaines à venir.

L’accélération sur le GPU concerne toutes les étapes du solveur, répliquées par rapport à la version CPU : les contraintes, les contacts, les phases de recherche. Cependant, au niveau de l’implémentation, la version GPU a été optimisée à certains points, comme la gestion d’îlots d’objets, pour gérer des scènes encore plus grandes. L’API est très similaire à celle de PhysX, ce qui facilitera l’utilisation de ce nouveau solveur ; cependant, tout le code GPU utilise NVIDIA CUDA, ce qui empêche son utilisation sur du matériel de fabricants concurrents mais devrait être compatible Linux et OS X.

NVIDIA Flow simule l’écoulement de fluides combustibles, ce qui modélise notamment le feu et la fumée ; la différence par rapport aux techniques précédentes est que ce solveur n’est pas limité à un volume prédéfini de simulation, puisqu’il adapte la grille de calcul aux nouveaux besoins. Contrairement à NVIDIA PhysX GRB, cette bibliothèque n’a pas de parti pris au niveau du matériel : elle utilise directement DirectX 11 et 12 et fonctionne donc sur du matériel AMD (mais pas sur des systèmes d’exploitation autres que Windows).

Toujours au niveau physique, la première version finale de FleX est maintenant disponible pour le grand public, un solveur GPU généraliste que NVIDIA a commencé à montrer en 2013, mais aussi intégré à Fallout 4 pour la gestion des débris.

Du code libéré

Il y a un an, NVIDIA montrait les premiers signes d’ouverture du programme GameWorks en mettant gratuitement à disposition les sources de PhysX, son moteur physique, à l’exception des parties GPU — mais pas sous une licence libre ; de plus, l’accès au dépôt GitHub est soumis à un enregistrement.

Cette semaine, d’autres composants ont été libérés de la sorte : NVIDIA Volumetric Lighting, récemment annoncé et détaillé plus haut ; NVIDIA HairWorks, pour la simulation et le rendu de cheveux et poils ; ainsi que NVIDIA HBAO+, un effet similaire au VXAO utilisé dans Rise of the Tomb Raider.

Ce qui est plus étonnant, cependant, c’est qu’un composant complet a été libéré : FaceWorks, pour le rendu de visages. La licence indique que tout développeur peut créer un travail dérivé et le redistribuer librement, tant qu’il indique qu’il exploite du code source venant de NVIDIA — ce qui ressemble très étrangement à du logiciel libre. Les les modèles 3D ne sont pas concernés par cette licence.

Sources : NVIDIA Advances Real-Time Game Rendering and Simulation With Launch of NVIDIA GameWorks SDK 3.1, GDC 2016: PhysX GPU Rigid Body and NVIDIA Flow (y compris vidéo de NVIDIA PhysX GRB et image de NVIDIA Flow), Fallout 4 Graphics, Performance & Tweaking Guide (image de Fallout 4), Tom Clancy’s The Division Graphics & Performance Guide (image de The Division), Rise of the Tomb Raider Graphics & Performance Guide (image de Rise of the Tomb Raider)