• [^] # Re: Encore du travail pour RISC V

    Posté par . 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

    • 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