En attendant le lancement de nouveaux GPU, AMD continue de peaufiner ses pilotes. Les Radeon RX 5000 peuvent ainsi profiter de SAM, alors que des optimisations sont introduites pour de nouveaux jeux.
AMD vient de publier ses premiers pilotes de septembre. Si l'on s'attendait à une compatibilité avec Windows 11, évoquée par certains confrères, il n'en est pas fait mention dans les notes de version. Il faudra donc encore attendre.
On a tout de même droit à quelques nouveautés, comme le support du jeu Deathloop ou de la bêta ouverte de Call of Duty Vanguard. Quatre nouvelles extensions Vulkan sont également gérées désormais. Outre les habituels correctifs, une fonctionnalité s'étend : Smart Access Memory (SAM). Elle est accessible aux Radeon RX 5000 désormais.
Pour rappel, il s'agit du nom donné par AMD au Resizable BAR du PCI Express. Introduit sur les Radeon RX 6000 et les processeurs Zen 3, il était au départ très contraignant. Mais face à Intel et NVIDIA qui avaient une approche plus ouverte, le constructeur a peu à peu relâché ses limitations. On peut ainsi profiter de SAM sur les Ryzen 3000 depuis mars et désormais sur les RX 5000. Rien n'a été précisé concernant les générations antérieures.
Commentaires (14)
On a une idée du potentiel gain de perfs que ça peut amener ? J’ai du mal à trouver des ressources sur le sujet. J’imagine aussi qu’il faut un Windows à jour pour en profiter (vivement la nouvelle LTSC que je rafraîchisse tout ça)
C’était le cas aussi sous Windows 11 (pilote WDDM 3.0) depuis la première version de test distribuée par Microsoft.
Pour les pilotes Windows 11 justement, ce pourrait-il qu’AMD fasse le choix d’une distribution via WU uniquement ? Depuis la disponibilité de Windows 11 pour les Insiders, le pilote AMD a été mis à jour 4 ou 5 fois via WU.
Pour info, sous Windows 11, les pilotes WU sont installés de force avec possibilité pour certains d’entre eux de repasser à une version plus ancienne via les Mises à jour facultatives en cas de problème. C’est du coup plus simple pour un simple utilisateur. Mais par contre, ça vient écraser une installation manuelle, d’où ma question.
Une dizaine de % max. Chez moi, sur FFXIV, réglages à fond en 4K, je suis passé de 42IPS à 46IPS en moyenne. Ca permet à mon écran FreeSync de rester plus souvent dans une plage qu’il supporte (> 40IPS).
Non, et je ne vois aucun constructeur s’aventurer à un tel choix. Même si la part de distribution via WU augmente mécaniquement au fil du temps.
Tu aura au début quelques gain et puis tu n’en aura plus. Ce que permet cette techno c’est juste de pouvoir un peu mieux surcharger la carte graphique. C’est le genre de délire qu’ont devrait avoir depuis plusieurs années sur pc mais c’est retrouvé bridé à cause des consoles.
Pas vraiment. Les consoles actuelles et précédentes ont une mémoire unifiée (une seule mémoire qui fait office de RAM centrale et RAM vidéo), ce qui rend inutile le SAM / resizable BAR. Pour rappel, le SAM permet d’augmenter la taille de la “fenêtre” (qté de données, ~256Mo en ce moment) permettant de transférer de la mémoire centrale vers la mémoire vidéo. Les consoles (et le chip M1 d’Apple, il a aussi une mémoire unifiée) n’ont donc plus ce problème depuis au moins 2 générations, elles.
C’est le PC, et surtout nVidia et AMD qui ont traîné la pâte, et essaient aujourd’hui de faire passer ce standard comme une techno semi-proprio. Techniquement, la limitation est purement commerciale et semble destinée à faire vendre des nouveaux CPU et GPU.
Bonne nouvelle ça ! On sait si ça a été intégré dans les drivers Linux ? :)
C’est bien mais faut passer la carte mère en UEFI.
Et avec mes 2 distros Linux et le Win10 non signés, je l’ai dans le dos. Et non, je n’irai pas vers des noyaux signés, c’est trop la plaie à mettre à jour.
Tu confonds pas UEFI et Secure Boot par hasard ?
On pourrait mais non en fait.
Quand j’active le SAM sur la carte mère (msi x570-a-pro), le boot passe automatiquement de CSM en UEFI (le secure boot reste à sa valeur précédente CàD désactivé). Bref, avec ça, je perds tous les périphériques de boot « non UEFI ».
Au final, il va falloir que je regarde pour me prendre un autre SSD (plus gros parce que Steam ça mange un peu quand même) que je mettrai en GPT / UEFI. Le plus pénible sera de mettre au point l’environnement de compilation pour générer des noyaux signés : j’utilise toujours les derniers noyaux sortis sur kernel.org
Ceci dit à voir si les noyaux « unsigned » démarrent avec le secure boot à off.
Comme dit, Secure Boot n’est pas obligatoire en UEFI, tu peux l’activer ou pas, ça n’a rien à voir, donc il n’y a aucunr rapport entre UEFI et la signature de ton noyau (mais SB nécessite UEFI).
Je suis en UEFI et j’ai rien signé du tout, c’est absolument pas nécessaire si tu n’actives pas Secure Boot.
Pour information (et j’en ai parlé à Eldeberen sur un autre canal), c’est déjà intégré depuis longtemps dans les pilotes Linux libres (AMDGPU), et cerise sur le gâteau, déjà compatible avec tout un tas de matos. Ça marche même sur ma machine avec un Ryzen 2600X et une RX 590, même si ça n’a probablement aucun intérêt vu que je doute que ça soit réellement exploité sur ce matos (en tout cas je n’ai vu aucune différence de performances, en bien comme en mal, mais dmesg indique bien un BAR de la même taille que ma VRAM, 8192M de mémoire, alors qu’avant que je l’active dans le BIOS le BAR restait à 256M).
https://wiki.archlinux.org/title/Improving_performance#Enabling_PCI_Resizable_BAR
Bref, je suis bon pour tout réinstaller en GPT/UEFI/noSB … « trop vieux pour ces conneries ! »