Sortie de Qt 5.7

Trois mois après Qt 5.6, une version avec assistance technique à long terme, voici venue l’heure de Qt 5.7. Elle n’est pas dénuée de nouvelles fonctionnalités, cependant, à cause des différents retards dans le développement (d’abord pour Qt 5.6, puis 5.7, mais dans une moindre mesure) : outre les habituelles corrections de défauts en tout sens (néanmoins pas toujours en quantité suffisante) et améliorations de performance, cette nouvelle version de Qt vient avec de nouvelles fonctionnalités pour le domaine automobile et une série de modules anciennement uniquement disponibles sous licence commerciale, avec des changements au niveau des licences. Maintenant, les éditions commerciale et libre sont sur un pied d’égalité au niveau des fonctionnalités (à l’exception du Qt Quick Compiler, cet écart sera résorbé pour Qt 5.8).

Cette version pouvant laisser de côté la compatibilité avec une série d’anciens compilateurs (Qt 5.6 étant disponible pour ceux qui ne peuvent pas encore faire de mise à jour à ce niveau), le code même de Qt peut exploiter des fonctionnalités bien plus modernes de C++11 (constexpr, sémantique de déplacement, auto, for sur des intervalles). Ainsi, le code de Qt sera plus facile à maintenir dans le futur. Ces efforts de mise au goût du jour se poursuivront dans les prochaines versions et pourront offrir de nouvelles API plus modernes.

Un autre point très important de Qt 5.7 est l’arrivée de Qt 3D en version finale : il sera bien plus facile d’intégrer des graphismes 3D dans des applications, voire de transformer toute l’interface en 3D. Ce moteur 3D complet, accessible tant en C++ qu’en QML, rejoint l’intégration précédente d’OpenGL, le module Qt Canvas 3D et le nouveau Qt Data Visualization. Ce module dépasse de loin le simple rendu 3D, en proposant un framework 3D complet et extensible.

Côté Qt Quick, les contrôles de base ont droit à une cure de jouvence. La bibliothèque Qt Quick Controls arrive en version 2.0, la modification principale étant que les composants proposés ne sont plus seulement prévus pour les plateformes de bureau, mais également pour l’embarqué. Ils sont donc bien plus légers en mémoire et leur performance a été améliorée. Ces améliorations viennent avec quelques limitations, un peu en fonctionnalité, un peu en apparence (il n’y a plus d’intégration avec le style natif de la plateforme). Par contre, les gains en performance sont impressionnants.

De nouvelles fonctionnalités arrivent en tant que préversions technologiques, comme le Qt Wayland Compositor, très utile pour les applications automobiles de Qt. Ce module existait depuis quelques versions de Qt, son API a été retravaillée et stabilisée pour Qt 5.7, tant en C++ qu’en QML.

Un autre nouveau module est Qt SCXML, qui facilite l’utilisation de machines d’état au format SCXML dans Qt, en étant intégré dans le cadre actuel. Qt Gamepad facilite l’utilisation des manettes de jeu, toujours côté C++ et QML, sur bon nombre de plateformes : Windows, Linux côté bureau, mais aussi Android et iOS pour le mobile.

Source : Qt 5.7 released.
Télécharger Qt 5.7.

Le retour de Qt WebKit ?

Pour sa version 5.6, Qt officialisait l’abandon du module Qt WebKit, qui intégrait un moteur de rendu Web dans des interfaces Qt : WebKit, le moteur de Safari et dont dérive celui de Chrome (Blink). Ce module a été remplacé par Qt WebEngine, qui se base sur un moteur bien plus complet : Chromium, intégrant à la fois une pile réseau et multimédia. Qt WebEngine est bien plus lourd et monolithique que son prédécesseur, ce qui n’est pas sans poser quelques problèmes de distribution.

De plus, le passage de Qt WebKit à Qt WebEngine ne se fait pas sans douleur, puisque les interfaces sont assez différentes et que Qt WebEngine ne fournit pas le même degré d’intégration à Qt. Aussi, Qt WebEngine n’est pas exploitable à un niveau assez bas, pour travailler directement dans le DOM ou effectuer un rendu hors écran, ce qui est très utile pour toutes les applications devant traiter des pages Web.

C’est pourquoi certains développeurs se sont lancés dans un projet de réhabilitation de Qt WebKit, en mettant à jour la version utilisée du moteur tout en gardant la même API et ABI. Bien que ce projet soit encore à l’état embryonnaire, cette mise à jour apporte bon nombre d’avantages par rapport aux dernières versions officielles du module, notamment au niveau des fonctionnalités disponibles en JavaScript (une bonne partie d’ES2015) et des API HTML5 (WebAudio, images adaptées à la résolution). Le développement est loin d’être terminé : l’API widgets est relativement prête, mais pas du tout côté QML. Des API HTML5 comme IndexedDB et WebGL ne sont pas disponibles, ni les extensions (tant côté Qt que NPAPI).

Cependant, au niveau des plateformes compatibles, la liste s’amenuise par rapport à l’itération précédente de Qt WebKit : pas d’Android, de QNX ou de WinCE. L’un des freins au module existant était la nouvelle API de WebKit, mais les développeurs de ce nouveau projet ne sont pas sûrs de travailler sur une compatibilité avec Windows pour cette API WebKit 2. De plus, les développeurs de WebKit ont une politique nettement plus agressive au niveau des normes C++ utilisables dans leur code : ils sont passés depuis longtemps à C++11 (alors que Qt s’apprête seulement à franchir ce pas avec Qt 5.7) et C++14 dans les versions de développement actuelles. En d’autres termes, le choix de compilateurs se restreint.

Pour toutes ces raisons, il apparaît de manière relativement claire que ces efforts ne pourront pas se faire sous le nom de Qt WebKit, pour éviter la confusion avec le module précédent : ces efforts pourraient se nommer WebKitQt (comme les autres ports de WebKit) ou Qt WebKit NG (le nom de code interne actuel). En plus d’autres considérations pratiques, comme un alignement sur WebKitGTK, le planning des versions ne sera que rarement aligné sur celui de Qt. Par conséquent, WebKit ne fera probablement jamais son retour parmi les modules distribués d’office avec Qt, mais plutôt comme extension, téléchargeable à la carte… ce qui n’empêchera pas le développement sous l’ombrelle du Qt Project.

Sources : [Development] QtWebKit is coming back, [webkit-qt] [Announcement] QtWebKit Technology Preview 1.
Voir aussi : le site de Qt WebKit Reloaded.

Qt Automotive Suite : Qt se positionne dans le domaine automobile

Qt est un framework complet, qui s’adapte très bien à diverses situations, notamment les systèmes informatiques d’infodivertissement embarqués dans les voitures actuelles (IVI). Plusieurs sociétés ont posé ce constat, après plus d’une vingtaine de projets achevés dans le domaine et des millions de véhicules équipés (la plupart des véhicules récents, notamment chez Fiat et ses filiales et chez Tesla, ainsi que sur le système Ford Sync 3). Lors de ces projets, ces sociétés ont créé divers outils et composants bien pratiques, mais chacune dans son coin : pour pousser Qt plus loin dans le domaine de l’IVI, il devenait important de réutiliser ces outils, pour que chacun puisse se spécialiser sans perdre son temps à développer cet environnement de travail depuis zéro. C’est ainsi qu’est né le projet Qt Automotive Suite, en partenariat entre la Qt Company, Pelagicore et KDAB : en rassemblant ces outils et composants, actuellement développés à gauche, à droite, sous une licence libre pour une bonne partie.

Une de leurs observations a été l’évolution du secteur : en quelques années, ces systèmes d’infodivertissement sont passés d’un affichage d’une à deux lignes couplé avec l’autoradio à des systèmes multimédias complexes, avec plusieurs écrans répartis dans l’habitacle. Le cycle de développement s’en est vu chamboulé : la sous-traitance complète de cette partie n’est plus possible, les constructeurs automobiles doivent s’intégrer plus dans le processus de développement, notamment afin de corriger les défauts qui ne deviennent visibles qu’en situation réelle. Une partie des outils de Qt Automotive Suite facilitent donc ce processus d’itérations rapides pour tester divers changements dans les applications — ce qui aide à fournir un produit fini de meilleure qualité.

Architecturalement, cette suite d’outils se compose d’une série de modules Qt, d’extensions à Qt for Device Creation (un outil propriétaire), d’un gestionnaire d’applications, en plus d’outils de développement, notamment intégrés à Qt Creator.

Gestionnaire d’applications et compositeur

Vu la taille des systèmes actuels, tout développer dans une seule application n’a pas vraiment de sens : le processus serait trop fragile. Les architectures modernes sont plutôt orientées multiprocessus, l’interface complète étant divisée en unités fonctionnelles relativement indépendantes. Un autre avantage est la simplification des mises à jour, puisque seules les parties de l’interface qui ont été modifiées doivent être transmises.

Ainsi, la suite comprend un gestionnaire d’applications, qui gère le cycle de vie complet de chaque application : installation, permissions accordées pour les diverses API, lancement et fermeture des applications, notamment quand les ressources disponibles deviennent trop faibles. Ce gestionnaire est intégré dans un compositeur Wayland, qui arrive en préversion technologique avec Qt 5.7 : ainsi, les concepteurs des interfaces pourront choisir exactement ce qu’ils veulent pour la répartition des applications sur les différents écrans disponibles.

Qt IVI : un accès aux API automobiles

Comme d’autres modules de Qt, IVI est prévu pour l’accès aux API spécifiquement développées pour le domaine automobile. Cette couche d’abstraction favorise la réutilisation de code par-delà les plateformes utilisées. Le même système d’extensions est utilisé qu’ailleurs dans Qt pour fournir l’accès aux API disponibles sur la plateforme courante. Il est aussi intégré au gestionnaire d’applications pour la vérification des permissions. Pour le moment, des implémentations sont disponibles pour GENIVI, QNX et AGL. Un module multimédia est en cours de développement, il devrait arriver fin du mois.

Outillage

Pelagicore a contribué au Qt Project l’un de ses outils dans le cadre de cette suite : QML Live. Il sert à mettre à jour très rapidement, en temps réel, une interface Qt Quick dans le cadre du développement : ainsi, expérimenter de nouvelles interfaces devient très facile.

Pour faciliter le débogage d’applications, KDAB a développé GammaRay pour l’introspection et la visualisation d’applications Qt. Dans le cadre de Qt Automotive Suite, l’outil sera profondément intégré dans Qt Creator, avec des extensions pour les parties IVI.

Disponibilité

Qt 5.7 est prévu pour la semaine prochaine, Qt Automotive Suite 1.0 devrait arriver peu de temps après (à la fin de ce mois). Le développement a lieu en grande partie selon le même modèle collaboratif que Qt, avec des dépôts Git accessibles au grand public, un espace de revue de code et une liste de diffusion pour le développement.

Sources et images : Announcing The Qt Automotive Suite, Branding by UX – Announcing Qt Automotive Suite.

Sortie de Qt Creator 4.0.1

Parallèlement à Qt 5.6.1, une nouvelle version de maintenant de Qt Creator vient de voir le jour : la 4.0.1. L’un des grands axes des correctifs porte sur CMake : ce type de projet est nettement mieux intégré depuis Qt Creator 4.0. Maintenant, l’EDI affiche une notification quand le cache CMake est altéré depuis l’extérieur de Qt Creator et entre en conflit avec les paramètres de Qt Creator.

Du côté Windows, les binaires des compilateurs sont plus facilement trouvés : Qt Creator peut détecter automatiquement les Microsoft Visual C++ Build Tools ; l’analyse statique Clang n’échoue plus en cherchant le binaire du compilateur.

Cette nouvelle version de Qt Creator est notamment installée avec Qt 5.6.1, mais aussi de manière autonome.
Voir aussi : la liste des changements.
Source : Qt Creator 4.0.1 released.

Sortie de Qt 5.6.1

Pas loin de trois mois après la sortie de Qt 5.6, une version avec un support à long terme, la version 5.6.1 est arrivée. Elle n’apporte aucune nouvelle fonctionnalité, mais bien des corrections de défauts et de sécurité : pas moins de 800 améliorations ont eu lieu depuis Qt 5.6.0 — attendues depuis longtemps par certains. Les bibliothèques tierces ont notamment été mises à jour, comme libpng (pour la lecture d’images au format PNG) ou Chromium (à la base du module Qt WebEngine), afin de profiter de leurs dernières corrections, tant pour les fonctionnalités que la sécurité.

Bon nombre de tickets ouverts sur l’application de suivi restent ouverts pour Qt 5.6 (QTBUG-18009 pour les vues, QTBUG-52901 pour Android, etc.), mais ils seront étudiés pour les prochaines versions correctives de Qt 5.6 : avec ces 800 commits, la 5.6.1 est déjà relativement grosse et il valait mieux envoyer ces correctifs rapidement, plutôt que d’attendre de les avoir tous corrigés (ce qui aurait induit un délai de plusieurs mois supplémentaires).

Voir aussi : les changements apportés, module par module.
Télécharger Qt 5.6.1.
Source : Qt 5.6.1 Released.

Unreal Engine 3.12

La nouvelle version de l’Unreal Engine, numérotée 4.12, est sortie cette semaine. Bon nombre de nouveautés concernent la réalité virtuelle, avec notamment un éditeur dédié. Ceci se fait sans oublier de nouveaux effets et un tout nouvel outil de création d’animations et de cinématiques (qui permet d’importer les réalisations Matinee). Sur le plan technique, Vulkan fait aussi son arrivée, avec une première adaptation du moteur de rendu, même s’il n’est pas encore achevé ; sous Windows, la seule version de Visual C++ pour laquelle la compatibilité est assurée est maintenant la 2015 (y compris les éditions gratuites, Express et Community).

Animations avec Sequencer

Ce nouvel outil est prévu pour combiner la puissance d’éditeurs non linéaires avec des techniques d’animation 3D. Ainsi, l’édition ne doit pas se faire exclusivement selon la ligne du temps, tout en permettant de visualiser le résultat en permanence à n’importe quel moment de l’animation. Une autre fonctionnalité importante est l’édition en simultané entre plusieurs utilisateurs.

La gestion des caméras a été améliorée depuis Matinee, facilitant la création de plans plus réalistes. Notamment, il est possible de gérer finement les détails de l’optique utilisée pour générer une vidéo (notamment la longueur focale).

Éditeur pour la réalité virtuelle

Le nouveau mode d’éditeur VR permet de naviguer dans la scène et d’éditer les niveaux tout en étant immergé dans la réalité virtuelle, bien à l’aise dans son casque. Ainsi, il est bien plus naturel de déplacer des objets, grâce aux contrôleurs intégrés aux casques. La bibliothèque de contenus est aussi accessible, avec les outils de placement précis. Cette fonctionnalité est encore assez expérimentale et ne fonctionne, à présent, qu’avec un HTC Vive ou un Oculus Rift avec un contrôleur, afin de détecter précisément les mouvements de l’artiste aux commandes.

Effets liés à la réflexion

Dans les nouveaux effets, on compte les réflexions planaires calculées en temps réel. Celui-ci fonctionne en effectuant le rendu de la scène depuis les directions de la réflexion : elle est donc assez coûteuse en temps.

Cependant, la qualité est bien meilleure qu’avec la version précédente (screen space reflections, à gauche dans l’image).

D’autres nouvelles fonctionnalités configurent finement le moteur de rendu pour une réflexion sur des surfaces bien plus réaliste que précédemment, avec une très haute qualité, notamment pour la visualisation de voitures pour les mettre en évidence.

Vulkan sur mobile

Le moteur de jeu se met aussi à la nouvelle API Vulkan, exploitée pour le moment exclusivement sur les plateformes mobiles. Les fonctionnalités nécessaires pour les autres plateformes ne sont pas encore implémentées. Cette première version n’est qu’un aperçu de ce qui attend le moteur, elle n’a pas été particulièrement optimisée.

Source et images : Unreal Engine 4.12 Released!.

Sortie de Qt 5.7 RC

Qt 5.7 RC vient d’être annoncé, avec un certain retard sur le planning (Qt 5.7 était attendu pour avril). La version finale devrait arriver dans les prochaines semaines, en fonction des défauts trouvés dans cette nouvelle préversion : idéalement, elle devrait être disponible le 15 juin, soit dans moins de deux semaines. Avec les retards de Qt 5.6 et 5.7, pour le moment, la prochaine version (qui sera numérotée 5.8) n’est pas encore précisément planifiée, mais elle devrait venir d’ici à la fin de l’année.

En quelques mots, cette version apporte beaucoup d’éléments au niveau de Qt. Par exemple, les compilateurs non compatibles avec C++11 ne sont plus pris en charge, ce qui permet de nettoyer certaines parties du code. De nouveaux modules sont disponibles, comme Qt 3D (un moteur 3D pour Qt et Qt Quick) ou Qt Quick Components 2. D’autres modules arrivent en préversion (Qt Wayland, Qt SCXML, Qt GamePad, Qt Serial Bus). Pour plus de détails, consultez l’annonce de début d’année.

Source : Qt 5.7.0 Release Candidate Available.
Voir aussi : New Features in Qt 5.7.

Scala Native : accéder au bas niveau depuis Scala

Le langage Scala n’est pas dénué d’avantages, comme beaucoup d’autres : il est typé (comme C ou Pascal), mais ne force pas à indiquer les types explicitement dans le code (contrairement aux précités, mais comme Python) ; il n’impose pas une verbosité monstre (contrairement à Java), avec une syntaxe orientée productivité (comme Python) ; il est raisonnablement rapide (comme Java, mais nettement moins que C), mais permet d’exploiter le parallélisme très facilement (contrairement à Python).

Par contre, un des inconvénients de Scala est sa vitesse d’exécution, pas toujours suffisante : il faut compter le temps de démarrage de la JVM, puis les optimisations que le moteur JIT peut effectuer sur le code qui lui est soumis, sans oublier que le ramasse-miettes peut venir jouer. La sécurité que le langage offre peut aussi aller à l’encontre de la performance à l’exécution : il est impossible de s’échapper du bac à sable défini, à l’exception de quelques utilisateurs très expérimentés. Finalement, au niveau de l’accès aux bibliothèques natives préexistantes, leur réutilisation est presque impossible — après tout, ces bibliothèques natives pourraient causer des problèmes de sécurité !

Pour résoudre ces problèmes, une équipe de l’EPFL, déjà à l’origine de Scala, a lancé le développement de Scala Native. Ce compilateur Scala exploite LLVM, l’infrastructure de compilateurs derrière Clang, notamment. La syntaxe de cette variante de Scala ne diffère de l’originale que par quelques ajouts, dont l’objectif est de faciliter l’interopérabilité avec des bibliothèques natives, comme des structures C (avec l’annotation @struct sur une classe) ou encore l’allocation de mémoire sur le tas avec des pointeurs :

@struct class Vec ( // Définition d'une structure en C.
  val x: Double
  val y: Double
}
val vec = stackalloc[Vec] // Équivalent à un malloc() en C ou un new en C++ : vec est un pointeur sur le tas.

Pour accéder directement à des fonctions C (comme malloc()), il est aussi possible d’utiliser l’annotation @externe et directement définir la fonction comme utilisable :

@extern object stdlib {
  def malloc(size: CSize): Ptr[_] = extern
}
val ptr = stdlib.malloc(32)

Au niveau de l’implémentation, le projet Scala Native ne duplique pas l’analyse syntaxique du compilateur, mais l’utilise (ou bien dotty, la prochaine génération du compilateur Scala). Il profite donc d’une base de code bien établie, ainsi que d’optimisations éprouvées dans le contexte du code Scala.

À l’exécution, bien sûr, Scala Native exploite toujours un ramasse-miettes, le classique Boehm, simplement parce qu’il a l’avantage de déjà exister. Les développeurs notent qu’il ne peut que s’améliorer par rapport à cette implémentation générique. La bibliothèque standard Java est partiellement disponible, toute la bibliothèque standard C est accessible.

Ce générateur de code natif depuis Scala n’est pas encore prêt pour le plus grand nombre, il a, à peine, été annoncé ce mois-ci. Ses objectifs ne concernent pas les temps de compilation. Cependant, il montre que le langage Scala veut s’exporter de plus en plus, après un autre générateur de code JavaScript pour utiliser son code dans des navigateurs Web.

Source (dont image) : présentation à Scala NYC.
Voir aussi : le site officiel de Scala Native, le projet sur GitHub.

CryENGINE V : de la simulation de fluides et des particules sur GPU

Disponible depuis peu sur GitHub, la nouvelle version de CryENGINE, notée V, vient avec un nouveau système de simulation des particules sur le GPU, nommé Wavicle. Il s’agit d’un mouvement global, qui vise à déporter sur le GPU autant de calculs que possible, quand il n’est pas occupé à gérer les graphismes.

Wavicle s’organise exclusivement autour du GPU, en allouant et gérant les ressources nécessaires aux effets demandés, avec un impact sur le CPU à peu près nul. Puisque toutes les données sont déjà sur le GPU, elles peuvent être affichées très rapidement — tout comme la simulation des particules peut exploiter le tampon de profondeur utilisé pour le rendu, ce qui permet d’effectuer des calculs de collision avec les éléments affichés. L’avantage du GPU est qu’il peut traiter plus de particules qu’un CPU, simplement parce que ces calculs se prêtent mieux à la puissance de calcul disponible.

Le système est d’ores et déjà avancé, Wavicle permet de tester de nouveaux types d’interaction avec les données sur le GPU. Par exemple, il a permis le développement d’un système de simulation de fluides, avec une méthodologie SPH : le fluide est simulé comme une série de particules qui se déplacent, chacune modélisant une partie de la masse qui se déplace. En augmentant le nombre de particules utilisées, la simulation est plus précise, mais elle prend plus de ressources de calcul : il est alors possible de déterminer un compromis en performance assez précisément.

L’implémentation actuelle profite de DirectX 12 et de ses améliorations au niveau du calcul sur GPU. Cette passe de simulation s’intègre bien dans la nouvelle architecture de la partie affichage, spécifiquement repensée pour DirectX 12 : elle s’articule autour d’étapes bien définies, notamment pour s’occuper d’une partie de la géométrie de la scène ou pour traiter toute l’image, mais aussi pour effectuer des calculs plus généraux… et bientôt aussi asynchrones.

Actuellement, le prototype fonctionne assez bien. Les prochains travaux porteront principalement sur la gestion des collisions : les structures de données pour accélérer les recherches, notamment dans un voisinage données, ne fonctionnent pas toujours aussi bien dans le contexte d’un affichage, de la physique ou encore de l’intelligence artificielle. La limitation principale de l’effet, actuellement, est qu’il est gourmand en temps de calcul ; cependant, un nombre réduit de particules peut déjà créer un rendu suffisant dans pas mal de cas, même si les cas d’utilisations doivent encore être définis plus précisément.

Source : Looking ahead: GPU Fluid Dynamics for Particles.

L’avenir des circuits intégrés passe par la troisième dimension, selon Samsung

Depuis plus d’une décennie, le paradigme principal pour la conception de puces électroniques était d’assembler une série de transistors sur un plan. Ainsi, par exemple, Samsung est passé d’une technologie 120 nm en 2003 à du 16 nm en 2014, avec une amélioration chaque année au niveau de la finesse de gravure, en moyenne. Cependant, les améliorations se font au prix de processus de plus en plus compliqués, notamment au niveau de l’exposition des circuits : pour dessiner les transistors, un laser est utilisé à travers un masque, avec différents processus optiques pour atteindre les finesses de gravure actuelles (de nouvelles techniques sont en cours d’exploration, comme les EUV). Actuellement, les processus les plus avancés utilisent une exposition en quatre phases, ce qui nécessite une préparation des galettes de silicium en amont de plus en plus coûteuse : les étapes de dépôt et d’attaque chimique de la surface représentent maintenant les deux tiers du coût de fabrication d’une galette.

Cependant, cette manière de procéder doit évoluer, notamment à cause des difficultés à faire progresser les technologies d’impression de circuits tout en maintenant des coûts raisonnables. Pour ce faire, une technique actuelle est de combiner plusieurs circuits dans une même puce, comme le font déjà AMD et NVIDIA pour leurs processeurs graphiques (pas tous, loin de là !) ou encore Altera : la partie mémoire HBM2 est superposée au processeur principal.

De son côté, Samsung va encore plus loin : dès 2014, le fondeur coréen pousse l’idée de superposition encore plus loin pour leurs composants de mémoire. Une telle puce est composée de trois types de couches :

  • une couche CMOS pour toute la partie auxiliaire du composant, les contrôleurs ;
  • plusieurs couches formant un tableau de mémoire, là où les valeurs sont effectivement stockées ;
  • une structure d’interconnexion entre les deux types de couches.

Les contrôleurs et l’interconnexion sont des couches planaires tout à fait traditionnelles, alors que la mémoire proprement dite exploite un procédé tout à fait spécifique, en trois dimensions — schématiquement, un film de silicium est déposé, puis une première couche de transistors est créée, l’opération est répétée un grand nombre de fois. L’information est alors stockée le long d’une chaîne de cellules, au lieu d’une seule cellule : pour en agrandir une, il suffit de déposer un plus grand nombre de couches.

L’un des avantages est que les cellules sont plus grandes et peuvent contenir plus d’électrons, ce qui aide à améliorer certaines caractéristiques comme la vitesse ou l’endurance, par rapport aux technologies purement planaires.

Pour les chiffres, la densité peut beaucoup augmenter : par rapport à quelques mégaoctets par millimètre carré en 2003 à plus 1,1 Go en 2014 à raison de trois bits par cellule, la première génération 3D ne montait qu’à 0,97 Go le millimètre carré, en 2014, avec deux bits par cellule et vingt-quatre couches. Depuis lors, le processus s’améliore : en 2015, avec trente-deux couches, il était possible de stocker trois bits par cellule (1,86 Go/mm²) ; cette année, en montant à quarante-huit couches, la densité monte à 2,62 Go/mm², toujours avec trois bits par cellule. Dans le futur, de nouvelles couches devraient s’ajouter, avec à l’horizon 2020 cent vingt-huit couches, quatre bits par cellule, pour une densité de 8,67 Go/mm² (plus de huit fois la densité actuelle).

Actuellement, la technologie de Samsung reste relativement expérimentale, elle n’est pas prête pour la production de masse : les rendements sont relativement faibles, mais s’amélioreront avec l’expérience. Micron planche sur des techniques similaires et, d’après les premières expériences, une production avec trente-deux couches serait vingt-cinq pour cent moins chère par bit mémorisé que le même composant en technologie 16 nm. Les coûts de production d’une galette augmentent, mais il semblerait que ce soit dans des proportions raisonnables.

Source (dont image) : 3D NAND – Moore’s Law in the third dimension.