Intel préparerait son GPU dédié

Intel tente depuis longtemps de se créer une place sur le marché fort lucratif des processeurs graphiques — de plus en plus lucratif, d’ailleurs, depuis l’explosion de l’apprentissage profond et des cryptomonnaies. La première tentative date de 1998, avec la 740, une carte graphique AGP à la performance décevante ; les évolutions successives sous la marque Extreme Graphics n’étaient pas mieux reçues. En 2006, Intel tente de percer avec son architecture Larrabee : au lieu d’utiliser des cœurs de calcul extrêmement nombreux (plusieurs centaines, voire milliers) et spécifiques, l’idée était d’utiliser un grand nombre de cœurs (plusieurs dizaines) totalement indépendants ; l’idée a fait un flop comme carte graphique, mais est réapparue sous la forme de la ligne de produits Xeon Phi. Les premiers composants graphiques véritablement utiles sont apparus en 2010, avec l’intégration aux processeurs Core, sous les marques HD Graphics, puis Iris Pro/Plus Graphics et UHD Graphics.

Cependant, la firme de Santa Clara a récemment recruté Raja Koduri, un gros contributeur au renouveau d’AMD du côté des cartes graphiques. De plus, certains processeurs viennent avec une carte Radeon, sous licence d’AMD. Ces quelques éléments semblent indiquer qu’Intel est de plus en plus sérieux au niveau de la puissance des cartes graphiques.

Il semblerait que les douzième et treizième générations de processeurs graphiques portent les noms de code Arctic Sound et Jupyter Sound. Ces deux puces seraient entièrement développées par Intel et reliées au processeur central par un lien EMIB (les deux seraient disposées dans le même boitier). On s’attend à les voir vers 2020, mais un retard n’est pas à exclure.

Source : Arctic & Jupiter Sound: Intel bestätigt die Entwicklung von eigenständigen GPUs unter Raja Koduri.

Advertisements

Samsung annonce une mémoire HBM2 avec un débit de 2,4 Gb/s par pin

Le CES est l’occasion rêvée par bon nombre de constructeurs d’annoncer leurs nouveaux produits de haute technologie. Samsung a ainsi annoncé Aquabolt, sa nouvelle puce de mémoire HBM2. En quelques mots comme en cent, cette nouvelle génération est bien plus rapide que la précédente, avec un débit maximum de 2,4 Gb/s par pin et huit banques de mémoire empilées par puce. Avec cette technologie, il sera donc possible de proposer des cartes graphiques avec trente-deux gigaoctets de mémoire et une bande passante de 1,2 To/s dans le tout haut de gamme (avec quatre puces de HBM2, donc).

L’autre amélioration concerne la consommation d’énergie : ces puces fonctionnent avec une tension de 1,2 V. La génération précédente fonctionnait soit à 1,2 V (et un débit de 1,6 Gb/s et par pin), soit à 1,35 V (à 2 Gb/s). La consommation énergétique pourrait ainsi baisser de cinquante pour cent par rapport à la génération précédente.

Ces améliorations sont dues à la conception de la connexion entre les différents étages de la puce (TSV, through-silicon via) : on compte en effet pas loin de cinq mille de ces liens. Le contrôle de la dissipation de chaleur a aussi été amélioré.

Reste à voir si toute cette puissance sera réellement utilisable : même si la génération précédente pouvait fonctionner à 2 Gb/s, AMD la configurait pour n’utiliser que 1,9 Gb/s et NVIDIA… 1,75 Gb/s.

À la concurrence, SK Hynix lance aussi sa mémoire avec les mêmes spécifications, tant en termes de débit que de tension de fonctionnement.

Sources : Samsung Unleashes Fastest Ever HBM2 ‘Aquabolt’ Capable Of Achieving 2.4 Gbps On 1.2v, Increasing Performance Per Watt By 50%, SK Hynix va aussi lancer une HBM à 2.4 Gbps.

Production de GDDR6 : Samsung et SK Hynix dans la danse

Les nouvelles s’enchaînent au niveau de la prochaine génération de mémoire “conventionnelle” pour cartes graphiques, la GDDR6. Micron avait fait la première annonce, avec une qualification de son processus de fabrication — mais pas encore de grands volumes de production.

Samsung sera donc le premier à dégainer sa production de masse. Ses puces de mémoire sont fabriquées sur un processus 1x nm (que Samsung décrit comme le plus avancé, sans préciser exactement le X). La densité par rapport au nœud précédent (20 nm) est doublée : chez Samsung, à taille égale, une puce de mémoire GDDR5 montait à huit gigaoctets ; maintenant, en GDDR6, il faut compter seize gigaoctets. Le débit par pin annoncé est de dix-huit gigabits par seconde (septante-deux gigaoctets par puce), pour une tension de 1,35 V (par rapport à 1,55 V, cela représente une économie de l’ordre de trente-cinq pour cent en puissance).

SK Hynix a par la suite annoncé ses propres puces de GDDR6. La densité est moindre que chez Samsung (huit gigaoctets par puce), tout comme les débits : de dix à quatorze gigaoctets (jusque cinquante-six gigaoctets par puce) — le gain par rapport à la GDDR5X, par exemple, est donc minime. Par contre, les gains pourraient être plus marqués au niveau de la consommation énergétique : SK Hynix propose des modèles à 1,35 V, comme Samsung (pour des débits de douze à quatorze gigabits par seconde), mais aussi à 1,25 V (dix à douze gigabits par seconde).

Sources : Samsung Begins Mass Producing Fastest 18 Gbps GDDR6 Memory For High Performance Graphics Cards – Up To 24 GB of VRAM, 864 GB/s Bandwidth, La GDDR6 annoncée disponible chez SK Hynix.

Qt 3D Studio : le code source et une première préversion disponibles

Huit mois, c’est le temps qu’il aura fallu entre la donation de code de NVIDIA et la première mise à disposition publique. C’est en février que Qt 3D Studio était annoncé, une réécriture partielle du code fourni par NVIDIA (celui de NVIDIA Drive Design).

Cet outil est utilisé pour concevoir des interfaces graphiques en 3D, à destination tout d’abord des fabricants automobiles. Il permet notamment de créer rapidement des prototypes d’interface grâce à sa ligne du temps et ses animations par images clés. Il s’intègre très bien avec l’environnement Qt, même s’il est surtout prévu pour Qt Quick. Étonnamment, à l’origine, celui-ci n’était utilisable que sous Windows (étant codé avec les MFC), mais l’est maintenant aussi sous Linux et macOS.Pour faciliter le prototypage, Qt 3D Studio contient une importante bibliothèque de matériaux et d’effets, mais peut aussi importer des fichiers de Photoshop, Autodesk Maya et The Foundry MODO.

Depuis la donation du code, une série de développeurs de Qt s’est penché sur le code de NVIDIA Drive Design et sur son moteur d’exécution. Sur ces quelques mois, ils ont principalement porté l’éditeur sur Qt (pour éliminer la dépendance aux MFC) ; d’autres dépendances limitaient la portabilité et ont été remplacées par des équivalents Qt. L’API Qt Quick a été étendue, celle pour C++ a été créée de zéro. Le système de compilation a été intégré avec celui de Qt.

L’outil a été amélioré notamment sur le point de la facilité d’intégration avec des applications Qt existantes, surtout Qt Quick. Il est maintenant possible d’intégrer des scènes Qt 3D Studio dans des applications Qt Quick, mais aussi d’afficher des scènes Qt Quick dans des éléments 3D (sous la forme de textures).

La première version finale n’est pas encore prête, il reste du pain sur la planche. Elle devrait néanmoins être prête fin novembre, en même temps que Qt 5.10. Cette version 1.0 utilisera toujours le moteur de rendu de NVIDIA, avec les modifications nécessaires pour l’intégration à des applications Qt. En mai 2018, la version 2.0 devrait remplacer ce moteur de rendu par un autre basé sur Qt 3D, ce qui devrait améliorer la portabilité de ces applications, sans toutefois apporter de quelconque discontinuité visible pour les utilisateurs et développeurs ; ce changement devrait faciliter l’ajout futur de fonctionnalités (et profiter au développement de Qt 3D). Entre les deux, quelques versions mineures devraient apporter de nouvelles fonctionnalités requises par les utilisateurs, notamment en termes d’utilisabilité, de gestion du matériel et de systèmes d’exploitation embarqués.

Télécharger le code de Qt 3D Studio (instructions de compilation). Documentation.

Source : Qt 3D Studio Source Code and Pre-Release Snapshots Available.

Qt 5.10 accueillera Vulkan : les premiers pas

Les discussions pour une première gestion de Vulkan dans Qt ne sont pas récentes : elles datent de 2016 sur le gestionnaire de tickets du projet, avec les premiers résultats attendus pour Qt 5.10, en fin de cette année 2017.

Ceci se passe dans un contexte double : d’un côté, Vulkan a été développé comme successeur à OpenGL, pour exploiter au mieux les cartes graphiques (notamment pour la réalité virtuelle et des applications aussi gourmandes) ; de l’autre, Qt 5.8 avait pour nouveauté majeure côté Qt Quick une refactorisation du moteur de rendu du graphe de scène, pour le découpler d’OpenGL, avec de premiers travaux pour utiliser Direct3D 12 (l’équivalent Vulkan de Microsoft) pour le rendu de scènes Qt Quick.

Un premier objectif pour faciliter l’utilisation de Vulkan avec Qt est de fournir une série de classes (comme les QOpenGL) qui facilitent l’écriture de code portable. Notamment, la création d’une surface de rendu Vulkan est loin d’être aisée en devant gérer toute une série de plateformes :

QWindow *window;

#if defined(VK_USE_PLATFORM_WIN32_KHR)
    VkWin32SurfaceCreateInfoKHR createInfo;
    createInfo.hwnd = (HWND) window->winId();
    ...
    err = vkCreateWin32SurfaceKHR(...);
#elif defined(VK_USE_PLATFORM_WAYLAND_KHR)
    VkWaylandSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateWaylandSurfaceKHR(...);
#elif defined(VK_USE_PLATFORM_ANDROID_KHR)
    VkAndroidSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateAndroidSurfaceKHR(...)
#elif defined(VK_USE_PLATFORM_XCB_KHR)
    VkXcbSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateXcbSurfaceKHR(...)
#elif ..

Il serait nettement plus pratique (et orienté Qt) d’écrire un code concis et compréhensible comme :

QWindow *window;
VkSurfaceKHR surface = QVulkanInstance::surfaceForWindow(window);

Une gestion de Vulkan dans Qt, même basique, faciliterait donc grandement cette étape très importante dans l’utilisation de l’API. C’est donc le premier objectif de ce nouveau module Qt Vulkan et des classes QVulkan.

Un deuxième objectif à court terme pour ce module est de fournir une abstraction pour une fenêtre dont le rendu est entièrement effectué par du code Vulkan, tout comme QD3D12Window et QOpenGLWindow. Certes, ces classes ont quelques limitations, mais facilitent la prise en main. Ainsi est arrivée QVulkanWindow.

Par contre, pour Qt 5.10, les objectifs ne sont pas beaucoup plus élevés que cela. Notamment, l’API Vulkan n’est aucunement cachée à l’utilisation : Qt aide à créer des fenêtres, à gérer les différences entre plateformes et à charger dynamiquement les fonctions de Vulkan. La nouvelle API n’est, pour le moment, pas du tout utilisée dans des modules comme Qt Quick, Qt 3D, Qt Canvas 3D, QPainter : cela pourrait venir dans le futur, mais pas pour Qt 5.10. Des fenêtres Vulkan peuvent être combinées avec des interfaces à base de widgets à l’aide de la fonction bien connue QWidget::createWindowContainer(), tout comme des fenêtres OpenGL.

Au niveau des plateformes, Qt Vulkan peut être utilisé sous Windows (quand le SDK LunarG est installé et définit la variable d’environnement VULKAN-SDK), Linux (avec xcb, pas encore Wayland) et Android (avec les API de niveau 23 et 24, même si les en-têtes Vulkan ne sont disponibles que depuis le niveau 24).

Les bibliothèques Vulkan sont chargées dynamiquement, c’est-à-dire à l’exécution : il n’est nécessaire que de disposer des en-têtes de Vulkan (une version assez récente, au moins la 1.0.13) lors de la compilation de Qt, pas plus. Dans un futur proche, certaines configurations de test pourraient venir avec une bibliothèque Vulkan, mais ces détails sont en cours de fignolage et devraient être corrigés d’ici à la sortie de Qt 5.10.

Source : Vulkan Support in Qt 5.10 – Part 1.

Les dernières nouveautés de NVIDIA GameWorks

À la GDC 2017, NVIDIA aura annoncé une nouvelle carte graphique pour joueurs, extrêmement puissante et avec un tarif raisonnable (la GTX 1080 Ti est plus puissante que la Titan X Pascal, mais à un prix presque réduit de moitié), mais également toute une série de nouveautés dans ses produits pour développeurs de jeux, rassemblés sous la bannière GameWorks. Il s’agit notamment d’effets et de simulations physiques prêtes à l’emploi.

De manière générale, bon nombre de produits GameWorks deviennent compatibles avec DirectX 12, proposent une implémentation Direct Compute en plus de CUDA (ce qui permet d’utiliser l’accélération graphique avec des cartes AMD, mais uniquement sous Windows), ainsi que l’ouverture du code source d’une série de bibliothèques supplémentaires.

DirectX 12 pour les développeurs

La grande différence entre les versions 11 et 12 de DirectX est le niveau d’abstraction : il faut moins de code pour un même effet avec DirectX 11, le pilote graphique s’occupe de l’optimisation d’une série de primitives de haut niveau (qui déchargent donc le programmeur d’une grande partie du travail). Au contraire, avec DirectX 12, le programmeur récupère une énorme flexibilité, mais doit effectuer le travail que le pilote n’effectue plus.

Les possibilités d’optimisation sont donc bien plus grandes, mais les risques également. NVIDIA travaille sur les deux fronts : proposer de nouveaux outils de développement et préparer toutes ses bibliothèques GameWorks pour DirectX 12. Côté outils, Nsight 5.3 apporte la compatibilité avec DirectX 12 et certains casques de réalité virtuelle. PIX, le débogueur visuel DirectX de Microsoft, peut également lire les compteurs de performance des cartes graphiques GeForce.

NVIDIA annonce aussi un nouvel outil : Aftermath, une bibliothèque à intégrer aux jeux afin de déboguer plus facilement les cas de crash. Le principe est d’introduire des marqueurs à intervalle régulier dans le code, où l’état du GPU est sauvegardé. Lors d’une analyse après crash, il devient possible de remonter la ligne du temps au niveau de ces marqueurs. Au niveau de la performance, Aftermath est extrêmement léger : il n’a pas d’impact mesurable sur un jeu. Il peut donc être inclus dans des jeux en production, sans être cantonné au niveau du test.

Nouveautés GameWorks

Une nouvelle version de FleX, le moteur de simulation de particules unifié, est apparue : la 1.1.0 peut exécuter ses calculs sur un processeur graphique par CUDA ou par Direct Compute ; cela ne veut pas dire que CUDA est abandonné, puisque FleX est maintenant compatible avec la version 8.0. Quelques fonctionnalités ont été ajoutées, l’API a été uniformisée avec d’autres bibliothèques physiques de NVIDIA.

Bien évidemment, FleX est maintenant compatible avec DirectX 12. En particulier, la bibliothèque peut tirer parti des fils d’exécution asynchrones pour lancer ses calculs quand le GPU est moins utilisé par le rendu graphique.

Flow est une nouvelle bibliothèque pour le rendu et la simulation de volumes, principalement de la fumée, du feu, des fluides enflammés. Elle remplace et généralise Turbulence et FlameWorks.

HairWorks, pour la simulation de poils et de cheveux, apporte principalement la possibilité d’utiliser la bibliothèque avec DirectX 12 (la version 1.3 est d’ores et déjà disponible sur GitHub, mais pas encore ailleurs).

Le module de destruction, autrefois connu sous le nom de APEX Destruction, a été complètement réécrit pour pleinement profiter des cartes graphiques modernes, tout en laissant la plus grande flexibilité aux développeurs. Blast se focalise sur l’implémentation de la destruction des objets, pas de la simulation physique en général ou de l’affichage : ces points doivent être gérés par l’application (évidemment, un module d’extension intègre Blast dans le moteur physique maison, PhysX). Côté simulation, les contraintes sont simulées de manière bien plus détaillée qu’à l’époque APEX Destruction, ce qui permet de créer les fissures aux endroits les plus faibles. (Plus de détails sur le site officiel.)

De manière similaire, APEX Clothing laisse la place à NvCloth. La bibliothèque semble avoir été réécrite pour plus de flexibilité, comme Blast, avec une compatibilité DirectX 11 et 12, les solveurs pouvant fonctionner indifféremment sur CPU ou sur GPU.

Libération du code source

La libération du code source de GameWorks est une opération de longue haleine, débutée en 2015. NVIDIA continue dans la lignée, avec plus de code disponible. Cependant, les conditions ne semblent pas changer : pas de licence libre, enregistrement obligatoire mais gratuit.

Sources et images : communiqué de presse de NVIDIA, NVIDIA talks DX12, including GameWorks support, GDC 2017: NVIDIA Gameworks goes DX12 and more !.

Annonce de Qt 3D Studio

Qt est un framework à l’origine prévu pour la conception d’interfaces graphiques. Avec les années, il s’est de plus en plus ouvert à la troisième dimension : tout d’abord, en facilitant l’utilisation d’OpenGL dans des interfaces Qt, puis en allant jusqu’à proposer un moteur 3D complet, Qt 3D. Ce petit monde est en passe d’évoluer radicalement grâce à NVIDIA. En effet, le fabricant de processeurs graphiques a fait l’une des plus grandes contributions libres à Qt : leur système de conception d’interfaces 3D à destination des graphiques, NVIDIA DRIVE Design Studio, un outil déjà mis à l’épreuve et utilisé dans bon nombre de systèmes en production à l’échelle industrielle. L’outil est en développement depuis de nombreuses années et, au fil de son existence, a été connu sous les noms de NVIDIA UI Composer ou Anark Gameface.

Cette contribution se chiffre en centaines de milliers de lignes de code (!), avec un outil graphique, la bibliothèque de fonctions utilisée, ainsi qu’une intégration avec Qt (notamment Qt Quick). Qt possèdera donc très bientôt un environnement 3D de très haute qualité, l’un des meilleurs sur le marché. L’outil de NVIDIA sera renommé pour faire référence à Qt plutôt qu’au caméléon (même s’il est lui aussi vert) : Qt 3D Studio.

Une application conçue avec l’outil de NVIDIA peut d’ores et déjà être étendue à l’aide de code Qt Quick, dans tous les sens du terme : on peut intégrer une partie Qt 3D Studio dans une application Qt Quick existante, mais aussi adapter l’interface produite par les graphistes à l’aide de code QML. L’intégration avec Qt 3D est prévue à terme ; actuellement, l’outil utilise son propre moteur de rendu, entièrement découplé de Qt 3D (pour des raisons de performance, il réutilise cependant le contexte OpenGL de la scène Qt Quick).

Le travail ne fait que commencer : le projet Qt n’a reçu le code que cette semaine, il ne sera disponible au grand public que lorsqu’il sera prêt — aucune date n’est avancée pour le moment, mais les premières versions devraient arriver “rapidement”. Actuellement, rien n’est spécifique au GPU utilisé (le code emploie OpenGL ES 2.0, pas d’extension propriétaire de NVIDIA). Cependant, l’éditeur mélange des parties écrites avec Qt et d’autres avec MFC : il faudra réécrire ces dernières pour qu’il soit utilisable sur toutes les plateformes (pas seulement Windows) ; le code de rendu n’a pas cette limitation. La réflexion est lancée pour l’intégration de l’éditeur dans Qt Creator, mais les plans initiaux prévoient de le garder comme outil indépendant.

Cette contribution marque le degré d’importance de Qt dans l’écosystème de l’automobile. Les ambitions de la Qt Company dans le domaine ne sont plus à prouver, après l’annonce l’année dernière de Qt Automotive Suite.

Sources : Introducing Qt 3D Studio, Nvidia spendiert Qt Hunderttausende Zeilen Code, The Qt Company Adopts NVIDIA DRIVE Design Studio.