Les « prochains produits révolutionnaires d'Apple », avec Nvidia ?

Mickaël Bazoge |

Nvidia revient en odeur de sainteté chez Apple, comme le raconte Bloomberg. Plusieurs offres d'emploi publiées par le spécialiste des cartes graphiques annoncent en effet un réchauffement des relations avec le constructeur de Cupertino. Dans une offre pour un ingénieur logiciel, Nvidia dit que cette perle rare devra « aider à produire les prochains produits révolutionnaires d'Apple », rien de moins !

Il lui faudra travailler en partenariat avec Apple et développer du code qui « définira et bâtira le futur » des logiciels graphiques sur les Mac. Tout cela est bien alléchant. Une autre offre parle elle de développer des pilotes graphiques de produits Nvidia pour les Mac.

Actuellement, les Mac embarquent des cartes Intel ou des GPU d'AMD pour les hauts de gamme. Nvidia n'est plus présent nulle part dans cette famille de produits. À lire ces offres d'emploi, il semble que Nvidia aura bientôt de nouveau droit de cité dans les ordinateurs d'Apple.

Bloomberg évoque un besoin de puissance pour la réalité virtuelle — et on sait à quel point les Mac sont sous-dimensionnés dans ce domaine, lire : Oculus sur Mac ? Si jamais Apple sort un bon ordinateur. Dans une moindre mesure, les calculs liés à l'apprentissage automatique pourraient aussi tirer profit de cette puissance ; au contraire de Google qui déporte ces calculs vers ses serveurs, Apple laisse ses ordinateurs faire tout le travail.

Tags
avatar Yohmi | 

Intel qui rate le coche, nVidia invité après la fête, j'ai l'impression que ce MacBook Pro 2016 va être joli à regarder mais sera vraiment cette fameuse rev1 à éviter. J'avais prévu de remplacer mon modèle actuel, mais ça s'annonce assez moyen pour ces composants clefs. Bien sûr, Apple ne proposant aucun moyen d'avoir un clavier d'un autre pays, je vais être bien embêté quand je vais rentrer en France car j'ai besoin d'un clavier ㄅㄆㄇ… zut ! ☹️

avatar awk | 

@Yohmi

Le vieux fantasme de la Rev A :-)

C'est un peu obsolète, les Rev B se font bien rare de nos jours.

avatar ilyon | 

Le "retour" d'Apple chez NVIDIA est assez cohérent: les 2 boites partagent une passion historique pour la fermeture de leurs API. Après, je n'ai pas de chiffres, mais je pense que, vu que le Mac représente de moins en moins chez Apple, le Mac avec accélérateur graphique dédié doit réellement être la portion congrue, donc un fournisseur pour un autre ...
Et puis c'est à mettre en perspective avec ça (avec les pinces de rigueur:

http://wccftech.com/apple-macbook-pro-amd-zen-soc/

Par contre je pense que vous vous trompez et sur les performances des Mac Pro, loin d'être négligeables pour l'usage qui leur est dévolu, et sur les attentes du client Mac de 2016.

Pour clarifier, il ne veut pas jouer à Civilization.

avatar IceWizard | 

@ilyon
"Pour clarifier, il ne veut pas jouer à Civilization."
Ça tombe bien, Firaxis ne veut plus développer de jeux sur Mac. Civ 6 sort le mois prochain sur PC. La version Mac est annoncé pour .. une date ultérieure (ou jamais).

avatar awk | 

@ilyon

"Le "retour" d'Apple chez NVIDIA est assez cohérent: les 2 boites partagent une passion historique pour la fermeture de leurs API. "

Et elles sont loin d'être les seules en ce qui concerne les API 3D, MS fait de même avec Direct3D

Les approches ouvert ont un avantage : leur ouverture qui les rend cross-plateform

Mais elles ont aussi un inconvénient : la lourdeur de la collégialité de décision et de validation du consortium. Cela c'est clairement vu avec OpenGL par exemple

avatar ilyon | 

Il faut admettre qu'intel comme AMD et - c'est dur à dire - même Microsoft font des efforts tangibles pour mettre leurs technos au service de tous (à but évidemment lucratif, ce n'est pas la question), et qu'NVIDIA tente une approche premium qui permet de différencier, mais qui ne porte que partiellement ses fruits. Apple se rapprcohe vraiment de Microsoft dans sa façon de gérer son écosystème logiciel, personnellement ça me va très bien, vu la bonne tenue de son matériel.
Après l'ouvert rend forcément les choses lentes, et NVIDIA a eu une com percutante pour vanter CUDA, ce qui lui a permis de verrouiller pas mal de choses. Le semi-ouvert de D3D/Metal semble être la bonne approche si on regarde bien: une API qui permet à tout un écosystème de travailler de la même manière, qui reste accessible à tous et dispose d'une "ouverture" suffisante. Et si Steam et Google s'emparent de Vulkan, ce qui semble être le cas, on aura enfin à l'horizon 2020 la promesse de 2010 tenue ...

avatar byte_order | 

> Mais elles ont aussi un inconvénient : la lourdeur de la collégialité de décision
> et de validation du consortium. Cela c'est clairement vu avec OpenGL par exemple

Pas tellement, car très tôt OpenGL a intégré un mécanisme d'extension propriétaire permettant justement d'offrir le meilleur des deux mondes : un standard ouvert et des extensions propriétaires détectables de manière standardisée - à charge aux développeurs de les exploiter ou pas - jusqu'à ce que les extensions propriétaires les plus pertinentes fassent l'objet d'une standardisation officielle, et ainsi de suite.

Par contre, l'architecture d'OpenGL a été pensée y'a longtemps autour d'un seul pipeline de rendu avec une machine à état. Et ça, c'est plus du tout adapté aux capacités des GPU actuellement, nettement plus parallélisé, nettement plus multiusage, sans parler des programmes eux mêmes de plus en plus parallélisé pour produire des données 3D ou de calcul en même temps.

Du coup, les pilotes OpenGL sont devenus obèses pour supporter via une API inadaptée tout un spectre d'usages différents en cachant la réalité des manipulations intermédiaires pour y arriver.

Coté CUDA, nVidia a fait ce que les autres n'ont pas su faire : ils ont proposé tout une suite d'outils d'aide au développement, ce qui a fait la différence côté choix des developpeurs. Leur GPU étant en plus de plus en plus en avance sur la concurrence...

Après, comme à chaque fois, quand une techno est interessante mais pas assez cross-plateforme, une couche intermédiaire nait et propose de distribuer les tâches au mieux de ce qui est disponible au moment de l'exécution.

Personnellement, j'utilise de plus en plus ArrayFire. Qui permet en plus de distribuer les calculs sur des clusters, pas uniquement sur des GPU locales...

avatar awk | 

@byte_order

En premier lieu nous sommes d'accord sur l'héritage d'OpenGL issu de SGI qui n'était plus en ligne avec les réalités de l'époque et qu'il fallait avoir le courage de balayer tant il était devenu obsolète.

Sur les extensions propriétaires je serais loin positif que tu ne sembles l'être, cela reste un pis-aller qui ne donne pas pour autant la réactivité qu'ont les approches réellement propriétaires.

Sur ton évaluation de la démarche de Nvidia sur CUDA je suis plus que d'accord avec toi, je rajouterai même qu'ils ont fait un réel travail d'évangélisation large avec de vrais moyens commerciaux à destination des éditeurs, des partenaires, de certains grands comptes ... et qu'ils ont été beaucoup à l'écoute des besoins, des pratiques, des enjeux ... ils ont simplement fait du bon travail dépassant la simple mise en place d'une technologie et il est normal qu'ils en récoltent les fruits.

Quant au poids de la propriété il est assez faible sur l'adoption et le succès commercial de l'approche, être obligé de passé par Nvidia n'est pas un poids pour une très grande majorité de cibles économiquement intéressantes.

Pour finir merci pour la référence à ArrayFire que je ne connaissais pas.

avatar byte_order | 

> Sur les extensions propriétaires je serais loin positif que tu ne sembles l'être,
> cela reste un pis-aller qui ne donne pas pour autant la réactivité qu'ont
> les approches réellement propriétaires.

Je ne l'ai pas vécu comme ça, je trouvais au contraire que cela permettait d'exploiter une accélération optimisée pour tel matos tout en l'employant quand même dans le cadre d'une API plus générale standardisée, ce qui a éviter les forks d'API toutes propriétaires, évitant de revoir largement le code applicatif pour pouvoir tirer vraiment partie de tel ou tel gain de performance.

Et cela n'a pas semblé tellement freiner l'innovation des constructeurs pour autant.
NVidia a publier une grosse quantité d'extension NV_* pour OpenGL mettant en avant les capacités de leurs nouveaux modèles de GPU, dont certaines sont devenu clairement des changements majeurs, NV_vertex/fragment_program en particulier, les meilleurs obtenant l'adhésion rapide des développeurs.
Les extentions OpenGL ont permis le support de fonctionnalités Beta et/ou proprio par les constructeurs sans devoir tout redevelopper pour les développeurs. Un compromis pragmatique pour l'un comme pour l'autre.

Bon, à force, les extensions ont finalement changer tout l'approche de l'utilisation des GPU pour au final transformer OpenGL en une API de compilation, édition de lien et d'exécution de code pour unité de calcul massivement parallèle... mais une API *séquentielle*, donc anachronique désormais.

> Quant au poids de la propriété il est assez faible sur l'adoption et
> le succès commercial de l'approche, être obligé de passé par Nvidia n'est pas
> un poids pour une très grande majorité de cibles économiquement intéressantes.

Pour le client, oui.
Pour certains éditeurs, ce type d'API peut être quand même un investissement sur le long terme, sa pérennité et sa portabilité est un coût à prendre en compte.
Pour d'autres, le cycle de vie de leurs logiciels est plus court.

avatar awk | 

@byte_order

Pour avoir côtoyé pas mal de gars de SGI, Alias, Softimage … qui participaient aux commissions je peux témoigner que la lourdeur des processus leur pesait pas mal et qu’ils avaient une certaine jalousie vis-à-vis de la liberté d’action dont jouissait MS avec Direct 3D.

Je pense que tu seras d’accord avec moi pour considérer que toutes les solutions que tu énumères, si elles ont réellement permis de dépasser certaines limites, reste des pis-aller tenant un rien du bricolage peu élégant qui ne faisait que reculer l’arrivée dans une impasse.

Il est d’ailleurs intéressant de noter que le consortium était loin de nier cet état de fait et que le passage à Vulkan sur la base de Mantle a été plus que rapide par rapport à ce qu’était les normes du consortium. Il y avait vraiment péril en la demeure.

avatar awk | 

@byte_order

"Pour le client, oui.
Pour les éditeurs, ce type d'API est quand même un investissement sur le long terme, sa pérennité et sa portabilité est quand même un coût à prendre en compte."

Là tout est affaire de secteur d'activité et de marchés.

Sur bien des marchés Nvidia a montré à ses partenaires le sérieux de son engagement et l'exclusivité de la solution n'est pas vécu comme un frein.

Après il est des usages plus pointus où ce caractère propriétaire peut s'avérer pesant.

Si je lis entre les lignes cela semble être le cas dans ton activité, je me trompe ?

avatar softjo | 

Je prédis une carte graphique à brancher sur l'unique port usb-c. Il faudra choisir entre charger ou avoir de bonnes performances. C'est la direction qu'Apple prend pour son MacBook, puis l'iPhone et bientôt les MacBook Pro.

avatar reborn | 

@softjo :
On n'achète pas un macbook pour ses performances. Ce n'est pas la raison d'être de cette machine.

Par contre une 1080 en externe sur macbook pro je dis oui. Si ça peu éviter de transformer le macbook en barbecue de 4 cm d'épaisseur..

avatar awk | 

Pour compléter ce que je mettais en avant dans mon échange avec Byte_order.

Ce qu’a fait Nvidia sur le GPGPU mérite vraiment d’être salué, c’est le seul acteur de l’industrie à avoir réellement misé sur cette approche en s’en donnant les moyens.

Cela a été fait sérieusement d’un point de vue technique, mais aussi en terme de stratégie commerciale et marketing.

C’est aujourd’hui une des forces de Nvidia : aller chercher des relais de croissance sur de nouveaux usages, ils l’ont fait pour le GPGPU, ils le font avec le deep-learning, l’industrie automobile … avec des démarches qui ont commencé très tôt.

avatar ovea | 

Pour se faire une idée des calcul distribués

GPGPU programming with OCaml
SPOC and Sarek

http://www.algo-prog.info/spoc/docs/cambridge-20130517.pdf

avatar ovea | 

Pages

CONNEXION UTILISATEUR