Controverse sur l’utilisation de NVIDIA GameWorks dans Witcher 3

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

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)

Compatibilité avec Windows 10

L’actualité Windows est actuellement trépidante, les détails sur la nouvelle version du système d’exploitation arrivant régulièrement, en prévision d’une sortie officielle cet été. Quel degré de compatibilité Qt propose-t-il avec cette nouvelle version ? Toutes les applications Qt qui fonctionnaient sur les versions précédentes de Windows continueront à tourner, sans limitation, qu’il s’agit d’applications traditionnelles (Win32) ou modernes (WinRT, Windows Store).

Par contre, ces applications pourraient présenter des dysfonctionnements par rapport aux nouvelles fonctionnalités, comme le mode fenêtré des applications modernes (elles ne sont plus limitées au plein écran) : les versions actuelles de Qt présentent quelques défauts lors du redimensionnement, qui seront corrigés avec Qt 5.5 ; également, le style n’est pas automatiquement adapté à WinRT. Qt est d’ores et déjà testé avec les préversions de Visual Studio 2015, même si le support officiel ne sera disponible qu’à sa version finale (Qt 5.5 devrait être disponible avant Windows 10 et Visual Studio 2015).

Comme toujours avec Qt, le même code pourra être utilisé pour plusieurs déploiements d’une même application : le même code pourra servir pour OS X, Linux, Windows, mais également pour WinRT.

Une nouveauté non technique du port de Qt 5.5 vers WinRT sera la licence, comme pour de précédents modules : il s’agira d’une double licence LGPL 3-GPL 2+ (en plus d’une licence commerciale), compatible avec les termes et conditions de déploiement sur le Windows Store.

Source : Windows 10 Support in Qt

Sortie de qbs 1.4.0

qbs est un système de compilation prévu pour remplacer qmake pour les projets Qt. La description des projets se fait en QML. L’outil est certes prévu pour Qt, mais a une vocation plus généraliste : il peut être utilisé pour tout type de projet C++ (comme qmake).

La version 1.4.0 vient avec quelques nouveautés intéressantes, comme l’ajout de projets Android : qbs est maintenant capable de compiler des projets pour Android, qu’ils contiennent du code natif ou non (tant avec le SDK que le NDK, donc) ; cette fonctionnalité n’a pour le moment rien de spécifique à Qt et n’est pas intégrée à Qt Creator.

Un module d’archivage fait son apparition, afin de générer des fichiers compressés après la compilation à partir d’une liste de fichiers à inclure. La propriété builtByDefault permet d’indiquer qu’un produit ne doit pas être compilé, à moins d’être explicitement demandé ; elle sert notamment à lancer des séries de test, comme la cible check de nombreux Makefile.

Source : qbs 1.4.0 released

Qt Creator 3.4.0

La nouvelle version de Qt Creator, numérotée 3.4.0, vient d’arriver. Elle se focalise sur le peaufinage de l’existant, avec des corrections de défauts (notamment au niveau du débogueur) et des améliorations du code interne, tout en apportant quelques nouvelles fonctionnalités.

Côté C++, une nouvelle action de refactorisation a été ajoutée pour déplacer les définitions de fonction en dehors d’une définition de classe ; également, l’autocomplétion propose maintenant la nouvelle syntaxe pour la connexion entre signaux et slots arrivée avec Qt 5. Un nouveau filtre propose également de signaler tous les fichiers C et C++ inclus dans le projet, même sans être explicitement mentionnés.

L’intégration Android est désormais compatible avec les chaînes de compilation 64 bits. Le développement sur des plateformes embarqués sans Qt (bare metal) peut être fait avec des projets génériques.

Clang se fait une place plus importante dans l’EDI : son analyseur statique n’est plus considéré comme expérimental, il peut d’ailleurs être utilisé en combinaison avec les compilateurs Visual C++ et MinGW.

Sources : Qt Creator 3.4.0 released, Qt Creator 3.4 RC1 released, Qt Creator 3.4 beta1 released.
Voir aussi : les notes de version.

PhysX sur GitHub : quelques nouveautés

Quelques nouveautés du côté de PhysX et de l’ouverture de son code (sans qu’on puisse parler de logiciel libre, toutefois). Le premier élément tient plus de l’ordre du détail : le dépôt GitHub précédent est déprécié au profit d’un dépôt par version majeure. PhysX-3.3 ne contiendra donc que PhysX 3.3 (et les diverses mises à jour, probablement), un nouveau dépôt sera créé pour la branche 3.4.

Ce nouveau dépôt contient maintenant les sources nécessaires à la compilation de PhysX pour iOS, ainsi que celles des exemples livrés avec le SDK. Plus intéressant : dans les semaines à venir, NVIDIDA proposera un contrat de licence pour les contributeurs. En conséquence, les développeurs de PhysX pourront recevoir et accepter des pull requests de la part d’utilisateurs de PhysX, ce qui ouvre le développement du moteur à un public plus large, tout comme Unreal Engine 4.

Source : New Github Repo: PhysX-3.3. Old repo PhysX is deprecated!

Qt Installer Framework 2.0

Le Qt Installer Framework est une brique logicielle prévue pour créer des installateurs, tant en ligne que hors ligne, pour Windows, Linux et OS X, en gérant les mises à jour. Bien que focalisé sur Qt, l’outil est suffisamment générique pour des applications ne l’utilisant pas.

La version 2.0 vient de sortir, avec quelques nouvelles fonctionnalités. La raison principale pour le changement de version majeure est que cet outil est maintenant compilé avec Qt 5 plutôt que Qt 4. La compatibilité a été préservée par rapport à la version précédente : il devrait être possible de mettre à jour une installation réalisée avec QIF 1.6 avec un installateur basé sur cette nouvelle version.

Notamment, le moteur JavaScript précédemment utilisé, Qt Script, a été remplacé par celui de Qt Quick, en gardant la compatibilité avec les scripts existants. Aussi, il devient possible de lancer des installations sans aucune interface graphique.

Télécharger Qt Installer Framework 2.0.
Voir aussi : les notes de version.
Source : Qt Installer Framework 2.0 Released

PEEL, un outil de comparaison de moteurs physiques

NVIDIA avait développé un outil pour comparer les performances de différents moteurs physiques, notamment pour situer son moteur maison (PhysX) par rapport à la concurrence, mais aussi pour repérer les régressions en performances (certaines ont déjà été repérées pour PhysX 3.4 et sont en cours de correction). Il avait déjà été utilisé pour la sortie de PhysX 3.3. Cet outil, nommé PEEL, est maintenant disponible gratuitement pour tous, sources incluses (sous une licence zlib). Des binaires sont fournis pour Windows.

Une série de moteurs est déjà incluse dans la distribution : Newton (3.13, 3.9), Bullet (2.79, 2.81, 2.82) et PhysX (2.8.4, 3.1, 3.2, 3.3.0, 3.3.1, 3.3.2, 3.4). Les sources pour intégrer Havok (6.6.0, 2011.3.0, 2011.3.1, 2012.1.0, 2012.2.0, 2013.1.0) sont incluses, mais pas de source ou de binaire pour Havok lui-même, pour des raisons de licence.

Télécharger PEEL.

Source : http://physxinfo.com/news/12580/physics-engine-evaluation-lab-peel-is-released/.

Intégration de PhysX et GameWorks dans Unreal Engine 4

Depuis Unreal Engine 3 et UDK, Epic utilise le moteur physique PhysX, développé par NVIDIA. Unreal Engine 4 en utilise d’ailleurs la dernière mouture (la série 3.x). Depuis lors, NVIDIA a lancé une série de nouvelles briques logicielles dans le domaine de la simulation physique sous l’ombrelle GameWorks.

L’une de ces briques est une réflexion de fond sur la manière d’exploiter les GPU pour la simulation multiphysique en temps réel, avec des couplages entre tous les types de simulation : des interactions entre solides (déformables ou non), liquides et tissus, chaque type d’objet étant régi par des systèmes d’équations différents. NVIDIA FleX unifie toutes ces problématiques en considérant chaque objet comme un ensemble de particules. Après quelques années de développement et des démonstrations dont les principaux intérêts sont techniques (couplages en temps réel), la version 0.25 dispose maintenant d’une intégration (certes encore expérimentale et incomplète) dans Unreal Engine 4.

Les sources de l’intégration sont disponibles sur un dépôt Git, accessible sous les mêmes conditions que les sources d’Unreal Engine 4. D’autres modules de GameWorks sont en cours d’intégration : HBAO+, VXGI, Vehicles et WaveWorks sont d’ores et déjà disponibles, toujours en tant qu’intégrations expérimentales, toujours uniquement pour Windows.

Il est prévu d’ajouter d’autres modules dans les mois à venir, comme HairWorks ou Turf Effects. Certains modules ont besoin d’un GPU NVIDIA, d’autres se satisfont d’un GPU DirectX 11.

Source : NVIDIA GameWorks Integration, le clone NVIDIA du dépôt Unreal Engine.

Les sources de PhysX disponibles gratuitement

Peu après Unreal Engine 4, voici que son moteur physique, PhysX, développé par NVIDIA, se met à la même mode : son code source est gratuitement disponible. Bien évidemment, le projet ne devient pas libre pour autant : il est nécessaire de s’enregistrer sur le site de NVIDIA avant d’avoir accès aux sources.

Ce moteur physique est disponible pour les plateformes Windows, Linux, OS X et Android (en plus des consoles de jeux, mais elles sont exclues de cette ouverture) et est utilisé dans plus de cinq cents jeux. Il était déjà gratuit pour des utilisations, commerciales ou non.

L’ouverture concerne principalement le moteur physique, mais également le débogueur visuel (PVD) et quelques modules APEX : Clothing, Destructible et Emitter. Il s’agit de la version 3.3.3 (PhysX) et 1.3.3 (APEX), c’est-à-dire la prochaine version. Parmi les fonctionnalités disponibles, on compte les corps rigides, les collisions, la gestion des personnages, des particules et des véhicules, en plus des tissus et objets déformables, notamment.

Le dépôt GitHub n’est cependant pas celui de développement : il ne contient que huit commits depuis fin janvier. Le code CUDA, qui déporte une partie des calculs sur le GPU, est bien évidemment de la partie.

Sources : https://developer.nvidia.com/content/latest-physx-source-code-now-available-free-github, http://physxinfo.com/.