COMPTOIR
  
register

×

roadmap amd entreprise 2015 2019 t

Toujours plus de coeurs chez AMD en 2018 ?
roadmap amd entreprise 2015 2019 t

Voilà qu'un document qui serait interne à AMD vient de sortir du chapeau magique de Videocardz. On y voit une sorte de roadmap qui montrerait les plans de l'ex fondeur en matière de processeur pour les années à venir, depuis 2015 jusqu'en 2019 à vrai dire. Seul hic, il date de février 2016, et il est clairement indiqué qu'il peut être soumis à n'importe quel moment à un changement de stratégie sans préavis. Les CPU vaguement explicités dans ce slide montrent plusieurs choses, non officielles même si les caractéristiques des CPU commercialisés depuis collent avec les données du tableau.

 

roadmap amd entreprise 2015 2019 t [cliquer pour agrandir]

 

Tout d'abord, on se rend compte que les Naples étaient prévus pour mi-2016, et qu'ils ont aussi subi l'année de retard car ils vont être lancés mi-2017. Les caractéristiques continuent d'être les bonnes sur ce point, avec 32 coeurs et 64 threads maxi, le tout avec des TDP qui iraient de 30 à 180W, sans que l'on ne sache comment atteindre ces 30W. On remarque aussi que les successeurs nommés Starship dans le slide auraient été prévus pour début 2018. Il n'y a quasiment aucune chance qu'ils soient en vente 6 mois après Naples, commercialement ça ne tient pas après avoir passé tant de temps en R&D pour les élaborer.

 

Surtout ils monteraient à 48 coeurs et 96 threads, soit 50% de coeurs de plus que Naples, ce n'est pas anodin. Autre fait que dit ce slide, ces "opteron" qui seraient architecturés autour des coeurs Zen 2 seraient gravés en 7nm ! Cela ferait un sacré saut quand on voit qu'Intel a un mal de chien à sortir son 10nm, imaginez les partenaires d'AMD novices sur ces gravures de puces complexes débiter du 7nm les doigts in ze noise ! Heureusement qu'il y a la clause "produits en cours de conception et soumis à des changements". A voir mais de tels engins ne seraient pas là avant fin 2018, à moins qu'AMD ait un plan B.

 

Dans tous les cas, cela montre que le géant a l'intention de ne pas laisser le champ libre à Intel. Le plus dur pour Amédé, c'est désormais de convaincre les grosses entreprises qu'elles peuvent conseiller et vendre du Zen (comme dans les stations dans le milieu médical), acheter du Zen pour leur propre compte, prouver que la plateforme est stable et que le support est optimal, chose qui a fait énormément défaut aux stations à base d'Opteron Bulldozer. Car sur le plan des performances, les coeurs Zen en applicatif et en consommation​ sont tout à fait légitimes !

 

amdlogo

Un poil avant ?

Leto se resserre autour de Raijintek !

Un peu plus tard ...

AOC lance un second moniteur USB 3.0

Les 31 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un ragoteur à l'apéro de Lorraine, le Lundi 15 Mai 2017 à 11h02  
par UpsiloNIX, le Samedi 13 Mai 2017 à 16h42
Pour les serveurs même aujourd'hui c'est pas ça encore. Donc oui un ARM peut-être plus efficient qu'un x86, mais sous conditions. Principalement : Le programme est développé et optimisé pour de l'ARM, ce qui n'est pas toujours possible vu le jeu d'instruction ARM.
Tes données sont franchement pas récentes, l'A9 commence à dater sérieusement...

Depuis on a eu l'A52, l'A57 et maintenant l'A72 tous en 64b avec des perfs en hausse constante, sans parler des cores custom.

Reste que malgré ça, il y a de quoi rire quand on voit les benchmarks HTTP/SQL, un smartphone premier prix à base de dual A7 serait assez puissant pour héberger CDH qui doit rarement dépasser les 100 requêtes simultanées par exemple (bon, en stockage ça se discute ceci dit, mais c'est cohérent avec l'usage détourné ). Si on prend du monstre chez les hébergeurs c'est pour mutualiser, on fera tourner 100+ serveurs qui seront individuellement plus performants du fait de la puissance disponible pour chaque serveur (logiciel) actif à un instant T inévitablement plus importante.

Pour le grand public, le problème est tout autre, il est actuellement impossible de prédire la domination ARM ou x86, mais si M$ propose un émulateur x86, il y a fort à parier que c'est pour rendre Windows parfaitement multiplateformes, comme il l'était fin du siècle dernier à vrai dire.
par Baba the Dw@rf feignasse de Antwerpen, le Lundi 15 Mai 2017 à 06h17  
par Un ragoteur charitable embusqué, le Dimanche 14 Mai 2017 à 21h30
Merci de me corriger. Gameworks n'est pas une librairie ou une suite de librairie ? Cela n'ajoute pas à la taille jeu qui l'utilise ? Cela n'inclut pas tous les effets visuels et physiques ( du moins en partie ) à la mode dernier cri chez nVidia ?
Oui et non, c'est une librairie en effet mais elle n'est pas liée à l'optimisation à un matos spécifique. Elle ajoute un pannel d'effet visuel c'est vrai mais c'est pas du code qui prend de la place. Pour te donner une idée de la place que prend un code qui génère des particules et effet physique regarde les demo-scenes. C'est le cas d'école des soft graphique qui n'utilise aucune ressources hors librairie principale (DX, QT, ou autre). Tout est généré jusqu'au texture.
D'ailleurs je ne serais pas étonné que Gameworks soit juste une API et que le vrai code soit au niveau driver (ce qui rend la tâche difficile pour AMD vu que pour utiliser les effets avec leur matos ils n'ont que l'API et doivent tout construire de zero derrière). Mais bon la je ne m'avance pas trop il y a trois cas possibles (code dans les drivers, code dans une librairie externe comme PhysX en son temps ou code packagé avec le jeu mais un truc comme ça c'est quelque Mo tout au plus).
par Un ragoteur charitable embusqué, le Dimanche 14 Mai 2017 à 21h30  
par Baba the Dw@rf, le Dimanche 14 Mai 2017 à 20h48
Sérieux faut arrêter, d'une part le code compilé ...
Et pour ce qui est des librairies tu rêves éveillé, ce sont des APIs, pas des implémentations, l'implémentation se fait de manière matériel et/ou logiciel du coté du constructeur pas de la librairie.
Merci de me corriger. Gameworks n'est pas une librairie ou une suite de librairie ? Cela n'ajoute pas à la taille jeu qui l'utilise ? Cela n'inclut pas tous les effets visuels et physiques ( du moins en partie ) à la mode dernier cri chez nVidia ?
par Baba the Dw@rf, le Dimanche 14 Mai 2017 à 20h48  
Sérieux faut arrêter, d'une part le code compilé d'un jeu récent dépasse rarement 1 ou 2 dixième de pourcent du volume total du jeu. En plus optimiser du code reviens généralement à le rendre plus compacte et plus efficace, l'opti au cas par cas ça n'existe pas dans le monde du PC grand publique, il y a beaucoup trop de variation, c'est le rôle des constructeurs de proposer des drivers plus ou moins bas niveau au petit oignons. T'imagine pas le temps qu'on gagne en réduisant la taille du code (plus le code est long et complexe plus il prends du temps à être exécuté ).
Au mieux on va gérer une dizaine d'API macro différente (généralement une seule -> DX) qu'on va optimiser du mieux qu'on peut avec au pire 4-5 choix différent en fonction des constructeurs pour faire un truc un peu plus léché mais dans tout les cas même en multipliant par 10 le nombre de cas gérer le code n'augmentera pas d'autant et on restera sur une taille négligeable vis à vis du reste du contenu. Et pour ce qui est des librairies tu rêves éveillé, ce sont des APIs, pas des implémentations, l'implémentation se fait de manière matériel et/ou logiciel du coté du constructeur pas de la librairie.
par Un ragoteur charitable embusqué, le Dimanche 14 Mai 2017 à 16h39  
Certes les compressions ne sont pas toutes destructrices, comme avec 7zip, winzip ou winrar. Mais utiliser ces algos de compression sur des images ou des fichiers audio montrera vite ses limites sans parler des ressources nécessaires pour l'utilisation à la volée de fichiers compressés. On gagne un pouillème, rien de bien significatif, même si c'était salvateur à l'époque du 56k où le moindre fichier jpeg était zippé pour un DL.
Pour les compressions destructrices, c'est utilisé pour les textures certainement, mais sans recette magique pour l'instant apparemment malgré les avancées dans les GPU notamment pour ce qui est de la compression des textures lors de leur traitement par la carte. Il suffit de voir la taille des fichiers de textures dans les mods des jeux "moddables" et moches d'origine : on veut du beau, il faut du lourd.
par Un ragoteur charitable embusqué, le Dimanche 14 Mai 2017 à 16h29  
par Gaurbhack, le Dimanche 14 Mai 2017 à 13h43
Sans vouloir être agressif, c'est pas du tout vérifié ce que tu dis
Écrire du code prends au mieux quelques Mo d'espace supplémentaire pour des millions de ligne de texte (je parle même pas de l'espace une fois compilé )
Toute compression n'est pas destructrice non, le .zip/rar/png sont là pour le prouver. Les compressions destructrices peuvent obtenir un ratio plus intéressant avec le h265 vs h264. Les développeurs peuvent améliorer l'architecture de leur soft par exemple en ne gardant que les packs de langue dont a besoin le joueur (Titanfall je crois) une optimisation très simple mais demandant un peu de temps aurait économisé 30Go de DL aux joueurs.
Non en effet, cela ne sera pas le code qui va faire quelques Go de plus, mais il sera appuyé sur une tripotée d'autres fichiers comme les librairies ( corrigez moi si je me trompe ) pour adapter au mieux le jeu à la config du joueur et cela ne prendra pas moins de place que d'optimiser. A moins de faire un code "basique" débarrassé de la prise en charge de toutes les fioritures visuelles sans tenir compte des possibilités particulières du matos de chacun.
Effectivement, ne devoir DL ( puisque les jeux se DL tous de nos jours ) que les fichiers pile poil nécessaires serait le top. Pour ce qui est des langues, cela se fait dans pas mal de jeux déjà, au moins au niveau du son.
par Baba the Dw@rf, le Dimanche 14 Mai 2017 à 14h31  
par Un ragoteur tout mignon embusqué, le Dimanche 14 Mai 2017 à 11h02
Des développeurs qui optimisent leur code, font en sorte que leur jeu puisse tourner au mieux sur la multitude de combinaisons de configs matérielles/logicielles possibles : cela augmente mécaniquement la place que prend le jeu, pas de miracle puisque cela implique d'écrire du code supplémentaire. C'est donc le contraire de ce qu'Arobase dit : optimiser = moins de place.
[...]
Franchement dire qu'un code optimisé prends plus de place, tu as déjà vu la taille de l'exécutable d'un jeu ??? C'est pas ça qui prends de la place.

Par contre contrairement à ce que tu pense, la compression des textures, de l'audio et de tous les autres trucs qui prennent de la place peut sauver énormément de place. Sachant que certains type de compression sont géré à la volée par les archi CPU et GPU de nos jours, il y a toujours moyen de trouver le juste millieu entre charge et gain de place. Surtout qu'une resource compressée est plus rapide à chargée et prend moins de place en mémoire. Si le temps gagné au chargement est plus petit ou égal au temps de ajouté par la décompression, alors la compression est intéressante.

Et la on ne fait qu'effleurer la surface des possibilités d'optimisation en terme d'espace. Si on revoit en profondeur les moteurs on pourrait faire des trucs extra-ordinaire mais les studios ont pas les sous.
par Gaurbhack, le Dimanche 14 Mai 2017 à 13h43  
par Un ragoteur tout mignon embusqué, le Dimanche 14 Mai 2017 à 11h02
Des développeurs qui optimisent leur code, font en sorte que leur jeu puisse tourner au mieux sur la multitude de combinaisons de configs matérielles/logicielles possibles : cela augmente mécaniquement la place que prend le jeu, pas de miracle puisque cela implique d'écrire du code supplémentaire. C'est donc le contraire de ce qu'Arobase dit : optimiser = moins de place.

[...]Toute compression étant destructrice, plus c'est fin et détaillé, plus ça prend de la place.
Bref, optimiser est devenu un mot fourre tout, employé par les gens qui ne savent pas ce qu'implique ce dont ils parlent, qui peut tout dire et son contraire.
Sans vouloir être agressif, c'est pas du tout vérifié ce que tu dis
Écrire du code prends au mieux quelques Mo d'espace supplémentaire pour des millions de ligne de texte (je parle même pas de l'espace une fois compilé )
Toute compression n'est pas destructrice non, le .zip/rar/png sont là pour le prouver. Les compressions destructrices peuvent obtenir un ratio plus intéressant avec le h265 vs h264. Les développeurs peuvent améliorer l'architecture de leur soft par exemple en ne gardant que les packs de langue dont a besoin le joueur (Titanfall je crois) une optimisation très simple mais demandant un peu de temps aurait économisé 30Go de DL aux joueurs.
par Un ragoteur tout mignon embusqué, le Dimanche 14 Mai 2017 à 11h02  
par Un ragoteur qui draille de Harjumaa, le Dimanche 14 Mai 2017 à 10h12
Je ne vois pas en quoi parler d'optimisation n'as aucun sens...
Enfin bon ...
Des développeurs qui optimisent leur code, font en sorte que leur jeu puisse tourner au mieux sur la multitude de combinaisons de configs matérielles/logicielles possibles : cela augmente mécaniquement la place que prend le jeu, pas de miracle puisque cela implique d'écrire du code supplémentaire. C'est donc le contraire de ce qu'Arobase dit : optimiser = moins de place.

Je vois mal ce que signifie optimiser pour ce qui est des Go de textures HD ou de fichiers audio nécessaires pour en mettre plein les mirettes ou les esgourdes de ceux qui jouent en haute définition avec les dolby thx true theater FX 36.1 bidule chouette. Toute compression étant destructrice, plus c'est fin et détaillé, plus ça prend de la place. Comme c'est la principale cause de l'embonpoint des jeux actuels, à moins de revenir en arrière à des définitions plus faibles, je vois mal la taille des packs de textures/sons diminuer.

Bref, optimiser est devenu un mot fourre tout, employé par les gens qui ne savent pas ce qu'implique ce dont ils parlent, qui peut tout dire et son contraire.
par Un ragoteur qui draille de Harjumaa, le Dimanche 14 Mai 2017 à 10h12  
par Un #ragoteur connecté embusqué, le Samedi 13 Mai 2017 à 21h09
Il est tellement simple de parler d'optimisation, ce mot à la mode qui n'a aucun sens dans la situation commentée.
Je ne vois pas en quoi parler d'optimisation n'as aucun sens...
Enfin bon ...
par Un #ragoteur connecté embusqué, le Samedi 13 Mai 2017 à 22h52  
par Arobase40, le Samedi 13 Mai 2017 à 22h34
Et pourtant quand tu vois la qualité et le niveau des jeux sous OS mobiles ils ne sont pas loin de ceux existants sous Windows alors qu'ils n'occupent qu'une fraction de la taille de stockage et de la quantité de RAM nécessaire que ce soit sous Android ou éventuellement iOS également pourvu d'une I.A...
Et bien évidemment, je ne parles pas des jeux du type Candy Crush ou les autres où on chope des bonbons ou autres cochonneries dans le même genre...

Même les jeux clients-serveur genre Steam sont tout simplement "ÉNORMES" à tous points de vue et extrêmement énergivores !
J'ai bien ri. Merci pour le fun l'ami.
par Arobase40, le Samedi 13 Mai 2017 à 22h34  
par Un #ragoteur connecté embusqué, le Samedi 13 Mai 2017 à 21h09
Tu oublies un peu facilement les évolutions entre les jeux en 640x480 et les jeux qui peuvent pousser jusqu'au 4k actuellement. La taille des jeux est pas mal dépendante de la taille des textures et autres bricoles visuelles. Sans parler de tous les aspects du genre IA et moteur physique qui n'existaient pas à l'époque où les jeux tenaient sur 10 disquettes.
Il est tellement simple de parler d'optimisation, ce mot à la mode qui n'a aucun sens dans la situation commentée.
Et pourtant quand tu vois la qualité et le niveau des jeux sous OS mobiles ils ne sont pas loin de ceux existants sous Windows alors qu'ils n'occupent qu'une fraction de la taille de stockage et de la quantité de RAM nécessaire que ce soit sous Android ou éventuellement iOS également pourvu d'une I.A...
Et bien évidemment, je ne parles pas des jeux du type Candy Crush ou les autres où on chope des bonbons ou autres cochonneries dans le même genre...

Même les jeux clients-serveur genre Steam sont tout simplement "ÉNORMES" à tous points de vue et extrêmement énergivores !