Le topic de la DDR (DDR3, 4 et 5 welcome, GDDR aussi)

[vectra]

Hello les canards,


A la demande générale, je cesse de flooder le beau topic de la programmation pour venir flooder chez Hardware Advanced.

J'ai genre plein de questions sur la mémoire en général, donc hop, sans transition.


J'ai passé quelques jours à essayer de comprendre la différence entre DDR3 et DDR4 afin de comprendre un peu quels débits maximums on pourrait espérer obtenir.
Visiblement, avec du quad-channel sur Haswell-E et en o/c l'Uncore, on devrait atteindre environ 70 Go/s, ce qui n'est tout de même pas rien.


J'ai voulu voir un peu quel futur il y aurait pour la DDR, étant donné que la DDR4 semble marquer la fin d'un cycle technologique.
Visiblement, y'a du nouveau pour la "DDR5", à savoir des puces mémoire 3D à gros débit qui tache, mais qui ne seraient pas normalisées JEDEC.

Sur CPU, ils prévoient ça pour 2017 (!!) et avec des débits de 125 à 400 Go/s.
Sur GPU, ils ne sont pas en reste, et avec le même type de puces, Nvidia promet le To/s dans plus ou moins les mêmes délais.

http://www.extremetech.com/computing...id-memory-cube


Hé ben. Il se passe plein de trucs et on ne me dit rien

[Foudge]

A noter qu'on trouve déjà la HBM sur des produits grand public : les Radeon Fury à base du GPU Fiji (8.9Md de transistors, 4 Go de HBM en 4096bit).
Petite photo :


Hardware.fr avait fait un dossier sur ce type de mémoire, juste avant la sortie de ces cartes : http://www.hardware.fr/focus/109/com...e-par-amd.html

On parle déjà de mémoire HBM de deuxième génération tandis que Micron part plutôt sur de la GDDR5X, qui permet de doubler les débits par rapport à la GDDR5.

Ce post était sponsorisé par HFR

[vectra]

HBM et HMC sont dans un bateau...

Donc en fait, deux technologies qui ont l'air assez similaires on dirait, notamment au niveau des perfs.
Ca va sûrement donner des GPUs de riches avec encore plus de bande-passante que d'hab, mais là on est presque habitués.

Par contre, la grosse baffe, ce serait de voir arriver ce genre de mémoires sur CPU. Ou là, on va passer direct à 100 ou 200 Go/s sur le pécé à mémé
C'est prévu au moins pour la HMC / Intel, semble-t-il.

[Møgluglu]

De ce que j'ai compris, l'idée de la HBM consiste à amener la mémoire plus près du processeur, quitte à en avoir moins (et à l'utiliser comme cache de dernier niveau ou gros scratchpad). Donc tu auras quelques Go sur le package, et le reste en DDR classique.
Pour le HMC, l'idée est plus d'amener la logique plus près de la mémoire : on des buffers avec SerDes comme au temps de la FBDIMM, mais sur le même package. Il y a pas-mal de hype autour du near-memory processing aussi : tant qu'à avoir de la logique dans ta puce mémoire, tu peux autant calculer des trucs directement sur place sans avoir à faire l'aller-retour jusqu'au processeur.

[vectra]

Programmer des minicores déportes sur la mémoire?
C'était pas presque l'idée derrière les GPU

Au lieu d'avoir une grille de cores qui parcourent la mémoire, on a carrément la mémoire qui est aussi un core?

[Møgluglu]

C'est pas forcément un core à la Von Neumann. Pour l'instant, sur le HMC 1.0, tu peux faire des accumulations atomiques 128-bit + 64-bit -> 128-bit, où le mot 128-bit reste en mémoire. C'est déjà pratique pour faire des réductions et des histogrammes. On peut imaginer étendre ça à des multiply-accumulate pour faire des produits scalaires et des convolutions avec un des vecteurs en mémoire par exemple.

[vectra]

Si ça s'étendait encore un peu plus, ça serait vraiment une grosse avancée.

Dans le même temps, est-ce que les gens avec des CPUs seront prêts à payer plus cher pour ça?
Pour les GPUs de compèt à 800 euros, c'est open-bar par contre.

[hellsing]

De ce que j'ai compris, l'idée de la HBM consiste à amener la mémoire plus près du processeur, quitte à en avoir moins (et à l'utiliser comme cache de dernier niveau ou gros scratchpad). Donc tu auras quelques Go sur le package, et le reste en DDR classique.
Pour le HMC, l'idée est plus d'amener la logique plus près de la mémoire : on des buffers avec SerDes comme au temps de la FBDIMM, mais sur le même package. Il y a pas-mal de hype autour du near-memory processing aussi : tant qu'à avoir de la logique dans ta puce mémoire, tu peux autant calculer des trucs directement sur place sans avoir à faire l'aller-retour jusqu'au processeur.

Pour moi la HBM est surtout un paliatif à moyen terme.
Les débits doivent augmenter donc soit on parallélise à mort et on augmente un peu les débits mais le routage est une merde absolue, et la conso des IO augmente pas mal.
Soit on sérialise les data et on met plusieurs liens série, mais la longueur des interconnections devient génante (au dela de 20gb/s faut encore changer vers un substrat encore plus cher), la latence augmente. Les serdes à 24gb/s ça suce l'air de rien en plus. Faut barde le tout d'équalizer de de pré-emphasis, bref ça commence à couter cher à designer (mais ça me fait du travail )

A long terme la vram sera embarquée dans le GPU. Actuellement c'est quasi impossible, les rendements s'écroulent trop avec l'augmentation de la surface du die.

Les fabricants de fpga ont la même problématique, et ont trouvé la solution depuis un moment :
http://www.xilinx.com/support/docume...Technology.pdf
allez directos page 4 pour voir le principe. Ca coute ultra cher en prod mais vu le prix de ventes des puces (10k) c'est pas grave.

Ca sera pas pour tout de suite mais la tendance dans l'industrie est la.
On pousse vers de plus en plus d'intégration, de plus en plus les SoC et SiP se démocratisent, même dans le spatial qui est le marché le plus frileux possible (genre le rohs ils connaissent toujours pas)

[Møgluglu]

A long terme la vram sera embarquée dans le GPU. Actuellement c'est quasi impossible, les rendements s'écroulent trop avec l'augmentation de la surface du die.

Embarqué dans le package comme actuellement OK, mais dans le même die ça me paraît compliqué. Au moins tant qu'on reste sur de la techno DRAM. Optimiser un process pour de la logique ou pour de la DRAM c'est plutôt antinomique. L'espoir est plutôt dans les nouvelles mémoires non-volatiles qui pourraient changer la donne.

Les fabricants de fpga ont la même problématique, et ont trouvé la solution depuis un moment :
http://www.xilinx.com/support/docume...Technology.pdf
allez directos page 4 pour voir le principe. Ca coute ultra cher en prod mais vu le prix de ventes des puces (10k) c'est pas grave.

Ce qui est décrit dans le whitepaper, c'est du 2.5D sur Silicon Interposer.
La HBM, c'est pareil mais avec en plus plusieurs dies mémoire superposés et des TSV à travers.

[hellsing]

Oui dans le même package, mais sur le même die actuellement c'est mort (process, rendement, alim etc). Un jour on y passera je pense.
Et comme tu peux pas stacker le gpu avec la ram, tu pourra jamais évacuer correctement les 100W du GPU, donc tu va la mettre à coté sur l'interposer (2.5D). Avec un gros capot par dessus le tout. Tu gagne de la place par rapport à la HBM

La HBM est juste une étape intermédiaire, mais je peux me planter. J'aimerais bien voir les rendements de la HBM d'ailleurs, surtout des TSV.

[Møgluglu]

Quelle est la différence par rapport à Fiji au-dessus, du coup ? Je vois un GPU et 4 stacks de HBM côte-à-côte sur un interposer. C'est pas exactement ce que tu décris ?

[hellsing]

Quelle est la différence par rapport à Fiji au-dessus, du coup ? Je vois un GPU et 4 stacks de HBM côte-à-côte sur un interposer. C'est pas exactement ce que tu décris ?

Ha ils font déjà ça, merde suis à la bourre. Me semblait que le hbm était dans un un package dédié et passait par un interposer pas en silicum.

En effet c'est tout joli:
http://www.hardware.fr/medias/photos...G0047672_1.jpg

Tu vois je suis un visionnaire, je prédis le passé!!

[Møgluglu]

Ouf, j'ai eu peur. Sinon pour les FPGA, Intel a une solution pour se passer d'interposer et de TSV :
https://www.altera.com/content/dam/a...in-package.pdf
(là ça commence page 6)