Les « prochains produits révolutionnaires d'Apple », avec Nvidia ?
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.
Au passage s'il y a changement d'alliance il n'est pas improbable que Nvidia soit prés à de gros efforts de négociation pour enfoncer le clou sur un concurrent très fragilisé économiquement.
Chouette, peut-être que Civilization 5 sera fluide sur mon prochain MacBookPro. Et qu'il n'y aura plus cet horrible bruit de soufflerie dés qu'un jeu monte un peu en charge (MBPr 13" mi-2015 - GPU intégré Intel iris). * touche du bois *
@IceWizard :
Il est fluide sur mon Mac Pro de 2006 ...
Moi aussi il est fluide en mode minimum ;)
Enfin ! Le retour de NVIDIA !
A chaudement souhaiter pour tous ceux qui créent des animations 3D. Pour l'heure, rien n'arrive à la cheville de CUDA… et pour ça: Il faut une CG NVidia, point barre!
Justement AMD propose un outil aux développeurs pour convertir les instructions CUDA pour les intégrer à OpenCL et donc lever le verrou de CUDA=uniquement NVidia.
Pas sûr que les développeurs se lancent.
http://www.amd.com/Documents/HIP-Datasheet.pdf
C'est un peu comme passer du C au C++ ...effectivement, pas sûr que les développeurs se lancent ! :-D
@Philbee
L'analogie est quand même assez capilotractée ;-)
Le plus gros frein provient surtout de la très forte érosion de la présence d'ADM sur le segment des stations de travail servant ce type d'usages.
Pourquoi s'emmerder pour un faible retour sur investissement ?
Pour faire simple : CUDA est en C et OPEN CL en C++
Donc, pas de capilotractage ;-)
@Philbee
Si, si réduire la problématique à cela me semble l'être, pour le moins ;-)
Quand on voit que Adobe a adressé un message alarmant sur l'arrêt soudain de Quicktime Legacy alors qu'Apple a affiché sa feuille de route sur le remplacement de QTKit depuis des lustres, effectivement j'ai l'impression que les développeurs s'emmerdent surtout sur le développement de nouvelles fonctions plutôt que sur les fondements des logiciels.
Cela peut se comprendre au regard du faible retour sur investissement.
@Rayban
"Il est fluide sur mon Mac Pro de 2006 ..."
En fait Civilisation 5 est globalement fluide sur mon MBPr, mais il se produit des choses curieuses. Par exemple quand je change de zone en cliquant sur la mini-carte, il arrive (une a deux fois par heure) que le décor s'affiche en fil de fer, sans textures. L'image met prés d'une seconde à se reconstruire à la normale, les textures semblant se charger les unes après les autres, au ralenti.
Si c'est une allusion au prochain macbook pro j'ai l'impression qu'ils sont loin d'être ! :(
*prets
Un Mac pro avec nVidia, ce qui expliquerait le retard de renouvellement ? On peut rêver...
@Myaboki
C'est un des bruits de couloir du FCPX user group au NAB, mais ce n'est qu'un bruit de couloir : Apple attend la fin des accords avec AMD.
En tout cas, c'est très bien si apple se rapproche de NV pour utiliser autre chose que des GPU outrepassé, mais Apple a mis bien trop de temps a corriger le tir (on en sait rien tout ceci reste encore de la supposition, embauché des gens dont le boulot demande 1 ou 2 ans avant de pouvoir apparaitre dans la gamme réelle), moi je quitte le navire vers l'autre monde où la visibilité sur l'avenir est autrement moins hasardeuse que chez apple...
@bobdu87
"GPU outrepassé"
Objets inanimé avez-vous donc une âme ?
?
Oui moi j'ai une âme mais plus apple ;)
Payer des GPU dépassés dans des machines qui avoisinent les les 3000 euros, c'est fort en cacao et non cocoa! Si la 390m du mac book pro *haut de gamme* vous semblent correcte, c'est très bien... Je suis plus dans les 1080*m* qui rentrent dans des portables en offrant des performances qui rendent chauve un mac pro desktop haut de gamme...
Mais bon rien d'étonnant, les fans d'apple sont totalement hermétiques a ce qui se fait ailleurs, en même temps c'est bien pratique pour éviter de voir le ridicule de ce qu'apple propose actuellement...
Ce que les belges disent de la France est finalement très proche de ce qu'on peut dire des apple fanboys : même sur un tas de fumier le coq chante fièrement....
@bobdu87
"Oui moi j'ai une âme mais plus apple ;)
C'était juste un clin d'oeil a ton étrange usage "d'outrepassé" qui n'a pas le sens que tu sembles lui prêter ;-)
Aucun pb à ce que tu trouves ton bonheur sous d'autre cieux que ceux d'Apple ;-)
@bobdu87
Effectivement, si une puce Intel suffit à la plupart des utilisateurs ceux qui ont des besoins GPU importants doivent se sentir lésés sur la plateforme macOs. Si cela ne justifie pas, j'ai l'impression que cela a toujours été le cas.
S'embarquer sur macOs c'est aussi être conscient des limites des choix d'Apple. Malgré toutes les frustrations, mauvaises surprises, pour ma part je tiens le choc. :)) ATI 4850 512Mo sur iMac :)) C'est fou, mais je préfère signaler que ça marche pour de l'email, internet et autres. Sur FCPX(HD), Motion, C4D, ben là je pars fumer une clope lors des calculs et pourtant, ça marche.
Au boulot, iMacs de 2014, avec des cartes de 2go ou 4go, rien de différent pour email, internet et autres en revanche pour FCPX/Motion il y a un monde. Et cela me suffit à l'usage. Les rares fois ou j'ai pu accéder aux macpro 2013, là, super plongée dans un autre univers et il faut avouer que cela laisse rêveur d'imaginer ce que cela donnerait avec des cartes comme les 1080. Tout cela pour dire que je comprends la remarque.
D'après ces offres d'emplois, Apple semble rester sur OpenCL /Metal et semble n'avoir que faire de OpenGL/Vulkan et CUDA. Si les développeurs n'adhèrent pas à ces dogmes technologiques, la messe est dite et ceux qui ont besoin des avantages de CUDA ou Vulkan iront sans doute voir ailleurs.
@cv21
D'après ces offres d'emplois, Apple semble rester sur OpenCL /Metal et semble n'avoir que faire de OpenGL/Vulkan et CUDA. Si les développeurs n'adhèrent pas à ces dogmes technologiques, la messe est dite et ceux qui ont besoin des avantages de CUDA ou Vulkan iront sans doute voir ailleurs.
Les offres n'émanent pas d'Apple mais de Nvidia ;-)
Sur CUDA ils ne doivent pas vraiment manquer de spécialistes ;-)
De même pour OpenGL et son successeur Vulkan
J'ai bien vu que les annonces sont éditées par NVidia :))
J'ai dû mal formuler ma pensée. J'essaie autrement.
Sur le logiciel Fusion par exemple, le noeud de rendu peut utiliser soit les CPU, soit OpenGL.
Sur les anciens macpro la Nvidia quadro 4000 n'est plus supportée par blackmagic resolve car elle ne prend pas en compte CUDA2.
J'imagine mal les développeurs proposer leurs logiciels à la fois optimisés OpenCL, OpenGL, CUDA et maintenant Metal. Ça fait beaucoup, non ?
En grossissant le trait, supposons une station de travail avec la "magnifique" 1080 avec un driver pour Mac :
- LES logiciel 3D optimisés CUDA
- LES logiciels Adobe optimisés CUDA, etc..
- LE logiciel d'Apple, dans son coin, optimisé Metal, pas optimisé sur la 1080, on passe un peu à côté, non ?
Je me trompe peut-être. Je ne fais pas le distinguo entre la puissance brute de la carte vidéo et l'apport des API.
@cv21
Si Nvidia revient dur les Mac ils devront supporter un large ensemble d'API
- Metal évidement puisque ces le cheval de bataille d'Apple et qu'il est utilisé par l'OS.
- OpenCL aussi car la bases logiciel reposant sur cette approche et large et que les logiciels Apple y ont recourt.
- CUDA : Forcément puisque Nvidia porte cette technologie
- OpenGL : Obligatoirement
- Vulkan : Difficilement contournable puisqu'il a vocation à se substituer à Open GL qui n'évoluera normalement plus.
Avec cela le champs des possible des usages GPGPU sur Mac couvrira un large ensemble.
Nvidia cherche à recruter sur les enjeux où elle n'a pas d'expérience à commencer par Metal
Mais au delà de l'existence de ces API la grande question reste celle de la qualité de l'implémentation, hors Metal, Mac OS est actuellement très à la traine.
Il y a un travail de fond espéré depuis des années qui est à faire pour tirer vraiment partie du potentiel des GPU sur MacOS
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 ! ☹️
@Yohmi
Le vieux fantasme de la Rev A :-)
C'est un peu obsolète, les Rev B se font bien rare de nos jours.
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.
@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).
@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
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 ...
> 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...
@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.
> 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.
@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.
@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 ?
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.
@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..
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.
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
http://hgpu.org/
Pages