Implémentation matérielle ou logicielle, quels impacts sur les puces ?

Nous continuons aujourd'hui notre voyage au cœur de la fiabilité de nos chères puces au silicium et du hardware, après avoir expliqué les évolutions en cours dans l'industrie des PCB et l'importance croissante de la conception analogique. Toutefois, aujourd'hui nous nous pencherons sur des pistes plus larges, car la conception des puces n'est pas que matérielle, mais aussi logicielle, avec l'utilisation des drivers, BIOS et autres implantations codées versus les circuits dédiés à des calculs précis. 

Pour comprendre le débat, il faut se pencher sur l'évolution des demandes au niveau des unités de calcul, qui doivent prendre en compte de plus en plus d'algorithmes complexes, que ce soit pour le domaine professionnel avec les IA, le machine learning ou le Big Data. Cependant, le domaine consumer commence à être touché, avec l'apparition des traitements lourds comme le raytracing et le supersampling par machine learning, qui deviennent un des nouveaux nerfs de guerre dans la bataille des GPU. Par conséquent, il est légitime de se poser une question simple et pleine de sens : quels sont les impacts du développement de ces solutions autant sur le plan logiciel que matériel, outre que les performances ?

Courbe simplifiée de lien entre le temps et la fiabilité.

L'approche par le hardware 

L'implémentation matérielle est souvent la solution mise en avant lorsque nous recherchons la qualité, l'efficacité et les meilleures performances. Elle peut être aussi gage d'une fiabilité exemplaire, à condition que celle-ci soit bien conçue, ce qui en est le gros souci : une fois une architecture matérielle définie, il devient difficile de la modifier, il faut donc s'assurer en amont qu'elle soit impeccable, ce qui demande du temps, de l'argent et des moyens humains en conséquence. Parfois, cette approche demande donc plusieurs générations, à l'instar des puces Ryzen, qui arrivées à la 3ème itération - si nous comptons Zen+ comme une étape transitoire - deviennent très performantes et matures. Cela se vérifie aussi sur les GPU RTX ou RDNA, qui commencent à faire leurs preuves et à pouvoir gérer des éléments jusque là impossibles en temps réel, grâce à la création de nouvelles unités dédiées.

Malheureusement, cette approche dispose aussi d'un désavantage conséquent : plus l'architecture se complexifie, plus il de vient difficile, long et couteux de la produire. Nous entendons au loin certains qui diraient "oui mais voilà, l'économie d'échelle...", un argument de moins en moins vrai, avec des productions en flux tendus qui ne semblent plus justifiés, un manque de stocks en conséquence et des services marketing qui semblent loin d'être au courant de la production réelle. Alors oui, l'évolution matérielle est intéressante et nécessaire, toutefois nous devons apprendre à devenir patients - actuellement les stocks des cartes Ampere et RDNA2 sont quasi inexistants - si elle est trop mise en avant, et le coût de R&D en conséquence peut se montrer faramineux, voire prendre trop de temps, à l'instar des puces en 10 nm de chez Intel.

L'évolution des puces ne passe pas uniquement par la gravure, mais aussi par l'intégration de nouvelles fonctionnalités. (source : ITRS)

Vous avez dit lignes de code, non ?

À côté nous avons aussi l'implémentation logicielle, qui se base sur des unités plus génériques, certes moins puissantes, mais qui peut fournir des améliorations intéressantes, tester de nouveaux algorithmes et vérifier la compatibilité entre les appareils avant de recourir à des optimisations matérielles. Elles ont souvent été discréditées par le passé en étant qualifiées de peu fiables ou de boguées, car le souci du détail sur les lignes de code est parfois jugé moins important que le routage d'un circuit électronique.

Pourtant, cette approche devient de plus en plus intéressante et fiable, notamment grâce à des méthodes d'amélioration continue - non, nous ne parlons pas de méthodes agiles, mais bien de procédures intégrant toute une équipe - et en exploitant de mieux en mieux les optimisations des unités de calcul ou en créant des interfaces de plus bas niveau, comme DX12 pour les GPU. Or il ne faut pas oublier que cela ne remplacera pas indéfiniment les évolutions architecturales, l'exemple de Skylake chez les bleus montre qu'il faut faire évoluer le matériel de temps en temps tout de même, sans quoi un fabricant peut vite devenir obsolète.

Les cocktails, le meilleur choix

Alors dans tout ça, comment obtenir les meilleures générations de puces, que ce soit pour le particulier qui aime jouer ou les gros datacenters ? Dans les deux cas, le souci reste le même : l'évolution du hardware doit provenir non pas forcément de telle ou telle méthode, mais du sérieux porté à sa fabrication. De bons drivers, de bons BIOS ou de bonnes évolutions du microcode seront tout aussi bien, voire meilleurs, que de simplement mettre à jour la conception des puces en dur, sans s'assurer derrière de la fiabilité des galettes de silicium, des capacités de production ou de la survie sur le long terme.

L'évolution sur les deux plans des puces semble être la plus performante, mais renforce le fossé entre les capacités des puces et la productivité des usines...

C'est donc une réflexion sur ces deux éléments qui est à prioriser, notamment au niveau de la R&D, qui doit être conjointe afin d'éviter d'éventuels soucis lors des évolutions, comme les soucis sur les puces mémoires des premières cartes Turing ou les écrans noirs sur les premières cartes RDNA. Des évolutions qui doivent donc non pas seulement être meilleures sur les performances, mais aussi accessibles, réfléchies et prévues pour le long terme, si nous voulons être utopiques. (source : Semiengineering)