Journal De Intel/Nvidia à AMD.

Posté par  . Licence CC By‑SA.
Étiquettes :
42
2
juin
2021

Hola 'nal,

Depuis quelques mois, j'ai mis fin à une relation de plus de 15 ans de trouple avec Intel et Nvidia. J'ai voulu voir si l'herbe était plus verte chez le voisin rouge… elle l'est.

Depuis que je suis en âge d'utiliser un ordinateur, toutes mes machines (x86) ont eu un CPU Intel avec un GPU Nvidia. Toutes sans exception jusqu'à il y a peu.

J'ai commencé avec un HP Pavillion dv9051ea équipé d'un surpuissant Intel Core 2 Duo T5500 cadencé à 1,66 GHz et d'une Nvidia GeForce Go 7600. C'était le balbutiement des processeurs multicoeurs sur les ordinateurs portables. Une jolie machine pour l'époque que j'ai conservé pendant 7 à 8 ans. C'est sur elle que j'ai fait mes premiers pas sous Linux. D'abord Ubuntu, avec un live CD commandé sur leur site arrivé plusieurs mois après chez mes parents. A l'époque, beaucoup de problèmes dans la gestion des multicanaux audios et aucune solution pour utiliser les chipsets graphiques intégrés. J'ai essayé pas mal de distributions majeures mais sans la possibilité d'accélération 3D, j'ai conservé mon dual boot Windows. Ma machine commençant à se faire vieille, j'ai cherché une distribution Linux légère et je suis tombé sous le charme de CrunchBangLinux.

Puis j'ai eu un MSI GE70 0ND, un laptop résolument orienté vers le jeu vidéo, le meilleur rapport qualité/prix que j'avais pu trouver à l'époque qui rentrait dans le budget du Père-Noël. Ici on retrouve un Intel Core i7-3630QM et une Nvidia GTX 660M. Il est possible d'utiliser son GPU intégré depuis, Nvidia ayant sorti un driver capable de le supporter sous Linux mais il faut choisir : le chipset du CPU ou le chipset Nvidia, Nvidia ne supportant pas le changement à chaud, autrement appelé "Optimus". On a vu naître des projets comme Bumblebee pour gérer le changement à chaud, parfois avec plus ou moins de réussite selon les jeux vidéo. Peu avant, Linus disait en conférence à Nvidia d'aller se faire cuire un oeuf tant le support de Linux était désastreux. Evidemment, le pilote libre Nvidia, s'il fonctionne correctement pour l'accélération 2D, est totalement à la ramasser pour l'accélération 3D. J'ai donc toujours utilisé le pilote propriétaire.

Au même moment, je commence à me renseigner sur ce que fait la concurrence au niveau du support GPU. Les performances des GPU AMD sous Linux étaient, vraisemblablement, désastreuses.

Mon connecteur d'alimentation a un beau jour fait de la fumée noire, des étincelles et une flamme a jailli du châssis. Je l'ai ressoudé comme un cochon le temps de pouvoir acquérir une nouvelle machine, au risque que ça reprenne feu. J'aime vivre dans le danger (et je suis un peu pyromane sur les bords peut-être…).

Il fallait donc investir dans un nouveau compagnon. J'ai découvert PCSpecialist sur lequel on pouvait personnaliser son laptop. Ce sera donc un châssis Proteus Series de 17.3" avec un Intel i7 6700HQ et une Nvidia GeForce GTX 970M. Machine que je possède toujours aujourd'hui et qui fonctionne au poil. Crunchbang ayant eu une phase de mou, j'ai commencé à cherché un remplaçant. J'ai trouvé CTKArch qui reprenait un peu la même philosophie que Crunchbang mais avec une base Arch puis elle a fini par être abandonnée. Mais une nouvelle distribution naissait peu de temps après : ArchBang. Je ne l'ai plus jamais quitté. Les pilotes Nvidia avaient des performances tout à fait acceptables mais il était toujours impossible de faire un changement de GPU à chaud. Entre temps, AMD a libéré ses drivers, je regardais ça de loin et les performances semblaient s'améliorer petit à petit avec le temps. Steam a intégré Proton dans son client, facilitant le jeu sous Linux. Ma machine commençait à être un peu juste pour les jeux vidéo les plus récents, d'autant plus sous Wine/Proton, j'avais un petit pactole de côté, il était temps de me faire un petit plaisir… Je me renseigne sur comment fonctionnent les GPU AMD sous Linux aujourd'hui, visiblement les performances sont au niveau de ce qui existe sous Windows à présent. Et si je ne l'ai pas signalé jusqu'ici, j'en ai eu marre des changements dans le driver Nvidia qui de temps en temps cassaient mon affichage. Rien de grave, il suffisait souvent d'aller lire les changelogs pour remettre le tout sur pied. Mais pénible de serrer les fesses à chaque MAJ et de parfois devoir faire un chroot.

C'est l'heure de tromper mes premiers amours…

J'ai longuement hésité, ayant quand même peur de me retrouver avec un GPU faiblard sous Linux, ce qui aurait été rédhibitoire, le jeu étant une activité qui me prend beaucoup (trop ?) de temps. Mais la pénurie des GPU de Nvidia 3080 et la 3080 Ti étant repoussé chaque mois m'ont finalement décidé à franchir le pas. Me voila aujourd'hui heureux possesseur d'un desktop (toujours monté sur PCSpecialist) avec un AMD Ryzen 5900X et une AMD 6900 XT Red Devil. Première installation, le GPU fonctionne directement, sans aucune configuration ni installation… et oui Mesa intègre le support des GPU AMD. Woah, encore plus facile que sous Windows. Bon il faudra quand même que je configure xrandr pour supprimer le tearing, gérer le dual screen et mettre à la bonne fréquence mes deux moniteurs. Une seule ligne dans mon .xinitrc et c'est plié :

xrandr --output DisplayPort-0 --dpi 120 --set TearFree on --primary --mode 2560x1440 --rate 165 --pos 0x0 --rotate normal --output DisplayPort-1 --dpi 96 --set TearFree on --rate 165 --mode 1920x1080 --pos 2560x360 --rotate normal --output DisplayPort-2 --off --output HDMI-A-0 --off

Il fallait quand même que je m'assure que mon GPU performe correctement. Hop, on télécharge la ludothèque Steam et on essaye de lancer des jeux récents et gourmands. N'ayant pas installé Windows, je compare avec des benchmarks que je trouve sur Internet. Ca vaut ce que ça vaut mais ça fait un point de comparaison à défaut de mieux. Parfait, selon les jeux, même sous Wine/Proton j'arrive à égaler des performances de jeux sous Windows à +/- 10% de performances. Parfois c'est un peu mieux, parfois c'est un peu en-dessous mais c'est globalement très proche. Avec les jeux natifs, j'arrive même à exploser certains benchmarks (Linux serait-il prêt pour le gaming avant le desktop ?)

J'ai eu quelques mises à jour du kernel et donc de Mesa depuis, évidemment je n'ai pas eu une expérience aussi longue qu'avec Nvidia et le fait d'avoir un desktop à la place d'un laptop facilité pas mal le bousin (pas de technologie "Optimus" ou similaire) mais tout s'est déroulé sans accroc.

J'ai également préféré un CPU AMD à un CPU Intel, en puissance brute ils sont devenus simplement plus performants, ils souffriraient moins de la mitigation de Spectre que son concurrent et je voulais essayer le "Smart Access Memory" sous Linux. Si d'après AMD la technologie est supportée sous Linux, j'avoue ne pas avoir remarqué de grosses différences en jeu mais visiblement ça peut dépendre des titres. Je l'ai donc laissé activer.

Pendant de longues années, les joueurs sous Linux, et moi le premier, ne juraient que par Nvidia, le seul à fournir un pilote performant. Visiblement AMD a aujourd'hui bien rattrapé son retard, autant sur le matériel que sur le logiciel et est capable de rivaliser sérieusement avec son concurrent. Les libristes apprécieront également la performance du driver libre.

Je n'ai évidemment aucun lien avec aucune des marques ou aucun des projets cités.

  • # Pilote ?

    Posté par  (site web personnel) . Évalué à 3.

    Un petit détail mal saisie : quel est le pilote utilisé pour les tests de performance AMD, le libre ou l’autre ? Y a-t-il de grosses différences de performance ou de compatibilité entre les deux ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Pilote ?

      Posté par  (site web personnel) . Évalué à 10.

      Nibel a dit:

      Première installation, le GPU fonctionne directement, sans aucune configuration ni installation… et oui Mesa intègre le support des GPU AMD.

      Donc je suppose qu’il parle du libre. =)

      Il n’y a aucun intérêt à utiliser le pilote non-libre, à moins de travailler pour des pousses-papier qui ont écrit telle ou telle procédure impliquant de télécharger le pilote corporate du constructeur, auquel cas le pilote propriétaire serait seul à satisfaire l’indicateur associé quand bien même le pilote libre serait mieux à même de satisfaire les besoins réels… Ou à moins de requérir un bug spécifique du pilote propriétaire en tant que fonctionnalité…

      Vraiment. Il n’y a plus vraiment de raison de ne pas utiliser le pilote libre.

      Avec Unvanquished par exemple le pilote libre est simplement deux fois plus performant que le pilote propriétaire (le pilote propriétaire a les performances du pilote libre d’il y a 4 ans).

      Pour résumer l’état des lieux :

      Dans tous les cas, il faut utiliser le pilote noyau amdgpu libre (inclus dans le noyau Linux, livré avec la distrib).

      Avec ça il y a deux pilotes OpenGL possible (on peut installer soit l’un, soit l’autre sur le même pilote noyau, mais pas en même temps) :

      • radeonsi (Mesa développé avec AMD, libre, carrément meilleur, et recommandé par AMD, livré avec la distrib)
      • amdgpu-pro (AMD, propriétaire, pour les pousse-papier grand-prêtres des indicateurs)

      Avec ça il y a trois pilotes Vulkan (installable en même temps, du moins pour radv et amdvlk, on peut les installer simultanément, c’est pratique si l’un est plus efficace pour telle ou telle application) :

      • radv (Mesa, libre, livré avec la distrib)
      • amdvlk (AMD, libre)
      • amdgpu-pro amdvlk (AMD, propriétaire je crois, car peut avoir quelques fonctionnalités avant que ça n’arrive dans les dépôts)

      Avec ça il y a quatre pilotes OpenCL (installable plus ou moins en même temps, mais ça ne fait pas beaucoup sens pour certains qui visent différentes générations de carte):

      • libclc-gcn (Mesa, libre, mais pas encore prêt pour certains usages type traitement photo avec DarkTable, deux fois plus rapide que Orca sur LuxMark)
      • amdgpu-pro Orca (AMD, propriétaire, pour d’anciennes cartes type GCN1 et GCN2)
      • amdgpu-pro PAL (AMD, propriétaire, pour d’anciennes cartes type GCN3)
      • ROCm (AMD, libre, pour les cartes actuelles)

      Avec ça il y a des pilotes libres VA-API et VDPAU (déprécié au profit de VA-API) pour le codage/décodage de vidéo sur le GPU.

      Par exemple, comme j’ai une R9 390X (GCN2), j’ai les paquets suivants sur ma machine:

      • linux-image-generic (amdgpu, noyau)
      • libgl1-mesa-dri (radeonsi, OpenGL)
      • mesa-vulkan-drivers (radv, Vulkan)
      • amdvlk (Vulkan)
      • mesa-opencl-icd (libcl-gcn, OpenCL)
      • opencl-orca-amdgpu-pro-icd (Orca, OpenCL)
      • mesa-va-drivers (VA-API)
      • mesa-vdpau-drivers (VDPAU)

      Seul opencl-orca-amdgpu-pro-icd n’est pas libre (et c’est parce que j’ai une carte désormais vieille selon AMD).

      Tuto pour Ubuntu (à adapter selon la distro, à faire en root après sudo -s):

      Note: je n’ai pas installé de distro Ubuntu depuis un LiveCD/USB depuis une décennie bien que je l’utilise tous les jours (j’utilise debootstrap pour installer… ou je mets simplement à jour l’existant), il est très probable que mesa-vulkan-drivers soit installé par défaut désormais… Donc ces instructions sont vraiment pour les gens qui veulent faire plus que jouer.

      # radv vulkan, mesa opencl, va-api, vdpau…
apt-get install mesa-vulkan-drivers mesa-opencl-icd va-driver-all vdpau-driver-al

# outils pour voir si ça marche (glxinfo, vulkaninfo…)
apt-get install mesa-utils vulkan-tools vainfo vdpauinfo

# amdvlk vulkan, rocm opencl
wget -q -O - https://repo.radeon.com/amdvlk/apt/debian/amdvlk.gpg.key | apt-key add -
wget -q -O - https://repo.radeon.com/rocm/rocm.gpg.key | apt-key add -

cat > /etc/apt/sources.list.d/radeon.list <<\EOF
deb [arch=amd64] http://repo.radeon.com/amdvlk/apt/debian/ bionic main
deb [arch=amd64] http://repo.radeon.com/rocm/apt/debian/ ubuntu main
EOF

apt-get update
apt-get install rocm-opencl amdvlk

      Il y a aussi des paquets rocm-dkms et rocminfo pour des choses plus avancées.

      Bref, merci AMD de jouer le jeu du libre. Ce serait dommage d’acheter du Nvidia en effet… J’ai aussi acheté du Nvidia au début quand il fallait choisir entre le pilote propriétaire Nvidia et le pilote propriétaire ATI fglrx… Mais depuis 2008 (et le pilote libre radeonhd), je suis passé sous ATI/AMD.

      Sur mon poste principal j’ai eu une HD 2600 PRO AGP (TeraScale), puis une HD 7970 (GCN1) et j’ai actuellement une R9 390X (GCN2). Sur mon serveur j’ai une R7 (240-2GD5-L, GCN1), dans l’APU de mon NAS de sauvegarde une autre R7 mais pas de même génération (RX-421BD, GCN3), et une RX Vega 3 (R1606G, GCN5) dans l’APU d’une… Atari VCS.

      J’ai toujours du Intel et du Nvidia dans mon portable (Thinkpad), mais j’ai toujours acheté mes ordinateurs portables d’occasion. Dernier processeur Intel acheté neuf ? un Pentium 4. Dernière carte graphique Nvidia acheté neuve ? Une Geforce 6600 AGP. Ça nous ramène à 2004~2005 ou quelque chose comme ça. Aucun regret. Premier AMD64 autour de 2006 et première ATI/AMD en 2008, ça ne me rajeunit pas. =)

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Pilote ?

        Posté par  (Mastodon) . Évalué à 6. Dernière modification le 02 juin 2021 à 08:26.

        Ah bin tiens tu tombes bien toi qui a l'air d'avoir compris 2-3 trucs :)

        J'ai dans mon salon (enfin, mon garage avec un câble qui traverse le mur) un serveur Debian qui me sert de NAS mais également de media center sous KODI. Actuellement je fais avec le GPU intégré du Core-i3, mais vu que je vise de passer à la 4K bientôt, je me posais la question de mettre une carte video, et je partais à priori sur du AMD.

        Tu saurais me dire quel modèle je peux chercher d'occase sachant que mon seul critère est le support matériel du décodage vidéo en 4K (et pas du tout les perfos 3D) ? Dans quelle génération je peux taper les yeux fermés ?

        Merci d'avance :)

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Pilote ?

          Posté par  (site web personnel) . Évalué à 5.

          En fait je ne me suis jamais préoccupé de l’accélération matérielle en lecture. En général mes ordis s’en sortent bien comme ça, c’est vrai qu’il y a peut-être moyen d’économiser de l’énergie, mais je n’ai jamais vraiment investigué dans ce sens.

          Ce qui m’intéresse c’est pour l’encodage, surtout que dans mon cas ça m’a même permis d’aider à la stabilité de mon système.
          Il y a par exemple dans Kdenlive un profile communautaire nommé “mp4-vaapi”, il s’appelle (mal nommé) “Export to mp4 with vaapi intel accelleration”, mais ce profile n’est pas du tout spécifique à Intel. Dès lors que vous avez un pilote va-api compatible ça marche. J’ai pu le tester avec succès sur du Radeon et du Intel en effet. Je m’en sers autant que possible pour tout ce qui est clip intermédiaire. Au delà de l’éventuel gain en temps, cela laisse surtout mon CPU complètement libre ce qui me permet de faire d’autres tâches pendant que j’encode (par exemple faire le montage d’autre chose).

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Pilote ?

            Posté par  . Évalué à 4.

            En tuant un moucheron sur l'écran de mon téléphone, j'ai inutilé ton commentaire… Désolé :-|

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Pilote ?

        Posté par  . Évalué à 6.

        Il n’y a aucun intérêt à utiliser le pilote non-libre

        C'est vrai 99% du temps mais j'ai trouvé au moins un cas où le pilote propriétaire a un intérêt : le support du Ray Tracing.

        Intérêt encore limité, à ma connaissance seuls 2 jeux natifs l'utilisent : Quake II RTX et Metro Exodus. Wine supporte le RTX selon l'implémentation, si c'est l'implémentation Nvidia, ça ne fonctionnera que sur un du matériel Nvidia. Mais le RTX fonctionne à travers Wine sur Ghostrunner et Control avec un GPU AMD supportant le Ray Tracing (donc 6700/6800/6900 XT uniquement).

        Dans tous les cas, la fonctionnalité finira par arriver dans le pilote libre tôt ou tard.

        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

      • [^] # Re: Pilote ?

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 02 juin 2021 à 19:37.

        Pour Thomas : On serait fortement intéressé pour avoir un coup de main sur les drivers video et les jeux sous Linux dans le cadre d'un projet de serveur de jeux en client léger.

      • [^] # Re: Pilote ?

        Posté par  (site web personnel) . Évalué à 3.

        J’ai oublié de préciser un truc, quand on installe à la fois radv et amdvlk, on peut choisir quel pilote utiliser avec cette variable d’environnement :

        AMD_VULKAN_ICD=RADV

        ou

        AMD_VULKAN_ICD=AMDVLK

        Par défaut c’est amdvlk si les deux sont installés.

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Pilote ?

          Posté par  (site web personnel) . Évalué à 3.

          Par exemple avec mon poste de travail (Radeon R9 390X) :

          radv :

          $ AMD_VULKAN_ICD=RADV vulkaninfo | egrep '^GPU[0-9]*:' -A 9
GPU0:
VkPhysicalDeviceProperties:
---------------------------
    apiVersion     = 4202641 (1.2.145)
    driverVersion  = 88080385 (0x5400001)
    vendorID       = 0x1002
    deviceID       = 0x67b0
    deviceType     = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
    deviceName     = AMD RADV HAWAII (ACO)

          amdvlk :

          $ AMD_VULKAN_ICD=AMDVLK$ vulkaninfo | egrep '^GPU[0-9]*:' -A 9
GPU0:
VkPhysicalDeviceProperties:
---------------------------
    apiVersion     = 4202675 (1.2.179)
    driverVersion  = 8388797 (0x8000bd)
    vendorID       = 0x1002
    deviceID       = 0x67b0
    deviceType     = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
    deviceName     = AMD Radeon (TM) R9 390 Series

          Avec l’Atari VCS (Radeon RX Vega 3) :

          radv :

          $ AMD_VULKAN_ICD=RADV vulkaninfo | egrep '^GPU[0-9]*:' -A 9
'DISPLAY' environment variable not set... skipping surface info
GPU0:
VkPhysicalDeviceProperties:
---------------------------
    apiVersion     = 4202627 (1.2.131)
    driverVersion  = 83894278 (0x5002006)
    vendorID       = 0x1002
    deviceID       = 0x15d8
    deviceType     = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
    deviceName     = AMD RADV RAVEN2 (ACO)

          amdvlk :

          $ AMD_VULKAN_ICD=AMDVLK$ vulkaninfo | egrep '^GPU[0-9]*:' -A 9
GPU0:
VkPhysicalDeviceProperties:
---------------------------
    apiVersion     = 4202675 (1.2.179)
    driverVersion  = 8388797 (0x8000bd)
    vendorID       = 0x1002
    deviceID       = 0x15d8
    deviceType     = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
    deviceName     = Unknown AMD GPU

          ce commentaire est sous licence cc by 4 et précédentes

  • # Ironie

    Posté par  (site web personnel) . Évalué à 8.

    Perso j'ai quitté AMD car il était devenu difficile d'avoir un système libre (i.e. sans driver propriétaire) sur cette plateforme. Sans être fan d'Intel, les plateformes Intel ont considérablement simplifié ces 10 dernières années la vie des libristes qui cherchent à s'équiper sans être expert de chaque référence de puce.

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Ironie

      Posté par  . Évalué à 8.

      La plateforme, oui, mais le GPU, y a pas photo. OK, les GPU intégré d'Intel marchent avec des pilotes libres, mais les GPU intégré d'AMD (pour comparer ce qui l'est) sont bien, bien meilleurs.

    • [^] # Re: Ironie

      Posté par  (site web personnel) . Évalué à 7.

      Perso j'ai quitté AMD car il était devenu difficile d'avoir un système libre

      Ce n'est plus vrai aujourd'hui, depuis quelques années tu peux être en full foss pour utiliser du AMD (contrairement à Nvidia, les drivers ne sont pas libres et distribués en binaires, et sans le driver Nvidia, adieu les jeux).

    • [^] # Re: Ironie

      Posté par  (Mastodon) . Évalué à 5.

      Tu parles de quoi? Du chipset (jamais eu besoin de driver pour ça)? Des cartes sons, ethernet, raid et wifi intégrées? En général ça n'a rien à voir avec AMD qui n'était pas propriétaire de ces éléments mais aux choix plus ou moins heureux des différentes marques de cartes mères.

      • [^] # Re: Ironie

        Posté par  (site web personnel) . Évalué à 4.

        Des cartes sons, ethernet, raid et wifi intégrées? En général ça n'a rien à voir avec AMD qui n'était pas propriétaire de ces éléments mais aux choix plus ou moins heureux des différentes marques de cartes mères.

        Beh si, ça a à voir que Intel a fourni une solution intégrée pour le son, l'ethernet, le wifi, la carte graphique (je ne joue pas), etc. qui était bien supporté en libre (hors wifi qui nécessite son firmware fermé).

        En comparaison, AMD == Jungle hasardeuse pour l'acheteur que j'ai été. Parce que justement dans le cas d'un proc AMD ces éléments étaient plus systématiquement soumis aux choix plus ou moins heureux des différentes marques de cartes mères.

        NB: chipset == « jeu de puces »

        Adhérer à l'April, ça vous tente ?

      • [^] # Re: Ironie

        Posté par  . Évalué à 3. Dernière modification le 04 juin 2021 à 10:10.

        Ne serai-ce que pour les ports USB3, j'ai toujours eu besoin de drivers pour le chipset (Intel Z87 avec microprocesseur Core i5-4570).
        D'ailleurs j'ai acheté ce PC quelques mois après la sortie de ces composants, il a fallu que je passe (temporairement) sur Fedora pour avoir un noyau qui intègre les drivers.

        Pareil pour l'USB3 sur mon ordinateur portable.

        Les vrais naviguent en -42

  • # C'est le watt que j'préfère

    Posté par  . Évalué à 4.

    Ce qui m'ennuie avec AMD, c'est la consommation à performance égale avec Nvidia.

    Ils ont fait beaucoup de progrès (surtout dans les CPU+APU). Mais…
    une carte graphique AMD consomme 30% de plus que l'équivalent Nvidia.
    Je précise n'avoir regardé que le milieu de gamme (cartes entre 200 et 300€).

    Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr

  • # Nostalgie quand tu nous tiens ...

    Posté par  (site web personnel) . Évalué à 3.

    Très interressant ton journal, cela m'a donné envie de regarder de plus près Steam …

    Et j'ai essayé de me rappeller de mes anciennes machines :
    Voici la liste des machines que j'ai possédées :

    • Texas Instrument Ti 57 47 pas/octets pour la programmation
    • Sinclair ZX 81 1Ko de RAM
    • Commodore Vic 20 3,5 Ko de RAM
    • Commodore 64 64Ko de RAM 38911 Bytes Free …
    • Amiga 500 512Ko de RAM
    • PC 386 sous SCO Unix (et W3.1 je crois) 8 Mo de RAM quand même
    • Gateway Pentium 100 16 mo RAM W95 en Dual Boot Linux RedHat 3 sur Diskette (je crois) Lecteur CD
    • Assemblage PC Multi Boot SCO / Windows / Linux Lecteur DAT (Recup) Lecteur CD
    • Assemblage PC Multi Boot Windows / Linux 512 Mo Lecteur + Graveur CD
    • Gateway PC 1 Go RAM Graveur DVD

    depuis quelques années j'utilise le portable du bureau en dual boot, le dernier est sous Linux Mint 19.3 et a une partition W7 qui me sert à jouer uniquement, a quelques jeux en ligne quand une envie irrépressible me prend.

    Mais je vais regarder Steam de plus près … et si possible recupérer l'espace disque gaspillé par W7

    • [^] # Re: Nostalgie quand tu nous tiens ...

      Posté par  . Évalué à 3.

      Merci !

      A savoir que tous les jeux non-natifs ne fonctionneront pas avec Wine/Proton. J'utilise pour ça la base de données utilisateurs ProtonDB qui recense les tests des joueurs et parfois quelques astuces pour des jeux un peu récalcitrants.

      Le problème bloquant principal étant très souvent le client anticheat, comme je l'ai évoqué dans un commentaire sur un autre journal traitant du sujet.

      Même si je suis un joueur passionné, j'accepte de passer à côté de certains jeux. Aujourd'hui notre système d'exploitation préféré a à disposition une ludothèque franchement impressionnante, il y a 10 ans c'était encore au stade du rêve, et une vie entière ne me suffira de toute façon pas à jouer à tous les jeux disponibles.

      Je l'ai souvent répété ici : Valve (Steam) a fait d'énormes efforts pour rendre le jeu vidéo sous Linux accessible et agréable et même si l'entreprise est critiquable a bien des égards, il est indéniable que sans leur impulsion le jeu vidéo ne se porterait pas aussi bien sous Linux aujourd'hui. Ca ne représente pourtant même pas 1% de leur part de marché mais malgré tout ils ne considèrent pas notre système comme un OS de seconde zone.

      La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # libre depuis 2007

    Posté par  . Évalué à 3.

    Entre temps, AMD a libéré ses drivers>

    Oui depuis 2007 donc avant ton premier PC ;P

    Mais pour avoir connu ça avec ma Radeon HD 3850, les six premiers mois c’était pas utilisable (juste afficher un menu d'une application gtk-2 c'était laborieux). Après un 1 ans c'était utilisable pour tout ce qui était applicatif 2D et les vidéos était enfin correctement afficher.

    La parti 3D ça a était plus compliqué, quand j'ai changer ma 3850 par une autre radeon (mais aucune idée du modèle mais c'était 3-4 ans plus-tard), il y avais le support des dernières version d'opengl et d'une grand partie de leurs instructions. Niveaux perf c'était utilisable mais clairement moins bon que sous Windows.

    Depuis j'ai changer encore deux fois pour des radeons, et l'écart de performance avec Windows c'est bien réduit, mais avec des petit surprise pour certain jeux ; exemple j'avais un jeux inutilisable sous linux (sous Windows aucun problème) après une mise à jour de Mesa je suis passé à 60fps et tout à font. La raison une petite optimisation dans Mesa qui devais faire gagné que quelle-que % de perf en plus.

    • [^] # Re: libre depuis 2007

      Posté par  . Évalué à 4. Dernière modification le 02 juin 2021 à 15:45.

      Concernant la libération du pilote AMD, j'avais effectivement un doute dans la chronologie et je pensais que c'était un peu moins ancien que ça. Au doigt mouillé j'aurai dit autour de 2010/2011.

      J'ai suivi d'assez loin l'évolution de ses performances et c'est resté assez longtemps mauvais, comme ton commentaire semble le confirmer.

      J'ai aussi régulièrement lu qu'il y avait parfois des problèmes avec le driver AMD sur certains jeux. Notamment des artéfacts qui rendaient les dits-jeux inutilisables.

      Actuellement je n'ai rencontré aucun problème, ni de performance, ni d'artéfacts. Je ne sais pas si j'ai eu de la chance jusqu'ici ou si le driver est enfin arrivé à maturité. Mais c'est vrai qu'entre l'idée que je m'en faisais jusqu'ici et la réalité, j'ai été agréablement surpris de constater qu'AMD avait fait de très gros progrès et j'ai fait ce journal pour justement essayer d'inverser un peu l'idée, toujours assez tenace, que les drivers et les GPU AMD étaient à la traîne. Ce n'est plus vrai, pour le plaisir des joueurs (et des libristes !).

      Merci pour ton retour d'expérience sur du matériel AMD qui semble confirmer ce que je lisais à l'époque.

      La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

      • [^] # Re: libre depuis 2007

        Posté par  (site web personnel) . Évalué à 8.

        Concernant la libération du pilote AMD, j'avais effectivement un doute dans la chronologie et je pensais que c'était un peu moins ancien que ça. Au doigt mouillé j'aurai dit autour de 2010/2011.

        ATI a été racheté par AMD en 2006 il me semble, et il me semble qu’AMD a commencé à publier de la documentation vers 2007-2008, mais pas encore du code, au début.

        Je peux retrouver un message de moi en 2008 sur Phoronix suivi d’un commentaire de John Bridgman (employé AMD) qui disait “On the Linux side, we are going to update the release notes in the next driver to make it clear that AGP support for HD2xxx parts is not yet there[…]” alors que je venais de parler du pilote libre RadeonHD qui fonctionnait avec ma HD 2600 PRO AGP, il semblait donc parler du pilote propriétaire de l’époque (fglrx) et pas du pilote libre.

        Peut-être que ton souvenir de 2010/2011 pourrait correspondre à leur éventuelle implication dans Mesa (je ne me souviens plus quand ils s’y sont mis) ?

        Je ne sais pas quand AMD a commencé à écrire du code, s’ils ont été impliqués dans RadeonHD autrement qu’en publiant leur documentation, mais très vite ils ont commencé à écrire du code dans le noyau et dans Mesa. Il y a quelques années un changement important a été initié avec le pilote historique radeon ayant été forké (à l’intérieur de l’arborescence du noyau) en amdgpu pour servir de base non seulement au pilote Mesa mais aussi au remplaçant de fglrx: amdgpu-pro. Il peut encore exister des pilotes noyaux tiers (généralement installé avec DKMS) dans amdgpu-pro or rocm, mais il s’agit toujours de livrer le code et les fonctionnalités avant que Linux ne l’intègre officiellement.

        J‘avais écrit une dépêche en 2016 sur le sujet des pilotes graphiques, et j’y retrouve que l’initiative amdgpu avait été annoncée en 2014 et livrée en 2015. Ils étaient donc déjà fortement impliqués dans le pilote Linux radeon et le pilote Mesa radeonsi depuis plusieurs années à ce moment-là.

        l'idée, toujours assez tenace, que les drivers et les GPU AMD étaient à la traîne

        Clairement, les pilotes AMD sous Linux sont de très bonne qualité aujourd’hui.

        Une chose à savoir, certaines personnes recommandent de ne pas se jeter trop rapidement sur les nouvelles générations de cartes, mais ce problème est généralement lié au cycle de développement de certains logiciels libres : il faut que le noyau Linux et Mesa soit non-seulement stabilisé mais aussi empaqueté et distribué dans les distributions (c’est là que le pilote amdgpu-pro pourrait parfois dépanner). Donc si on achète les nouvelles générations avec quelques mois de délai, c’est magique : on branche la carte dans le PC et c’est terminé.

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: libre depuis 2007

          Posté par  (site web personnel) . Évalué à 4.

          Ça doit bien faire depuis 2008 que j'utilise exclusivement les driver libres AMD/Radeon. Au début ça marchait pas top, mais depuis au moins Debian 9 les performances et la stabilité sont au rendez-vous.

          En effet il vaut peut-être mieux utiliser la génération précédentes de cartes, la stabilité s'améliorant au fil du temps.

          J'ai eu un instabilité chronique de mon système pendant quelques temps avec un CPU AMD, résolue en passant à un CPU Intel. Donc pour l'instant je considère le couple CPU Intel/GPU AMD comme le plus adapté sous Linux.

          Dommage que AMD conserve une mauvaise réputation pour ses GPUs sous Linux, alors que c'est clairement mieux que NVidia depuis quelques temps déjà.

  • # Le multi GPU, ce fléau

    Posté par  (site web personnel) . Évalué à 6.

    Je n'ai toujours pas compris l'intérêt du multi GPU. Ça crée tellement de soucis (pas seulement sous Linux, Windows est aussi est à la ramasse régulièrement) pour résoudre heu ben je ne sais pas trop quel était le problème à la base.

    Il me semble que l'idée est de changer de GPU selon l'usage pour économiser de la batterie, mais franchement les batteries sur PC de jeu moderne, c'est de la blague, ça sert juste à le transporter d'une pièce à l'autre sans l'arrêter.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Le multi GPU, ce fléau

      Posté par  . Évalué à 5.

      C'est pour quand tu as plusieurs usages sur une même machine. Par exemple 6 heures dans un éditeur de texte, et 2 heures dans un jeu (ou dans Blender).

      Ceci dit, c'est clair que c'est très très pénible. Ma solution a été de de toujours passer par le GPU NVidia qui se sert du Intel pour passer les pixels à l'écran. Du coup, ça consomme plus que la NVidia seule :(.

      L'idéal serait d'avoir des modes d'économie d'énergie plus efficaces sur les gros GPUS, ce qui permettrait de pouvoir se passer de ces double GPUs.

      • [^] # Re: Le multi GPU, ce fléau

        Posté par  . Évalué à 5.

        Pas sûr qu'Intel ait envie de vendre des CPU mobiles sans GPU.

        « 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

  • # Lien cassé

    Posté par  . Évalué à 4.

    Le lien : PCSpecialist ne fonctionne pas.

    • [^] # Re: Lien cassé

      Posté par  . Évalué à 3.

      Oups en effet, j'ai raté mon copier-coller.

      Le lien est : https://www.pcspecialist.fr/

      Si quelqu'un de la modération peut le corriger, ce serait sympa svp :).

      La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.