CJC (chinois japonais coréen, calque de l'anglais CJK, en raison de l'ordre alphabétique) devrait être remplacé par CCJV (chinois, coréen, japonais, vietnamien), le vietnamien l'ayant utilisé jusqu'à 1954 et l'utilisant toujours en partie.
On ne dit pas idéogramme, mais sinogrammes (caractères chinois) dans les quatre langues l'utilisant, on parle plutôt de caractères han ce qui est plus juste et est le nom donné dans les quatre principales langues l'utilisant.
Le Viêt Nam fait aussi partie de la 1ère sphère culturelle chinoise (celle qui utilise les caractères chinois qui ne sont pas que des idéogrammes) et à utilisé les caractères chinois jusqu'à environ 1954, lors de don indépendance avec la France. Pourtant si l'invention de cette translittération est plus ancienne, ce sont les français qui ont poussé à apprendre à l'école l'écriture latine pour le vietnamien, mais les 2 systèmes étaient utilisés en parallèle dans les documents officiels.
Les caractères chinois, sont comme en Corée, toujours présent sur de nombreux monuments, et utilisés sur des symboles de fêtes ou religieux. Les érudits confucéens l'apprennent toujours, et on trouve encore quelques sites web en écriture chinoise du vietnamien. Par contre, si la partie CJV est relativement homogène, à la fois dans les formes traditionnelles, et dans les formes simplifiées (à commencé à la fin du XIXe, mais a été plus massif au XXe siècle en japonais , puis encore plus en chinois de chine continentale) le vietnamien se distingue par la création de nombreux nouveaux caractères, suivant toujours les règles étymologiques de construction chinoises, mais apportant de nouveaux caractères.
La Nôm preservation foundation a crée les NomNaTong fonts pour les supporter. Les fontes NOM A et NOM B, qui deviennent dures à trouver apportent aussi une assez bonne partie de ces caractères spécifiquement vietnamien.
On ne devrait pas d'ailleurs dire chinois, mais han, la population chinoise qui utilise les caractères han. Il y a aussi une adaptation au Zhuang, le Sawndip, mais cette langue de la première minorité de Chine (principalement Région autonome zhuang du guangxi, mais également des parties des provinces avoisinantes et au Vietnam), est principalement écrite en latin. Elle fait partie de la famille des (langues kra-dai](https://en.wikipedia.org/wiki/Kra-Dai_languages) de Chine, une famille de langue comprenant le thaïlandais et lao. Ce sous ensemble fait donc partie des langues chinoises, mais pas des langues han qui font partie de la famille des langues sino-tibétaines (le terme sino n'étant encore un fois probablement le plus approprié). Il y a aussi plein de langues au Viêt Nam, Japon (certaines sont éteintes suite au nationalisme des XIXe et XXe), et probablement dans les deux Corées, mais la langue nationale correspond également au nom du pays, dans ces différents cas.
Le but est de fournir des outils de développement, donc produit en petite quantité, il vaut mieux passer son chemin si on à pas la volonté de travaillé au déploiement ou débogage de GNU/Linux ou autre OS sur ce type d'archi pour le moment, ça commencera peut être à devenir concurrentiel dans 2 ou 3 ans… Si on est pas tous morts cuits+noyés+emportés par un ouragan d'ici là. Ça avance à grand pas, mais le grand pas dans l'ajout de nouvelles architectures, ça prend des années, les SoC généraux sur RISC-V ont commencé il y a à peine 3 ou 4 ans, les premières optimisations de Linux et GCC, seulement cette année.
Mais par contre, dire que ARM s'est déclarée britannique est maladroit, elle a été crée au Royaume-Uni, dans les cadre de BBC Micro (enseignement informatique publique britannique à destination des jeunes écoliers), et les premiers ordinateurs à avoir utilisé ces puces étaient les Acorn Archimed. Celui-ci explosait les perfs de tous les autres micro-ordinateurs, qui utilisaient alors tous des processeurs de technologie CISC. Les PC bien que 5 à 10 fois plus chers que les micro-ordinateurs de l'époque étaient complètement largués au niveau des performances.
Concernant les performances, à fréquence et finesse égale un RISC-V est plus performant, mais pour le moment dans le domaine des processeurs, on part avec des années de retard, il n'y a pas que le cœur lui même à développé, mais le bus, tout ce qui est interaction avec le reste de l'architecture, le travail de cohérence des caches, etc. Certains cœurs arrivent pourtant déjà au niveau de cœurs ARM proche des hauts de gammes (Cortex-A7x). Le bus des SoC RISC-V actuels réutilise un bus produit par ARM et décrit sous licence-libre, le bus AMBA.
Heuuu, le premier concepteur de RISC-V (David Patterson) est tout simplement celui qui à créé l'architecture RISC, dans les années 80~90, qui était destiné à remplacer les architecture CISC, et tout le monde à abandonné ce dernier sauf Intel/AMD/Cyrix avec l'architecture x86 et clones et sa possibilité de dominer le marché.
On s'attendait à ce que ça devienne la norme à l'époque, comme déjà plus performant, mais finalement, le standard ouvert d'IBM PC qui à permit à des tas d'entreprises de produite à faible cout des compatible IBM PC, à fait prendre l'avantage à Windows + Intel (puis au moment du passage des x86 aux 64bits, AMD avec son archi x86_64, l'Itanium d'Intel ayant été un bide). Ils ont juste bouffé tout le marché avec ça. Ça a partiellement tué l'architecture RISC, qui était sur tous les gros serveurs à l'époque. Ça a baissé les coûts d'entrée, au prix d'une plus grosse consommation d'énergie => moins de performances, pour arriver au même résultat.
Le fait que ARM continue dans l'embarqué, puis son arrivée sur les téléphones et tablettes qui ont pris une part importante du marché, et où un CISC est clairement inutilisable (soit énorme téléphone, soit autonomie pourrie), à participer grandement au retour en masse. Les portages multi-architectures sont allé de paire, avec de plus en plus de SBC et portables (tablette + claviers, Chromebook, etc) en ARM. Ça a été un bide pour Windows, ça ne l'est pas pour Linux et tous les systèmes libres (*BSD, systèmes embarqués/temps réels), qui sont visiblement plus facilement portables.
RISC-V est une évolution extrême du principe du RISC, bénéficiant d'années d'évolution et de connaissances avec une architecture encore plus efficace. Elle arrive également à un moment, ou ARM domine le marché global des SoC (embarqué, mobile, certains supercalculateurs, mais pas ordinateurs fixes de bureau et serveurs, bien qu'il y en ai aussi). Ce phénomène est à lié aussi aux logiciels open-source qui ont pris le gros du marché du développement, et à la baisse des coûts des fabrications de circuits imprimés, et des FPGA, à permis à n'importe qui de pouvoir créer son implémentation de processeur, et ça tombe bien, puisque l'ISA RISC−V, dans sa version minimale à une très petite empreinte, et permet donc d'être déployé sur une carte FGPA à moins de 10€, ou une version plus complète sur des versions plus évoluées, et on trouve des dizaines de softcores opensource, dans différents langages HDL ou plus haut niveau, dont une implémentation en moins de 1000 lignes (et 2K LUT), en langage Silice ou le [PICO-RV32 qui utilise entre 750 et 2K LUT)(https://github.com/YosysHQ/picorv32) et qu'on retrouve sur pas mal de plateformes FPGA comme processeur de démo.
Sa modularité extrême en fait un processeur idéal pour le mode veille ou bien des applications très spécifiques dans l'embarqué, où seul les extensions nécessaires sont mis dans le SoC, et permet de remplacer des vieilles architectures, dont les outils (compilateurs, os, etc) ne sont pas forcément au point ni maintenus. Le nombre d'OS libres (embarqués, puis serveurs + bureaux) disponible sur cette architecture étant vraiment important, il faut plutôt chercher ceux qui ne le sont pas encore ;). Sa modularité et légèreté, permet également d'avoir un plus grand nombre de cœurs à nombre de transistor ou surface égale par rapport aux autres architectures.
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
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.
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.
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
On peut se limiter aux instructions les plus réduites et ainsi, avoir une efficacité énergétique hors paires. C'est pour ça qu'on le trouve déjà notamment, dans pas mal de SoC pour le mode veille, même d'architecture « éveillée » différente.
À fréquence égale un cœur consomme beaucoup moins en général, et offre de meilleures performances, mais aujourd'hui les échantillons étant, en dehors de l'embarqué, en petit nombre, principalement à destination des développeurs, la gravure est moins fine, la fréquence moins élevée que sur des architectures gravée pour la vente en masse, ça avance.
Il y a encore des optimisation à porter sur RISC-V, les noyaux Linux 6.x (Linux est le principal noyau utile pour le non-embarqué ) ont depuis le début de l'année environ pas mal d'optimisations en assembleur sur des fonctions de base, et depuis peu des plus avancées, comme l'utilisation du processeur vectoriel pour le chiffrement.
GCC 14 est le premier à supporter vraiment le processeur vectoriel et pas mal d'autres extensions, que se soit au niveau de son assembleur, (à partir de source en assembleur, il fallait des patchs depuis 2 ou 3 ans) ou de l'auto-vectorisation (automatisation de la génération à la compilation de code source C ou autre) :
** 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
Ayé, ça vire au politique, bien qu'il n'y ai pas de rapport. On pourrait dire que Dunin, s'est méfié des politiques de Trump et Biden, et à préféré fuir comme l'a fait la RISC-V foundation avant. Qu'il a préféré boycotter les États-Unis en raison des nombreuses guerres qu'il font partout (Irak, Afghanistan, Syrie (où ils sont toujours illégalement), Yémen pour les plus récentes), et financement sans faille du génocide en Palestine, comme il soutenait autrefois l'Afrique du Sud de l'apartheid, sans parler de l'enfermement de Julian Assange, du suicide de Aaron Schwartz etc. On pourrait aussi rappeler que, comme l'on noté tous les grands quotidiens US, le fils de Biden, Hunter Biden, est à la tête de Burisma, la plus grande compagnie pétrolière ukrainienne, depuis 2014, et qu'il y a beaucoup de pétrole dans les eaux territoriales de Gaza.
« fourcher » tout simplement ? Comme dans « ma langue à fourché ». La fourchette est la petite fourche, mais il me semble que fork c'est avant tout la fourche.
Par contre Angie est développé par le développeur original de Nginx, Dounin est arrivé après.
Il y a aussi depuis au moins 10 ans le fork permanent Tengine d'Alibaba, qui apporte pas mal de fonctionnalités et le patch qui produit OpenResty (et qui fait que quelque soit les stats, nginx, incluant ses différentes variantes, est toujours en tête du classement).
J'oubliais un élément moins connu des cartes le SPI flash, une eeprom de quelques Mo qui contient un micrologiciel permettant, notamment, et sur certaines cartes de sélectionner l'ordre de boot entre eeprom (principale)/réseau/SATA/sd/USB/etc…
Uboot implémente aussi depuis quelques temps (mais pas eu de carte+boot l'utilisant) des fonctions graphiques, permettant d'initialiser l'écran et d'avoir des menus etc donc.
Contrairement à ce qui est dit dans l'article, il y a bien une unification par architecture avec Device Tree, dant queles pilotes sont dispo. Les versions spécifiques de ARMbian (ou d'autres distros), sont liés à certains périphériques pas encore présent dans le noyau mainline. Je boot personnellement du mainline sans bidouille sur plusieurs cartes ARM ou sur du RISC-V. Ça marche aussi bien avc U-Boot, LibreBoot, CoreBoot (ou OreBoot la version rust). RISC-V dispose aussi d'OpenSBI pour faciliter le standard, des fonctions d'aides génériques ouvertes.
Il y a aussi Linuxboot qui utilise le noyaux Linux pour le boot, permettant d'éviter d'avoir à dupliquer les pilotes du Device Tree. Mais ça peut être un peu lourd pour des systèmes limités si Linux n'est pas le système cible.
La légende du besoin d'UEFI pour arriver à un boot qui fonctionne sur différentes cartes/Soc utilisant la même ISA (instruction Set Architecture: ARM, RISC-V, Power, x86 etc) est tenace et fait perdre des ressources avec des devs qui s'engagent sur la mauvaise voie :(.
Tout à fait, c'est une tête de vache/bœuf d'ailleurs à l'origine en phénicien 𐤀, qui s'est fait retournée avec l'évolution des écritures alphabétiques autour de la méditerranée jusqu'au LATIN => A. le a minuscule est arrivé plus tard à priori. Je crois que c'est avec l'écriture mérovingienne (dérivé de l'écriture manuscrite latine) ou la minuscule carolingienne ?
C'est l'industrie liée au BIOS et à Windows qui le met en avant, pour pouvoir continuer à cacher le code de leur pilotes pourris, pas les développeurs Linux. Linux utilise Device Tree par défaut, comme u-boot, Apache Nutt-X et pas mal d'autres systèmes.
Non, ça n'est pas le standard, c'est un des standard, l'autre étant device tree, qui garanti une meilleure portabilité, des pilotes plus légers etc, et qui ne favorise pas les firmwares fermés. Comme je disais les
Avec EFI, on passe par le "firmware" (u-boot la plupart du temps sur les cartes ARM) qui va se charger pour nous de tous ces détails. Et donc notre bootloader n'a plus besoin d'aucun code spécifique à chaque plateforme.
Aucun rapport, les firmwares restent spécifiques à chaque plateforme, comme dans le cas du BIOS, ils sont juste fermé et ça paraît donc transparent pour l'utilisateur, mais il n'y a pas de miracle, il faut bien initialiser et communiquer avec les différents composants. Device tree utilise une interface unifiée, stable et légère, facilement gérable, contrairement à UEFI. Une initialisation via device tree, permet également de démarrer de façon transparente sur différent type de cartes ayant la même architecture de processeur, c'est ce qui est utilisé par exemple par Arch Linux ARM. UEFI c'est un retour à l'ère de BIOS, il faut bien prendre conscience de ça.
On peut se procurer des RISC-V depuis pas mal de temps, en plus des émulateurs dont Qemu.
Je ne me suis jamais inscrit à une liste d'attente pour me procurer mes dizaines de cartes variées comportant du RISC-V… Il vaut mieux éviter les StarFive un peu trop fermée et qui manque cruellement de doc et plutôt s'orienter vers le Lichee Pi 4A plus performant et ouvert. Je l'ai reçu en moins de 3 semaines en le commandant sur le boutique Aliexpress de la marque, mais il y a aussi pas mal de microcontrôleurs variés, des tas de softCores pour FPGA etc… le choix ne manque donc pas, il n'y a pas trop d'excuse pour ne pas en avoir en matériel, si vraiment intéressé.
Dans le cas des cœurs SiFive, c'est un peu vrai, mais quasiment tout est déjà mainliné sur cette carte (en grande partie à coup de reverse), donc, non pas de firmware fermé, sur les procs de T-Head, ils travaillent eux même à l'intégration dans Linux par contre et font du assez bon travail.
Il n'y a pas que SiFive qui fait du RISC-V, niveau perfs les T-Head sont meilleures, et ont différentes finalités : processeurs pour desktop (le TH520, 4 cœurs, GPU, NPU, VPU, etc…), pour serveurs (un 64 cœurs), et d'autres déclinaisons, mais il existe différents autres acteurs faisant des cœurs RISC-V ouverts, dont les pilotes libres existent. Le but pour les sociétés asiatiques et européennes étant en partie de se débarrasser de leur dépendance à l'industrie de la Silicon Valley (en grande partie financée par l'armée) et de ses pressions sur les industriels et états. C'est aussi pour ça que la fondation RISC-V à déménagé en Suisse il y a quelques années.
Il y a également CAES qui à sorti NOEL-V en verilog, sous license GPL pour les satellites de l'ESA, ceux de l'Académie des sciences de Chine (Xianshan, etc…) et plus généralement des universités autour du monde, des amateurs éclairés, ou des sociétés. Au niveau de l'embarqué Espressif à sorti plusieurs SoC RISC-V également avec leur framework ESP-IDF complètement ouvert. Les SoC GD32V ont des pilotes ouverts aussi. Par contre le BIOS est complétement fermé, peu de carte x86/x86_64 ont la totalité de leur pilotes libres.
Non, ça sert à rien et pas de Windows de prévu pour l'instant sur RISC-V, et ça intéresse qui??? D'autre part, UEFI c'est uniquement fait pour continuer à utiliser du BIOS avec tous ses blobs binaires proprio. Device tree fait mieux et de façon plus propre le boulot. Ça permet une réutilisation (dans U-Boot, CoreBoot, LinuxBoot (dont le but est d'unifier le Noyau et la partie boot) et par différetnts OS embarqués libres par exemple, des informations des pilotes. Et bénéficie d'un peu de relecture par des paires, comme l'ensemble de Linux ou les spécifications de RISC-V. Et ça n'apporte rien non plus, un kernel générique basé sur Device tree, est également identique pour toutes les cartes ARMv7 aujourd'hui, UEFI n'apporte aucunement plus de portabilité.
Il n'y aura pas d'applications avant longtemps pour Windows non plus, puisqu'on sais même pas si Microsoft prévoit un portage à court terme, par contre toutes les distros majeures Linux/BSD et même Haiku fonctionnent déjà sur RISC-V, sans parler des OS embarqués qui le sont depuis encore plus longtemps. Il reste quelques JIT à (finir de) porter et c'est fondamental, on ne s'en rend pas forcément compte, mais le travail est quasi achevé
Il faut savoir que si les spécifications de l'ISA RISC-V sont ouvertes et libre de droit, ça n'est pas toujours le cas des implémentations. Il en existe tout un tas d'ouvertes, mais pas celles de SiFive utilisées dans le SoC de la VisionFive 2, malheureusement.
Le firmware est donné au goutte à goutte, par JH, la doc est inexistante et les firmware ne semble pas top (déjà pas de baisse de fréquence possible), il y a beaucoup de travail de hackers pour que cela fonctionne.
Sinon, le SoC T-Head TH1520 de la LicheePi4A est bien plus intéressant, non seulement l'implémentation des (4 également) cœurs + de différents cœurs annexes (comme le DSP basé sur du RISC-V aussi) sont ouvertes (les sources en Verilog sont dispo sur github entre autre), contrairement aux cœurs de SiFive, mais en plus les performances sont supérieures, et il y a des processeurs vectoriels intégrés et le GPU (PowerVR aussi, mais gamme au dessus, pilotes en cours d'ouverture aussi) est un poil plus performant également. L'intégration mainline est en court, le travail fait sur l'AllWinner D1, également basé sur les cœurs et différents autres composants de T-Head permet d'avoir déjà une base. Une version 64 cœurs à également été développée et les premières implémentations devrait être disponibles d'ici 1 ou 2 mois. Les performances d'après les quelques personnes qui ont put les tester sont alléchantes :).
Visiblement, il n'y a toujours pas de baisse de fréquence possible, le processeur tourne donc toujours à pleine puissance, ce qui explique la surchauffe.
Maintenant que PowerVR est (enfin) en train d'ouvrir ces pilotes, principalement dans une perspective de support RISC-V. Ça sera peut être l'occasion d'une mise à jour pour cette console (et les EEEpc 701). Je ne sais pas si il y aura du Full OpenGL dessus, comme ont fait les développeurs de Mali et Panfrost avec un GPU ne supportant officiellement que GL ES.
# CJC => CCJV, il faudrait arrêter de supprimer le vietnamien
Posté par tao popus . En réponse à la dépêche Unicode en version 16.0.0, le plein de hiéroglyphes égyptiens et de symboles informatiques. Évalué à 5.
CJC (chinois japonais coréen, calque de l'anglais CJK, en raison de l'ordre alphabétique) devrait être remplacé par CCJV (chinois, coréen, japonais, vietnamien), le vietnamien l'ayant utilisé jusqu'à 1954 et l'utilisant toujours en partie.
On ne dit pas idéogramme, mais sinogrammes (caractères chinois) dans les quatre langues l'utilisant, on parle plutôt de caractères han ce qui est plus juste et est le nom donné dans les quatre principales langues l'utilisant.
Le Viêt Nam fait aussi partie de la 1ère sphère culturelle chinoise (celle qui utilise les caractères chinois qui ne sont pas que des idéogrammes) et à utilisé les caractères chinois jusqu'à environ 1954, lors de don indépendance avec la France. Pourtant si l'invention de cette translittération est plus ancienne, ce sont les français qui ont poussé à apprendre à l'école l'écriture latine pour le vietnamien, mais les 2 systèmes étaient utilisés en parallèle dans les documents officiels.
Les caractères chinois, sont comme en Corée, toujours présent sur de nombreux monuments, et utilisés sur des symboles de fêtes ou religieux. Les érudits confucéens l'apprennent toujours, et on trouve encore quelques sites web en écriture chinoise du vietnamien. Par contre, si la partie CJV est relativement homogène, à la fois dans les formes traditionnelles, et dans les formes simplifiées (à commencé à la fin du XIXe, mais a été plus massif au XXe siècle en japonais , puis encore plus en chinois de chine continentale) le vietnamien se distingue par la création de nombreux nouveaux caractères, suivant toujours les règles étymologiques de construction chinoises, mais apportant de nouveaux caractères.
La Nôm preservation foundation a crée les NomNaTong fonts pour les supporter. Les fontes NOM A et NOM B, qui deviennent dures à trouver apportent aussi une assez bonne partie de ces caractères spécifiquement vietnamien.
On ne devrait pas d'ailleurs dire chinois, mais han, la population chinoise qui utilise les caractères han. Il y a aussi une adaptation au Zhuang, le Sawndip, mais cette langue de la première minorité de Chine (principalement Région autonome zhuang du guangxi, mais également des parties des provinces avoisinantes et au Vietnam), est principalement écrite en latin. Elle fait partie de la famille des (langues kra-dai](https://en.wikipedia.org/wiki/Kra-Dai_languages) de Chine, une famille de langue comprenant le thaïlandais et lao. Ce sous ensemble fait donc partie des langues chinoises, mais pas des langues han qui font partie de la famille des langues sino-tibétaines (le terme sino n'étant encore un fois probablement le plus approprié). Il y a aussi plein de langues au Viêt Nam, Japon (certaines sont éteintes suite au nationalisme des XIXe et XXe), et probablement dans les deux Corées, mais la langue nationale correspond également au nom du pays, dans ces différents cas.
[^] # Re: Performances
Posté par tao popus . En réponse au journal Le RISC-V pour le Desktop, on en reparle ?. Évalué à 1.
Le but est de fournir des outils de développement, donc produit en petite quantité, il vaut mieux passer son chemin si on à pas la volonté de travaillé au déploiement ou débogage de GNU/Linux ou autre OS sur ce type d'archi pour le moment, ça commencera peut être à devenir concurrentiel dans 2 ou 3 ans… Si on est pas tous morts cuits+noyés+emportés par un ouragan d'ici là. Ça avance à grand pas, mais le grand pas dans l'ajout de nouvelles architectures, ça prend des années, les SoC généraux sur RISC-V ont commencé il y a à peine 3 ou 4 ans, les premières optimisations de Linux et GCC, seulement cette année.
[^] # Re: Je reçois ma milk-v meles bientôt
Posté par tao popus . En réponse au journal Le RISC-V pour le Desktop, on en reparle ?. Évalué à 1.
Mais par contre, dire que ARM s'est déclarée britannique est maladroit, elle a été crée au Royaume-Uni, dans les cadre de BBC Micro (enseignement informatique publique britannique à destination des jeunes écoliers), et les premiers ordinateurs à avoir utilisé ces puces étaient les Acorn Archimed. Celui-ci explosait les perfs de tous les autres micro-ordinateurs, qui utilisaient alors tous des processeurs de technologie CISC. Les PC bien que 5 à 10 fois plus chers que les micro-ordinateurs de l'époque étaient complètement largués au niveau des performances.
Concernant les performances, à fréquence et finesse égale un RISC-V est plus performant, mais pour le moment dans le domaine des processeurs, on part avec des années de retard, il n'y a pas que le cœur lui même à développé, mais le bus, tout ce qui est interaction avec le reste de l'architecture, le travail de cohérence des caches, etc. Certains cœurs arrivent pourtant déjà au niveau de cœurs ARM proche des hauts de gammes (Cortex-A7x). Le bus des SoC RISC-V actuels réutilise un bus produit par ARM et décrit sous licence-libre, le bus AMBA.
[^] # Re: Je reçois ma milk-v meles bientôt
Posté par tao popus . En réponse au journal Le RISC-V pour le Desktop, on en reparle ?. Évalué à 3.
Heuuu, le premier concepteur de RISC-V (David Patterson) est tout simplement celui qui à créé l'architecture RISC, dans les années 80~90, qui était destiné à remplacer les architecture CISC, et tout le monde à abandonné ce dernier sauf Intel/AMD/Cyrix avec l'architecture x86 et clones et sa possibilité de dominer le marché.
On s'attendait à ce que ça devienne la norme à l'époque, comme déjà plus performant, mais finalement, le standard ouvert d'IBM PC qui à permit à des tas d'entreprises de produite à faible cout des compatible IBM PC, à fait prendre l'avantage à Windows + Intel (puis au moment du passage des x86 aux 64bits, AMD avec son archi x86_64, l'Itanium d'Intel ayant été un bide). Ils ont juste bouffé tout le marché avec ça. Ça a partiellement tué l'architecture RISC, qui était sur tous les gros serveurs à l'époque. Ça a baissé les coûts d'entrée, au prix d'une plus grosse consommation d'énergie => moins de performances, pour arriver au même résultat.
Le fait que ARM continue dans l'embarqué, puis son arrivée sur les téléphones et tablettes qui ont pris une part importante du marché, et où un CISC est clairement inutilisable (soit énorme téléphone, soit autonomie pourrie), à participer grandement au retour en masse. Les portages multi-architectures sont allé de paire, avec de plus en plus de SBC et portables (tablette + claviers, Chromebook, etc) en ARM. Ça a été un bide pour Windows, ça ne l'est pas pour Linux et tous les systèmes libres (*BSD, systèmes embarqués/temps réels), qui sont visiblement plus facilement portables.
RISC-V est une évolution extrême du principe du RISC, bénéficiant d'années d'évolution et de connaissances avec une architecture encore plus efficace. Elle arrive également à un moment, ou ARM domine le marché global des SoC (embarqué, mobile, certains supercalculateurs, mais pas ordinateurs fixes de bureau et serveurs, bien qu'il y en ai aussi). Ce phénomène est à lié aussi aux logiciels open-source qui ont pris le gros du marché du développement, et à la baisse des coûts des fabrications de circuits imprimés, et des FPGA, à permis à n'importe qui de pouvoir créer son implémentation de processeur, et ça tombe bien, puisque l'ISA RISC−V, dans sa version minimale à une très petite empreinte, et permet donc d'être déployé sur une carte FGPA à moins de 10€, ou une version plus complète sur des versions plus évoluées, et on trouve des dizaines de softcores opensource, dans différents langages HDL ou plus haut niveau, dont une implémentation en moins de 1000 lignes (et 2K LUT), en langage Silice ou le [PICO-RV32 qui utilise entre 750 et 2K LUT)(https://github.com/YosysHQ/picorv32) et qu'on retrouve sur pas mal de plateformes FPGA comme processeur de démo.
Sa modularité extrême en fait un processeur idéal pour le mode veille ou bien des applications très spécifiques dans l'embarqué, où seul les extensions nécessaires sont mis dans le SoC, et permet de remplacer des vieilles architectures, dont les outils (compilateurs, os, etc) ne sont pas forcément au point ni maintenus. Le nombre d'OS libres (embarqués, puis serveurs + bureaux) disponible sur cette architecture étant vraiment important, il faut plutôt chercher ceux qui ne le sont pas encore ;). Sa modularité et légèreté, permet également d'avoir un plus grand nombre de cœurs à nombre de transistor ou surface égale par rapport aux autres architectures.
[^] # Re: À part l'ISA ?
Posté par tao popus . En réponse à la dépêche Linus Torvalds: comment éviter que RISC-V ne reproduise les erreurs du passé?. É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
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par tao popus . En réponse à la dépêche Linus Torvalds: comment éviter que RISC-V ne reproduise les erreurs du passé?. É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.
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par tao popus . En réponse à la dépêche Linus Torvalds: comment éviter que RISC-V ne reproduise les erreurs du passé?. É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: Encore du travail pour RISC V
Posté par tao popus . En réponse à la dépêche Linus Torvalds: comment éviter que RISC-V ne reproduise les erreurs du passé?. É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: Dommage
Posté par tao popus . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à -6.
Ayé, ça vire au politique, bien qu'il n'y ai pas de rapport. On pourrait dire que Dunin, s'est méfié des politiques de Trump et Biden, et à préféré fuir comme l'a fait la RISC-V foundation avant. Qu'il a préféré boycotter les États-Unis en raison des nombreuses guerres qu'il font partout (Irak, Afghanistan, Syrie (où ils sont toujours illégalement), Yémen pour les plus récentes), et financement sans faille du génocide en Palestine, comme il soutenait autrefois l'Afrique du Sud de l'apartheid, sans parler de l'enfermement de Julian Assange, du suicide de Aaron Schwartz etc. On pourrait aussi rappeler que, comme l'on noté tous les grands quotidiens US, le fils de Biden, Hunter Biden, est à la tête de Burisma, la plus grande compagnie pétrolière ukrainienne, depuis 2014, et qu'il y a beaucoup de pétrole dans les eaux territoriales de Gaza.
[^] # Re: le titre m'a trompé !
Posté par tao popus . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à 4.
« fourcher » tout simplement ? Comme dans « ma langue à fourché ». La fourchette est la petite fourche, mais il me semble que fork c'est avant tout la fourche.
[^] # Re: Angie
Posté par tao popus . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à 3.
Par contre Angie est développé par le développeur original de Nginx, Dounin est arrivé après.
Il y a aussi depuis au moins 10 ans le fork permanent Tengine d'Alibaba, qui apporte pas mal de fonctionnalités et le patch qui produit OpenResty (et qui fait que quelque soit les stats, nginx, incluant ses différentes variantes, est toujours en tête du classement).
[^] # Re: Standardiser le boot sur équipements embarqué/arm.
Posté par tao popus . En réponse au journal Petitboot sur ARM, le bon, le bad et le ugly. Évalué à 1.
J'oubliais un élément moins connu des cartes le SPI flash, une eeprom de quelques Mo qui contient un micrologiciel permettant, notamment, et sur certaines cartes de sélectionner l'ordre de boot entre eeprom (principale)/réseau/SATA/sd/USB/etc…
[^] # Re: Standardiser le boot sur équipements embarqué/arm.
Posté par tao popus . En réponse au journal Petitboot sur ARM, le bon, le bad et le ugly. Évalué à 1.
Uboot implémente aussi depuis quelques temps (mais pas eu de carte+boot l'utilisant) des fonctions graphiques, permettant d'initialiser l'écran et d'avoir des menus etc donc.
Contrairement à ce qui est dit dans l'article, il y a bien une unification par architecture avec Device Tree, dant queles pilotes sont dispo. Les versions spécifiques de ARMbian (ou d'autres distros), sont liés à certains périphériques pas encore présent dans le noyau mainline. Je boot personnellement du mainline sans bidouille sur plusieurs cartes ARM ou sur du RISC-V. Ça marche aussi bien avc U-Boot, LibreBoot, CoreBoot (ou OreBoot la version rust). RISC-V dispose aussi d'OpenSBI pour faciliter le standard, des fonctions d'aides génériques ouvertes.
Il y a aussi Linuxboot qui utilise le noyaux Linux pour le boot, permettant d'éviter d'avoir à dupliquer les pilotes du Device Tree. Mais ça peut être un peu lourd pour des systèmes limités si Linux n'est pas le système cible.
La légende du besoin d'UEFI pour arriver à un boot qui fonctionne sur différentes cartes/Soc utilisant la même ISA (instruction Set Architecture: ARM, RISC-V, Power, x86 etc) est tenace et fait perdre des ressources avec des devs qui s'engagent sur la mauvaise voie :(.
# À propos de Firefox
Posté par tao popus . En réponse à la dépêche Revue de presse de l’April pour la semaine 46 de l’année 2023. Évalué à 3.
L'extension Stylish semble dérober des données personnelles. Une version communautaire, a été développé pour palier à cela : https://userstyles.world/
[^] # Re: Typo dans les versions zfs
Posté par tao popus . En réponse à la dépêche Proxmox Virtual Environment 8.1 avec SDN et Secure Boot disponible . Évalué à 2.
Toujours pas patché correctement: https://www.phoronix.com/news/OpenZFS-Data-Corruption-Battle
[^] # Re: Un d qui s'incline
Posté par tao popus . En réponse au sondage A priori, que représente « a » ?. Évalué à 5.
Tout à fait, c'est une tête de vache/bœuf d'ailleurs à l'origine en phénicien 𐤀, qui s'est fait retournée avec l'évolution des écritures alphabétiques autour de la méditerranée jusqu'au LATIN => A. le a minuscule est arrivé plus tard à priori. Je crois que c'est avec l'écriture mérovingienne (dérivé de l'écriture manuscrite latine) ou la minuscule carolingienne ?
[^] # Re: UEFI
Posté par tao popus . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 2. Dernière modification le 20 juin 2023 à 18:27.
C'est l'industrie liée au BIOS et à Windows qui le met en avant, pour pouvoir continuer à cacher le code de leur pilotes pourris, pas les développeurs Linux. Linux utilise Device Tree par défaut, comme u-boot, Apache Nutt-X et pas mal d'autres systèmes.
[^] # Re: UEFI
Posté par tao popus . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 3.
Non, ça n'est pas le standard, c'est un des standard, l'autre étant device tree, qui garanti une meilleure portabilité, des pilotes plus légers etc, et qui ne favorise pas les firmwares fermés. Comme je disais les
Aucun rapport, les firmwares restent spécifiques à chaque plateforme, comme dans le cas du BIOS, ils sont juste fermé et ça paraît donc transparent pour l'utilisateur, mais il n'y a pas de miracle, il faut bien initialiser et communiquer avec les différents composants. Device tree utilise une interface unifiée, stable et légère, facilement gérable, contrairement à UEFI. Une initialisation via device tree, permet également de démarrer de façon transparente sur différent type de cartes ayant la même architecture de processeur, c'est ce qui est utilisé par exemple par Arch Linux ARM. UEFI c'est un retour à l'ère de BIOS, il faut bien prendre conscience de ça.
# Pourquoi liste d'attente ????
Posté par tao popus . En réponse à la dépêche Un émulateur et un désassembleur Risc-V , couteaux suisses du hacker. Évalué à 2.
On peut se procurer des RISC-V depuis pas mal de temps, en plus des émulateurs dont Qemu.
Je ne me suis jamais inscrit à une liste d'attente pour me procurer mes dizaines de cartes variées comportant du RISC-V… Il vaut mieux éviter les StarFive un peu trop fermée et qui manque cruellement de doc et plutôt s'orienter vers le Lichee Pi 4A plus performant et ouvert. Je l'ai reçu en moins de 3 semaines en le commandant sur le boutique Aliexpress de la marque, mais il y a aussi pas mal de microcontrôleurs variés, des tas de softCores pour FPGA etc… le choix ne manque donc pas, il n'y a pas trop d'excuse pour ne pas en avoir en matériel, si vraiment intéressé.
[^] # Re: performances -> spectacles
Posté par tao popus . En réponse à la dépêche Robot humanoïde libre français Poppy. Évalué à 1.
Ou de plusieurs actes ?
[^] # Re: au final... ou entre temps ?
Posté par tao popus . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 6.
Dans le cas des cœurs SiFive, c'est un peu vrai, mais quasiment tout est déjà mainliné sur cette carte (en grande partie à coup de reverse), donc, non pas de firmware fermé, sur les procs de T-Head, ils travaillent eux même à l'intégration dans Linux par contre et font du assez bon travail.
Il n'y a pas que SiFive qui fait du RISC-V, niveau perfs les T-Head sont meilleures, et ont différentes finalités : processeurs pour desktop (le TH520, 4 cœurs, GPU, NPU, VPU, etc…), pour serveurs (un 64 cœurs), et d'autres déclinaisons, mais il existe différents autres acteurs faisant des cœurs RISC-V ouverts, dont les pilotes libres existent. Le but pour les sociétés asiatiques et européennes étant en partie de se débarrasser de leur dépendance à l'industrie de la Silicon Valley (en grande partie financée par l'armée) et de ses pressions sur les industriels et états. C'est aussi pour ça que la fondation RISC-V à déménagé en Suisse il y a quelques années.
Il y a également CAES qui à sorti NOEL-V en verilog, sous license GPL pour les satellites de l'ESA, ceux de l'Académie des sciences de Chine (Xianshan, etc…) et plus généralement des universités autour du monde, des amateurs éclairés, ou des sociétés. Au niveau de l'embarqué Espressif à sorti plusieurs SoC RISC-V également avec leur framework ESP-IDF complètement ouvert. Les SoC GD32V ont des pilotes ouverts aussi. Par contre le BIOS est complétement fermé, peu de carte x86/x86_64 ont la totalité de leur pilotes libres.
[^] # Re: UEFI
Posté par tao popus . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 10.
Non, ça sert à rien et pas de Windows de prévu pour l'instant sur RISC-V, et ça intéresse qui??? D'autre part, UEFI c'est uniquement fait pour continuer à utiliser du BIOS avec tous ses blobs binaires proprio. Device tree fait mieux et de façon plus propre le boulot. Ça permet une réutilisation (dans U-Boot, CoreBoot, LinuxBoot (dont le but est d'unifier le Noyau et la partie boot) et par différetnts OS embarqués libres par exemple, des informations des pilotes. Et bénéficie d'un peu de relecture par des paires, comme l'ensemble de Linux ou les spécifications de RISC-V. Et ça n'apporte rien non plus, un kernel générique basé sur Device tree, est également identique pour toutes les cartes ARMv7 aujourd'hui, UEFI n'apporte aucunement plus de portabilité.
Il n'y aura pas d'applications avant longtemps pour Windows non plus, puisqu'on sais même pas si Microsoft prévoit un portage à court terme, par contre toutes les distros majeures Linux/BSD et même Haiku fonctionnent déjà sur RISC-V, sans parler des OS embarqués qui le sont depuis encore plus longtemps. Il reste quelques JIT à (finir de) porter et c'est fondamental, on ne s'en rend pas forcément compte, mais le travail est quasi achevé
Il faut savoir que si les spécifications de l'ISA RISC-V sont ouvertes et libre de droit, ça n'est pas toujours le cas des implémentations. Il en existe tout un tas d'ouvertes, mais pas celles de SiFive utilisées dans le SoC de la VisionFive 2, malheureusement.
Le firmware est donné au goutte à goutte, par JH, la doc est inexistante et les firmware ne semble pas top (déjà pas de baisse de fréquence possible), il y a beaucoup de travail de hackers pour que cela fonctionne.
Sinon, le SoC T-Head TH1520 de la LicheePi4A est bien plus intéressant, non seulement l'implémentation des (4 également) cœurs + de différents cœurs annexes (comme le DSP basé sur du RISC-V aussi) sont ouvertes (les sources en Verilog sont dispo sur github entre autre), contrairement aux cœurs de SiFive, mais en plus les performances sont supérieures, et il y a des processeurs vectoriels intégrés et le GPU (PowerVR aussi, mais gamme au dessus, pilotes en cours d'ouverture aussi) est un poil plus performant également. L'intégration mainline est en court, le travail fait sur l'AllWinner D1, également basé sur les cœurs et différents autres composants de T-Head permet d'avoir déjà une base. Une version 64 cœurs à également été développée et les premières implémentations devrait être disponibles d'ici 1 ou 2 mois. Les performances d'après les quelques personnes qui ont put les tester sont alléchantes :).
[^] # Re: En data center
Posté par tao popus . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 4.
Visiblement, il n'y a toujours pas de baisse de fréquence possible, le processeur tourne donc toujours à pleine puissance, ce qui explique la surchauffe.
[^] # Re: devnewton, j'adore tes interviews !
Posté par tao popus . En réponse à la dépêche Entretien avec LuigiBlood. Évalué à 2. Dernière modification le 18 avril 2023 à 14:29.
Maintenant que PowerVR est (enfin) en train d'ouvrir ces pilotes, principalement dans une perspective de support RISC-V. Ça sera peut être l'occasion d'une mise à jour pour cette console (et les EEEpc 701). Je ne sais pas si il y aura du Full OpenGL dessus, comme ont fait les développeurs de Mali et Panfrost avec un GPU ne supportant officiellement que GL ES.
[^] # Re: Logique bibnaire
Posté par tao popus . En réponse au sondage Public de LinuxFr. Évalué à 3.
QCD : Questionnaire à choix démultipliés (ou autre terme à trouver)