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

Publié le par
Répondre

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

Publié le par
Répondre

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

Publié le par
Répondre

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

Publié le par
Répondre

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

Publié le par
Répondre

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

Publié le par
Répondre

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

Sortie de Unreal Engine 4.8, version focalisée sur la stabilité

Publié le par
Répondre

Trois mois et demi après la précédente version, la nouvelle mouture d’Unreal Engine est disponible, numérotée 4.8. L’un des points majeurs de cette version est la stabilité de l’éditeur et des jeux, en prenant en compte la plupart des bogues courants et des plus petites demandes de fonctionnalité. L’éditeur et le moteur d’exécution devraient ainsi être plus solides. Notamment, le portage de l’éditeur vers Linux est bien avancé, même s’il ne sera pas possible de lancer des jeux.

Lire la suite →

L’avenir de Qt 4.8 passe-t-il par CopperSpice ?

Publié le par
Répondre

La dernière version de maintenance de Qt 4.8 est sortie, numérotée 4.8.7. Qt 5.0.0 est sorti fin 2012 ; l’un des objectifs était de garder une grande rétrocompatibilité avec les versions précédentes, pour faciliter la transition.

Cependant, certains développeurs ont préféré effectuer des changements plus profonds dans Qt 4.8, notamment afin d’exploiter les templates C++ et les nouveautés de la norme C++11. Leur travail a donné naissance à CopperSpice, dérivé de Qt 4.8. L’un des points essentiels est la disparition du moc, le compilateur de métaobjets utilisé par Qt depuis ses débuts. Ce générateur de code servait, dans les années 1990, à pallier les manques du C++ à l’époque, qui rendait impossible l’implémentation de systèmes comme les signaux et slots (également implémentés dans Boost.Signals dès le début des années 2000, sans tel outil).

Ce n’est pas la première fois que l’obsolescence de cet outil était pointée du doigt, malgré les justifications apportées dans la documentation. L’un des défauts couramment rapportés est l’impossibilité d’utiliser les templates avec ce système de métaobjets, mais également la performance (comparaisons de chaînes de caractères à l’exécution) — CopperSpice cite d’ailleurs dans sa documentation une liste d’inconvénients. Récemment, des preuves de concept ou des réflexions avancées ont été proposées pour s’en passer ou l’inclure au niveau du compilateur.

CopperSpice se défait donc complètement de cet héritage du passé, remplacé par C++11. Par conséquent, du code utilisant CopperSpice n’a pas besoin d’outil externe pour sa compilation, ce qui pouvait rendre les choses plus compliquées pour l’intégration avec du code C++ existant ; le code C++ utilisant Qt peut être transformé à l’aide d’un outil automatique de traduction, baptisé PepperMill. Il intègre également des nouveautés de Qt 5. De même, la compilation se fait avec les GNU AutoTools, certes plus répandus que qmake, mais pas forcément plus modernes (contrairement à CMake, par exemple). L’un des objectifs à plus long terme est de remplacer les conteneurs de Qt par leurs équivalents de la STL (ce qui évite de les recoder).

Cette manière de procéder pose cependant question : était-il nécessaire de créer un nouveau projet pour « juste » se débarrasser du moc, c’est-à-dire s’écarter d’une grande communauté ? Pourquoi repartir d’une version aussi ancienne (Qt 4.8.2 date de mai 2012), alors que Qt 5 a justement permis beaucoup de nettoyage ? Les développeurs de CopperSpice ont aussi leur propre version de Doxygen pour la documentation (renommée DoxyPress). L’univers Qt Quick ne fait pas partie des fonctionnalités de CopperSpice.

Sources : annonce de CopperSpice, site officiel, discussion sur Phoronix.

Controverse sur l’utilisation de NVIDIA GameWorks dans Witcher 3

Publié le par
Répondre

NVIDIA GameWorks est l’ombrelle sous laquelle NVIDIA propose une série de technologies d’effets pour des jeux. Leur principal avantage est d’être déjà implémentés et optimisés par NVIDIA, les développeurs des jeux peuvent donc ajouter un surcroît de réalisme à leurs productions sans toutefois y passer des semaines ou des mois. Ce programme contient notamment leur moteur physique PhysX et les diverses extensions APEX (Clothing, Destruction, etc.), mais aussi des bibliothèques d’occlusion ambiante (HBAO+), d’illumination globale (GI Works), de rendu de visages (FaceWorks), de poils et de cheveux (HairWorks) ou d’océan (WaveWorks). Avant ce programme, NVIDIA proposait déjà ce genre d’effets, mais sous la forme de code à intégrer au jeu, pas comme bibliothèque externe, ce qui en limitait l’utilisation.

Cependant, ces outils peuvent poser question : ils ne sont accessibles qu’aux studios de développements (bien que certaines parties soient déjà intégrées à Unreal Engine 4 et que FleX est téléchargeable seul), leurs sources ne sont pas disponibles… y compris pour les fabricants de cartes graphiques concurrentes comme AMD ou Intel. Ainsi, ils ne peuvent pas optimiser ces bibliothèques pour leur matériel, contrairement à NVIDIA — une pratique courante dans l’industrie.

Le problème, dans le cas de Witcher 3, c’est que la performance du jeu décroît sensiblement en activant HairWorks sur des GPU sans caméléon. Un des développeurs précise :

Many of you have asked us if AMD Radeon GPUs would be able to run NVIDIA’s HairWorks technology – the answer is yes! However, unsatisfactory performance may be experienced as the code of this feature cannot be optimized for AMD products. Radeon users are encouraged to disable NVIDIA HairWorks if the performance is below expectations.

De même, Project Cars a tendance à nettement moins bien fonctionner sur du matériel AMD que NVIDIA. Il utilise des technologies GameWorks, contrairement à d’autres jeux du même genre qui ne souffrent pas d’un grand écart de performance ; notamment, la simulation physique des voitures utilise PhysX, qui peut utiliser les cartes NVIDIA pour une partie des calculs grâce à CUDA, contrairement aux cartes AMD — désactiver les calculs physiques sur GPU pour une carte NVIDIA donne également des problèmes de performance.

D’autres jeux utilisant la même technologie n’ont pas ce genre de problème, comme FarCry 4 : activer HairWorks diminue certes le nombre d’images par seconde d’une dizaine d’unités, mais indépendamment de la marque du GPU utilisé, tant sur du matériel NVIDIA que AMD (récent et de haut de gamme des deux côtés), selon Far Cry 4 Graphics Features Performance Review: Fur Performance.

Ces critiques ne sont pas récentes, mais ce n’est qu’en avril 2014 que NVIDIA a commencé à offrir des licences pour ces technologies incluant le code source, en fonction du degré de maturité du code, soit après les premières utilisations dans des jeux finalisés. Peu après, deux ingénieurs ont avoué que les développeurs de jeux utilisant GameWorks n’étaient pas autorisés à travailler avec AMD pour optimiser leur code (en juillet 2014).

La réponse de NVIDIA à ce sujet apporte des précisions intéressantes à ce sujet :

We are not asking game developers do anything unethical.

GameWorks improves the visual quality of games running on GeForce for our customers. It does not impair performance on competing hardware.

Demanding source code access to all our cool technology is an attempt to deflect their performance issues. Giving away your IP, your source code, is uncommon for anyone in the industry, including middleware providers and game developers. Most of the time we optimize games based on binary builds, not source code.

GameWorks licenses follow standard industry practice. GameWorks source code is provided to developers that request it under license, but they can’t redistribute our source code to anyone who does not have a license.

The bottom line is AMD’s tessellation performance is not very good and there is not a lot NVIDIA can/should do about it. Using DX11 tessellation has sound technical reasoning behind it, it helps to keep the GPU memory footprint small so multiple characters can use hair and fur at the same time.

I believe it is a resource issue. NVIDIA spent a lot of artist and engineering resources to help make Witcher 3 better. I would assume that AMD could have done the same thing because our agreements with developers don’t prevent them from working with other IHVs. (See also, Project Cars)

Elle est en tout cas appuyée par des faits vérifiés à l’extérieur : la performance en tessellation est bien meilleure chez NVIDIA qu’à la concurrence. Ces différences en performance seraient donc dus à une exploitation intensive de la part de NVIDIA des parties qu’ils savent bien fonctionner chez eux. Sciemment ou non, cela a eu des impacts négatifs sur le matériel AMD — sans interdire toute optimisation par AMD.

Sources : Nvidia Responds To Witcher 3 GameWorks Controversy, PC Gamers On The Offensive, message de Marcin Momot, message de 007sk2, Far Cry 4 Graphics Features Performance Review: Fur Performance, NVIDIA and AMD Fight over NVIDIA GameWorks Program: Devil in the Details, The NVIDIA GeForce GTX 980 Review: Maxwell Mark 2

Qt WebEngine : le problématique empaquetage de KDE

Publié le par
Répondre

Qt 5.4 est venu avec une énorme nouveauté, Qt WebEngine, une intégration de Chromium (le projet libre derrière Google Chrome) pour l’intégration de contenu Web dans des applications Qt. Chromium est un véritable navigateur, avec notamment une pile réseau complète, construit sur Blink, un moteur de rendu dérivé de WebKit. L’objectif est de déprécier Qt WebKit assez rapidement.

Ce nouveau module est d’ores et déjà utilisé par certaines parties de KDE 5, comme KDE PIM, un outil de gestion des informations personnelles.

Avis des mainteneurs

Pourtant, ce mouvement ne se fait pas sans à-coup, notamment du côté des mainteneurs de KDE pour Debian et Fedora, par la voix de Lisandro Pérez Meyer. Leur grief est que Qt WebEngine est un composant logiciel très difficile à empaqueter, notamment à cause de ses nombreuses dépendances. En elles-mêmes, elles ne posent pas de problème ; cependant, Qt WebEngine les intègre dans ses sources avec des modifications, ce qui empêche d’utiliser les versions installées à l’échelle du système. Cette manière de procéder consomme plus d’espace disque et plus de mémoire, mais aussi complique la tâche lors de mises à jour de sécurité (chaque binaire doit alors être mis à jour séparément, plutôt que la copie globale).

Cette difficulté est déjà présente au niveau de Chromium et explique à elle seule pourquoi ce navigateur n’est pas inclus dans Fedora. En plus, le moteur JavaScript V8 manque de portabilité : WebKit contenait une couche d’abstraction du moteur JavaScript, que Blink (donc Chromium) a abandonné, ce qui force l’utilisation de V8. Pour Fedora, le problème est mineur, puisque V8 est compatible avec toutes les plateformes majeures visées par la distribution ; par contre, des outils comme Qt Assistant, s’ils passaient sur Qt WebEngine, ne pourraient plus fonctionner sur les plateformes secondaires (comme ARM 64 bits — dite AAarch64 —, PowerPC ou s390 — utilisée par les IBM System z).

De plus, la compilation des informations de débogage est pratiquement impossible, à cause de la quantité astronomique de RAM utilisée par l’éditeur de liens (plus de huit gigaoctets) — en augmentation depuis Qt WebKit, qui n’était déjà pas connu pour sa facilité de compilation.

Réponse des développeurs

La réponse que font les développeurs de KDE aux mainteneurs des distributions n’implique pas de grands changements du côté du développement de Qt WebKit ou de Chromium : selon Albert Astals, l’objectif d’une distribution est de fournir les logiciels demandés aux utilisateurs ; si leurs règles ne leur permettent pas de distribuer ces logiciels, c’est qu’il faut adapter les règles.

Au contraire, Franz Fellner propose d’adapter les applications : pourquoi forcer l’utilisation d’un moteur aussi complexe que Chromium quand les besoins sont relativement limités, comme afficher des courriers électroniques ?

D’autres avis sont encore plus tranchés, comme celui de Kevin Kofler : puisque Chromium n’en a cure de l’empaquetage, il faudra que Qt en maintienne sa propre version… ou déprécier le module Qt WebEngine au profit de Qt WebKit !

Sources : Distros and QtWebEngine (discussion), Deprecating modules with 5.5 (message de Kevin Kofler)