COMPTOIR
register

Les prochaines Radeon équipées de mémoire HBM pour mettre la pâtée à la GDDR5 ?

Les rumeurs s'enchaînent à propos des futures Radeon. La dernière information en date nous vient du forum Overclock.net sur lequel un utilisateur a posté des documents de SK Hynix (qui datent de décembre 2013...) qui nous dévoilent quelques détails sur les futurs GPU d'AMD. Il semblerait que la mémoire HBM (High Bandwith Memory) soit de la partie et permette une hausse considérable de la bande passante mémoire.

 

La mémoire HBM consiste à créer des puces de mémoire 3D (stacking memory) avec 4 couches au lieu des puces planes à une couche. L'intérêt est de permettre une plus grande densité des puces, une consommation inférieure (40% selon SK Hynix) et des performances supérieures (65% selon le spécialiste de la mémoire) par rapport à la GDDR5. De quoi supprimer un goulet d'étranglement pour les performances graphiques.

 

Le forumeur en profite pour nous donner quelques détails sur les futures puces. Selon lui, les prochaines puces qui sortiront à la fin de l'année seront basées sur l'architecture actuelle Volcanic Islands avec la mémoire HBM et porteraient comme nom de code : Iceland, Tonga et Maui. On verrait ensuite débarquer la nouvelle architecture Pirate Islands en 2015 qui devrait inaugurer la gravure en 20 nm. On a essayé de regarder dans sa boule de cristal mais on a rien vu ! De là à dire qu'on est aveugle ...

 

sk_hynix_hbm.jpg  

Un poil avant ?

Plein de tests de cartes maman Z97, M2 en force

Un peu plus tard ...

Une carte mère équipée d'un Pentium quad-core J2900 fanless avec un TDP de 10W

Les 31 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un ragoteur de Lorraine, le Mardi 13 Mai 2014 à 09h39  
Si la question porte sur la latence "chiffrée", type tCL, c'est un tel bazar que c'est difficilement explicable. Il y en a tout un wagon et chacune a son propre impact.
par Un ragoteur de Lorraine, le Mardi 13 Mai 2014 à 09h36  
La question n'est pas de savoir si c'est possible en théorie, mais en pratique.

Un CPU traite les données principalement en série et ces données sont de taille bien inférieure à ce que balance la RAM, d'où les caches et une exécution OoO très lourde en logique pour limiter les cas extrêmes, par exemple où on ne lit qu'une donnée 32bits pour un paquet de 512bits. Cette taille minimale de 512bits est due au fait que la RAM fonctionne en réalité à une fréquence très inférieure à celle du bus de données, historiquement 100 à 200MHz, 200MHz correspondant à la DDR-400 PC3200/DDR2-800 PC2-6400/DDR3-1600 PC3-12800. On n'a vu arriver plus rapide que récemment dans les papiers du JEDEC.

C'est certainement encore pire avec les CPU multi-cores, puisque chaque core accède à son propre code pas forcément dans le même espace RAM que les autres. Tout ça montre bien à quel point cette voie a toujours été hasardeuse, au final...
par Un ragoteur de passage embusqué, le Mardi 13 Mai 2014 à 08h35  
Merci pour la reponse. Mais desole d insister, cela veut il dire que tous les 256 (ou 512) bits le temps de latence intervient? Pas moyen d envoyer des donnees e tdonc une page entiere en burst?
par Un ragoteur de Lorraine, le Lundi 12 Mai 2014 à 19h10  
par JeNeSuisPasUnTroll embusqué le Lundi 12 Mai 2014 à 13h02
En quoi les latences memoires affectent elles les perfs CPU sachant que les PCU addressent des pages entieres de memoire plutot que des bouts de ligne memoire?
Les données sont fondamentalement accédées par unité (32, 64, 128 ou 256bits), la RAM les envoie en outre par prefetch de 8 données 64bits et pour compenser ça il faut déjà réorganiser les opérations de lecture/écriture. On peut voir ce que ça donnait déjà avec les modes ganged/unganged chez AMD (bus 128bits ou 2 bus 64bits indépendants).

Pour un GPU c'est moins problématique.
par Vincent S., le Lundi 12 Mai 2014 à 15h48  
par Un ragoteur sans nom d'Ile-de-France le Lundi 12 Mai 2014 à 12h20
AMD and Hynix announce joint development of HBM memory stacks (décembre 2013)
En effet l'info est "vieille" mais n'avait pas été rendue publique de manière massive et AMD n'avait pas précisé quand cette mémoire serait intégrée dans les cartes.
par YulFi le Lundi 12 Mai 2014 à 13h48
On peut s'étrangler avec un noyau mais parler de noyau d'étranglement c'est une expression du comptoir ?
J'ai trop abusé du goulot !
par YulFi, le Lundi 12 Mai 2014 à 13h48  
On peut s'étrangler avec un noyau mais parler de noyau d'étranglement c'est une expression du comptoir ?
par JeNeSuisPasUnTroll embusqué, le Lundi 12 Mai 2014 à 13h02  
Enfin une innovation digne de ce nom chez AMD? Ca me parait plausible car il en avait deja etait question pour la Playstation 4 (Sony regardant tous les moyens possible pour decupler la bande passante).

Question aux specialistes: En quoi les latences memoires affectent elles les perfs CPU sachant que les PCU addressent des pages entieres de memoire plutot que des bouts de ligne memoire?
par Un ragoteur sans nom d'Ile-de-France, le Lundi 12 Mai 2014 à 12h20  
AMD's Technical Forum and Exhibition 2011 (TFE 2011):
Blazing A Trail to High Performance Graphics

AMD and Hynix announce joint development of HBM memory stacks (décembre 2013) :

- [Bryan Black, Sr Fellow and 3D program manager at AMD] announced that AMD is co-developing HBM with SK Hynix which is currently sampling the HBM memory stacks and that AMD "...is ready to work with customers."
- [Minsuk Suh, principle engineer at Hynix] indicated that the first application for HBM would be GPUs and that it will next move to networking and HPC applications.
par Un ragoteur de Lorraine, le Lundi 12 Mai 2014 à 12h14  
par Activation le Lundi 12 Mai 2014 à 11h01
Après l'idée c'est pas de pondre des bus 2048bits.
Manque de pot, c'est pile pwal l'idée...

HBM et HMC (2 pseudo-technologies qui sont en réalité un seul et même concept chez les 2 principaux concurrents de la RAM) ne se justifient QUE par ça, sachant que ça implique :

- une baisse de consommation sensible à bande passante équivalente (un bus 1024bits @600MHz consomme moins qu'un bus 256bits @2400MHz, gros problème de la GDDR5 malgré les bidouilles destinées à réduire la conso)
- une baisse de conso indirecte par l'utilisation d'un bus point-à-point court (voir articles sur Mullins parlant des améliorations côté conso)
- un gain de place non-négligeable à largeur de bus égale (pas de pad destiné à la connexion au package pour cette RAM)

Reste que 1024bits @1.2Gbps/pin c'est pas terrible terrible, juste bon pour du mainstream 2015 (R9-270X -> 256bits @5.6Gbps/pin, soit 15% de plus... en tablant sur des GPU légèrement plus puissants, il faudrait combiner cette HBM à de la RAM externe 128/9.6 ou 256/4..

Pour les APU, par contre, ça a tout son sens, en l'utilisant comme un énorme scratchpad ou L3/L4 (actuellement, 128bits @2.1Gbps/pin)
par Activation, le Lundi 12 Mai 2014 à 11h07  
par lulu-nico le Lundi 12 Mai 2014 à 08h17
ça va arriver sur des gpu en 20 qui on donc plus de puissance de calcul et donc un plus gros besoin de bande passante qu'actuellement.
Pour ça qu'il y a des caches dans les cpu et gpu, des prefetchs,...

La mémoire là elle est en amont, sans les caches... elle resterait en amont quand même

ici on reste toujours pour le moment à l'optimisation d'une mémoire unifié cpu/gpu avec à la clé la réduction des lecture mais surtout écriture inutile consommatrice
ça nécessite pas forcément plus de bande passante, mais plutôt de faire travailler gpu et cpu plus intelligemment ensemble

dans le genre, pourquoi envoyer un courrier papier à qqun par la poste si t'habite le même immeuble que lui, la solution n'est pas de filer une ferrari au postier n'y de mettre une autoroute 12 voies entre le bureau de poste et l'immeuble
La première étape c'est plutôt de lui mettre direct le courrier sans timbre dans sa boite au rez de chaussée si personne répond à sa porte
par Activation, le Lundi 12 Mai 2014 à 11h01  
C'est surtout qu'au lieu de devoir mettre 4 puces adressé chacune en 32bits pour avoir un bus 128bits.
Tu ne va mettre qu'une puce de 4couches adressé au total en 128bits un gain de place d'un rapport 4, qui permet de voir arrivé des gpu ET soc avec la mémoire total système ET graphique unifié.
Après cela risque d'être des die secondaire accolés au die du gpu/soc

En cela aucune révélation ici.
Ça existe déjà en monocouche tout comme ça existe déjà che nvidia, et est également prévu en multicouches aussi chez nvidia (maxwell c'est pas que pour du gpu).

Après l'idée c'est pas de pondre des bus 2048bits.
C'est avant tout d'unifier mémoire systeme et gpu physiquement (comme une ps4 par exemple).
Et du fait de réduire les distances entre la mémoire, le cpu et le gpu d'en réduire la latence (ce que tout le monde vise, amd, intel, apple, nvidia,samsung, qualcomm, etc...)

Ce qui me semble le plus ridicule c'est la pertinence de s'emmerde à vouloir sortir la ddr4, tellement tout porte à laisser penser qu'on va vers une mémoire unique qui est la remplacante de la gddr5 actuelle, avec toute cette unification.

La ddr4 c'est autant dire mort né, son seul intérèt c'est de proposer une bande passante double comparé à la ddr3, donc nécessité un nombre 2x moindre de puces pour une même bande passante, mais si au final on joue à la guéguerre du nombre de couches
par Petalpusher, le Lundi 12 Mai 2014 à 10h20  
Ca craint pas d'arriver sur la prochaine gen AMD en étant aux premiers samples.. mais ca arrivera surement en masse dans les 5 ans. Ce qu'on voit là c'est un interposer, ca va permettre de coller des bus énormes 1024/2048 facile mais la mémoire en elle même va pas évoluer dans les mêmes proportions en fréquence, voire régresser car c'est des process plus généralistes que ce qui est utilisé pour de la GDDR5 par exemple.