Comme on s'y attendait, NVIDIA a profité de la Game Developer Conference (GDC) pour faire de nouvelles annonces sur l'évolution de son écosystème. Comme dans le domaine des serveurs, c'est l'adaptation à ARM et Linux qui concentre son intérêt. Cette fois avec le marché des joueurs en tête.
Ne vous y trompez pas, si NVIDIA investit dans ARM, ce n'est pas seulement pour s'opposer un peu plus à AMD et Intel dans les datacenters. C'est aussi pour s'offrir de nouvelles opportunités sur le marché des ordinateurs grand public. Sa précédente annonce de SoC MediaTek avec des GeForce allait dans ce sens. Le constructeur confirme la tendance.
Il vient en effet de faire la démonstration d'une GeForce RTX 3060 utilisée avec une puce MediaTek Kompanio 1200 capables de faire fonctionner une démo (The Bistro) et Wolfenstein : Youngblood sous Arch Linux, sans la moindre trace de puce x86, de Windows ou de DirectX. Ce, bien que plusieurs technologies maison étaient utilisées.
C'était notamment le cas du Deep Learning Super Sampling (DLSS) ou de RTX pour l'illumination directe/globale, OptiX pour le denoising, l'optimisation de l'utilisation de la mémoire graphique, etc.
Tant de couches logicielles portées pour ARM et Linux par NVIDIA. Le support est assuré pour Linux et Chromium, les SoC Mediatek avec GeForce étant notamment prévus pour fonctionner sous Chrome OS. RTXDI, NRD et RTXMU sont d'ores et déjà disponibles sur le site développeur de NVIDIA. Pour RTXGI et DLSS cela arrivera sous peu.
Une annonce qui intervient peu après celle de la compatibilité de DLSS avec Proton, pour son exploitation au sein de jeux sous Linux, bien qu'ils n'aient pas été développés spécifiquement pour ce système.
NVIDIA précise que cette avancée lui profitera aussi sur d'autres marchés, comme la conception automobile ou l'architecture, à travers le soutien d'applications comme l'Unreal Engine d'Epic Games. Il ajoute que la version de Wolfenstein : Youngblood utilisée ne sert que de démonstration technique et n'a pas vocation a être commercialisée.
Commentaires (22)
#1
Je suis assez ébahi par la vitesse à laquelle les poids lourds technologiques s’adaptent à l’ARM et tout autant stupéfait de voir que MS ne soit pas capable de montrer la même efficacité dans son ouverture à cette plateforme.
Certes ce sont des choses difficilement comparables mais on ne peut pas dire que MS ai pris le train en retard ni particulièrement snober l’idée, mais dans les faits on en est loin.
M’enfin je suis peut-être un peu HS.
#2
Tu compares des patates avec des tomates. Cherche voir comment Apple a conçu et utilise son CPU ARM avec macOS et comment MS fait (en gros le CPU ARM d’Apple est un monstre en… x86).
#3
Le fait que NVIDIA le fasse a surtout à voir avec leur stratégie globale et à long terme. Cela prend du temps, mais ils ont déjà adapté toute la stack CUDA-X, maintenant ils passent à des usages grands publics, et les prochaiines évolutions seront sans doute multiplateforme nativement. Mais vu que leur but est de contourner x86 et de se payer ARM, leur motivation est moteur de ces évolutions.
Pour Apple/MS c’est difficilement comparable, les contraintes et pratiques des deux acteurs ne sont pas du tout les mêmes. Apple est habitué à tout jeter pour repartir de zéro, là où une des forces de Windows (et donc sa principale faiblesse) est de constamment continuer à gérer l’existant.
#4
Pour Apple/MS, on peut tout de même remarquer que les puces M1 gèrent quasi-parfaitement la rétro-compatibilité x86 grâce à du logiciel d’Apple (Roseta 2 qui traduit le bytecode) ce qui fait du M1 et de la transition ARM un grand succès, alors que les tentatives de Microsoft sur ARM ont jusqu’ici été des échecs douloureux justement à cause du non-support du x86/win32, vu qu’ils n’ont proposé aucune technologie de transition (ou juste récemment en suivant Apple).
Apple a quand même réussi à deux reprises (IBM->Intel->ARM) là où Microsoft a échoué justement parcequ’ils ont très bien géré la rétrocompatibilité.
#5
bonjour,
Pour ce qui est du DLSS ce n’est pas étonnant qu’ils accélèrent, il y a Amd qui viens de passer en open source le code du FSR :
https://www.cowcotland.com/news/77265/le-fidelityfx-super-resolution-d-amd-passe-en-open-source.html
et en prime il y a déjà un patch pour le Unreal Engine 4.26 :
https://www.ginjfo.com/actualites/composants/cartes-graphiques/fidelityfx-super-resolution-alias-le-fsr-amd-publie-le-code-source-20210719
Epic Game soutien le DLSS, mais ils tournent pas le dos au FSR.
#6
Oui et non. Toute entreprise de ce genre a vocation a étendre son champ d’action. Apple fait dans l’intégratopn progressive, NVIDIA c’est un peu différent. Ils ont surtout une vision du CPU comme une “comodité” au sein des différents segments où ils sont présents, un composant qui doit laisser le GPU s’exprimer. Mais dans tous les domaines où ils sont x86 règne.
ARM leur permet de mettre en musique leur vision des choses tout en créant pas mal d’opportunités. Apple se moque de créer un écosystème (autre que logiciel) ou d’avoir une vision globale. Ils veulent juste proposer des produits 100% Apple (excepté les composants où ils ne peuvent créer leur propre valeur).
Pour Apple/MS, j’ai déjà précisé ma pensée et je ne vois pas quoi ajouter (outre le fait que MS ne fait pas ses propres CPU, ils se reposent sur Qualcomm principalement).
Je sais que tu vois tout par le prisme d’AMD, mais si tu penses que le portage ARM de telles solutions se décident en trois semaines pour “contrer” FSR alors que les stratégies entre cles deux acteurs sont à peu près opposées sur tous les points sur le sujet, c’est que tu n’as (encore) rien compris.
#7
D’un coté, je n’arrive pas bien à comprendre ce qu’ils veulent démontrer ici. En gros, j’ai tendance à conclure que NVidia a des pilotes pour ARM/Linux qui arrive utiliser les instruction de ray tracing (via OptiX ou Vulkan ? ) et CUDA (ce qui à me semblait déjà exister)
Mais sinon, j’ai l’impression que le vrai but de NVidia, c’est de montrer que ARM est une solution viable pour l’avenir (dans l’optique de confirmer que l’achat d’ARM est une bonne idée)
#8
C’est surtout une démo technique pour dire “eh coucou enfaite ça fonctionne sur ARM”. Le coeur de vente de Nvidia reste les GPU jusqu’à preuve du contraire.
Sauf qu’aujourd’hui le GPU reste en majorité à un CPU qui est X86, et les seuls fabriquant de ce genre de processeurs sont Intel, AMD (et Zhaoxin pour la Chine), ce qui est un gros manque car on dépend d’un fournisseur externe qui n’a pas forcément la même vision que toi. A contrario ARM et RiscV permettent (pour ARM moyennant finance vu qu’il y a le prix de la licence) de faire ses propres CPU, donc à la vision de l’entreprise.
C’est très intéressant car ça leur permet d’aller au bout de leurs idées et de leurs visions. L’exemple le plus probant est Apple ou la puce M1 n’est pas qu’un CPU, c’est un SoC (system on chip) avec des accélérateurs pour tout qui avec la bonne prise en charge logiciel enlève le CPU de lourds calculs. Lui il gère uniquement quoi envoyé à l’accélérateur, la finalité étant que les accélérateurs soit totalement indépendant du CPU. C’est ce qu’on peut voir aussi dans une certaine mesure avec DirectStorage.
#9
Nvidia veut devenir le futur Apple en intégrant ces puces graphiques dans des SoCs basés sur ARM?
Je préfère le bon vieux modèle du PC avec carte mère et périphériques remplaçables.
#10
Je comprends tout à fait l’intérêt de NVidia dans ARM. AMD et Intel ont leur propre solution graphique (intel allant proposer des solution plus haut de gamme) et du coup, oui NVidia peut craindre que ces 2 boites mettent en avant leur solution au dépend des solutions tiers, donc NVidia.
Cependant, niveau pro, ça fait des années que les puces NVidia fonctionne avec des puce ARM. C’est la base des solutions NVIdia Jetson (et il me semble qu’il y a aussi quelque supercalculateur basé sur ce type d’architecture comme le récent Cambridge-1). En soit, la démonstration ici n’est donc pas techniquement impressionnante.
Du coup, c’est pour ça que je me demande ce que NVidia essaie ici de dire vraiment, quel est le message et à qui.
#11
L’ intégration de tous les périphériques au sein du CPU comme ses fonctions annexes est en marche depuis un bon moment et avec l’ idée du chiplet à marier à volonté plus rien ne va l’ arrêter.
Que peut bien proposer un fondeur de cpu quand une limite de gravure devient extrêmement chère et difficile à franchir à part proposer plus de fonctionnalités et périphériques intégrés au sein dudit CPU comme le TPU exigé pour Windows 11 ?
Rien d’ autre qu’ un SOC avec une tonne de mémoire intégrée comme chiplet 3D comme l’ a montré AMD.
#12
#13
Nvidia reste encore beaucoup dépendant de ARM. Ici il montre une autre façon de faire. Que les processeurs ARM ce n’est pas que pour le mobile. Ca va dans une vision plus globale au niveau du dev où on commence à s’intéresser à ARM car il est puissant dans certaines choses, bien plus que X86 (l’inverse est vrai par ailleurs).
#14
Comme dit dans l’article, le sujet c’est toute la conversion des SDK pour qu’ils soient exploitables dans un écosystème ARM. CUDA-X a déjà été porté sur ARM, mais ce n’est pas le sujet ici.
En fait c’est leur but depuis un peu plus de 10 ans (Tegra, Jetson, toussa) et ils y sont parvenus sur la plupart des marchés où ils sont présents où ARM est au centre de leur offre d’une manière ou d’une autre. En ce moment ils progressent sur le DC/HPC (avec Grace notamment et le HPC SDK). Il n’y a pas besoin de plus pour expliquer leur envie d’intégration d’ARM.
Là ils montrent que c’est aussi une solution viable pour des PC du quotidien, même pour les joueurs ou les besoins “Pro” impliquant du rendu 3D performant si on se donne la peine de faire le boulot au niveau de l’écosystème logiciel (ce qui prend un temps fou quand on est pas Apple qui fonctionne en circuit court/fermé).
Spoiler : tout le monde ne se positionne pas par rapport à Apple. Comme dit, NVIDIA travaille sur ARM depuis plus de 10 ans. Sinon quelques rappels utiles :
SoC (bon, une partie des E/S est souvent dans un chipset, mais on a compris l’idée). AMD parle d’APU.
Pour faire court : si rien n’est interchangeable ou presque chez Apple, c’est un choix technique d’Apple. C’était le cas en x86, c’est le cas en ARM. Il n’y a aucun rapport avec ce qui est annnoncé par NVIDIA aujourd’hui. Penser que c’est le cas parce qu’il y a “ARM” dans le texte n’a aucun sens.
Petit exemple pratique pour finir : Cette photo, c’est un serveur ARM ou x86 d’après toi ?
Comme dit, NVIDIA travaille depuis longtemps sur ses propres SoC ARM avec GeForce intégrée. Mais elles sont principalement utilisées pour du calcul. C’est pour ça que la couche CUDA-X a été portée sur ARM à travers le temps. Ce n’était pas (encore) le cas des SDK pour les solutions graphiques.
Du coup si, parce que bon, tout ça ne se fait pas en 5 minutes.
Pour entendre, il faut ouvrir les oreilles ;)
#15
On peut même dire à 3 reprises : 68k -> PPC -> Intel -> ARM
#16
Apple décide quel CPU mettre dans ses PC. Les consommateurs et éditeurs suivent.
Microsoft édite des OS pour les constructeurs qui décident quel CP mettre dans leurs PC. Microsoft suit.
#17
Microsoft vend aussi du matériel (Surface), et les versions ARMs n’ont pas de succès, car on ne peut rien faire avec (moins qu’un Chromebook, qui fait au moins tourner des applis Android). Par ailleurs aucun constructeur grand public ne choisi d’utiliser Windows/ARM pour son matériel.
Alors qu’en revanche le matériel Apple M1 se vend comme des petits pains, car ils supportent tous les logiciels x86, même les jeux, avec souvent de meilleurs perfs que sur Intel..
Là où on peut faire un parallèle, c’est que la fin de la domination technologique d’Intel, qui maitrisait des pans entiers de la chaine de valeur, a ouvert un espace à de nouveaux gros acteurs pour développer leur propre propriété intellectuelle et prendre eux même une plus grande part de la chaine, en exploitant les gains permis par l’architecture ARM.
#18
La comparaison n’est pas mauvaise pour autant car comme le dit David les choix de MS sont dictés par leur nécessité de garder leur compatibilité historique. Si Win10 peut toujours lire des disquettes et refuse d’attribuer les lettres A et B (c’est l’exemple le plus visuel) c’est parce que le monde de l’industrie le demande. Les machines ARM de Microsoft font peu de vagues car ils doivent “malheureusement” répondre à un public voulant le beurre et l’argent du beurre : avoir une nouvelle plateforme efficiente mais continuer à utiliser ses logiciels vieux de 10/20/30 ans.
Dans ma boite on utilise encore 2⁄3 softs 16 bits développés pour des produits précis (dont un n’est plus commercialisé depuis… 2 ans à peine). Quand j’ai reçu le premier pc portable qui n’était plus compatible boot legacy (et donc OS 32bit) ça s’est affolé.
#19
Le raisonnement est fondé sur l’assomption qu’il est impossible de créer des couches de comptabilité fonctionnelles, performantes et transparentes.
Mais le travail remarquable d’Apple pour assurer la rétro-compatibilité démontre le contraire..
Apple a justement fait beaucoup mieux que Microsoft alors que logiquement c’est Microsoft qui en aurait eu le plus besoin (et le fait aujourd’hui en suivant Apple).
#20
Microsoft a effectué ce travail mais pas dans Windows 10, sur Win11 ARM les applications compilées pour ARM64EC fonctionnent sans perte de performance.
#21
Oui après Intel reste quand même une boite solide qui est positionnée sur de très nombreux marchés (et pas que le CPU 1P grand public) quoi qu’on en dise ici ou là. Il suffit de voir les bilans financiers même récents pour le comprendre. L’enjeu c’est surtout de se réinventer pour le monde qui vient qui sera fondamentalement différent. Le choix d’IDM 2.0 est là pour ça notamment (ça a été tout une partie de l’équipe ces dernières années, peu visible médiatiquement, d’isoler les blocs IP dans ce but).
#22
Faut pas pousser le bouchon non plus. Apple force la main aux développeurs à chaque évolution majeure et limite donc grandement le scope nécessaire pour assurer la compatibilité. Je rappelle que MacOS est passé au tout 64bit il y a 2 ans alors que MS doit s’assurer de gérer 64 ET 32bit.