Discussion :

[Guesset]

Bonjour,

Je me demande pourquoi il chauffe plus qu'un smartphone alors qu'il utilise des solutions de même type. Peut être parce qu'elles sont plus anciennes et quelles sont poussées en fréquence pour avoir des performances correctes ?

Salutations

[Steinvikel]

C'est très simple.
La fondation à l'origine des design du Rpi a axé le choix des composants sur du "open-hardware" (qui est PLEINEMENT documenté, et dont les docs sont accessibles à tous ET gratuitement). Ce "open-hardware" reçoit bien moins d'évolutions /contributions de la part des acteurs technologiques, qui dépenssent des millions (voir des milliards) sur l'élaboration de leur propre matériel, leur propres optimisations... le tout sous une documentation tenu secrète.

Ainsi donc, tu te retroves dans un monde ou un Rpi possède un CPU + GPU étant plus gourmand et moins perforrmant qu'un CPU de smartphone, qui embarque pourtant un iGPU.
Conclusion : c'est du moins bon matos, car moins travaillé ...mais c'est du "open-hardware", chose très rare à notre époque !

[Guesset]

Bonjour Steinvikel,

C'est très simple.
La fondation à l'origine des design du Rpi a axé le choix des composants sur du "open-hardware" (qui est PLEINEMENT documenté, et dont les docs sont accessibles à tous ET gratuitement)...

Il est fait référence à un processeur ARM qui, quelque soit les licences, n'est pas du open-hardware même s'il est bien documenté. L'évolution par rapport aux schémas ARM est au mieux marginale (sauf dans le cas rare car cher de la licence qui permet de tout redéfinir - bonjour Apple - hors la compatibilité au jeu d'instruction). Je pense que c'est le choix d'anciennes architectures (et peut être de taille de gravure) qui a le plus d'effet sur des performances un peu en retrait. Donc à mon sens plus des contraintes économiques, très compréhensibles, plutôt qu'un manque de ressources bénévoles.

Coté CPU, l'open hardware arrivera peut être avec RISC V .

Salutations

[Steinvikel]

Non effectivement.
Je me suis un peu emporté. ^^'

Le design a été pensé dès le début, transparent, accessible (la documentation), à moindre coût, et ne pas partir de zéro de manière absolu... mais juste réutiliser les composants qui existent déjà.

La première priorité est de proposer un produit axé pour l'éducation et la découverte /prototypage.
La transparence et l'accès à l'ensemble de la documentation a orienter le design à choisir uniquement des composants pleinement documentés, et des logiciels open-sources à minima.
La politique de proposer un équipement à moindre coût à naturellement orienter le design vers des éléments non brevetés lorsque possible, ou bien sur des brevets à moindre coût.
La partie CPU et GPU ne sont pas du open-hardware, c'est une concession pratique pour atteindre un minimum de performance. Ils sont tous deux sous des brevets Broadcom.

Un certain Eric Anholt a permi de pousser la balance pour inciter Broadcom à "lâcher" la documentation du GPU (de type VideoCore IV).
Au 2e anniversaire du Rpi (2014), Broadcom publie la documentation intégrale partielle du GPU
(uniquement le GPU et VPU, pas le CPU, et ne contenant pas la source du bloc HDMI, du bloc de gestion du processeur ARM, et de ThreadX ...ni le compilateur C (alors que le VPU utilise une architecture unique)).
Cela concerne donc la totalité du code source des drivers OpenGL ES 1.1 et 2.0 pour le GPU Broadcom VideoCore IV 3D utilisé dans le SoC BCM21553, BCM2835...
Et un peu plus tard, on découvre l'apparition de pilotes vulkaniens (Vulkan).
Ce fut un tournant majeur, car jusque là, c'était des binaires propriétaires non divulgués qui permettait l'usage du GPU, et il se trouve que l'une des premières étapes de boot s'appuie sur un firmware du GPU.
On a alors vu un gain de perf graphique de l'ordre de 100%.
Note j'ai entendu dire qu'il n'était livré que sur le Rpi 2, je n'ai pas vérifier la véracité de ce fait.

Néanmoins, il reste des blobs propriétaires pour une simple raison : pouvoir décoder du H264, MPEG and VC1.

Attention: bien que des drivers libres existe pour les GPU BideoCore IV (Rpi 1 à 3 en passant par les pi-zero), les Rpi 4 s'appuient quand à eux sur VideoCore VI ...je ne pense pas qu'il existe des drivers libres pour ceux-là.
(et j'élude la question du micro-code)

j'ai retrouvé un lien vers un équivalent open-hardware du Rpi ...dont certaines cartes ont un port SATA !
https://www.olimex.com/Products/OLin...ource-hardware
...en attendant l'équivalent RISC-V effectivement. : )

En résumé, Rpi n'est pas du open-hardware, mais il s'y confond sur une majeur partie du projet. =)