Open... Quoi ?

L'OpenCL est à AMD ce que CUDA est à Nvidia, la prise en charge du GPU pour les opérations de rendu (vidéo, 3D, photo... même LibreOffice s'y est mis). En gros, ce n'est plus votre CPU qui va faire tout cela, mais votre GPU qui dormait jusque là. C'est de la vraie optimisation de votre matériel et pour le coup c'est super utile pour des projets vidéo ou 3D qui peuvent prendre des heures de rendu final.

Si CUDA de Nvidia est propriétaire, OpenCL (Open Computing Language) est open-source. Cela signifie que tous les OS peuvent le prendre en charge, des supercalculateurs IBM aux cartes graphiques de gamers. OpenCL est intégré directement dans les OS Apple par exemple (principalement parce que Apple en est l'initiateur).

Un standard utilisé par l'industrie

L'OpenCL est développé au sein du groupe Khronos, qui développe OpenGL mais aussi Vulkan. C'est un consortium étendu d'entreprises regroupées pour développer les standards de l'industrie. C'est pour cela que beaucoup d'applications professionnelles 3D utilisent OpenGL pour les rendus et non DirectX. Le passage vers Vulkan est en ce moment crucial pour l'industrie.

Mais l'OpenCL est aussi utilisé dans les calculs CPU pour accélérer les rendus complexes. Ainsi les programmes SETI, Folding@Home utilisent l'OpenCL que ce soit sur les cartes graphiques AMD, Nvidia ou Intel (ou d'autres circuits exotiques). Et c'est bien là la force de l'OpenCL : ne pas être limité par un fabricant de matériel.

Oui et sur Linux ?

Comme je suis récemment un nouveau acquéreur d'une carte AMD. Je vais vous expliquer ici mon parcours, car c'est un vrai parcours afin de trouver les bonnes informations et j'espère que cela vous donnera des idées pour vos recherches. ;)

La version OpenCL des pilotes libres est limitée à la version 1.1 Et ceci est un problème : la plupart des applications professionnelles demandent à minima la version 1.2, autant dire que cela est une bonne base mais que je ne trouverai pas mon bonheur dedans !

Le parcours pour installer

Première recherche : “OpenCL”, je trouve les quelques informations que je vous ai présenté plus haut. Mais je me souviens d'un article précédent sur ce blog qui me permet d'aller directement à cette page : la page d'installation des pilotes AMD propriétaires pour Linux. Alors oui ok, j'aime bien mes pilotes libres (ils fonctionnent très bien), mais si je peux installer les pilotes propriétaires et avoir le support d'OpenCL, banco !

Première erreur : vouloir passer par les pilotes officiels. Et oui, comme je l'ai déjà indiqué, les pilotes AMD propriétaires sont faits pour une certaine version de kernel les version LTS (18.04 et 20.04). Or, j'ai un kernel modifié par PopOS, plus haut en version (20.10 maintenant). Donc forcément, quand le pilote propriétaire souhaite installer son module, bin, il ne trouve pas le bon kernel, donc error, donc ne surtout pas rebooter, désinstaller le tout et revenir à la case départ !

Deuxième recherche : passer par des applications qui demandent OpenCL et donc voir s'il n'existe pas un tutoriel bien fait à ce sujet ! Banco ! La recherche “OpenCL Blender” trouve un tutoriel intéressant sur le forum de Blender !

Deuxième erreur, vouloir installer les dernières versions de Blender : oui elles n'existent dans le PopShop qu'en version Flatpak (Blender 2.9) alors que la version des dépôts (2.83.5) est un peu plus ancienne. Effectivement, pour des questions de droits d'accès matériel...etc... les versions Flatpak (et cela s'applique aussi pour les versions Snap) sont parfois bridées dans leurs fonctionnalités, parce que ce sont des applications “sandboxées” (dans leur conteneurs plus ou moins étanches du reste du système).

Et donc, après avoir suivi le tutoriel, édité le script d'installation pour lui rajouter le terme “pop”, installé ce qu'il fallait avec la bonne commande ./amdgpu-install --opencl=legacy,pal --headless --no-dkms, redémarré... Blender s'offre à moi avec le support d'OpenCL ! Et Darktable aussi, et LibreOffice aussi, et KDEnlive aussi ... !!!

Conclusion !

C'est pas simple, il faut lire, comprendre ce que l'on fait, surtout éviter d'installer la partie avec le module du kernel, éviter de rebooter sans croiser les doigts (parce qu'il y a un risque d'écran noir)... bref, on aura vu plus facile ! Dans cet article, je vous partage mes liens, n'hésitez pas à les utiliser, ils sont d'intérêt général !

#amdopencl #popos #mesa #opencl

---

...et les autres !

Proton ?

D'abord qu'est-ce que Proton ? Proton c'est un super utilitaire développé par Valve et intégré à Steam-Linux pour faire tourner des jeux créés seulement pour Windows. Il contient tout ce qu'il faut pour faire tourner des jeux et est basé, entre autres, sur deux éléments indispensables : Wine et DXVK ! Pour utiliser tout cela voici un très bon tutoriel en français ici.

Wine et DXVK ?

Wine est un acronyme pour “Wine Is Not an Emulator”, comme son nom l'indique, Wine est une collection de librairies qui permettent à des jeux ou applications Windows de “retrouver leurs petits” lorsqu'ils sont lancés sur Linux. En gros, c'est un traducteur d'appels d'applications. Au lieu qu'une application demande directement le .dll qu'il lui faut, Wine lui fournit une version différente qui permet de dialoguer avec Linux.

Wine est intégré dans différents projets comme PlayOnLinux, Lutris, Codeweaver...

DXVK ?

DXVK est un peu aussi un acronyme de “DirectX VulKan”. Même chose que pour Wine, il s'agit d'un traducteur. Mais avec cette fois la puissance de Vulkan, ce qui entraîne un gain de performances important voire parfois des applications qui tournent mieux ou à performances égales selon les jeux. et avec les versions, DXVK se bonifie !

Proton et ses versions non officielles.

Je ne vais parler que de celle que je teste depuis quelques temps, la version Proton-GE. C'est une petite merveille de Thomas Crider alias GloriousEggroll qui comprend les derniers développements de Wine, DXVK ainsi que d'autres utilitaires audio comme FAudio, XAudio... En gros, utiliser une version non officielle permet le plus souvent de gagner en performances et en compatibilité d'applications. Le mieux est de recenser tout cela sur le site ProtonDB qui documente tous les jeux jouables ou ayant besoin d'astuces pour fonctionner correctement !

Comment installer tout cela ?

Simple ! Vous allez dans la partie “release” du code déposé sur GitHub, vous téléchargez, et vous décompressez dans le bon dossier ! Chez moi c'est celui-ci : /home/nasra/.steam/debian-installation/compatibilitytools.d

Il n'y a plus qu'à sélectionner la bonne version dans Steam !

#vulkan #popos #mesa #proton #wine #steam

---

Quelques petites astuces !

Après ma série lors de mon passage à la RX 5500 XT, la redécouverte des pilotes AMD pour Linux et quelques tests, j'ai expérimenté quelques soucis avec ma config que j'ai pu résoudre en lien avec les développeurs des pilotes (oui c'est ça la magie de Linux).

L'OpenGL se fait la malle...

J'ai testé quelques applications, et je me suis retrouvé avec ce genre d'artefacts graphiques. Du coup, je me suis dit, je vais mettre à jour les pilotes Mesa (les pilotes Libres). Et là, même soucis, et en pire puisque certaines applications web (Chrome par exemple, mais aussi LibreOffice et des applications Vulkan) se mettent à faire ces mêmes bugs ! Même chose en installant un noyau plus récent grâce à Mainline...

Alors je me suis dit que j'allais documenter ce bug sur le Git de Mesa.

Documenter, préciser, résoudre le soucis !

Tout est là : https://gitlab.freedesktop.org/mesa/mesa/–/issues/3323 (oui j'ai un autre pseudo sur Git)

En gros, et pour résumer le tout, après discussion, et retours des dev, notamment pepp, j'ai testé une solution avec les applications concernées. Ce retour de bug montre aussi mon cheminement dans ma connaissance pour placer les options correctement dans les commandes de lancement d'une application, où je me répond à moi-même ;)

À noter quelques trucs, que j'ai compris au passage. RadeonSI, ce sont les pilotes OpenGL, RadeonVK, ce sont les pilotes Vulkan. Selon vos applications, elles utilisent tour à tour OpenGL ou Vulkan. C'est notamment le cas des émulateurs de consoles (PCSX est OpenGL seulement, Dolphin permet le passage entre les deux, RPCS3 aussi) et c'est un très bon indicateur de rendu ;)

Bref, la solution est dans une option à placer avant le lancement de toute application : “AMD-DEBUG=nodcc” Et qu'on peut rendre permanente avec ce petit fix.

En attendant, le développement de Mesa est très actif et cette option, ou en tout cas la résolution du bug, qui rendrait caduque cette solution est en cours d'intégration dans les derniers développements de Mesa.

[MAJ : le bug a été résolu avec les dernières versions de Mesa, 20.0.1]

#amd #popos #mesa

---

3 salles, 3 ambiances !

Les pilotes AMD sur Linux, il y a quelques subtilités à connaître. Avec Nvidia, c'est assez simple : les pilotes libres (peu performants) et les pilotes propriétaires (performants).

Voyons voir du côté d'AMD !

RADV

RADV est le backend Vulkan développé par les développeurs MESA, pas AMD (même si certains développeurs AMD y contribuent). Il est installé par défaut et est ce que toute personne n'utilisant pas AMDGPU-Pro utilise pour jouer sur Linux. C'est la solution la plus simple et rapide : tout est intégré au noyau du système et il se met à jour avec les grosses mises à jour du système (ou mises à jour intermédiaires pour la famille Ubuntu). Ce sont des pilotes libres très performants !

AMDVLK

Là c'est le pilote Vulkan, open-source, développé directement par les développeurs d'AMD. Quand on parle de pilotes open-source d'AMD, on parle de ceux-là.

AMDGPU-Pro

AMDGPU-Pro est le pilote propriétaire d'AMD et n'est pris en charge que sur un très petit nombre de systèmes d'exploitation Linux : Ubuntu, SUSE, Cent et Red Hat, avec des versions spécifiques des noyaux du système. Il comprend une version d'AMDVLK que la communauté à tendance à appeler AMDVLK-Pro. Pour cette version, le support matériel de la part d'AMD est assez fidèle et une nouvelle version sort tous les mois. Petit bonus, il permet d'activer le support d'OpenCL pour le traitement d'images et vidéos par le GPU (un peu comme CUDA sur Nvidia).

Performances et compatibilités !

Premièrement, cela peut varier considérablement selon la distribution, la version du noyau... Dans les documentations, il n'est pas aisé à tenir à jour toutes les informations facilement. Des utilisateurs comme Arch et Fedora exécuteront la dernière version de ce qui est disponible dès qu'elle sera prête, alors que les utilisateurs d'Ubuntu et de SUSE devront peut-être attendre un certain temps pour obtenir la dernière version des pilotes. Sur ces “anciennes” distributions (typiquement les distributions LTS), il peut être avantageux d'exécuter les packages AMDGPU-Pro (si possible) car ils seront probablement plus à jour. Cela dit, certaines distributions, comme Ubuntu avec leurs dépôts HWE, prennent de leur côté l'initiative pour maintenir les pilotes plus à jour.

Voici un aperçu des performances, à noter que la mention “ACO” est une nouveauté des pilotes libres RADV qui permet de meilleures performances :

Enfin, un test plus détaillé : https://www.phoronix.com/scan.php?page=article&item=mesa-201aco-amd&num=1

Petite astuce : les trois pilotes Vulkan peuvent être installés en même temps ! Tout ce que vous avez à faire est de lancer des programmes avec la bonne variable d'environnement pour la changer de la valeur par défaut !

#amd #popos #mesa

---

Ça y est !

J'y suis ! De retour chez AMD après quelques années chez Nvidia. Je dois dire que la migration a été plutôt surprenante. Voici un petit historique.

Le matériel

Oui, j'ai craqué pour mettre à jour ma configuration. Je suis passé sur un Ryzen 5 2600, une carte mère Asus B450, 16 Go de DDR4 (3200Mhz), et bien sûr la RX 5500 XT.

J'ai voulu faire cette mise à jour pour une raison principale, ma RX 5500 XT ne peut pas fonctionner sans bios UEFI, et la carte mère que j'avais (Asus M5A87), n'en dispose pas.

Démontage de toute la config, pose de l'ancienne config...

Tout cela m'a pris, environ 2 heures, pour y aller calmement, tranquillement, en nettoyant au passage quelques poussières, réorganisant les passages de câbles dans mon boîtier antédiluvien. Si vous ne connaissez pas, c'est un Textorm 974MB, toujours fonctionnel pour mon usage.

L'OS

Bon, comme j'avais déjà mon système, mon SSD et mes disques durs sauvegardés, je me suis dit que je vais tester pour voir si tout démarre. Sans avoir désinstallé les pilotes Nvidia, sans avoir changé le boot en UEFI... Et... ça démarre, mon PopOS (20.04) affiche son interface, aucun soucis, le PC est fonctionnel à 100% !!

J'ai eu une petite déconvenue sur les jeux passant par SteamPlay et donc Vulkan, ils ne voulaient pas se lancer, écran noir, sans autre message d'erreur (même en lançant Steam en ligne de commande). Certainement un soucis avec l'installation de Vulkan sur AMD. Je suis donc parti à la pêche aux infos, comme si j'installais Vulkan pour la première fois sur une carte AMD. Je me suis basé sur ce site et ai installé seulement les paquets suivants (pas le PPA) :

# apt install libvulkan1 mesa-vulkan-drivers vulkan-utils

Et depuis tout fonctionne au poil !

Les logiciels

Avec ma carte Nvidia, j'avais installé et essayé GreenWithEnvy pour gérer au mieux les performances, les déclenchements des ventilos... Avec AMD, j'avais repéré ce logiciel, CoreCTRL ! Et, vous savez quoi ? Il est diablement efficace ! Par contre une petite astuce, n'installez pas le PPA si vous êtes sur Ubuntu/PopOS/Mint, mais plutôt directement le .deb à partir du site (partie releases), et prenez la version correspondante à votre OS (20.04 = f pour Focal). Si vous installez le PPA, vous aurez une version alpha de Mesa qui peut causer des soucis (comme chez moi, des artefacts graphiques).

#amd #popos #mesa

---

Mais pourquoi revenir chez AMD ?

Après mon historique personnel, jalonné de soucis entre moi, mes OS (Windows et Linux) et mes cartes graphiques ATI/AMD, voici que je reviens chez AMD !

Linux et l'open-source

Les fans d'Intel le savent bien, quand des pilotes sont open-source, ils sont directement intégrés dans le noyau du système. C'est un des gros avantages par rapport à Windows qui lui faut toujours des pilotes anti-datés à mettre à jour et parfois sujets à incompatibilités diverses selon la version de Windows, ou celle du pilote. Linux n'a pas ces soucis avec ses pilotes open-source car ils sont directement intégrés à son noyau. Dès que le système se met à jour, il met aussi à jour ses pilotes, automatiquement, aucun soucis de versions, d'incompatibilités, tout se passe de manière transparente, et totalement invisible pour l'utilisateur. La version du noyau peut être mise à jour avec celles du système et profiter ainsi des nouvelles performances. Un vrai confort au quotidien ! Ceci posé, pourquoi est-ce que j'en parle pour AMD, le frère ennemi d'Intel ? Parce que depuis quelques années, AMD s'est investi dans les pilotes open-source sur Linux, et a même embauché des ingénieurs pour ce faire. Depuis les cartes graphiques RX (480 à 580 et leurs dérivées), les pilotes open-source AMD sont capables des meilleures performances face aux pilotes propriétaires de... AMD ! Alors parfois, certaines cartes très récentes sont mal supportées par le pilote open-source, comme ce fut le cas des premières cartes Navi, mais des correctifs rapides (en moins de 2 semaines) ont été apportés aux noyaux des différentes distributions Linux. Manjaro en a profité rapidement car les noyaux sont plus récents et se mettent à jour très rapidement, mais les autres distributions aussi avec des “backport” vers des noyaux plus anciens (en gros, on patche le noyau plus ancien pour qu'il profite du nouveau support matériel ou de corrections de bugs). Dans tous les cas, les récentes cartes sont toujours supportées par les pilotes propriétaires le Radeon Software for Linux.

Vulkan et Navi dans un bateau

AMD est connu pour décliner ses technologies sur plusieurs générations. Ce fut le cas pour les cartes GCN, à partir des Radeon HD7000 et suivantes, jusqu'aux Vega (qu'on retrouve dans les Ryzen avec partie graphique) et Polaris (RX4XX et RX5XX). Aujourd'hui, les cartes à base de Navi utilisent une nouvelle technologie, RDNA, conçue pour durer plusieurs générations. AMD a un gros retard sur Nvidia dans le domaine des cartes graphiques et notamment sur le haut de gamme. Aujourd'hui, les RTX dominent le marché depuis leur sortie. Mais l'apparition de la gamme Navi est en train de changer les choses. D'une part les performances sont au rendez-vous, mais en plus, l'efficacité énergétique, le point faible des cartes de la gamme RX et Vega est en gros progrès. La carte Vega 64, par exemple, était un véritable monstre de chauffage par excellence (jusqu'à près de 380W en pic !). À performances équivalentes, les Navi s'en sortent beaucoup mieux que leurs aînées, même si la comparaison avec Nvidia est encore, sur ce point, à l'avantage des verts. Ensuite, les pilotes open-sources atteignent en ce moment des performances étonnantes, meilleures que Windows sur des jeux Windows. Une belle base pour la suite des séries Navi basées sur les évolutions de RDNA ! En plus, des nouveautés comme ACO promettent encore un boost de performances notable avec Vulkan !

Mon choix

Mon choix se porte sur la RX5500 XT. Pourquoi ? Pour des questions de prix en premier, mon budget actuel ne me permet pas de dépenser 500 ou 600€ dans une carte graphique. J'avais dépensé 200€ pour ma GTX970 c'est à peu près ce que j'estime pouvoir dépenser pour une CG sur mon PC. Question de performances aussi, j'ai un écran FullHD 60Hz performant et je ne compte pas en changer d'ici là. Les performances graphiques de la carte me semblent suffisantes (un peu meilleures qu'une GTX970) et aussi parce que je compte changer le reste de ma configuration vieillissante mais pas pour tout de suite.

Et dernier argument, je suis actuellement sous Pop_OS, un système qui me plaît beaucoup mais j'aimerai tester, utiliser, et adopter Manjaro, notamment parce que la distribution est une “rolling release”, c'est-à-dire qui se met à jour constamment avec les derniers paquets de la distribution, les derniers noyaux stables, les derniers logiciels...

Avec un PC et une carte Nvidia (et ses pilotes propriétaires) ce serait de l'expérimentation hasardeuse. En effet les pilotes propriétaires de Nvidia ont la fâcheuse tendance à ne pas accepter les derniers noyaux du système et provoquer ce que l'on appelle des “black screen”. La distribution ne peut pas afficher l'interface graphique et renvoie sur une invite de terminal des plus austères. Il suffit alors de revenir à une version antérieure du noyau pour redémarrer son interface graphique. J'ai pu expérimenter cela avec une Ubuntu Studio et des noyaux temps réel que j'avais trouvé pour diminuer la latence audio.

Bon, par contre, j'ai un vrai soucis. La carte n'accepte pas les Bios Legacy et ma carte mère n'a qu'un Bios Legacy... Le test de la carte est reporté le temps que je me décide entre acheter d'occasion une carte mère AM3+ avec Bios UEFI (ça se trouve aux environ de 80-90€), ou une upgrade plus complète (carte mère AM4, RAM, CPU Ryzen 5), et là, c'est plutôt de l'ordre de 400€...

#amd #popos #mesa

---