Simon Willison, le créateur de Datasette et co-créateur de Django, vient de porter un modèle d'inpainting d'image directement dans le navigateur. Sa démo vous permet de choisir une photo, de peindre sur la zone à faire disparaître et ensuite le modèle IA reconstitue ce qu'il manque. Et ce qui est merveilleux avec cette appli c'est que tout tourne sur votre carte graphique en local, comme ça vos données restent chez vous.

Le modèle s'appelle Moebius, dispose de 0,22 milliard de paramètres, et a été développé par une équipe de l'université Huazhong en Chine. À l'origine c'est un modèle PyTorch, que Willison a converti au format ONNX pour le faire tourner via ONNX Runtime Web sur le backend WebGPU, une nouvelle API qui donne aux pages web un accès direct au GPU. Et ce qu'on obtient, c'est un modèle de diffusion qui s'exécute à 100% côté client dans Chrome ou Safari.

Lors de la première utilisation, l'outil télécharge 1,27 Go de poids depuis Hugging Face, ce qui est énorme pour une page web. Mais c'est un one-shot car ensuite, le navigateur range tout ça dans son Cache Storage, et les fois d'après il ne re-télécharge rien.

Je l'ai installé et testé et ça fonctionne vraiment très très bien. J'ai sélectionné quelques tuiles comme un bourrin et ça me les a enlevées très proprement en quelques dizaines de secondes (une fois le modèle initial téléchargé évidemment).

C'est du vrai inpainting génératif en tout cas et pas un truc qui recopie les pixels d'à côté.

Willison raconte dans le README que la conversion PyTorch vers ONNX et l'appli web complète ont été réalisées par Claude Code avec le modèle Claude Opus 4.8, et qu'il n'a "*pas regardé une seule ligne de code *". Il s'est juste contenté de tester dans le navigateur et de signaler ce qui clochait. Hé ouais c'est comme ça maintenant, les temps changent ;)

C'est open source sous licence Apache 2.0, la démo est en ligne, et le code est sur GitHub si vous voulez le lancer chez vous. Testez, et effacez ce gars avec son coup de soleil sur le crâne qui gâche votre plus belle photo de vacances, je ne vous juge pas ^^.

Source : Hackaday

Accrochez-vous parce que celle-là, elle est bien barrée ! Des chercheurs de l'université d'Uppsala veulent stocker la mémoire d'une IA... dans de la lumière. Leur projet Fiber Memory fait tourner les données d'un LLM en boucle dans 1 000 km de fibre optique, et les puces se servent au passage !

Pour comprendre le délire, il faut voir comment ça marche aujourd'hui. Dans un gros data center IA, chacune des 10 000 puces de calcul (des accélérateurs, en gros des GPU) garde sa propre copie complète du modèle dans sa mémoire embarquée, la HBM . Un Llama 3 70B compressé pèse 70 Go, ce qui donne 700 To de mémoire hors de prix pour stocker 10 000 fois exactement la même chose.

Vous qui râlez déjà quand un modèle ne tient pas sur votre matériel , imaginez le même casse-tête multiplié par 10 000.

La solution d'Hannah Atmer et de son équipe, c'est le tapis roulant à sushis. Un serveur unique injecte 128 Go de données dans la boucle (les poids du modèle, plus un peu de marge), et tout ça défile en continu à 25,6 To/s. Chaque puce attrape alors les plats qui l'intéressent quand ils passent devant elle, et le tour complet prend 5 ms !

La topologie retenue : un seul serveur de poids alimente la boucle, les pods se servent au passage. Schéma tiré du papier d'Atmer, Voigt, Yao et Kaxiras.

Concrètement, chaque châssis prélève 1 % de la lumière qui circule et laisse filer le reste vers les copains d'après. Pas de requête, pas d'adresse mémoire, juste un péage optique qui pique sa part au passage.

Le prélèvement en détail : un splitter 99:1 détourne 1 % de la puissance optique vers le pod, le reste poursuit sa route et se fait ré-amplifier.

Et le plus dingue, c'est que cette idée de génie a 80 ans ! Les premiers ordinateurs des années 40 stockaient déjà leurs données sous forme d'ondes qui tournaient en rond dans des tubes de mercure, la fameuse mémoire à ligne de délai . On avait déjà croisé des mémoires franchement bizarres , mais celle-ci place la barre très haut.

Évidemment, y'a des conditions à respecter... Ça ne marche que pour des données qui ne changent jamais et que tout le monde se partage, comme les poids d'un modèle déjà entraîné (les calculs en cours restent dans une petite mémoire locale classique). Et si une puce rate son sushi, elle attend 5 ms que le tapis fasse un tour complet... une éternité pour un GPU.

Côté conso, leurs calculs annoncent 284,8 kW pour la livraison des poids, contre 1 024 kW avec la HBM classique. Presque 4 fois moins ! Bon, la comparaison avantage un peu leur bébé (le scénario fibre répartit les poids entre les 8 puces d'un châssis, quand la référence garde une copie entière par puce), mais l'ordre de grandeur reste violent.

Par contre, tout ça n'existe encore que sur le papier. Les briques sont là, entre les commutateurs Spectrum-X Photonics de NVIDIA qui causent déjà en lumière et la HBM3e de Micron qui dépasse 1,2 To/s par pile, mais personne n'a encore assemblé le puzzle. Et il faudrait quand même réussir à caser 280 amplificateurs sur la boucle, plus quelque 3 500 amplis et 1 750 régénérateurs autour des pods...

Reste à voir si le bilan énergétique survit à un vrai prototype !

Source

Vous avez une petite carte graphique, un vieux Mac ou juste un bon processeur, et vous cherchez LE modèle d'IA parfait qui pourra tourner en local sans que ça rame ?

Hugging Face vient d'ajouter le filtre qui manquait à sa page Models : un sélecteur de matériel qui ne vous proposera que les modèles réellement compatibles avec votre machine.

Vous renseignez votre config (une RTX 3060, un processeur AMD, une puce Apple Silicon M2…) dans les réglages de votre compte, et le catalogue ne gardera plus que ce qui passe pour un GPU, un CPU ou une puce Apple précis.

Fini l'époque, donc, où il fallait ouvrir chaque fiche, chercher la VRAM requise, sortir la calculette et croiser les doigts au moment du lancement.

Ce filtre d'Hugging Face repose sur la taille des fichiers proposés, notamment les versions quantifiées au format GGUF, ces modèles compressés qui font tourner de grosses IA sur des machines modestes, et sur la RAM ou la VRAM de votre config déclarée. Cette base hardware est constituée de ce que possède réellement la communauté des 300 000 membres qui ont accepté de déclarer leur matériel.

Une fois le bon modèle repéré, vous récupérez les commandes via le bouton "Use this model" présent sur chaque fiche, puis vous lancez tout ça avec les outils habituels de l'IA locale, du genre llama.cpp, Ollama ou LM Studio. Et pour ceux qui veulent aller plus loin sur Apple Silicon, il existe également des serveurs d'inférence maison pour remplacer l'API d'OpenAI par votre propre Mac .

Maintenant, si vous avez un chip un peu exotique, un accélérateur NPU ou une carte à peine sortie, il faudra parfois patienter, voire passer par le forum pour réclamer son ajout dans la base, mais bon, je chipote !

Source

Avec la sortie de CUDA 13.3, NVIDIA renforce son écosystème GPU sur deux fronts importants. La version Python passe officiellement en 1.0 (donc considérée comme stable et utilisable en production), et CUDA Tile arrive nativement pour les développeurs C++.

Petit rappel pour les non-initiés : CUDA, c'est l'outil que tout le monde utilise pour faire tourner du calcul sur les cartes graphiques NVIDIA, principalement pour l'IA et le calcul scientifique. 

Historiquement, c'est du C/C++ à 99%. NVIDIA pousse depuis quelques années pour rendre tout ça accessible en Python, et ce passage en 1.0 marque une étape importante. À partir de maintenant, l'API ne changera plus brutalement entre les versions mineures.

En pratique, les développeurs peuvent désormais compter dessus pour leurs projets long terme. La version 1.0 ajoute aussi le support des "green contexts" (un système pour réserver une partie de la GPU à des tâches isolées) et du checkpointing CUDA (la possibilité de sauvegarder l'état d'une exécution GPU pour la reprendre plus tard).

L'autre gros morceau, c'est CUDA Tile pour C++. Le modèle de programmation "tile" consiste à découper un calcul en blocs uniformes traités en parallèle, plutôt que de gérer chaque fil d'exécution individuellement (la GPU en fait tourner des milliers en même temps).

Il était déjà disponible en Python via des bibliothèques comme Triton. Il arrive maintenant en C++. L'idée est de monter d'un cran en abstraction : vous décrivez ce que vous voulez faire au niveau du bloc, et le compilateur s'occupe de mapper ça sur les threads. Le support couvre les GPU Hopper (l'architecture haut de gamme de NVIDIA pour les datacenters IA) et toutes les architectures plus récentes.

En bonus, NVIDIA introduit CompileIQ, un framework d'auto-tuning du compilateur qui promet jusqu'à 15% de gain sur des opérations critiques comme la multiplication de matrices ou les mécanismes d'attention utilisés dans les modèles d'IA. Le support du C++23 dans les compilateurs NVCC et NVRTC est aussi de la partie.

Pour les développeurs IA, c'est une nouvelle version importante. La programmation GPU est toujours un domaine très technique, mais NVIDIA réduit progressivement la barrière d'entrée, surtout côté Python. AMD a du boulot pour rattraper son retard avec ROCm, leur équivalent maison qui peine encore à convaincre la communauté.

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

Jellyfin sans GPU, c'est la croix et la bannière dès que quelqu'un lance un film en 4K. Mais c'était sans compter sur ffmpeg-over-ip qui est capable de transformer un serveur équipé d'un GPU en endpoint de transcoding distant, accessible via un simple binaire qui se fait passer pour ffmpeg. Y'a pas de passthrough GPU, ni besoin de vous lancer dans la config de point de montage réseau exotique.

Le principe c'est que le client reçoit les commandes ffmpeg de Jellyfin (ou Emby), les sérialise et les envoie ensuite via TCP (port 5050) vers un serveur qui lui dispose d'un bon GPU. Et côté Jellyfin, rien ne change puisque le binaire répond exactement comme ffmpeg le ferait (et je vous rassure, y'a un peu d'authentification pour éviter de vous faire squatter votre serveur de transcoding à l'insu de votre plein gré).

Alors imaginons un peu dans quelle situation ça peut être utile... Par exemple, vous pourriez avoir un NUC ou mini-PC tout neuf qui fait tourner Jellyfin dans Docker, et à côté une vieille tour avec une GTX qui traîne dans un coin pour le transcodage. L'avantage c'est que plusieurs clients peuvent ainsi partager le même serveur GPU en parallèle, donc ffmpeg-over-ip peut valoir le coup si vous avez du matériel qui dort dans un coin.

L'outil est signé Anees Iqbal (steelbrain) et voici comment l'installer (pensez à vérifier le contenu du .sh avant) :

curl -fsSL https://ffmpeg-over-ip.com/install-client.sh | sh

ln -s ffmpeg-over-ip-client ffprobe

Le pilote Vulkan open source d'Intel pour Linux vient de recevoir une optimisation qui améliore les performances des jeux DirectX 12 tournant via Proton.

La modification a été intégrée à Mesa 26.1 et concerne les cartes graphiques Arc Alchemist et Battlemage. Le patch avait été proposé pour la première fois en 2020, il aura donc fallu plus de cinq ans pour le voir arriver.

Ce qui change pour les joueurs Linux

L'optimisation porte sur la façon dont le pilote ANV gère le cache d'état graphique. En utilisant une combinaison de deux identifiants internes (Binding Table Pointer et Binding Table Index) au lieu d'un seul pour référencer les textures, le pilote peut supprimer certaines étapes de synchronisation qui ralentissaient le rendu.

Les développeurs d'Intel indiquent que le gain est mesurable sur tous les jeux DirectX 12 qu'ils ont testés via VKD3D-Proton, la couche de traduction utilisée par Steam pour faire tourner les jeux Windows sur Linux.

Pas de chiffres précis dans la note technique, mais une autre modification récente du même pilote (un simple changement d'une ligne de code pour le prefetch des tables de textures) avait déjà montré des gains allant jusqu'à 3 à 4 % sur God of War et Destiny 2.

Un patch qui a mis cinq ans à arriver

L'anecdote vaut quand même le détour. Ce patch a été proposé pour la première fois en novembre 2020, et il vient d'être fusionné dans Mesa en mars 2026.

Plus de cinq ans entre la proposition et l'intégration, ce qui donne une idée du rythme de développement des pilotes graphiques open source. Le code nécessite aussi un correctif au niveau du noyau Linux (dans le pilote Xe), qui devrait arriver avec Linux 7.1.

Les GPU concernés sont les Intel Arc à partir de la génération Alchemist (Arc A770, A750, etc.) et les plus récents Battlemage (Arc B580, B570).

Quelques limites quand même

L'optimisation ne fonctionne bien qu'avec les jeux DirectX 12. Sur les titres DirectX 11, les développeurs ont constaté des baisses de performances, ce qui fait que le mécanisme est activé automatiquement pour DX12 et désactivé pour DX11. Il est aussi possible de forcer son activation ou sa désactivation via un réglage dans la configuration DRI.

C'est le genre de petite avancée qui, mise bout à bout avec les autres, finit par rendre les GPU Intel Arc de plus en plus viables sous Linux pour le jeu. Cinq ans pour un patch, c'est long, mais le résultat est là. Et puis ça montre aussi que l'approche open source d'Intel sur ses pilotes graphiques continue de porter ses fruits, même si le chemin est quand même un peu plus lent que chez NVIDIA ou AMD.

Source : Phoronix

Séparer la voix, la batterie ou la basse d'un morceau, ça relevait du rêve d'audiophile il y a encore quelques années. Fallait installer Python, se taper Spleeter, galérer avec les dépendances CUDA... bref, un super truc de barbu. Mais ça, c'était avant, les amis !

Demucs-rs , une réécriture en Rust du modèle HTDemucs v4 de Meta, tourne maintenant directement dans votre navigateur grâce au WebGPU. Batterie, basse, voix, tout le reste..., chaque élément se retrouve ainsi isolé dans son propre fichier WAV. Et y'a rien à installer, puisque tout se passe côté client, sur votre machine.

Pour vous en servir, vous pouvez aller sur la web app , vous glissez-déposez votre fichier MP3 (ou WAV, FLAC, OGG, M4A... ça bouffe à peu près tout), et vous patientez... Le premier lancement télécharge le modèle (~84 Mo pour le standard), donc prévoyez une connexion correcte.

L'interface de la web app - vous glissez votre fichier et c'est parti

Comptez alors quelques minutes selon la durée du morceau. En sortie, vous aurez alors plusieurs fichiers WAV séparés que vous pourrez écouter, jouer en solo ou télécharger individuellement.

Les pistes séparées, prêtes à écouter ou télécharger

Trois modèles sont dispos. Le mode 4 pistes suffit dans 90% des cas. Il y a aussi le modèle 6 stems, ou plutôt htdemucs_6s, qui est pas mal pour du rock ou du jazz. Et pour les obsessionnels de la qualité, y'a le fine-tuned à 333 Mo... mais prévoyez une pause café, parce que ça va être long de fou !

Voilà, comme ça, si vous voulez faire un karaoké maison, vous virez la voix et vous gardez l'instrumental. Ou si votre truc c'est de sampler une ligne de basse d'un vieux morceau de funk ou encore pratiquer la guitare en jouant par-dessus le morceau original sans la partie guitare, c'est entièrement possible !

D'ailleurs, si vous aviez testé Spleeter avec Ableton à l'époque, c'est le même principe mais en BEAUCOUP plus simple !!

Perso, le fait que ça tourne dans le navigateur, c'est top, sans parler du fait que vos morceaux restent sur votre disque.

Maintenant, si la version navigateur vous semble un peu longue, y'a le CLI natif qui exploite Metal sur Mac et Vulkan sur Linux/Windows. Pour l'installer, clonez le repo et lancez make cli (Rust requis) :

git clone https://github.com/nikhilunni/demucs-rs
cd demucs-rs && make cli

demucs song.mp3 # 4 pistes dans ./stems/
demucs -s vocals chanson.mp3 # juste la voix
demucs -m htdemucs_6s -s guitar solo.flac # isoler la guitare
demucs -m htdemucs_ft morceau.mp3 # qualité max

Et si les meilleures techniques de game dev des années 2000 revenaient dans votre navigateur ?

ArcadeGPU, c'est un moteur de jeu complet qui tourne dans le navigateur grâce à WebGPU. C'est une vraie architecture de jeu avec walkmesh, hitbox BSP, moteur de script, pipeline graphique à la PS1 et même la physique Jolt intégrée (un moteur open source utilisé dans certains gros jeux).

Le truc c'est que le dev derrière, un Français qui bosse seul sur le projet, a pris le parti de ressusciter des techniques qu'on utilisait entre 2000 et 2010 dans le développement de jeux. Du walkmesh pour la navigation des personnages, du hitmesh pour les collisions, du draw call only pour le rendu... Des trucs qu'on ne voit quasi plus dans les moteurs modernes, et pourtant c'est redoutablement efficace pour les indés. Bon, après faut quand même être à l'aise avec TypeScript et la stack web, car c'est pas un moteur drag-and-drop à la GameMaker.

Car oui comme tout est en TypeScript, vous codez votre jeu comme une app web classique. Vous modifiez votre fichier main.ts, le jeu se rafraîchit en temps réel sans avoir à tout relancer. Et vous avez toute la pile web en support, du Web Audio API au CSS en passant par les workers async... Quand on compare avec les 45 secondes de build d'un projet Unity moyen, y'a pas photo.

Y'a aussi un paquet de démos jouables directement sur le site du projet et c'est pas des petits exemples bidon avec un cube qui tourne. Vous y trouverez de vrais prototypes de jeux complets, de la 2D rétro au rendu toon 3D avec ombres volumétriques. L'idée c'est de fournir des templates prêts à l'emploi, vous choisissez le gameplay qui vous correspond et vous partez de là (plutôt que de tout repenser from scratch).

D'ailleurs y'a même un jeu en bêta développé avec le moteur, un Sokoban versus, pour voir ce que ça donne en conditions réelles.

Côté compatibilité, ça tourne sur les navigateurs qui gèrent WebGPU (Chrome, Edge, et Firefox en mode expérimental avec le flag dom.webgpu.enabled). Pour Safari et mobile, c'est plus aléatoire pour le moment donc attention si votre cible c'est iOS. Le projet est open source sous licence Apache 2.0, dispo sur SourceForge et ça pèse environ 400 Mo avec toutes les démos.

Et le rendu... C'est du pipeline PSX complet avec ombrage toon, volumes d'ombre, le tout dans le navigateur. Pour les nostalgiques de la première PlayStation, c'est un peu la papillote Révillon version code (oui ça change des madeleines ^^), sauf que là, c'est vous qui créez les jeux.

Voilà, je trouve que cette approche old-school mixée avec la techno web moderne c'est pas bête du tout. Si vous êtes dev indé et que les usines à gaz style Unity ou Unreal vous donnent des boutons, ça vaut peut-être le coup d'aller jeter un oeil. Seul bémol, la doc est encore un peu légère, donc faudra fouiller dans les exemples pour comprendre l'API.

Bref, merci à Slay3r pour le partage et bravo !

J’sais pas si vous lisez des mangas de temps en temps mais si vous êtes à jour, vous avez peut-être envie de lire la suite, mais malheureusement, souvent c’est pas encore traduit en français. Alors vous 3 solutions… soit vous patientez, soit vous apprenez le japonais… Soit, soit…

Soit vous installez Koharu, un logiciel de traduction de mangas propulsé par IA. C’est hyper bien foutu puisque ça détecte automatiquement les bulles de dialogue, ça lit le texte japonais via OCR, ça efface proprement le texte original avec de l’inpainting, ça traduit le tout avec un modèle de langage aux petits oignons et ça replaque le texte traduit dans la bubulle.

Tout ça en quelques clics, évidemment, sinon ce serait pas drôle !

Le projet est développé par mayocream et c’est du 100% Rust avec une interface Tauri. Pour ceux qui ne connaissent pas, Tauri c’est un peu l’équivalent d’Electron mais en plus léger et plus performant. Le moteur d’inférence utilisé, c’est Candle de HuggingFace, ce qui permet de faire tourner des modèles IA localement sans avoir besoin d’envoyer vos data dans le cloud.

Côté modèles, Koharu embarque plusieurs outils spécialisés. Pour la vision par ordinateur, on a comic-text-detector pour repérer les bulles (avec le petit modèle custom de mayocream ), manga-ocr pour la reconnaissance de caractères et AnimeMangaInpainting pour effacer proprement le texte original. Pour la traduction, c’est vntl-llama3-8b-v2 ou Sakura-GalTransl-7B-v3.7 qui s’y collent et c’est sans galère puisque ces modèles se téléchargent automatiquement au premier lancement.

Et Koharu supporte évidemment l’accélération GPU donc si vous avez une carte NVIDIA, vous pouvez profiter de CUDA et pour les fans d’Apple Silicon avec un M1 à M5, Metal est également supporté. Bref, ça dépote et le logiciel gère aussi la mise en page verticale pour les langues CJK (Chinois, Japonais, Coréen), ce qui est plutôt indispensable quand on traduit des mangas.

Les sources sont dispo sur Github et y’a des binaires pour Windows et macOS directement sur la page des releases. Pour les autres plateformes, faudra compiler vous-même avec Rust et Bun.

Voilà, si vous rêvez de traduire ce manga obscur qui dort au fond d’un forum japonais, Koharu va vous plaire. Et un grand merci à Lorenper pour l’info !

Il y a des bugs qu’on corrige en urgence. Et puis il y a GPU.zip, cette faille que TOUS les fabricants de GPU connaissent depuis mars 2023 et que personne n’a jamais voulu fixer.

Et 2 ans et demi plus tard, des chercheurs viennent de prouver qu’elle permettait de voler nos codes 2FA sous Android en moins de 30 secondes !!

Et devinez quoi ?

Y’a toujours pas de patch !

L’histoire commence donc en septembre 2023. Des chercheurs de l’Université du Texas, Carnegie Mellon, et l’Université de Washington publient GPU.zip , une attaque par canal auxiliaire qui exploite la compression graphique hardware des GPU. Le principe c’est qu’en mesurant le temps de rendu de certaines opérations graphiques, on peut déduire la couleur des pixels affichés à l’écran. Pixel par pixel. Un peu comme prendre une capture d’écran, mais sans permission, bien sûr !

Tous les fabricants de GPU sont donc prévenu dès mars 2023. AMD, Apple, Arm, Intel, Nvidia, Qualcomm. Mais aucun patch n’a pointé le bout de son nez. La position officielle des fabricants de GPU étant que “C’est au software de gérer ça”.

Les navigateurs web colmatent alors la brèche en limitant les iframes cross-origin, mais la faille hardware elle-même n’est jamais corrigée. Trop coûteux. Trop compliqué. Pas leur problème…

Maintenant on fait avance rapide en octobre 2025. Une équipe de 7 chercheurs (UC Berkeley, Carnegie Mellon, Université de Washington) sort Pixnapping , une attaque qui ressuscite GPU.zip sur Android. Le papier sera d’ailleurs présenté à la 32nd ACM Conference on Computer and Communications Security qui a lieue cette semaine à Taipei. Alan Linghao Wang, Ricardo Paccagnella et leurs collègues on réalisé une démo où on voit une application Android malveillante voler des codes 2FA, des messages privés, ou n’importe quelle donnée affichée à l’écran, sans demander la moindre permission système.

Vous en avez marre que votre carte graphique soit bridée sous Linux ? Vous rêvez de pouvoir overclocker votre GPU comme un pro pour booster les perfs dans vos jeux préférés ? Alors laissez-moi vous présenter votre nouveau meilleur pote : CoreCtrl !

Ce logiciel open source va vous permettre d’exploiter enfin tout le potentiel de votre GPU AMD sans vous prendre la tête. Plus besoin d’être un champion de la ligne de commande pour régler les fréquences, les voltages et autres joyeusetés. Avec CoreCtrl, tout se fait en quelques clics depuis une interface super facile à prendre en main.

L’outil embarque une tripotée de fonctionnalités pour les power users. Vous pourrez par exemple créer des profils d’overclocking personnalisés, monitorer en temps réel les températures et les performances, gérer finement la vitesse des ventilateurs, et même undervolt votre GPU pour réduire sa consommation.

Et le top du top, c’est que CoreCtrl est compatible avec un tas de cartes graphiques AMD, des anciennes générations aux derniers modèles. Bref, que vous ayez une vieille Radeon HD qui traîne ou une RX 6900 XT flambant neuve, vous pourrez en tirer le meilleur.

Certains relous me diront : « Oui, euuuh, mais overclocker son GPU, euuuuh, ça fait fondre la carte et ça annule la garantieuuuu« .

Alors oui, forcément si vous poussez les curseurs dans le rouge en permanence, votre GPU risque de partir en fumée. Mais utilisé avec sagesse, l’overclocking peut vraiment donner un boost appréciable notamment pour tout ce qui est traitement GPU et gaming (sous linux, lol), sans forcement réduire la durée de vie de votre matos.

D’ailleurs, CoreCtrl intègre des garde-fous bien pensés pour éviter ce genre de déconvenues. Vous pourrez donc définir des seuils de sécurité pour les températures et les voltages, histoire de ne pas tout cramer. Et si jamais vous sentez que vous êtes allé trop loin dans l’optimisation, pas de panique : il suffit de recharger le profil par défaut et hop, votre carte retrouve son état d’origine.

Si ça vous branche de tester, c’est sur le dépôt GitLab du projet ou installable avec cette commande :

sudo apt install corectrl

Par contre, je ne serais pas responsable si vous faites de la merde, hein.

Happy overclocking les amis ! 😄

Vous pensiez que les cartes graphiques Intel Arc étaient réservées aux processeurs x86 ? Et bien détrompez-vous car un ingénieur de génie nommé Vladimir Smirnov, a réussi un exploit tout à fait inattendu. Il est parvenu à faire fonctionner un GPU Arc A750 sur un processeur ARM 64 cœurs Ampere Altra, et tout ça sous Linux !

Vladimir était en train de monter un serveur ARM avec une carte mère ASRock Rack et un processeur Ampere Altra et en attendant de recevoir toutes les pièces, il s’est dit qu’il allait tester différentes cartes graphiques qu’il avait sous la main : une vieille Radeon RX 550, une RX 5700 de minage et un Intel Arc A750 flambant neuf.

Pour la Radeon RX 550, pas de souci, installation simple et sans galère. Pour la RX 5700, petite compatibilité problématique avec le noyau Linux 6.1 sur ARM, en raison de registres non sauvegardés et d’un bug PCIe spécifique aux puces Ampere Altra. Heureusement pour lui, des correctifs ont été intégrés dans plusieurs distributions Linux, donc c’est facilement contournable.

Mais mais mais… Pour l’Intel Arc A750 c’est un autre délire. En effet, les pilotes (le i915) pour ce GPU d’Intel sont principalement conçus pour une architecture x86, ce qui pose problème sur ARM et malheureusement, le nouveau pilote Xe dédié aux cartes Arc pose aussi problème sur ARM.

Alors que faire ? Se rouler en boule dans un coin et pleurer ? Non ! Vladimir ne s’est pas laissé décourager. En commentant des bouts de code liés à la compatibilité avec les vieilles consoles VGA, il a pu obtenir une image via HDMI. Mais pas de 3D… snif… Il a donc fallu recompiler Mesa3D avec la version compatible Xe et appliquer des correctifs pour résoudre ces bugs spécifiques aux puces Ampere Altra. Et finalement, petit miracle 2024, l’Intel Arc A750 a pu afficher de la 3D sur son processeur ARM 64 cœurs !

Bien que cette configuration ne permette pas de jouer à des jeux extrêmement gourmands tels que Crysis en 8K, pouvoir faire tourner Doom 3 représente déjà un exploit ! Bravo Vlad, tu es notre héros

Bref, la prochaine qu’on vous dira « c’est pas possible« , fait comme Vlad, persévérez !

Source

Si vous êtes un développeur à la recherche d’un nouvel éditeur de code, vous allez être content avec Lapce dispo pour Windows, Linux et macOS. Encore en version pré-alpha, Lapce n’a d’autres ambitions que de venir chatouiller les orteils de Visual Studio Code.

Pour le moment, on en est loin, mais cet éditeur a quand même quelques atouts dans sa manche. Tout d’abord, son interface graphique et ses performances sont au top du top de l’optimisation grâce au langage dans lequel il est codé, à savoir Rust.

En effet, grâce à l’accélération GPU intégrée à l’interface graphique native, les lags au lancement de l’éditeur et lors de la saisie sont totalement éliminés. Pour les développeurs de Lapce, tout ralentissement lors de la frappe est considéré comme un bug et sera donc résolu.

L’une des fonctionnalités les plus intéressantes de Lapce est la possibilité de se connecter à une machine distante en toute transparence via SSH, pour bénéficier d’une expérience « locale ». Cela vous permet de profiter d’un environnement identique à votre serveur de production ou d’exploiter toutes les performances de la machine distante. Idéal pour les développeurs travaillant en équipe ou en télétravail.

Côté mise en forme du code, Lapce utilise Tree-sitter pour la coloration syntaxique, ce qui est une solution bien plus rapide et efficace que les techniques à l’ancienne basées sur les expressions régulières (regex). De plus, la prise en charge intégrée du protocole LSP (Language Server Protocol) permet à Lapce de proposer de la complétion de code, des diagnostics ainsi que des actions éventuelles sur le code analysé en temps réel.

Si vous êtes un utilisateur de Vim, bah déjà bon courage. Mais surtout, ne vous inquiétez pas, Lapce intègre nativement une expérience d’édition similaire à Vim, sans avoir besoin d’installer de plugin. Vous n’avez qu’à activer l’option d’édition modale dans les paramètres de l’IDE et vous pourrez utiliser tous vos raccourcis Vim comme un bon tröll velu.

Pour encore plus de personnalisation, vous pouvez aussi écrire vos propres plugins pour Lapce en utilisant n’importe quel langage de programmation capable d’être compilé pour produire du WASI (WebAssembly System Interface). Ainsi, vous pouvez choisir un langage de programmation que vous aimez pour créer des plugins rapidement sans apprendre un truc spécifique.

Enfin, Lapce vous permet de lancer un terminal directement dans le répertoire de votre espace de travail, sans quitter l’éditeur. Cette fonction simplifie la gestion des fichiers et des dossiers, rendant votre workflow encore plus fluide.

Bref, bien que Lapce soit encore en phase pré-alpha, et loiiiin d’égaler Visual Studio Code, cet éditeur open source écrit en Rust, est promis à un bel avenir chez tous ceux pour qui les perfs sont très importantes (tout le monde quoi…).

Rendez-vous sur lapce.dev pour en savoir plus ! Et la doc est ici.

Merci à Lorenper

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 !

Vous pensiez que votre GPU était à l’abri des regards indiscrets ? Que nenni damoiseaux zé demoiselles !!!

Une équipe de chercheurs vient de mettre en lumière des failles béantes dans la sécurité de l’API WebGPU, cette technologie qui booste les performances graphiques de nos navigateurs.

D’après cette étude, ces vulnérabilités permettraient à des scripts malveillants d’exploiter les canaux auxiliaires du GPU pour siphonner des données sensibles, comme vos mots de passe ou vos clés de chiffrement. Rien que ça ! 😱 Concrètement, les chercheurs ont réussi à monter ces attaques par canaux auxiliaires en fonction du temps et de l’état du cache du GPU, le tout depuis un simple navigateur web.

En analysant finement l’impact de différentes charges de travail sur les performances du processeur graphique, ils sont parvenus à en déduire des informations sur les autres processus utilisant cette ressource qui est, vous vous en doutez, partagée. Et c’est là qu’est le problème.

Le plus inquiétant, c’est que leur proof of concept se résume à du code JavaScript tout ce qu’il y a de plus basique. Pas besoin d’avoir accès au PC, un site web malveillant peut très bien faire l’affaire. De quoi donner des sueurs froides aux éditeurs de navigateurs… Rassurez-vous, je ne compte pas l’intégrer sur Korben.info, la bouffe n’est pas assez bonne en prison ^^.

Pour l’instant, à part Mozilla qui a publié un bulletin d’avertissement, les principaux acteurs comme Google ou Microsoft n’ont pas réagi. Bouuuuh ! Ils estiment sans doute que le jeu n’en vaut pas la chandelle et préfèrent miser sur les gains de performances de WebGPU plutôt que de s’embarrasser avec des demandes d’autorisations qui gâcheraient l’expérience utilisateur.

Pourtant, les chercheurs sont formels, les sociétés qui conçoivent des navigateurs doivent traiter l’accès au GPU avec la même rigueur que les autres ressources sensibles comme la caméra ou le micro. Sinon, gare aux dérives ! On peut imaginer des utilisateurs qui se font piller leurs cryptomonnaies pendant qu’ils surfent innocemment, ou pire, des fuites de données à grande échelle orchestrées depuis des sites en apparence légitimes.

Avec ça, le bandeau RGPD peut aller se rhabiller ^^/

Rassurez-vous, pour le moment, WebGPU est activé par défaut uniquement dans Chrome et ses dérivés. Pour Firefox, c’est encore seulement dans les versions Nightly (mais ça arrive bientôt). Je vous laisse tester votre navigateur avec le proof of concept dont je vous parlais un peu plus haut.

Bref, cette étude a le mérite de lancer le débat sur les implications sécuritaires des API web de plus en plus intrusives. À l’heure où le GPU s’impose comme une ressource de calcul incontournable, y compris pour des tâches sensibles, la question de son isolation et de la maîtrise des accès devient cruciale.

Bref, on réfléchira à deux fois avant d’autoriser l’accès au GPU sur un site louche… 😉

Source