Lors de leur keynote à l'Open Source Summit 2024, Linus Torvalds et Dirk Hohndel ont échangé sur l’avenir des architectures matérielles libres, en particulier RISC-V. Linus, avec son franc-parler habituel, a partagé ses craintes et ses espoirs concernant l’évolution de RISC-V et le rôle crucial que peuvent jouer les communautés open source pour éviter les erreurs passées, notamment dans le développement des plateformes comme ARM et x86.
Linus estime qu’il existe un risque majeur que RISC-V répète les erreurs commises par les architectures précédentes, comme lorsqu’ARM est devenu une plateforme serveur et a ignoré en partie les leçons apprises lors du développement de l’architecture x86, notamment en matière de sécurité. Cependant, il reconnaît également que grâce à l’expérience accumulée, ces erreurs ont été corrigées plus rapidement. La question cruciale est à présent de savoir si RISC-V saura tirer parti de cette expérience collective pour éviter ces écueils ou s’il devra traverser les mêmes cycles d’apprentissage douloureux.
Leçons du passé et rôle des logiciels libres
Les erreurs évoquées par Linus sont multiples. Il parle notamment des problèmes de compatibilité et d’interopérabilité qui ont compliqué l’adoption de nouvelles architectures matérielles. Il mentionne également le manque de communication entre les concepteurs de matériel et les développeurs de logiciels, créant un fossé qui ralentit l’innovation et entraîne des inefficacités. Enfin, il rappelle que les délais nécessaires pour corriger les erreurs matérielles sont bien plus longs que pour les logiciels, ce qui peut freiner l’évolution des nouvelles technologies.
Cependant, l’open source présente une opportunité unique pour surmonter ces obstacles. Une architecture matérielle ouverte comme RISC-V permet une transparence totale, où les développeurs de logiciels peuvent intervenir dès les premières phases de conception pour s’assurer que les erreurs du passé ne se reproduisent pas. Cette collaboration précoce entre développeurs matériels et logiciels est essentielle pour anticiper et résoudre les problèmes avant qu’ils ne deviennent des obstacles majeurs.
L’open source a déjà prouvé sa valeur dans le domaine des logiciels en offrant une flexibilité et une adaptabilité incomparables. Cette même philosophie appliquée au matériel peut accélérer l’innovation et permettre de répondre plus rapidement aux besoins du marché. De plus, une communauté ouverte permet de partager les connaissances et les meilleures pratiques, réduisant ainsi les risques de répéter les erreurs passées.
Sécurité et architecture matérielle open source
Un point crucial soulevé par Linus concerne la sécurité, en particulier les défis posés par les failles matérielles et les attaques par canal auxiliaire. Ces vulnérabilités résultent souvent des optimisations dans le silicium, comme l'exécution spéculative, qui peuvent être exploitées pour compromettre la sécurité des systèmes.
Linus a exprimé sa frustration face à la nature secrète des processus de gestion des failles de sécurité dans le domaine du matériel. Il a souligné que cette opacité empêche de travailler en toute transparence sur ces problèmes intéressants et techniques. Une architecture matérielle open source, comme RISC-V, pourrait potentiellement atténuer ces frustrations en permettant une collaboration ouverte dès le début, facilitant ainsi la détection et la correction rapide des vulnérabilités.
L’open source offre également un modèle de confiance basé sur la transparence et la vérification par les pairs. Dans le contexte de la sécurité, cela signifie que les failles peuvent être identifiées et corrigées plus rapidement grâce à une surveillance continue et à une coopération étroite entre les développeurs de matériel et de logiciels.
La vision d’un avenir open source pour le hardware
L’un des points forts de l’open source est sa capacité à démocratiser l’accès à la technologie. Avec des projets comme RISC-V, il est possible de voir émerger des solutions matérielles qui ne sont pas seulement le produit de quelques grandes entreprises, mais le fruit d’une collaboration globale. Cela peut mener à des avancées significatives non seulement en termes de performances, mais aussi de coûts et d’efficacité énergétique, en offrant des alternatives viables aux architectures propriétaires.
Linus Torvalds a également évoqué l’évolution des pratiques du développement du matériel. Il y a dix ans, il était difficile de passer de x86 à une autre plateforme, mais aujourd’hui, grâce à l’open source, la transition est beaucoup plus fluide. Les utilisateurs finaux ne se soucient plus de savoir si leur serveur fonctionne sur un processeur Intel, AMD ou ARM ; ce qui compte, c’est que l’infrastructure logicielle soit solide et interopérable.
Pour que RISC-V réalise pleinement son potentiel, il est donc crucial que les communautés du logiciel et du matériel libres continuent de favoriser une culture de partage et de collaboration. Les développeurs de logiciels doivent être encouragés à s’impliquer dans le processus de conception matérielle, et vice versa. En travaillant ensemble, ils peuvent s’assurer que les erreurs du passé ne se reproduisent pas et que les nouvelles technologies répondent aux besoins réels du marché.
# MJ
Posté par antistress (site web personnel) . Évalué à 4.
(chante avec moi)
Non, blague à part, c'est cool !
[^] # Re: MJ
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 0.
Heeeeheee
Un gentil du net
# Merci pour la transcription
Posté par Ontologia (site web personnel) . Évalué à 8.
J'avais du mal à me décider de passer une demi heure alors que ce résumé me conviens parfaitemen !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Encore du travail pour RISC V
Posté par Ontologia (site web personnel) . Évalué à 7. Dernière modification le 15 juillet 2024 à 11:14.
Des remontées que l'on a du RISC V, l'efficacité de l'architecture n'est pas encore au niveau de ce qu'il se se fait sur ARM ou X86_64. On répondra que ce sont des processeurs pour l'embarqué, mais quand même.
Mais l'OpenSource a son épingle à tirer du fait de l'évolution des processeurs : ayant "trop" de transistors à graver, les architectures deviennent de plus en plus des SoC et des contraintes de plus en plus complexes comme le fait qu'un die doit être à + de 50% non alimenté pour ne pas trop chauffer
La conception de processeur deviens plus compliqué, mais la réutilisabilité du code va devenir crucial car les sous parties spécialisées vont devenir prépondérantes, dans un contexte où la puissance de calcul augmente de 3% par an
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Encore du travail pour RISC V
Posté par tao popus . Évalué à 2.
Non, ce ne sont pas que des processeurs embarqués, il y des processeurs à destination du bureau/serveur depuis plusieurs années déjà (de SiFive, T-Head, Sophgo, SpacemiT), mais par contre leur intégration Open-source/libre au noyau est encore en cours, il y a encore que des pilotes proprios pour les GPU (2D (principalement Vivante) ou 3D (principalement PowerVR)) intégrés, les version opensource commence à montrer le bout de leur nez pour certains modèles, IT travail aussi sur des pilotes en interne, mais ça semble traîner, c'est balbutiant (le pilote arrive à avoir un triangle texturé qui fonctionne dans certains cas depuis quelques semaines). Les cartes graphiques en PCI avec pilote libre fonctionnent par contre depuis 1 an ou 2, mais peu de cartes ont des bus PCI, on est plutôt globalement sur le tout intégré.
Il ne faut pas confondre puissance de calcul et performances. L'architecture RISC-V est déjà plus performante, en raison de l'efficacité de son architecture
** version de ref 0.7 (renommé extension T-Head, comme se sont les seuls à les avoir implémentés (processeurs AllWinner ou T-Head même), mais ils l'ont rendu disponible, grâce à ça depuis plusieurs années
** version de ref 1.0, les premières implémentations matérielle sont arrivée cette année, avec le SpacemiT K1 pour le bureau, un Kendryte pour l'embarqué en fin d''année dernière.
Par contre, il faut éviter le portable DC-ROMA donné dans l'article, il est hors de prix, et se dit lui même orienté NFT, ce qui ne sert pas à grand chose. D'autres plus récents sont bien moins chers, avec des capacités équivalentes ou meilleures, mais c'est orienté devs, comme le Musebook, du même constructeur, ou la carte fille Licheepi 3a de Sipeed, utilisable dans leurs ordinateur/console portables qui utilisaient du TH1520 jusqu'à présent. Ça n'est vraiment pas orienté utilisateur final dans l'état actuel, à moins de vouloir plein de pilotes fermés et moyennement stable, avec peu de garantie de maintenabilité dans le temps. Ça avance tout de même, dans le « mainlining » Linux
[^] # Re: Encore du travail pour RISC V
Posté par Ontologia (site web personnel) . Évalué à 2.
Je te répond avec retard, car certains aspects de ton post m'intéresse beaucoup : Je prends note sur la partie driver, mais ce qui m'intéresse, c'est l'efficacité par Mhz des architectures Risc V vs ARM vs Intel.
Intel c'est un code CISC donc compact par essence, mais je ne suis pas sûr que ce soit aussi intéressant (hors meumeu X, AVX, et seuseuseu) que celui d'ARM.
La force du jeu d'instruction ARM ce sont les instructions conditionnelles. Ça permet d'économiser énormément de code et d'instructions quand c'est bien utilisé.
Donc plusieurs questions :
Est-ce que le RISCV a ce genre d'efficacité ? Si oui, en quoi RISC V est plus efficace qu'ARM ?
Est-ce que les compilateurs sont capables d'exploiter cette fonctionnalité su jeu d'instruction ARM ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Unification de l'ISA mais fragmentation des microarchitectures
Posté par sjub . Évalué à 6.
De mon point de vue, le risque est la prolifération de plein de microarchitectures différentes supportant la même ISA. Une même ISA, c'est bien pour la portabilité du code mais pas pour la portabilité des perfs. Et il va y avoir celles qui seront documentées, et les autres bien opaques : c'est in/out of order ? combien de ports FMA ? c'est quoi la latence/throughput de tes instructions ? la largeur de ton unité SIMD ? etc. Un peu comme sur Arm entre un Cortex et des designs customisés genre M1, Graviton4, A64FX, etc. Et après dans le compilo il faudra un flag pour chaque type, comme c'est déjà le cas aujourd'hui mais sans doute avec un encore plus grand nombre de "saveurs". Bref, encore du boulot !
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par BAud (site web personnel) . Évalué à 10. Dernière modification le 16 juillet 2024 à 16:18.
alors
si je te parle de MST / MSO dans les Telco, tu penses à quoi si je n'indique pas la signification à la 1ère utilisation ? (et encore, j'ai donné le contexte…)
Mais que cela ne t'empêche pas de préciser ta pensée (et tes sigles / acronymes), c'est intéressant ;-)
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par Aldebaran (site web personnel) . Évalué à 1. Dernière modification le 06 août 2024 à 16:34.
Histoire de recentrer les débats (parce que ça déborde pas mal) pour FMA, plus FMAB ou son aîné FMA ? Perso je préfère FMA.
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Les flags pourrait être utilisable si ils sont inclusifs.
Si tu as 4 groupes d'instructions, cela te donne 16 combinaisons possibles : aucune chance que les logiciels gèrent toutes les combinaisons.
L'histoire du x86 permet de voir ce qui se passe : au début, seul les instructions de base sont utilisés (Debian compilé en "i486"), le reste ne l'est pas. Puis, le SSE 2.1 devient utilisé lorsqu'il est inclus dans AMD64. Certaines instructions spécialisés sont utilisé parfois très localement (instruction AES dans openssl), ou le SIMD dans les jeux et photosphop.
Le fait d'avoir une instruction gérée par le compilateur ou non, change tout sur son adoption, mais attention aux problèmes de retro-compatibilité.
Pour que cela marche pour le RISC V, il faut avoir 4 saveurs : lite, base, medium, large, avec lite, sans option, et large tout inclus.
Ainsi, il n'y a que 4 versions de codes à gérer au pire.
"La première sécurité est la liberté"
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par jch . Évalué à 2.
Il ont récemment défini les profils standard RISC-V. Ce n'est pas tout-à-fait ce que tu proposes :
Le plan, si j'ai bien compris, c'est que Linux recquière RVA20U64. Je ne sais pas s'ils comptent définir un profil plus large lorsqu'ils auront réussi à se mettre d'accord sur une extension SIMD.
Par contre, je doute qu'ils définissent un profil raisonnable pour systèmes embarqués, même ARM ne l'a pas fait.
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Si tu définies 2 ou 3 profils très bien gérés par GCC, personne n'utilisera tes extensions privées sauf dans ton code perso de ton chip perso : Code qui sera incompatible avec la terre entière.
Si tu rajoutes linux, ou freertos, threads ou autre OS embarqué, tu peux vraiment fixer l'usage. SSE2.1 a vraiment été utilisé à partir de la sortie de l'AMD64.
"La première sécurité est la liberté"
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par tao popus . Évalué à 2.
Il faut vraiment oublier le SIMD, C'est pourrit, RISC-V à définit dès depuis des années une extension vectorielle (actuellement nommée RVV), l'avantage, par rapport au SIMD:
* Sur un SIMD, tu as des instructions qui chargent les données, les traite et les sauvegarde, puis il faut indiquer les données suivantes et recommencer via une boucle.
* Sur un processeur vectoriel, tu donne une séquence de données, la séquence de commandes à y appliquer, et ça se pipeline tout seul pour gagner en latence. Plus la séquence de données est importante, plus on gagne en performances dans le deuxième cas par rapport au premier.
Le kernel Linux le gère déjà et l'utilise notamment pour la crypto (on imagine l'intérêt pour le déchiffrement d'un gros fichier). GCC depuis la 14 commence à auto-vectoriser en RVV,
Il y a aussi un outil pour du SIMD SSE x86_64 vers du RVV RV64 plus ou moins automatiquement (comme premier pas, ça peut aider à automatiser), probablement inspiré d'autres pour convertir automatiquement de SIMD x86 vers du SIMD PowerPC ou ARM.
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par reno . Évalué à 2. Dernière modification le 08 août 2024 à 14:08.
Bah, tant que c'est vraiment la même ISA ça va encore, après tout c'est déjà le cas dans le monde x86.
Mais RISC-V autorise des extensions privées et ça, ça peut être un vrai problème.
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par tao popus . Évalué à 1.
Bof, tant qu'elles sont décrite ouvertement. à l'inverse dans le noyau Linux, l'extension RISC-V vectoriel 0.7 qui en était la première spécification, faite par tous les participants, n'a été produite que par T-Head, et c'était pendant 2 ou 3 ans le seul disponible de toute façon. Pour pas perdre cela ça a été passé comme extension T-Head, bien que ce soit les spécifications ouverte.
Voir toutes les extensions aujourd'hui gérée dans le noyau, la suite GNU, Qemu, l'émulateur RVVM (moins complet mais 3* plus performant que Qemu un tas d'implémentation pour FPGA, ou la variété disponiblle en ASIC, pour voir que ça n'est pas un si gros problème que ça. Pas plus que le nombre d'extension sur les autres architectures. GCC permet de passer des flags RV64GC (pour le général, utilisé dans Arch-RISC-V ou Debian RISC-V par ex. RV64GC est l'équivalent de RV64I(MAFD)C pour Integer, Mul/div entier, Flottant, Double et instruction Compressées sur 16bits), RV32I pour seulement les entiers en 32 bits etc, et compilera en fonction de l'architecture cible. Le standard n'étant pas encore mort, il va continuer à évoluer, avec, la nouvelle habitude de mettre l'année de la publication de la specification.
C'est ce qui s'est toujours passé dans toutes les architectures, et ça n'a jamais été un problème majeur. Le noyau se charge de détecter les extensions présentent et les utilise ou pas.
Par contre, le fait de pouvoir n'en sélectionner que quelques unes et un avantages pour réduire le nombre de portes et multiplier les cœurs à nombre de transistors équivalents.
# À part l'ISA ?
Posté par jseb . Évalué à 2.
À part l'ISA, autre chose est open-source ?
Je vois que certaines implémentations matérielles sont open-source, mais ce qui va se retrouver dans les micro-controleurs vendus en masse le sera t-il également ?
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: À part l'ISA ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Dans un premier temps probablement que non, mais il se pourrait bien qu'une partie du matériel open-source soit soutenu par la communauté et donc vive bien. Un peu comme Linux. Ce qui est vendu n'est pas open-source mais beaucoup de firmes y contribuent à commencer par Microsoft et Google… au final on arrive à des OS comme Debian ou Ubuntu 100% open-source.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: À part l'ISA ?
Posté par RoyalPanda . Évalué à 2.
Juste parce que je suis un vieux grincheux :
Hmm. Les premières distrib étaient là avant et ce n'était pas vu d'un bon œil de la part des grands acteurs économiques du secteur. C'est relativement récent l'open source friendly des grands firmes et je dirais que ça c'est fait contre leur volonté.
[^] # Re: À part l'ISA ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Disons que Debian fait quand même partie des premières distrib ;-)
[^] # Re: À part l'ISA ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 11 août 2024 à 18:33.
Assez vite certaines firmes ont soutenu l'open-source, d'abord en sous-main puis officiellement. Sinon, Linux entre autres n'aurait jamais pu connaitre le développement qu'il a connu. Les premiers contributeurs étaient bel et bien des passionné bénévoles, mais très vite quelques entreprises y ont vu un intérêt et ont financées directement ou indirectement quelques patch/évolutions. Bien sûr il ne faut pas oublié les raisons fiscales/politique… j'entends par là que cela permet aussi aux firmes de défiscaliser de la plus value en faisant des "dons aux associations" et cela permet de se faire bien voir.
Après au sein des entreprises, il y a les pionnier, les open-sources friendly et les réticents et tous les lots des ambigües.
Parmi les friendly, je citerai (Outre les entreprises de l'open-source comme Debian, Red-Hat et autres), Google, Facebook, Yahoo…
Parmi les ennemis et surtout les défenseurs des brevets logiciels et de leurs profit, je citerai Microsoft, Apple (Même si c'est un peu plus complexe et ils contribuent aussi beaucoup à BSD entre autre), et Amazon et Oracle (ces 2 dernières restant es pires).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: À part l'ISA ?
Posté par tao popus . Évalué à 1.
Pourquoi parler au futur ? Les micro-contrôleurs sont déjà vendus en masse, environ 500 millions avaient été vendus en début 2024. Ils sont déjà inclus dans tous les SoC de Qualcomm pour la basse conso, dans les GPU Nvidia, dans les contrôleurs disques de différentes marques, différents ESP-32 sont en RISC-V ou mix RISC-V + Tencillia, plusieurs fabriquants de SoCs (Sophgo, Bouffalo, Rockchip, etc) font un mix ARM+RISC-V (avec l'un ou l'autre, selon les cas, comme processeur le plus efficace, des fois mix micro-controlleur+microprocesseur, linux tournant dans certains cas sur le cœur RISC-V), on en trouve dans les satellites artificiels de l'ESA, etc.
On est plus ou moins dans le futur pour les micro-processeurs, bien qu'il en existe déjà depuis des années. Les pilotes graphiques sont encore majoritairement priorio, ce qui limite son développement. Android, GNU/Linux, les 3 *BSD, Haiku fonctionnent depuis déjà tous depuis ans dessus. Debian tourne depuis au moins 5 ans dessus par exemple, mais il y a toujours les derniers 5% de logiciels complexes à portés. ça a été le
# Le harware libre : Un combat initié depuis plus de 10 ans
Posté par libreX . Évalué à -1. Dernière modification le 11 septembre 2024 à 18:01.
L'idée est portée par l' opensource depuis le début. Mais le hardware est bien plus complexe à mettre en oeuvre que le software. Le frein est technologique. C'est le souci du matériel accessible aux passionnés capables de développer et maîtriser des technologies comme la lithographie et la mesure nanométrique. Heureusement que la miniaturisation avance. Le développement du Hardware libre est une bonne chose.
(le -4 sur le commentaire est un bug de la matrice: Attribué automatiquement)
[^] # Re: Le harware libre : Un combat initié depuis plus de 10 ans
Posté par Faya . Évalué à 3.
Pas un bug. La modération t'a déjà expliqué pourquoi tu postes en négatif automatiquement : karma négatif à cause des nombreux moinssages sur tes commentaires.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.