Samsung annonce le début de la production en volume d'une puce HBM2 de 8 Go fonctionnant à 2.4 Gbps et atteignant donc une bande passante de 307 Go/s via son ...
Lire la suite ...

Merci, il sera intéressant de voir les gains perf/conso apportés.

C'est dommage que Samsung ne propose qu'une plage de fréquence/tension
On pourrait par exemple avoir du 1.5 ghz/1.35v ou 800 mhz/1.1v voir même 700 mhz/1v ( approximation pour donner un exemple )
On pourrait avoir plus de bande passante avec moins de pile de hbm et donc réduction de coup
Ou en mobile réduction de la consommation.

En même temps que Ryzen+, ça pourrait faire une bonne surprise pour une Vega refresh, genre les modules 1.9Gbps pour la 56 et 2.4 pour la 64 mais bon, c'est pas prévu dans la roadmap

Oui en 12 nm fréquence en hausse hbm en hausse et qui consomme moins mais amd n'a rien prévu

AMD devrait quand-même sortir la génération 600 cette année, à voir ce que ce sera.

Les Vega 64/56 comme les Vega M 24/20 sont équipées de puce(s) HBM2 de 4 Gio. (Respectivement deux puces 1,9/1,6 Gbps et une puce 1,6/1,4 Gbps.)
Or il est question dans cette annonce d'une puce de 8 Gio.
Donc si un hypothétique refresh de Vega utilisait cette puce, il s'agirait avant tout d'une quantité de mémoire doublée. (Il y a déjà eu un précédent avec le refresh des 290(X) en 390(X).)
 
Seulement, AMD se fournissant généralement chez SK Hynix, peut-être Samsung vise-t-il d'autres débouchés pour cette puce ?
Ainsi, sur le marché pro, Nvidia ayant déjà fait appel à Samsung pour la HBM2 de ses Tesla V100, peut-être serait-il intéressé de décliner son porte-étendard en version 32 Gio avec 1,23 To/s de bande passante ?!

Si ça permet d'avoir une Vega Refresh de moins de 30cm en custom et pour 360 boules, alors oui ! Sinon se sera comme pour Vega 1er du nom, Plouf dans l'eau pour AMD.

Enfin moins de 30cm, 350W, le radiateur en conséquence, j'ai peur pour un petit PCB  

Le R600 c'est déjà passé, et c'était pas glorieux...

Comme les R300, 400 et 500 du coup  

Non le r300 était en avance sur son temps un excellent gpu
Le r400 n'était qu'un double r300.
Le r500 évoluait enfin dans le bon sens suivie du r580 qui commençait a avoir plus de sp que de tmu.
Le r600 dommage que les rops était buger les performances aurait été autre
Mauvais choix du bus 512 bits le rv670 a montré que c'était initile.
Il fallait bus 256 bits gddr4 moins couteux.

C'était une blague je parlais des R9/RX 300,400 et 500  

Y'a pas eu de R500, c'était R520 (idem pour R400 d'ailleurs)
 
Par contre, pour la séquence R600/RV670, on a strictement la même avec Fiji/Vega, si t'avais pas remarqué  
 
Le bus 512bits était inutile vu le peu de puissance en texturing/rasterizing, mais la GDDR4 n'apportait vraiment pas grand chose.

 
Juste que Vega a en plus quelques spécificités niveau compute que n'avait pas Fiji .

Oui tu as raison
Pour le bus difficile de juger vu les rops buger
La gddr4 aurait apporter un peu de bande passante en plus sans couter plus cher ou très peu donc bon a prendre

Qui n'avait pas un excédent de BP évident, en prime.

C'est peut-être plus proche de la différence entre RV770 et Juniper, mais c'était déjà pas énorme comme différence "pratique".

Fiji avait plus de bande passante que besoin car compression couleur apportée avec gcn 1.2 et cache l2 bien plus grand
Donc 512 go/s c'était largement suffisant.
Vega 10 a une puissance de calcul qui augmente de 1/3 donc juste une compression en plus c'est un peu juste.
Amd a rajouter enfin comme nvidia la rasteristion mais impossible de savoir si c'est activé ou non.

 
Fiji avait assez de bande passante comme le souligne lulunico06.  
 
Les performances ne décollaient pas vraiment VS Hawaï ...

Fiji avait trop de sp et pas assez de géométrie ( shader engine )
Pour vega 10 limité par la taille du die a cause de l interposé, une fois les nouveauté du die ajouté il ne restait assez de place que pour ou plus de sp se qui est initile ou plus de shader engine sans plus de sp mieux mais peut de performance en plus vu que la puissance de calcul ne bouge pas.
Augmenter la fréquence permet plus se géométrie et plus de puissance de calcul.
Mais toujours un déséquilibre avec trop de sp.
Vu que la bande passante ne bouge pas de fiji a vega 10 comme la fréquence augmente 48 rops n'était pas suffisant ?

 
G.C.N. étant bloqué à 4 Shader Engine depuis Hawaï ... la seul façon d'augmenter la puissance géométrique/tesselation c'est en augmentant la fréquence et part quelques "astuces" comme les "Primitive Shader", mais bon ça nécessite un travail coté dév ...   De plus, le nombre de ROPs doit être dictée par la largeur du bus mémoire et ses 2 empilements sur 2048 bits, passé à 32 ROPs aurait été clairement insuffisant.
 
Pour avoir 48 ROPs faudrait genre avoir 3 empilements ... de HBM2.

Amd a dit qu'il peut faire des design avec 8 shader engine
6 c'est possible ? Si non pourquoi ?
Il y a 4 bus 512 bits pour 2 piles de hbm
Mettre 12 rops par bus au lieu de 16 ce n'est pas possible ? Encore une fois si c'est non pourquoi ?

 
Oui, AMD a dit qu'il pourrait augmenter le nombre de shader engine, mais que ce n'était pas nécessaire selon eux, c'est surtout que impliquerait de gros travaux du coté du compilateur ... chantiers qu'ils n'ont pas les moyens de mener.
 
ROPs et largeurs de bus sont toujours des multiples sur les GPUs non castrés.

Le 7 nm augmentant la densité de ninimum x2 x3 s'ils utilisent tsmc ça va être obligatoire.
Sauf si la rumeur de plusieurs die relié par infinity fabric prend forme.
Du coup amd ferais bien de faire un die optimisé pour une pile de hbm.

Genre celui qu'on retrouve sur Kaby Lake G?

Le problème c'est qu'en coller plusieurs côte à côte c'est un vrai casse-tête niveau process, sans même parler de la nécessité d'employer un bus à gros débit entre chaque "GPU" si on veut pas y perdre en perfs...

L'Infinity Fabric n'est pas la panacée a tout les problèmes, c'est au contraire rajouter une complexité supplémentaire. Autant avec les CPU, AMD a pu concevoir des blocs de base relativement bien maitrisés et donc ils peuvent les relier sans (trop de) problèmes, autant au niveau GPU ils sont loin de ça.
A mon avis, la grande fautive, c'est GCN. Avec Fidji déjà, c'est un facteur limitant. Avec Vega, c'est encore plus criant. GCN n'est plus adaptée. Il faut donc arrêter de la faire évoluer et repartir sur quelque chose de plus actuel.

Amd en a développé une pour gou a 512 gbps ce n'est pas rien
C'est moins efficace qu'un unique gros die mais niveau coût de production rien a voir.  
C'est dommage que gcn ne soit pas modulaire qu'on rajoute x unité de telles type si besoin.
Pour la rasteristion sur vega on a des nouvelles ? C'est activé ?

 
Pourquoi un seul empilement ?

Amd prévoit un die optimisé pour utiliser la bande passante d'une seul pile de hbm
Le die sera petit et donc peu coûteux.
Tu veux plus puissant tu mets plusieurs fois ce die avec sa pile de hbm et tu relie les die par infinity fabric
Un peu moins efficace qu'un seul gros die avec autant d'unité mais fain de rendement zt se coût évident.
Infinity fabric spécial gpu a 512 gbps actuellement voir plus dans des futurs version pas celle de ryzen

 
Le multi DIE coté GPU c'est pas pour tout de suite, c'est des pistes en études, on est loin de l'application réelle de la chose.

Tel que c'est parti, en prime, c'est plutôt NVidia qui le fera en premier...

Les GP/GV100 intègrent les prémices et ils ont déjà publié il y a un moment leur stratégie multi-dies (remodelage de la hiérarchie des caches).

Tu appelles quoi prémices ? Les gpc dans les die ça a commencé avec kepler il me semble

Oh que non ! Imaginons un Infinity Fabric reliant des modules GPU. Ce bus ou "switch" chargé de relier les GPU a un coût en transistor qui est important, car il ne contribue pas de manière directe à la puissance de calcul de la puce, il ne sert qu'a coordonner les GPU. Or, si on regarde un peu l'état de l'art d'AMD en rapport puissance GPU / transistors, ils sont en retard. Rajouter un bus de ce genre ne ferait qu'aggraver la situation.

Quand tu as plusieurs CPU ou GPU qui accèdent à la mémoire, tu dois prévoir un système d'arbitrage et de synchronisation des caches. NVidia sait le faire, exploite déjà son NVLink et les API qui vont avec. C'est complètement différent d'un comportement comme le SLI ou le Crossfire.

C'était effectivement le NVLink, pour les caches faudrait retrouver l'article qui en causait, mais il est déjà passé sur le forum il me semble.

Non mais je parles de faire comme sur threadripper avec une version plus rapide de l infinity frabric.
Au lieu de faire un gros die genre 8192 sp en faire un de 2048 et les relier comme threadripper
Un peu moins performant mais beacoup moins coûteux.

Ok je vois
La rumeur veut que amd face des multi die aussi en gpu donc ils ont sûrement un truc équivalent dans les cartons.

La rumeur voulait qu'AMD sorte des radeons qui défoncent NVidia en puissance / consommation, ils ont sortit les RX. La rumeur voulait que AMD révolutionne le marché du GPU avec Vega, ils ont juste creusé encore plus leur retard.
 
Tu devrais être vacciné contre les rumeurs non ? Même s'il est certain qu'AMD est acculé a réussir son prochain GPU sous peine de disparaitre, je les vois mal tenter un pari aussi risqué, ils n'ont pas la maitrise qu'NVidia a déjà sur ce point et la prise de risque serait vraiment énorme. Leur prochain GPU sera juste une évolution des RX, forcément osée techniquement (sur le process de gravure a priori, peut être avec d'autres surprises), pour se refaire la cerise et recoller en termes de PDM.
Le multi GPU sera certainement introduit comme NVidia l'a fait, via une carte pro pour serveur, histoire là aussi d'exister sur le marché de l'IA qui est en train de lui échapper complètement.

Le problème de cette approche, c'est que l'interconnexion sera elle-même énergivore, les perfs ne seront elles pas forcément mauvaises... sauf qu'AMD a déjà un gros problème côté consommation à cause de ce type de communication, ça aggraverait donc un problème déjà existant.