Bonjour Nal,
Je partage mon retour d'expérience très positive que j'ai eue avec l'acquisition très récente d'une carte graphique AMD RX 6800XT (C'est Noël avant l'heure cette année, confinement tout ça).
Joueur né et linuxien depuis l'adolescence (2001, avec ma première Mandrake 7.1), mon expérience avec les cartes ATI/AMD furent, au mieux, mitigées, sinon désastreuses. De mémoire, ma dernière carte de la marque était une Radeon HD 4770 achetée en 2009 (cette époque lointaine où une carte milieu/haut de gamme coûtait 200€). À l'époque, sous Debian Sid, je me remémore sans regret du pilote propriétaire tout pourri (fglrx) qui avait toujours plusieurs versions de retard sur le noyau et qui cassait tout à chaque mise à jour. Je m'étais alors juré que, sauf miracle, plus jamais je n’achèterai une Radeon, malgré leurs très bonnes performances (dans les tests publiés sous Windows en tout cas) pour un prix raisonnable.
Je suis donc passé du rouge au vert. Nvidia avait au moins la décence de fournir un pilote qui bien que propriétaire, était fiable, à jour et performant. Entre deux maux, je prenais le moins pire.
J'avais entendu entre temps qu'AMD avait ouvert les spécifications de son matériel et soutenait le pilote libre. Malheureusement, entre temps AMD était dans le creux de la vague et les cartes graphiques comme les CPU avaient mauvaise réputation pour leurs performances, leur consommation électrique et leur fiabilité.
Et puis, il y a l'arrivée de Steam sous Linux, avec le soutien actif de Valve à Mesa et à Wine (qui l'eût cru, je pariais sur GoG à l'époque, qui a complètement abandonné notre communauté). Conjugué aux progrès techniques constants des cartes AMD qui rattrapait son retard, je lisais de plus en plus régulièrement qu'AMD était une option viable, sinon la meilleure, pour jouer sans concessions sous Linux. Avec l'introduction des architectures RDNA 1 et 2, il m'en fallait peu pour sauter le pas. Macron aura été cette étincelle, le second confinement est décrété et j'ai réussi à dégoter, par chance, une RX6800XT à sa sortie.
Préalablement, j'ai scruté les sites spécialisés, comme Phoronix qui assurait que la carte était supportée à la sortie. Tous les feux étaient au vert.
J'ai pris quelques précautions en installant un noyau 5.10 en RC (linux-mainline dans le dépôt AUR de Arch Linux), linux-firmware-git et… c'est tout. Tout juste marche à merveille. Depuis la mise à jour du noyau 5.9.12, ce dernier est même désormais compatible et la version de linux-firmware empaquetée de base dans le dépôt Core est également suffisante.
Les performances sont au rendez-vous puisque, par exemple, le benchmark intégré dans le jeu Red Dead Redemption II donne en 1440p avec tous les curseurs poussés à droite (exception faite du MSAA) 74 images/sec en moyenne. Doom Eternal dépasse quant à lui allègrement les 250 images/s.
Il y a 10 ans, je n'aurais jamais cru qu'on puisse jouer sous Linux avec des pilotes entièrement libres dans des conditions similaires, voire supérieures à celles sous Windows (il semblerait que les jeux Vulkan sous Proton tournent généralement mieux sous Linux que nativement sous Windows, comme l'illustre ce test).
Bref, je suis ravi. Une petite déception cependant : le support d'OpenCL via Mesa n'est pas encore complet. Il est par exemple impossible de l'activer dans Darktable. Il semblerait qu'il faille passer par l'implémentation d'OpenCL de ROCm, mais je n'ai pas encore essayé. Sinon, tant pis, je n'en mourrai pas.
# Le choix de AMD
Posté par AlexTérieur . Évalué à 4.
Force est de constater que AMD a fait un choix sur le long terme, qui n'apparaissait pas gagnant sur le moment mais qu'aujourd'hui plus personne ne peut contester. Perso, c'est à chaque fois bonheur d'installer un nouvel OS sans me soucier de la question performance graphique… ça n'a pas été toujours le cas, bien évidemment.
Cela fait un moment que, bien qu'étant loin d'être un "gamer", j'aime jouer occasionnellement tout en restant sur Linux. Ça doit bien faire au moins 3 années où jamais je n'ai poussé un soupir "ah, et si ça marchait aussi bien que Windows"…
Le jeu qui m'a le plus stupéfait est Resident Evil 2 Remake. Il a fonctionné à la perfection, sur ma pauvre RX 580 (8 Go tout de même), options graphiques presque tout à fond, fluidité sans aucune chute de framerate. Le meilleur, c'est que j'aurai pu jouer en 4K si j'avais baissé quelques options graphiques (véridique).
Et sinon, pour le support OpenCL, j'ai répondu à un journal, une réponse qui est restée confidentielle, parce que j'avais fait un journal auparavant traitant de la difficulté d'avoir OpenCL sur AMD en 100% libre, mais comme je l'ai dit dans la réponse, les choses semblent avoir changer.
[^] # Re: Le choix de AMD
Posté par Pif le Chien . Évalué à 3.
De ce que j'ai compris à ROCm (cf lien dans le journal), il faut passer par le pilote amdgpu d'AMD en lieu et place de radeon. J'ai juste ?
Je ne suis pas super chaud pour utiliser un pilote réputé moins bon dans la majorité de mes usages pour une fonctionnalité dont je me sers qu'une fois de temps en temps.
[^] # Re: Le choix de AMD
Posté par AlexTérieur . Évalué à 3. Dernière modification le 07 décembre 2020 à 20:31.
Non, en fait le gros problème de ROCm est son support qui n'est pas "complet", par exemple, étant utilisateur Fedora, impossible d'utiliser sans bidouille les paquets RPM qui sont prévus pour CentOS/RHEL… Là avec Fedora 33, ça s'est amélioré même si ce n'est pas "officiel", il marche sans problème il faut juste changer manuellement le lien symbolique vers le bon pilote ICD. On ne touche absolument pas aux pilotes de la cartes graphiques, qui resteront ceux qu'on a installé. J'avais réussi à faire fonctionner OpenCL sur Fedora 31/32 au prix d'une grosse bidouille un peu limite (exploiter un dépôt RPM bidouillé pour être installable sous Fedora, c'était le propos de mon journal) mais là, on peut installer proprement ROCm et changer le lien symbolique, ça reste beaucoup moins "crade" comme manip.
Tout est expliqué dans le lien que j'ai donné dans le commentaire de l'autre journal : https://linuxreviews.org/Radeon_Open_Compute
[^] # Re: Le choix de AMD
Posté par Pif le Chien . Évalué à 3. Dernière modification le 07 décembre 2020 à 21:14.
Ok. Donc ça me rebute encore plus :-D
[^] # Re: Le choix de AMD
Posté par AlexTérieur . Évalué à 2. Dernière modification le 10 décembre 2020 à 21:46.
Même si le support n'est pas dit "officiel", je t'assure qu'il n'y a rien d'aussi rebutant que ce que j'ai pu connaître (sur Fedora 31/32 j'ai vraiment eu peur de péter l'OS). Maintenant sur Fedora 33, tu n'as plus qu'à installer les bons rpm avec dnf (pour rocm principalement) et juste un seul lien symbolique à changer. A noter que le support Ubuntu est officiel, donc probablement encore plus simple et moins risqué.
[^] # Re: Le choix de AMD
Posté par inkey . Évalué à 1. Dernière modification le 07 décembre 2020 à 22:33.
À noter l'obligation d'avoir un CPU plutôt récent pour faire fonctionner ROCm … ainsi que le fait que le driver réagi incorrectement sur darktable : https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/issues/103
J'avais envisagé la chose, mais malheureusement c'est un domaine ou il n'y à pas de bonne solution libre.
OpenCL même n'étant pas un standard très fort, à tel point qu'un des gros logiciel de photogrammétrie opensource
meshroom utilise CUDA (la technologie de Nvidia) et ne permet toujours pas un fonctionnement correct en dehors
(voir l'issue https://github.com/alicevision/meshroom/issues/595)
# Ah les Radeon HD 4xxx
Posté par xoddark . Évalué à 4.
Ah les Radeon HS de la génération 4000, je dirais que c'est la première génération a avoir un bon support avec les drivers open-sources, en tous cas, moi c'est avec une radeon HD 4850 que j'ai commencé a bien profiter des drivers libre … mais c'était pas à leur sortie, il a fallu être bien patient 😄.
Pour OpenCL avec Mesa, c'est dommage que clover ai été mis en de coté par AMD au profit de ROCm, à l'époque ni nouveau et Intel n'avait accroché, mais il semble que clover retrouve de l’intérêt (pour Nouveau et Intel), peut-être que ça va aussi profiter aux cartes AMD.
Dommage que je ne m'y connaisse ni en programmation de Drivers, ni en OpenCL sinon j'aurais essayer de regarder pour participer. Si quelqu'un lançais un financement participatif, je participerais.
J'aimerais bien pouvoir profiter d'OpenCL avec Darktable 😉.
[^] # Re: Ah les Radeon HD 4xxx
Posté par AlexTérieur . Évalué à 1. Dernière modification le 07 décembre 2020 à 20:36.
En fait, de ce que j'ai compris, ROCm ce n'est pas qu'un pilote ou une architecture/pilote, mais un ensemble d'outils tournant autour du traitement par GPU (classiquement OpenCL et en version > ou = à 2). Rien ne dit que par la suite Mesa n'intègrera pas l'ICD que propose ROCm, par contre je n'en sais rien des discussions.
[^] # Re: Ah les Radeon HD 4xxx
Posté par Chris K. . Évalué à 3.
Les HD4000 utilisent encore l'ancien pilote radeon. Cela fait un bon moment qu'il fonctionne plus que correctement, il fait tourner la HD6950 que j'utilise encore sans que je n'ai jamais eu à m'en plaindre.
J'ai aussi connu les déboires de fglrx avant cela avec la HD3870 : lire une simple vidéo en synchronisant la sortie avec un moniteur ou un projecteur pour qu'elle soit parfaitement fluide était problématique. J'étais aussi alors repassé sur une carte nvidia à cette époque.
Le gros changement de cap a été le passage au pilote amdgpu à partir de la génération des R9 2XX de mémoire.
En tout cas merci pour le retour sur la nouvelle génération. Il est vrai que AMD à fait du très bon travail de ce coté depuis un peu plus de 10 ans.
Je pense aussi sauter le pas pour une carte RDNA 2 mais je vais attendre la sortie des RX 6600/6700, moins onéreuses, n'ayant que de simples moniteurs full HD pouvant afficher au maximum 60 images par secondes.
# PCI Resizable BAR / Smart Access Memory
Posté par Pif le Chien . Évalué à 2.
À noter que sous Linux j'ai pu activer dans le BIOS le "PCI Resizable BAR" avec mon CPU Ryzen de série 3000, ce qu'AMD appelle
pompeusementcommercialement le Smart Access Memory (SAM) et qu'il vend comme une exclusivité des processeurs de série 5000 qui viennent évidemment de sortir. Il s'agit en réalité d'une spécification standard du PCI express (Cf la doc de Arch Linux).Il y a donc flagrant moquage de figure sur ce point. Mais bon, Lisa Su n'est pas une Bienfaitrice de l'Humanité, et business is business.
Pour éviter les bugs, j'ai du toutefois utiliser mesa-git (la version 21 en développement), sinon certains jeux ne détectent que 16 Mo de VRAM de la carte graphique et se plaignent logiquement que ce n'est pas suffisant.
Après un rapide benchmark, sur RDRII je passe de 69 à presque 74 images/s en moyenne sur (+6%). Ce n'est pas super rigoureux, il faudrait le passer plusieurs fois, mais le gain semble a priori exister.
# Un peu perdu dans les cartes graphiques
Posté par gUI (Mastodon) . Évalué à 10.
Depuis la 3DFX2 j'ai un peu décroché les cartes graphique (j'exagère à peine).
Je suis depuis des
sièclesannées sur le graphique intégré Intel, et vu que mon jeu principal c'est de recompiler Vi, ça passe.Mais je commence à avoir une petite bibliothèque sur Steam par exemple, et certains jeux, même simples, gagneraient avec une carte graphique.
Pour une 100aine d'€ dans l'occasion, quelle carte graphique hyper bien supportée sous Linux je pourrais trouver ? Refroidissement passif idéalement, ou disons discret à minima (je voudrais pas d'un sèche cheveu dans ma tour qui ne fait quasiment pas de bruit).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Un peu perdu dans les cartes graphiques
Posté par jame_s . Évalué à 3.
En neuf, tu peux avoir une RX550 à moins de 70 euros. Certaines cartes graphiques ont un ventilateur mais qui ne tourne pas quand elles ne sont pas fortement sollicitées (cherche mode 0 dB sur ton moteur de recherche préféré). J’avais cherché comme toi des cartes fanless mais c’est rare chez AMD, trop cher et pas performant.
En occasion, tu peux trouver pour moins de 100 euros des RX560, voir des RX570.
[^] # Re: Un peu perdu dans les cartes graphiques
Posté par ekyo . Évalué à 6.
Pour avoir eu une rx580, et maintenant une rx5700xt, le mode 0db tu peux très bien le créer toi-même : j'ai un script bash qui change la vitesse des ventilos en fonction de la température et de la charge du cpu.
function f_set_gpu_fan {
echo 1 > /sys/class/drm/card0/device/hwmon/hwmon0/pwm1_enable
echo ${1} > /sys/class/drm/card0/device/hwmon/hwmon0/pwm1
}
En fait, avec amdgpu, tout est exposé dans le fs, il est possible d'overclocker, underclocker, undervolter (désolé pour ces anglicismes) très simplement, et d'adapter au jeu que l'on lance par exemple.
[^] # Re: Un peu perdu dans les cartes graphiques
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Si tu souhaites un PC silencieux tout en voulant jouer, il faut penser au water-cooling :)
Une pompe D5 + radiateur 360 + bloc CPU + bloc CGU ça change la vie…
Pour le budget, c'est pas tant que ça, les soldes docmicro sont ton ami et au niveau silence on fait difficilement mieux.
J'ai fais ça sur un cpu amd FX-9800 et une Radeon RX Vega 64, petit moment de stress lors de la mise en route avec une fuite d'eau distillée réparée depuis, au final c'est top :)
Au début fallait faire sauter le "GPU pas supporté" dans le driver avec une commande qui patchait le binaire, maintenant ça fonctionne sans se poser de question de base.
[^] # Re: Un peu perdu dans les cartes graphiques
Posté par ekyo . Évalué à 2.
Salut, j'ai aussi fait des WC custom sur quelques unes de mes anciennes configs, mais j'en suis revenu. Rien de mieux qu'un bon sous voltage de tous les composants, et un bon gros rad avec des ventilos silencieux. Honnêtement, il n'y a pas match.
CPU 1800x OC via p-states, UV entre 975mv@1,8Ghz et et 1.045V@3,7Ghz, conso environ 30W en utilisation classique. Un bon gros ventirad double tour (un NH D15 dans mon cas), et même pas besoin de faire tourner les ventilos, ni du ventirad, ni du boitier. En charge 100% sur tous les coeurs @3,7Ghz, les 2 ventilos du ventirad tournent à 700RPM, ceux du boitier à 300RPM. Je vis à la campagne, pas un seul voisin, pas une route, rien… et impossible d'entendre le PC à moins de coller sa tête dessus (boitier Nanoxia DS1revB, ventilos boitier BeQuietSW2/3).
Pour la rx5700xt, c'est une nitro+ de sapphire, donc déjà une bonne base avec un bon système de refroidissement. Comme pour le CPU, je l'ai undervoltée (750mv@800Mhz jusqu'à 1,018V@1900Mhz), et j'ai abaissé le powercap à 200W. Comme pour le CPU, au repos aucun ventilo qui tourne, 25W de conso dissipés exclusivement via le rad. En charge, les ventilos du gpu montent au max à 1000RPM, avec les ventilos boitier 500RPM pour les 2 de devant et 350RPM pour ceux du dessus et celui de derrière. Un léger souffle en somme, rien qu'une pompe qui tourne pas fort fait plus de bruit. Aucun watercooling ne fera mieux. En OC extrême, là oui, mais ce n'est pas mon cas. En silence pur, impossible puisque je suis fanless la majorité du temps.
Sinon, je leur fais encore de la pub, tu as ce genre de solutions qui te permet d'être sur une config 100% fanless même en charge : https://www.monsterlabo.com/the-beast
# Red dead redemption 2
Posté par Liorel . Évalué à 4.
Je me tâtais à acheter Red dead redemption 2, mais je suis toujours un peu frileux : le prix n'est pas donné, et pour ce prix-là, j'aimerais bien un jeu qui tourne. J'ai le souvenir de jeux payés plein pot qui n'ont jamais tourné, et il n'y a évidemment aucun moyen d'installer le jeu, de le tester, et de ne le payer que s'il fonctionne.
Du coup, vu que tu as l'air d'être sous Arch comme moi, est-ce que ça te dérangerait de partager ta config, notamment la version de Proton ?
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Red dead redemption 2
Posté par Pif le Chien . Évalué à 5. Dernière modification le 08 décembre 2020 à 08:59.
Je suis la version proposée par Steam de Proton, donc actuellement la 5.13-2. J'ai installé le jeu via Lutris, parce que je possède une version achetée sur le lanceur de Rockstar, mais la version Steam fonctionne pareil.
J'ai spécifié l'option "-vulkan" et il y a une commande à exécuter plusieurs fois de suite dans un terminal une fois le jeu lancé s'il ne se passe rien :
PID=$(pgrep RDR2.exe); kill -s SIGSTOP $PID && kill -s SIGCONT $PID
Avant d'acheter un jeu, je consulte systématiquement le merveilleux site ProtonDB.
[^] # Re: Red dead redemption 2
Posté par dj_ (site web personnel) . Évalué à 4.
Des solutions comme Steam et Gog permettent le remboursement des jeux selon une condition de durée de jeux ou de date d'achat
Steam c'est si t'as joué moins de deux heures par exemple
[^] # Re: Red dead redemption 2
Posté par HL . Évalué à 1.
Et pour Gog? Vu que les programmes d'installation des jeux sont téléchargeables sans DRM et n'ont pas besoin d'un compte pour fonctionner je me demande comment on peut se faire rembourser (en prouvant sa bonne foi en affirmant qu'on a supprimé l'exécutable).
J'ai voulu tenter de jouer à GRIS mais il n'a pas l'air de fonctionner pour le moment avec ma config, Wine + une CG intégrée Intel. Je n'avais pas trouvé comment faire. (Pour la petite histoire, j'étais conscient du risque, je l'ai gardé en attendant de pouvoir tester.)
[^] # Re: Red dead redemption 2
Posté par dj_ (site web personnel) . Évalué à 3.
Voir sur cette page Comment demander un remboursement ? et la FAQ lié
En gros, ils font confiance si c'est pas exagéré et ils étudient le nombre de demande etc
[^] # Re: Red dead redemption 2
Posté par HL . Évalué à 1.
Merci pour le lien, les choses sont effectivement assez claires. J'ai l'impression qu'à l'époque où j'ai cherché, c'était différent. Mais j'aurais pu revérifier avant de poser cette question. :-)
Je pense que télécharger un jeu pour le lancer sous Wine représente une prise de risque et il vaut mieux se préparer à un refus.
[^] # Re: Red dead redemption 2
Posté par dj_ (site web personnel) . Évalué à 2.
Ça date de fin février 2020
Next INpact : GOG rembourse jusqu’à 30 jours après l’achat sans condition, mais pas sans vigilance
Utilise d'abord les sites qui permettent de vérifier la compatibilité (winedb et surtout ProtonDB indiqué plus haut)
[^] # Re: Red dead redemption 2
Posté par ted (site web personnel) . Évalué à 2.
À l'époque on trouvait des démo de jeux, c'est pratique pour tester. Ça ne se fait plus?
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Red dead redemption 2
Posté par dj_ (site web personnel) . Évalué à 2.
Maintenant ils préfèrent publié des jeux en bêta payante (aka "accès anticipé")
Plus sérieusement, oui ça existe encore mais c'est pas la règle générale le catalogue steam des jeux en démo
[^] # Re: Red dead redemption 2
Posté par Pif le Chien . Évalué à 1.
Il existe même maintenant le concept de la démo pour celles et ceux qui ont précommandé le jeux.
[^] # Re: Red dead redemption 2
Posté par Tonton Th (Mastodon) . Évalué à 2.
Mais si : https://ptilouk.net/superflu-riteurnz/
# Donc, toujours pas de support pour Blender ?
Posté par Stinouff . Évalué à 2.
Une CG AMD me tentait bien pour les drivers libres et du calcul rapide sous Blender, mais de ce que je comprends, ce n'est pas encore l'heure, c'est ça ?
[^] # Re: Donc, toujours pas de support pour Blender ?
Posté par small_duck (site web personnel) . Évalué à 3.
Ce sera l'un ou l'autre :)
J'installe le driver proprio AMD, qui est, si je comprends bien, le driver libre + OpenCL proprio, et Blender tourne très, très bien. Mais c'est le driver proprio.
[^] # Re: Donc, toujours pas de support pour Blender ?
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
Tu peux faire l’un et l’autre, voir mon commentaire en dessous.
Tu peux installer la pile OpenCL comme ça (GCN3+) :
ou (GCN1 et GCN2):
À noter que pour les cartes GCN1 et GCN2 il faut forcer l’utilisation du pilote
amdgpuau démarrage, ce qui se fait avec les paramètres Linux suivants :Un petit aperçu de galères que l’ont peut rencontrer: https://github.com/RadeonOpenCompute/ROCm/issues/484#issuecomment-727734485
Mais il est important de savoir qu’avec le pilote noyau
amdgpuon peut installer en même tempsradeonsi(OpenGL),radv(Vulkan),amdvlk(Vulkan),rocm(OpenCL),orcaoupal(OpenCL),libclc-amdgcnet si le matériel est pris en charge, utiliser l’un ou l’autre sans redémarrage ni réinstallation.Il faut vraiment éviter le pilote propriétaire OpenGL d’AMD à moins d’avoir un besoin ésotérique : en faisant des tests j’ai découvert que le pilote libre pouvait désormais se montrer deux fois plus rapide que le pilote propriétaire historique.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Donc, toujours pas de support pour Blender ?
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Ça marche, mais c’est une galère sans nom. OpenCL sous Linux est le seul truc du côté des carte graphiques qui est encore un champ de mine:
https://gitlab.com/illwieckz/i-love-compute#frameworks
À noter que t’as la possibilité d’utiliser le pilote propriétaire AMDGPU-PRO OpenCL par dessus le pilote noyau libre
amdgpuen même temps que l’excellente implémentation OpenGL (radeonsi) et Vulkan (radv) libre de Mesa, ainsi que l’implémentation libre Vulkanamdvlkd’AMD.À noter aussi que tu peux installer plusieurs pilotes OpenCL en même temps, AMDGPU-PRO, ROCm et Clover/LibCLC (Mesa/LLVM).
Par exemple avec mon R9 390X avec un CPU pré-Ryzen je ne peux pas utiliser ROCm, mais AMDGPU-PRO (Legacy/Orca) fonctionne très bien avec Darktable et Blender, tandis que LibCLC ne peut pas faire tourner Darktable (prise en charge des images manquante) mais peut se révéler deux fois plus performants sur certains scénarios où la prise en charge est complète (exemple: le benchmark LuxMark, et donc le moteur de rendu LuxRender).
À noter que si tu veux faire du rendu Cycles dans Blender un CPU AMD avec plein de cœurs sera plus rapide qu’une carte graphique.
J’ai obtenu de meilleures performance avec un Ryzen 24 cœurs d’avant dernière génération qu’avec une AMD Vega (pilote AMDGPU-PRO) et de meilleures performance avec un ThreadRipper 32 cœurs de première génération qu’avec deux GTX 1060 (pilotes Nvidia).
Si tu as l’argent pour, un gros ThreadRipper c’est fait pour ça.
ce commentaire est sous licence cc by 4 et précédentes
# Drivers libres pour faire tourner des logiciels fermés ?
Posté par Anonyme . Évalué à -1.
Je lis ci-dessus beaucoup de commentaires qui parlent de faire tourner tel ou tel jeu non libre.
J'ai du mal à comprendre la cohérence qu'il peut y avoir à exiger des pilotes libres des constructeurs si c'est dans le but de faire tourner des jeux dont le code est non seulement fermé mais en plus, dans certains cas, enchaîné à une plateforme de DRM.
Vous faites tourner ces logiciels dans un environnement spécifique qui permet de contrôler ce à quoi ils pourraient avoir accès (données locales, profilage d'activités, envoi et partage de tout et n'importe quoi via la connexion réseau etc.) ou bien ça tourne en mode "youpi ça marche avec Wine" ?
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par claudex . Évalué à 9.
Ça ne sert pas qu'à faire tourner des jeux propriétaire, ça sert aussi à faire tourner des jeux propriétaire, c'est une distinction importante. De plus, si tu veux justement avoir une sandbox pour tes jeux proprio, il vaut mieux que le driver soit libre, mais du coup, c'est une étape nécessaire pour s'y mettre, ça ne veut pas dire que tu vas le faire du jour au lendemain.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Anonyme . Évalué à 4.
ce n'est pas ce qui ressortait de la majorité des commentaires lorsque j'ai posté le mien.
On est d'accord que le pilote libre est bien évidemment préférable au pilote propriétaire et je ne me plains certainement pas de la disponibilité de ces pilotes libres.
Mais dire "Youpi je vais enfin pouvoir utiliser un pilote libre avec de bonnes performances" , tout ça pour se précipiter sur du propriétaire qui pose les mêmes problèmes que les pilotes qu'on vient de remplacer, ça me perturbe, d'autant plus si aucune mesure de sécurisation n'est mise en place.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par claudex . Évalué à 10.
On est loin des mêmes problèmes, il est possible de sandboxé les jeux, les jeux proprio ne vont va pas te faire chier au boot ou aux mises à jour du kernel.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Anonyme . Évalué à 4.
On ne parle pas des mêmes problèmes: tu parles de problèmes techniques qui peuvent être communs aux logiciels libres et propriétaires lorsqu'ils sont mal conçus ou mal intégrés, alors que je parle de problèmes de transparence et donc de sécurité quant à ce que fait le logiciel de l'environnement qui lui est rendu accessible.
C'est pour cela que je pose la question et m’intéresse au type de protections mises en place par les joueurs qui installent ces logiciels et comment ces protections s'articulent avec les plateformes de DRM.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par claudex . Évalué à 6.
Pour la sécurité, tu peux sandboxer des applications propriétaire, pour sandboxer des drivers, c'est plus compliqué (il faut une architecture à la Windows, et encore). Et application propriétaire ne veut pas dire DRM.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Anonyme . Évalué à 4.
Au risque de me répéter, il me semble que c'était le but de la question dans mon premier commentaire: qu'est-ce que ces joueurs utilisent pour cloisonner ces jeux et dans quelles limites est-ce efficace ?
Les jeux dont il est question sont distribués par Steam qui est une plateforme de DRM.
Elle ajoute une couche supplémentaire de désagrément qui peut avoir un impact sur les solutions de cloisonnement mises en place par les joueurs.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par vv222 . Évalué à 4.
Heureusement, il existe une grande quantité de jeux propriétaires tournant sous Linux (nativement ou non) sans aucune forme de DRM.
Malheureusement, Valve a une force de frappe marketing immense qui en a fait une entreprise aimée et défendue par beaucoup de joueurs sous Linux.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Lutin . Évalué à 5. Dernière modification le 09 décembre 2020 à 06:56.
Sur GOG, la plupart des jeux sont vendus sans DRM.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par vv222 . Évalué à 5.
Attention à ne pas se faire piéger par contre : la plupart des jeux vendus sur cette boutique sont sans DRM mais il en reste une fraction non négligeable qui en utilisent pour contrôler l’accès à une partie des fonctionnalités, voire à la totalité.
Souvent ces jeux sont défendus à coup de « Ah mais ça ne compte pas si ça ne concerne que le multijoueur / le contenu additionnel / les bonus cosmétiques, etc. ». Évidemment, si on met bout à bout tous ces trucs qui "ne comptent pas" on recouvre vite l’intégralité d’un jeu ;)
Le gros souci c’est qu’à côté de ça cette boutique continue prétendre ne vendre que des jeux sans aucune forme de DRM, et donc ne propose aucune manière de savoir avant d’acheter un jeu quelle partie de ses fonctionnalités sont verrouillées derrière un système de ce genre.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Lutin . Évalué à 6.
Le DRM n'est pas un DRM ajouté par GOG (comme le fait Steam), mais un DRM intégré par le développeur du jeu (impossible de trouver le jeu légalement sans).
Ils sont, malheureusement, assez peu clairs sur ces points.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par vv222 . Évalué à 4. Dernière modification le 10 décembre 2020 à 15:21.
En effet, on n’a pas comme avec Steam l’imposition systématique d’un client tiers ou autres systèmes de verrouillage. C’est d’ailleurs pour ça qu’ici je critique GOG et pas Steam : le premier fournit encore partiellement un service utilisable, là où le second n’est comparable qu’à un GAFAM spécialisé dans le jeu vidéo.
À nuancer par la présence de DRM dans des jeux développés par CD Projekt Red, appartenant au même groupe que GOG. Deux exemples qui me viennent en tête pour ce studio :
À côté de ça ils continuent à se prétendre farouchement opposés à toute forme de DRM. Mensonge que ne pratiquent pas d’autres sites vendant un mélange de jeux avec ou sans DRM, comme Humble Bundle par exemple (qui a bien sûr d’autres défauts).
Et on en arrive à ce qui est à mon avis le problème majeur pour les joueurs refusant les DRM : on n’a aucune boutique de confiance à laquelle se fier.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Lutin . Évalué à 3.
C'est d'autant plus triste qu'ils (GOG) sont à l'origine du FCK DRM initiative.
Du… euh… DRM-free washing en somme.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par vv222 . Évalué à 3.
Dans le même esprit, un des contenus additionnels de Cyberpunk 2077 bloqué derrière une activation en ligne est une skin pour le personnage jouable. Un t-shirt pour être plus précis. T-shirt faisant la promotion… du DRM-free \o/
Allez, reconnaissons-leur un poil de scrupules, il semblent qu’ils en aient mis à jour la description depuis :
« Add this to V’s wardrobe to celebrate the DRM-free revolution. Keep that rebel spirit strong, cyberpunk. »
vers :
« A good ol’ t-shirt, maybe even the best one in the whole galaxy. Add this to V’s wardrobe for a look that’s truly out of this world! »
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Thomas Debesse (site web personnel) . Évalué à 10. Dernière modification le 08 décembre 2020 à 12:30.
Ton commentaire semble supposer le libre a pour seul intérêt de contrôler ce qui se passe. D’un point de vue sécurité oui faire tourner un jeu proprio peut ouvrir une brèche aussi grande qu’un pilote proprio (quoi qu’un pilote en espace noyau doit pouvoir exfiltrer une clé de chiffrement de disque dur et donc permettre une attaque offline par exemple alors que le programme en espace utilisateur ne verrait que les fichiers et requiert de faire les basses œuvres sur un système qui tourne).
Les logiciels libres peuvent avoir d’autre qualités qui font que tu peux être par exemple contraint d’utiliser tel logiciel propriétaire pour ton boulot mais cela te laisse libre de libérer le maximum que tu peux.
Typiquement sur le plan graphique (pas pour le calcul), les pilotes AMD sont excellents avec des performances remarquables, contrairement aux pilotes Nvidia qui proposent toujours la même mauvaise intégration depuis 15 ans (20 ans ?) et la même expérience fondée sur des technos non-renouvelées.
Si je devais écrire un slogan pour Nvidia ce serait « l’expérience de l’an 2000, plus rapide ». Par exemple sur mon ordi portable actuel j’avais du faire un fichier
xorg.confpour afficher quelque chose quand j’avais voulu essayer le pilote proprio, un truc qui ne se fait plus depuis au moins 10 ans… J’ai testé une cinquantaine de GPUs des trois marques AMD, Intel et Nvidia produits les dix dernières années… et le résultat est désastreux pour Nvidia : le pilote ment parfois et il faut implémenter une détection des versions buggées pour ne pas utiliser des fonctionalitées annoncées mais non-prises en charges, si tu as deux cartes graphiques (non pas pour de l’affichage étendu mais pour du calcul) tu peux voir le bios (et grub) s’afficher sur une carte et l’os sur une autre requérant de devoir switcher les câbles vidéo pendant la séquence de démarrage, ou encore des cartes qui demandent qu’un écran (que le pilote proprio ne pourra pas utiliser pour afficher quelque choses) soient branché sur le premier port vidéo afin de pouvoir gérer correctement le second port vidéo sur lequel serait branché l’affichage réel (quand le pilote libre sait gérer le second tout seul et les deux à la fois).Il n’y a donc aucune raison de prendre en plus un pilote graphique de merde sous prétexte qu’on subit déjà un logiciel propriétaire.
À moins de supposer qu’un logiciel propriétaire serait forcément plus performant et qu’on souffrirait le logiciel libre pour d’autres raisons comme la sécurité, il n’y a aucune raison de ne pas préférer un logiciel libre sous prétexte qu’on utilise déjà un logiciel propriétaire par ailleurs. Un logiciel libre peut être aussi de meilleure qualité, mieux intégré, fournir les performances attendues, et ne pas être troué de bugs dans tous les sens.
Pour la dernière question, quand j’essaie des trucs dans Steam, je le fais dans un chroot que j’ai créé pour ça. Ça n’empêche pas un éditeur de jeu de faire un keylogger qui écouterait X11, mais ça m’a déjà permis de ne pas rincer mes fichiers quand Steam avait un bug qui effaçait l’intégralité du /home et que j’ai reproduit ce bug… Je m’en veut toujours un peu de ne pas avoir trouvé le temps de le rapporter car je l’avais reproduit genre 6 mois avant ces pauvres gens. 😢
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Anonyme . Évalué à 3.
non, mon commentaire pose simplement l'incohérence que je ressens à se réjouir de la disponibilité de pilotes libres dont l'exploitation in fine m'a paru ne tourner qu'autour de l'utilisation de logiciels propriétaires dans les commentaires auxquels je fais référence.
En l’occurrence, on parle de se réjouir de pouvoir installer des jeux propriétaires: il ne me semble pas avoir lu que ceux-ci étaient imposés par qui que ce soit.
Je n'ai pas l'impression d'avoir dit le contraire.
À défaut de partager mon sentiment d'incohérence, c'était bien vers ce genre de réponse que je voulais orienter mon commentaire: quelles sont les mesures mises en place par des joueurs forcément sensibilisés aux problématiques du logiciel propriétaire, qu'elles soient sécuritaires ou idéologiques puisqu'on est quand même sur linuxfr.org avec des gens qui font le choix informé d'utiliser un environnement libre, mais qui font pourtant une entorse à ce choix pour pouvoir jouer à leurs jeux préférés ?
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Là j’ai le droit de dire que « ton commentaire semble supposer » quelque chose ?
Tu peux faire 95% de choses avec des logiciels libres et 5% de choses avec des logiciels propriétaires. Ces 5% peuvent décider pour les 100%. Par exemple quelqu’un qui aimerait bien jouer 1h par semaine à un jeu propriétaire qu’il apprécie se posera sérieusement la question de quel matériel et quel pilote utiliser. Ces 5% sont 100% décisifs.
De même, quelqu’un qui a une seule application CUDA qu’il utilise une fois par mois mais ne peut pas s’en passer pour diverses raisons, c’est cet usage minoritaire qui va en fait décider du matériel et du pilote. Nvidia l’a très bien compris, je considère d’ailleurs ceci comme une forme de racket.
Je réponds de manière générale que chacun peut avoir ses propres raisons. Je ne peux pas supposer ces raisons donc je donne un exemple de raison propre qu’il est facile d’imaginer, et qui suffit à prouver qu’il est possible d’avoir ses propres raisons sans avoir à les supposer ni d’exiger plus que cela de les révéler.
Par ailleurs, dans ce cas précis, même dans le loisir tu peux subir des pressions diverses (c’est pas forcément négatif, ça peut être des encouragements), comme par exemple partager des moments de jeux avec des membre de ta famille plus ou moins éloignée, et ils auraient tout à fait le droit de suggérer tel ou tel jeu.
Exemple simple : quand j’étais enfant je jouais à Streets of Rage sur Megadrive avec mon frère, un voisin nous avait offert la console après avoir acheté la Saturn et un autre voisin nous avait offert le jeu. Maintenant nous habitons loin l’un de l’autre, et quand est sorti récemment la version 4 du jeu, elle m’a fait beaucoup de l’œil pour une raison particulière : mon frère jouait Adam et moi je jouais Blaze. Il se trouve que le personnage d’Adam est complètement absent des épisodes 2 et 3 mais présent dans l’épisode 4. L’idée de pouvoir jouer ensemble à Streets of Rage avec nos personnages respectifs (ce qui a attendu le 4ème épisode pour être de nouveau possible !) était très séduisante. J’ai sincèrement considéré l’éventualité d’acquérir ce jeu propriétaire dans le but de jouer avec ma famille, ce qui est vraiment exceptionnel de ma part. Ce qui m’a finalement bloqué c’est que la version propriétaire mais sans DRM ne permet pas le jeu en ligne, et si j’aurai craqué ça aurait été pour jouer en ligne, et là, le DRM c’est trop pour moi.
Autre exemple, quelqu’un a récemment témoigné comment il en est venu à acheter une Xbox pour que sa fille puisse jouer avec ses copines. C’est un bon exemple de pression sociale, et avant de lâcher l’affaire et d’acheter la Xbox il a semble-t-il tenté wine, le double-boot… Bref de garder un minimum de contrôle et d’ouverture (face à une Xbox un PC sous Windows ressemble à un paradis d’ouverture).
Ton commentaire ressemble tout de même furieusement à « pourquoi se laver puisqu’on va se re-salir ? » (d’où le sentiment de se faire troller exprimé par un autre). Ton commentaire était tout de même vachement centré sur une seule considération, j’en apporte simplement la preuve qu’il est possible de préférer un logiciel libre pour d’autres raisons que la sécurité par exemple, une seule preuve suffit j’ai donc pris celle qui me semblait la plus évidente.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par small_duck (site web personnel) . Évalué à 5.
J'ai sauté le pas et déplacé Steam dans son propre compte quand j'ai commencé à installer des plugins X-Plane. Avec ces binaires venus d'on ne sait où, je commençais à avoir un peu les foies… Un petit script avec xhost + sudo plus tard, et je peux démarrer l'app Steam dans mon bureau sans qu'elle puisse accéder à mes fichiers.
Malheureusement, cette approche ne fonctionne plus pour certains jeux passés à Vulkan, qui n'aime pas le xhost. Pour ceux là (War Thunder, Desperados III), je me logge directement en tant que Steam, ce qui est moins pratique.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Pif le Chien . Évalué à 5.
Ça ressemble à un troll. Tant pis, je prends le risque de marcher dedans.
Il est possible d'installer Steam via Flatpak et depuis quelques temps de sandboxer les jeux qui y tournent https://www.gamingonlinux.com/articles/steam-for-linux-can-now-run-games-in-a-special-container.15384/page=2 ).
Mais je dois bien l'avouer, ce n'est pas mon usage (en partie parce que la version de Mesa empaquetée dans le Flatpak n'est pas à jour).
Mon approche est différente de la tienne : sans changer mes usages, je cherche systématiquement à privilégier le libre à la place du propriétaire si c'est possible, brique après brique. Pour un usage vidéoludique, il reste l'exécutable Steam et les jeux qui y sont lancés qui sont propriétaires. Pour le premier, il existe un espoir, pour les second, clairement pas.
En faisant ce choix, la sécurité de mon ordinateur de bureau n'est certes pas la priorité numéro 1, mais je m'en accommode. Je ne recommanderai évidemment pas cette option pour quiconque privilégie la sécurité et la confidentialité de par son travail ou ses choix de vie.
Par contre, je peux désormais me passer complètement de Windows ou de machines spécialisées (entièrement fermées) pour jouer, regarder des Bluray et écouter de la musique en streaming (merci Mopidy). De plus, mon système d'exploitation est maintenant incommensurablement plus pratique à utiliser, par la supériorité intrinsèque du libre, que les systèmes propriétaires pour mes usages.
Dans mon entourage, ce sont des arguments qui font mouche pour faire de Linux un système viable, bien plus que la sécurité (on peut le déplorer, mais c'est mon constat).
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Anonyme . Évalué à 1.
non, pas mon genre, ou alors je suis un troll qui s'ignore :).
Cela fait belle lurette que je n'installe plus de logiciels propriétaires, au début par volonté de faire le grand saut, aujourd'hui parce que je n'en ai aucune nécessité, le libre couvrant toutes mes attentes. Et c'est vrai que spontanément j'ai tendance à considérer que les lecteurs de linuxfr.org penchent davantage vers cette manière de faire plutôt que vers une migration encore en cours vers le tout libre.
Pour ce qui concerne les réfugiés du monde propriétaire, c'est effectivement une très bonne nouvelle et un appeau puissant d'avoir accès à certains logiciels sans que l'ensemble du système les faisant tourner ne soit lui-même propriétaire. Mais cela n'enlève pas la nécessité de cloisonner ces logiciels et c'est dans ce sens qu'allait mon commentaire en demandant ce qui était mis en place par ceux qui s'autorisent cette entorse aux bonnes pratiques du libre afin de satisfaire leurs besoins ludiques.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par xcomcmdr . Évalué à 6.
Qui décide quelles sont ces bonnes pratiques ? Toi peut-être ?
Sales gosses avec leurs jeux vidéos et leurs naintendo !
S'agirait de grandir… S'agirait de grandir…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Psychofox (Mastodon) . Évalué à 5.
J'imagine que pour une grande partie, l'intérêt d'un pilote libre est son intégration au noyau qui garantie en grande partie que rien ne va casser en cas de mise à jour du noyau, une installation de l'os facile car sans manipulation manuelle et mise à jour du driver graphique automatique sans manipulation particulière.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
A chaque couche sa solution:
Plus qu'à trouver une sandbox dédiée aux jeu. Tu n'aurais 42 millions d'euros pour financer le maxitel par hasard?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Alain (site web personnel) . Évalué à 1.
En fait il y a plusieurs choses à penser.
Les pilotes proprios qu'ils soient AMD ou Nvidia, vont demander une certaine version du kernel pour fonctionner (Nvidia a par exemple délayé le support du kernel 5.9 ce qui a posé des soucis pour beaucoup de Manjariens, les pilotes proprios d'AMD ne s'installent pas sur des Ubuntu 20.10 à cause de la version du kernel).
Donc pilote libre = tu peux profiter des dernières avancées dans les derniers kernels (support matériel, support de fonctionnalités plus avancées des cartes AMD, meilleures performances en I/O…).
Si tu enlèves l'idée des jeux vidéos (parce que oui c'est un usage de plus en plus répandu sur GNU/Linux, qu'ils soient natifs ou non), il reste le problème d'OpenCL.
Même chose pour le support des pilotes proprios avec les kernels (avec AMD, c'est 20.04 chez Ubuntu sinon rien). Et cela semble se résoudre ces prochains temps avec Mesa 21 avec le support d'OpenCL 3.0 dans Clover ( https://www.phoronix.com/scan.php?page=news_item&px=More-Gallium3D-CL-3.0-In-Mesa ).
D'ici février, avec Mesa 21, nous aurons une solution libre pour AMD qui sera à un bon niveau de performances sur tous les points.
# Prix
Posté par HL . Évalué à 1.
En parlant de prix raisonnables, j'ai été très surpris par ceux du modèle RX6800XT sur Materiel.net.
A côté, il y a la MSI Radeon RX 570 Armor OC - 8 GO qui est à moins de 200€, et même le modèle Sapphire Radeon RX 550 Pulse Lite 2 GO qui coûte environ 70€.
Il semble que la RAM joue un rôle majeur dans le coût.C'est à cause d'une pénurie, comme l'affirme cet article vieux de 2 ans?
[^] # Re: Prix
Posté par claudex . Évalué à 6.
Tu compares des GPU qui ont 3 ans d'écarts.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Prix
Posté par ekyo . Évalué à 3. Dernière modification le 13 décembre 2020 à 11:36.
C'est surtout que depuis quelques temps, il y a beaucoup plus de demande que de stocks.
Dis "merci" aux fermes de minage de cryptomonnaies.
Et du coup merci aussi à AMD et NVidia de vendre en quantité et sans contrôle efficace contre les bots.
[^] # Re: Prix
Posté par HL . Évalué à 1.
Merci, ça me semble vraisemblable comme explication (comparer avec les processeurs dont les prix ont l'air de plutôt stagner).
[^] # Re: Prix
Posté par Raphaël G. (site web personnel) . Évalué à 0. Dernière modification le 10 février 2021 à 00:31.
Quand je pense que je tremblais quand j'ai mis en watercooling ma Radeon RX Vega 64 à 500€ et que là tu parles de GPU à 1000€… (ça fait un peu péter la garantie)
Soit il y a eu une inflation cachée monstrueuse, soit j'ai l'impression de rêver…
# Commentaire supprimé
Posté par mobuysellram . Évalué à 0. Dernière modification le 09 décembre 2020 à 19:26.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.