La carte graphique minimum dont on a besoin pour émuler une PS3 est sortie... après la PS3. C'est AniLeo et kd-11, de l'équipe RPCS3 , qui viennent de descendre le minimum officiel de l'émulateur à la Radeon HD 2900 XT, sortie en mai 2007. La PS3, elle, arrivait en France en mars de la même année.

Certes, c'est moins de deux mois d'écart mais pour émuler une console, en général, on a besoin de matériel largement postérieur.

RPCS3 accepte donc maintenant les Radeon HD 2000, 3000 et 4000, la première génération TeraScale d'ATi. Le plancher précédent, c'était la HD 5550. Deux conditions quand même : ça ne marche que sous Linux, avec le pilote libre Mesa r600. Windows reste dehors, le vieux pilote d'AMD étant trop bancal pour l'émulateur.

Maintenant, ce qui bloquait vraiment n'était pas la puissance. L'émulateur tenait pour acquis que toutes les cartes qu'il supporte savent faire un certain type d'écriture en mémoire. Ces vieilles Radeon ne savent pas, et personne n'avait prévu le cas, alors l'affichage plantait dès le démarrage, sur un pointeur nul... snif. Le correctif consiste donc à vérifier si la carte sait le faire, et à s'en passer quand ce n'est pas le cas. Et voilà, une pull request plus tard et c'était du tout bon pour la Radeon HD 2900 XT !

Reste que la plus musclée de ces vieilles puces, la HD 4890 de 2009 avec son gigaoctet de mémoire, donne des résultats à géométrie très variable. Sur les captures de l'équipe, OutRun Online Arcade tourne entre 52 et 59 fps, et Metal Gear Solid HD Collection oscille entre 45 et 60 selon la densité de la scène. Jusque-là, ça va.

Par contre, la démo de FIFA 08 tombe à 15 fps, et le jeu Rain à 15 aussi, et là c'est la cata. Cette HD 4890 est pourtant plusieurs fois plus puissante que le RSX, la puce graphique de la PS3, mais ça ne suffit pas, parce que l'émulateur lui refile du boulot que la console ne lui demandait pas, comme décoder les textures à la place du processeur. Et surtout, parce que la mémoire n'est pas rangée pareil.

Sur PS3, la mémoire vidéo et la mémoire système sont bien deux réservoirs séparés, sauf que les jeux ont le droit de piocher directement dans les deux. Tout est à portée de main. Sur PC, les deux sont vraiment cloisonnés, du coup l'émulateur passe son temps à recopier les données de l'un vers l'autre.

En descendant dans la gamme, la sanction est immédiate. La HD 3870 doit tomber à 273p, l'équivalent d'une PSP, pour afficher les jeux les plus simples. La HD 2600 XT, elle, plafonne à 12,9 fps sur Portal à cette même définition. Bref, ça ne sert plus à rien de descendre plus bas, celle-là est carrément plus faible que la puce de la console qu'elle est censée émuler.

Côté manipulation, il faut mentir au pilote. Ces cartes annoncent une version d'OpenGL trop ancienne, et l'émulateur refuse de démarrer tant qu'il la voit. Deux variables d'environnement au lancement suffisent à lui faire croire le contraire :

MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=440 ./rpcs3.AppImage

Et si ça plante encore, l'équipe conseille de basculer le réglage Shader Mode sur "Legacy Recompiler".

Je vous parlais de RPCS3 en 2021 quand il servait surtout à rendre les vieux jeux plus beaux avec le FSR d'AMD et voilà maintenant qu'il sait les faire tourner sur du matériel de leur époque.

Le billet de l'équipe , que je vous invite à lire, détaille les réglages et les résultats carte par carte. Si vous avez une TeraScale au fond d'un placard, vous savez quoi en faire.

La Steam Machine de Valve vient à peine d'arriver dans les salons que le youtubeur ETA Prime l'a déjà éventrée sur son établi. Et je sais pas vous, mais moi j'ai bien envie de voir ça avant de lâcher les 1039 euros qu'elle va couter. Ce petit cube vient de sortir d'usine avec ses 16 Go de mémoire et un SSD de 512 Go ou 2 To, et la vraie question que tous les geeks se posent c'est ... roulements de tambour ... : Est-ce qu'on peut l'ouvrir et bidouiller dedans ?

ET BIEN OUI ! Et c'est même plus facile que ce que vous pensez !!!

Tout commence donc avec deux vis T8 à l'arrière (qui ne tombent pas, elles restent solidaires du châssis, c'est qualiiii) et quatre autres sous les pieds. La façade avant, elle, tient juste avec des aimants.

Un coup de spudger , on fait coulisser tout le bloc hors de sa coque en plastique, et là vous tombez sur un gros radiateur en aluminium avec ses caloducs en cuivre, une alimentation intégrée, et la carte mère prise en sandwich au milieu. C'est propre et ça permet d'éviter le gros bloc d'alim qui traine sous la TV.

Le slot M.2, les ports USB avant, le lecteur SD, les USB arrière et l'Ethernet sont montés sur des petites cartes filles reliées par des nappes, ce qui rend le tout très modulaire. Ainsi, si le connecteur USB vous lâche dans 2 ans, bah y'a juste qu'à remplacer le module concerné et basta !

Même le Wi-Fi et le Bluetooth, soudés sur la carte d'entrées-sorties avant, se changent en remplaçant ce seul bloc. Notez que le seul élément un peu fermé, c'est le ventilateur car il est custom, dessiné spécifiquement pour la machine, donc oubliez votre rêve de coller un Noctua à la place. Et pour accéder à la RAM, par contre, il faut sortir le ventilateur et son carénage, débrancher les antennes Wi-Fi, puis dégager le radiateur.

Bonne nouvelle aussi, y'aura pas besoin de refaire la pâte thermique puisque la carte mère se soulève d'un bloc pour libérer les deux emplacements SO-DIMM en dessous. Valve n'en utilise qu'un seul d'origine, avec une barrette de 16 Go en DDR5 à 5600 MT/s, en single channel. ETA Prime a viré ça pour deux barrettes Crucial de 32 Go, soit 64 Go au total.

Au reboot, SteamOS Holo lui a par contre affiché 62 Go de mémoire système (?). Et pour le stockage, le SSD d'origine est un format court 2230 , mais il y a la place pour un 2280 classique. Du coup notre Youtubeur y a mis un Kingston Fury Renegade de 4 To, cloné depuis le disque d'usine avec Etcher pour garder ses jeux et son compte.

La barrette SO-DIMM DDR5 d'origine, à côté des Crucial de 32 Go

Côté tripes, le menu système le confirme bien... La bête contient un AMD Custom CPU 1772 en architecture Zen 4, six cœurs et douze threads à 4,86 GHz, accompagné d'un GPU RDNA 3 (un Navi 33, pour les curieux) avec 8 Go de VRAM. Malheureusement (et là, vous allez chialer), ces 8 Go de mémoire vidéo sont soudés et donc non extensibles. Donc même avec 64 Go de RAM système, vous ne gagnerez quasiment rien en jeu, puisque c'est la VRAM qui fait le boulot graphique. C'est couillon...

Le menu système après upgrade : 62 Go de RAM, mais toujours 8 Go de VRAM

Cela signifie que vu les prix de la RAM en ce moment, ça ne vaut pas le coup de l'upgrader sur la Steam Machine. Les 16 Go d'origine suffisent largement pour la plupart des gens (Le prix de la mémoire était justement une des raisons pour lesquelles la Steam Machine coûte plus cher qu'une PS5 Pro, haha).

Pareil pour le SSD, payer un M.2 4 To, c'est se faire mal au portefeuille pour rien alors qu'un disque dur externe USB de 5 To coûte trois fois moins cher. Un peu plus lent au chargement, certes, mais c'est largement suffisant pour stocker votre ludothèque.

Mais je suis quand même content de voir que Valve a sorti une vraie machine ouverte, réparable avec un simple tournevis, là où la concurrence nous soude tout comme des déglingos et interdit le moindre accès.

Merci à ETA Prime pour le démontage en règle !!

Source : la vidéo d'ETA Prime

L' ordonnanceur du noyau Linux vient de recevoir une proposition de mise à jour qui fait grimper les perfs de façon assez spectaculaire sur certaines charges. Hygon, le fondeur chinois qui fabrique des x86 sous licence de l'architecture Zen d'AMD, a envoyé une série de patches pour étendre le cache-aware scheduling, et les chiffres annoncés montent jusqu'à 360% de mieux en termes de transactions par seconde sur MySQL.

Pour comprendre le délire, faut revenir au cache-aware scheduling de base, le fameux CAS, conçu par les ingénieurs d'Intel (Tim Chen, Chen Yu et Peter Zijlstra) et tout juste mergé dans Linux 7.2. Sur un CPU moderne avec plusieurs caches de dernier niveau, le fameux LLC, l'ordonnanceur essaie de regrouper sur le même domaine de cache les tâches qui partagent des données. Du coup, moins de ratés de cache, moins de données qui font des allers-retours entre les caches, et donc de la perf en plus sans toucher au matos mais juste en plaçant mieux les tâches.

Le hic, c'est que ce CAS de base raisonne au niveau d'un seul LLC. Tant que votre charge tient dans un domaine de cache, nickel. Mais dès que la charge dépasse ce que peut contenir un seul cache partagé, l'ordonnanceur ne sait pas regrouper les tâches au niveau du dessus : elles se dispersent sur des cœurs qui ne partagent plus le même cache, et toute la localité s'évapore. Et ça tombe mal pour Hygon, dont les puces récentes ne sont pas un bloc unique mais un assemblage de chiplets (le C86-7490 en réunit quatre), avec plusieurs caches partagés éparpillés sur la galette.

D'où l'idée de développer ces patches, qui permettent un regroupement hiérarchique et offrent la possibilité de s'étendre ou de se contracter dynamiquement selon la taille de la charge et la topologie de la machine.

Hygon annonce donc jusqu'à +49% sur Hackbench , +20% sur Schbench (non, pas le rappeur), et ce fameux +360% sur MySQL !! C'est le feu !

Maintenant, avant de revendre votre PC pour en prendre un sous Hygon, attention ! Ces chiffres, ce sont des "jusqu'à", mesurés sur des topologies multi-domaines, donc typiquement de gros serveurs à plusieurs chiplets. Sur votre laptop avec un seul LLC, vous ne verrez donc sans doute rien passer.... Ouais, je sais, sniiiif. Le 360% n'est pas un gain universel, mais plutôt le pic sur la config qui souffrait le plus du problème.

Un fondeur chinois qui, parti d'une licence Zen d'AMD, en vient à pousser du code dans Linux pour faire tourner tout le monde plus vite, Intel et AMD compris, c'est chouette quand même. Si ça vous intéresse, les patches viennent d'être postés sur la mailing list du kernel , donc rien n'est encore intégré mais si ça passe la revue, c'est de la perf gratuite pour les machines qui en bavent le plus.

Source

Si vous utilisez un ordinateur portable à puce graphique AMD Radeon sous Linux, vous avez peut-être déjà vu l'écran se figer d'un coup, sans raison apparente, à peu près une fois par semaine. Ce bug agace les utilisateurs depuis des années, et un correctif vient enfin de pointer le bout de son nez.

Le coupable se cache dans AMDGPU, le pilote graphique libre qu'AMD maintient pour Linux. On parle ici du logiciel qui fait le lien entre la carte graphique et le système d'exploitation.

Le problème ne date pas d'hier. En fouillant l'historique du code, le développeur à l'origine du correctif a remonté la piste jusqu'à une modification introduite en 2017. Presque huit ans de gels d'écran.

Le symptôme typique, c'est une erreur "flip_done timed out" dans les journaux du système. Pour faire simple, l'ordinateur attend que l'écran affiche l'image suivante, ce signal n'arrive jamais. Et tout gèle.

Le souci touche plusieurs machines, bien connues du monde Linux, comme le Lenovo ThinkPad T14 Gen1 en version AMD ou le Framework Laptop 13 équipé d'un processeur Ryzen 7 7840U. Jusqu'ici, le seul remède consistait à désactiver le PSR, pour "Panel Self Refresh".

Cette fonction d'économie d'énergie laisse l'écran réafficher tout seul sa dernière image fixe sans réveiller la carte graphique, histoire d'économiser de la batterie. Pratique sur un portable, sauf que c'est précisément elle qui déclenchait les gels.

Le plus intéressant, c'est la méthode employée. Le correctif a été mis au point en "vibe debugging" avec Claude Code, l'assistant de programmation d'Anthropic, le concurrent direct d'OpenAI. Le développeur a décrit le bug à l'IA, qui l'a aidé à explorer le code et à affiner les correctifs, plutôt que de dérouler une procédure de débogage classique.

Concrètement, les patchs revoient la gestion du "vblank" et du "page-flip" dans le bloc d'affichage DCN, c'est-à-dire la mécanique interne qui synchronise le moment où une nouvelle image remplace l'ancienne à l'écran. D'autres tentatives avaient échoué par le passé, mais cette série semble enfin tenir la route.

Maintenant patience, rien n'est encore intégré dans le noyau Linux officiel. Les correctifs doivent passer par les tests et la validation des mainteneurs avant d'arriver chez tout le monde, ce qui peut quand même prendre plusieurs versions du kernel.

Bref, on est là devant un bug fantôme qui date d'lil y a huit ans, débusqué en discutant avec une IA, voilà qui résume assez bien l'année 2026 côté développement.

Source : Phoronix

Vous n'avez pas de Mac Silicon, mais vous avez vu passer mon article de ce matin sur vLLM-MLX et son serveur d'IA local ? Hé bien bonne nouvelle, je suis tombé ce midi sur Lemonade SDK , un serveur d'IA local communautaire sponsorisé par AMD (et largement codé par leurs ingénieurs), qui joue dans la même cour, mais côté PC + Mac !

C'est la même logique qu'avec vLLM-MLX, vous installez le serveur (un paquet clé en main selon votre OS, pas de bidouille pip), et il expose un endpoint compatible API OpenAI sur http://localhost:13305/api/v1. Vos scripts tapent dessus au lieu d'envoyer vos prompts, et votre pognon, chez OpenAI.

Le démarrage tient en une ligne. Un lemonade run Gemma-4-E2B-it-GGUF lance un modèle, et un lemonade launch claude branche carrément Claude Code sur votre machine.

Sauf que là où vLLM-MLX s'appuie sur MLX pour les puces Apple, Lemonade vise les NPU Ryzen AI et les GPU Radeon. Et c'est tout l'intérêt du truc car depuis la 10.0 sortie en mars, le NPU XDNA2 des machines Ryzen AI récentes sert enfin à faire tourner des LLM sous Linux, et plus juste à décorer la fiche technique !

La 10.5 apporte également 2 nouveautés qui valent le coup. D'abord, le support macOS passe de bêta à officiel. Toutes les grosses fonctions sont validées sur Mac (le texte via llama.cpp et Metal, le reste via les autres moteurs embarqués) et ensuite, ça bascule sur ROCm 7.13 pour llama.cpp et la génération d'images.

J'ai pas de PC Ryzen AI sous la main pour tâter du fameux NPU, donc j'ai fait mes tests sur mon GPU Metal à moi. Notez qu'un lemonade list crache tout le catalogue, Qwen, Gemma, Llama, DeepSeek et compagnie.

Et ça dépote ! Un petit Qwen3-0.6B dans le chat intégré tourne à ~96 tokens par seconde avec mes 32 Go de RAM, c'est donc une réponse quasi instantanée. Après un modèle de 0,6 milliard de paramètres, c'est le poids plume du ring, donc comptez nettement moins sur un gros 8B, mais ça tourne nickel.

Du coup, sur Mac, vLLM-MLX joue la carte du natif Apple via MLX, alors que l'intérêt de Lemonade c'est surtout le cross-plateforme et le NPU Ryzen AI. Et comparé à Ollama , vous gagnez ce NPU mais aussi les fonctions audio (synthèse vocale, transcription) + un gestionnaire graphique de modèles pour piocher vos modèles. Et tout ça est sous licence Apache 2.0.

Bref, que vous soyez team Mac ou team Ryzen, c'est zéro ligne de facture API en fin de mois et surtout vos données qui restent chez vous !

Source : Phoronix

• lien nᵒ 1 : Radeon™ Software for Linux® 25.10.1 Release Notes (Annonce)

Commentaires : voir le flux Atom ouvrir dans le navigateur

Si vous avez un CPU AMD ou Intel de dernière génération et que vous êtes sous Linux, vous allez pouvoir profiter de sacrés gains de performances côté chiffrement AES-XTS. En effet, un certain Eric Biggers de chez Google a bossé dur pour implémenter de nouvelles versions optimisées de l’algorithme AES-XTS, spécialement conçues pour tirer parti des instructions AES-NI, AVX, VAES et AVX-512 des processeurs modernes.

Du coup, on obtient jusqu’à 155% de gains sur des CPU AMD Zen 4 !

Alors qu’est-ce que ça change pour vous ?

Eh bien si vous utilisez le chiffrement de disque complet (comme LUKS par exemple) ou que vous chiffrez vos fichiers sensibles avec des outils comme eCryptfs ou fscrypt, vous devriez voir une belle différence à l’usage. Fini les lenteurs et les ralentissements, place à la vitesse et à la réactivité ! Vos données seront protégées sans que vous ayez à sacrifier les performances. C’est plutôt une bonne nouvelle, avouez.

Pour en profiter, vous devrez donc avoir :

• Un système avec un processeur Intel ou AMD compatible VAES et AVX-512.
• Une installation de Linux à jour, avec la version 6.10 du noyau minimum.

Linux 6.10 apporte aussi d’autres améliorations côté sécurité et chiffrement. Je vous fais un petit résumé en chinois :

• Interdiction d’utiliser des courbes elliptiques avec un ordre inférieur à 224 bits (FIPS 186-5)
• Prise en charge de ECDSA avec la courbe NIST P521
• Support de l’accélération matérielle pour Intel QuickAssist Technology (QAT) avec migration à chaud
• Et un nouveau driver pour le moteur de sécurité des puces NVIDIA Tegra

Allez, bonne journée !

Source

Je sais pas si vous avez vu passer ça, mais dernièrement, il y a eu un peu de grabuge entre George Hotz (Geohot) et AMD, puisque ce dernier a essayé de faire tourner son framework IA Tiny Grad sur des GPU AMD.

Sauf que voilà, AMD lui a donné du fil à retordre avec ses firmwares propriétaires. Le driver open-source d’AMD se révélant être une jolie mascarade puisque tout les morceaux de code critiques sont bien protégés et sous licence.

Pourtant, Geohot n’a pas lésiné. Des mois à éplucher le code, à bypasser la stack logicielle, à discuter avec les pontes d’AMD. Mais rien à faire, les mecs veulent pas cracher leurs précieux blobs binaires. « Trop risqué, pas assez de ROI, faut voir avec les avocats. » Bref, c’est mort.

Pendant ce temps, Nvidia se frotte les mains avec son écosystème IA bien huilé. Des pilotes certifiés, des perfs au rendez-vous, une bonne communauté de devs… Tout roule pour eux, alors qu’AMD continue de s’enfoncer dans sa logique propriétaire, au détriment de ses utilisateurs.

La goutte d’eau pour Geohot ? Un « conseil » de trop de la part d’AMD qui l’a incité à « lâcher l’affaire« . Résultat, geohot est passé en mode « je vais vous montrer qui c’est le patron« . Si AMD ne veut pas jouer le jeu de l’open-source, alors il va leur exposer leurs bugs de sécu à la face du monde !

Et c’est ce qu’il a fait puisque durant un live de plus de 8h, il s’est attaché à trouver plusieurs exploit dans le firmware des GPU AMD. Il est fort !

Dans l’IA, l’aspect hardware compte évidemment mais le software c’est le nerf de la guerre. Les boîtes noires, les firmwares buggés, le code legacy, c’est plus possible et les sociétés qui tournent le dos à la communauté des développeurs et des hackers font, selon moi, le mauvais choix.

Et ce qui arrive à AMD n’est qu’un exemple de plus.

Bref, comme d’habitude, gros respect à Geohot pour son combat de vouloir encore et toujours que la technologie profite au plus grand nombre. En attendant, suite à sa mésaventure avec AMD, il a annoncé qu’il switchait tout son labo sur du matos Nvidia et qu’il bazardait ses 72 Radeon 7900 XTX sur eBay. Si vous voulez des GPU d’occase pour pas cher (et apprendre à les faire planter ^^), c’est le moment !

Et si le code source de ses exploits vous intéresse, tout est sur Github.

Merci George !

Bonne nouvelle, Ollama vient tout juste d’annoncer un truc qui devrait vous faire plaisir : le support des cartes graphiques AMD en preview ! Cela signifie que toutes les fonctionnalités d’Ollama peuvent maintenant être accélérées par les cartes graphiques AMD, que ce soit sur Linux ou Windows.

Mais au fait, c’est quoi Ollama ? Pour les deux du fond qui suivent pas, je vous refais un topo vite fait. Ollama, c’est un outil hyper pratique qui permet de faire tourner des grands modèles de langage open-source directement sur votre machine locale. Genre Mistral, Llama 2 et toute la clique.

Alors, quelles sont les cartes AMD compatibles ?

Pas de panique, je vous ai préparé une petite liste bien détaillée. Dans la famille des Radeon RX, on retrouve les monstres comme les 7900 XTX, 7900 XT, 7800 XT, 6900 XT et compagnie. Pour les pros, la gamme Radeon PRO est aussi de la partie avec les W7900, W6800X Duo, Vega II… Bref, y a du beau monde au rendez-vous. Et si vous êtes un fan des cartes Instinct, pas de jaloux, les MI300X, MI250, MI100 et autres sont aussi supportées.

Ollama promet également que d’autres modèles de cartes graphiques suivront. Alors on croise les doigts et on surveille les annonces comme le lait sur le feu. En attendant, si vous voulez vous lancer dans l’aventure Ollama avec votre carte AMD, c’est simple comme bonjour.

Téléchargez Ollama pour Linux ou Windows, installez le bouzin et hop, vous voilà parés pour faire chauffer votre GPU AMD ! C’est pas beau la vie ? Je vous ai même fait un tutoriel ici !

Allez, je vous laisse, j’ai un rendez-vous urgent avec mon Llama2 uncensored qui me fait de l’œil.

Source