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