Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
971 connectés 

  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Actu : Samsung atteint 2.4 Gbps en HBM2

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[HFR] Actu : Samsung atteint 2.4 Gbps en HBM2

n°10311582
Marc
Super Administrateur
Chasseur de joce & sly
Posté le 15-01-2018 à 09:30:25  profilanswer
0Votes positifs
 

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 ...

mood
Publicité
Posté le 15-01-2018 à 09:30:25  profilanswer
 

n°10311604
sebaas
Posté le 15-01-2018 à 10:04:33  profilanswer
1Votes positifs
 

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

n°10311617
lulunico06
Posté le 15-01-2018 à 10:24:28  profilanswer
1Votes positifs
 

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.

n°10311639
Multithrea​d
Regulus Nerdeus
Posté le 15-01-2018 à 11:10:07  profilanswer
1Votes positifs
 

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 :spamafote:

Message cité 1 fois
Message édité par Multithread le 15-01-2018 à 11:15:18

---------------
"-T'as mis quoi comme pâte thermique ??? :X "   "-C koi la pate thermique ?"
n°10311644
lulunico06
Posté le 15-01-2018 à 11:20:00  profilanswer
1Votes positifs
 

Multithread a écrit :

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 :spamafote:


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

n°10311778
Riseoflege​nds
Posté le 15-01-2018 à 14:43:12  profilanswer
0Votes positifs
 

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

n°10311983
Icorgnobi
zyps inside
Posté le 15-01-2018 à 20:05:45  profilanswer
1Votes positifs
 

Multithread a écrit :

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 :spamafote:

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 ?!

n°10312037
Spartan88
Posté le 15-01-2018 à 21:35:56  profilanswer
1Votes positifs
 

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.

n°10312094
Zurkum
Posté le 15-01-2018 à 23:07:43  profilanswer
0Votes positifs
 

Spartan88 a écrit :

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  :O

n°10312101
B00lay Ier
Posté le 15-01-2018 à 23:16:49  profilanswer
0Votes positifs
 

Riseoflegends a écrit :

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


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

mood
Publicité
Posté le 15-01-2018 à 23:16:49  profilanswer
 

n°10312102
Zurkum
Posté le 15-01-2018 à 23:18:07  profilanswer
0Votes positifs
 

B00lay Ier a écrit :


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


Comme les R300, 400 et 500 du coup  :O

n°10312249
lulunico06
Posté le 16-01-2018 à 11:53:03  profilanswer
0Votes positifs
 

Zurkum a écrit :


Comme les R300, 400 et 500 du coup  :O


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.

n°10312251
Zurkum
Posté le 16-01-2018 à 11:54:46  profilanswer
0Votes positifs
 

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

n°10312287
B00lay Ier
Posté le 16-01-2018 à 13:03:51  profilanswer
0Votes positifs
 

lulunico06 a écrit :

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.


Y'a pas eu de R500, c'était R520 :o (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é :whistle:  
 
Le bus 512bits était inutile vu le peu de puissance en texturing/rasterizing, mais la GDDR4 n'apportait vraiment pas grand chose.

n°10312313
havoc_28
Posté le 16-01-2018 à 13:30:27  profilanswer
1Votes positifs
 

B00lay Ier a écrit :


Y'a pas eu de R500, c'était R520 :o (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é :whistle:  
 
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 :p.

n°10312314
lulunico06
Posté le 16-01-2018 à 13:31:02  profilanswer
0Votes positifs
 

B00lay Ier a écrit :


Y'a pas eu de R500, c'était R520 :o (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é :whistle:  
 
Le bus 512bits était inutile vu le peu de puissance en texturing/rasterizing, mais la GDDR4 n'apportait vraiment pas grand chose.


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

n°10312359
B00lay Ier
Posté le 16-01-2018 à 14:13:39  profilanswer
0Votes positifs
 

havoc_28 a écrit :

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


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".

Message cité 1 fois
Message édité par B00lay Ier le 16-01-2018 à 14:15:11
n°10312453
lulunico06
Posté le 16-01-2018 à 16:37:43  profilanswer
0Votes positifs
 

B00lay Ier a écrit :


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.

n°10312472
havoc_28
Posté le 16-01-2018 à 17:05:13  profilanswer
0Votes positifs
 

B00lay Ier a écrit :


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 assez de bande passante comme le souligne lulunico06.  
 
Les performances ne décollaient pas vraiment VS Hawaï ...


Message édité par havoc_28 le 16-01-2018 à 17:12:17
n°10312514
lulunico06
Posté le 16-01-2018 à 17:58:02  profilanswer
0Votes positifs
 

havoc_28 a écrit :


 
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 ?

Message cité 1 fois
Message édité par lulunico06 le 16-01-2018 à 18:16:34
n°10312555
havoc_28
Posté le 16-01-2018 à 18:59:45  profilanswer
0Votes positifs
 

lulunico06 a écrit :


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.


Message édité par havoc_28 le 16-01-2018 à 19:04:56
n°10312612
lulunico06
Posté le 16-01-2018 à 20:32:35  profilanswer
0Votes positifs
 

havoc_28 a écrit :


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 ?

n°10312660
havoc_28
Posté le 16-01-2018 à 22:52:10  profilanswer
0Votes positifs
 

lulunico06 a écrit :


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.


Message édité par havoc_28 le 16-01-2018 à 22:55:37
n°10312669
lulunico06
Posté le 16-01-2018 à 23:09:21  profilanswer
0Votes positifs
 

havoc_28 a écrit :


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.

Message cité 1 fois
Message édité par lulunico06 le 16-01-2018 à 23:37:41
n°10312693
B00lay Ier
Posté le 17-01-2018 à 00:52:19  profilanswer
0Votes positifs
 

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...


Message édité par B00lay Ier le 17-01-2018 à 00:53:38
n°10312695
HashBoost
Posté le 17-01-2018 à 01:02:19  profilanswer
0Votes positifs
 

lulunico06 a écrit :

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.


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.


Message édité par HashBoost le 17-01-2018 à 01:02:37
n°10312809
lulunico06
Posté le 17-01-2018 à 10:31:55  profilanswer
0Votes positifs
 

HashBoost a écrit :


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é ?

n°10312886
havoc_28
Posté le 17-01-2018 à 12:22:31  profilanswer
0Votes positifs
 

lulunico06 a écrit :


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.


 
Pourquoi un seul empilement ?

n°10312891
lulunico06
Posté le 17-01-2018 à 12:32:46  profilanswer
0Votes positifs
 

havoc_28 a écrit :


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

n°10313146
havoc_28
Posté le 17-01-2018 à 19:52:19  profilanswer
0Votes positifs
 

lulunico06 a écrit :


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.


Message édité par havoc_28 le 17-01-2018 à 19:53:06
n°10313198
B00lay Ier
Posté le 17-01-2018 à 21:28:18  profilanswer
1Votes positifs
 

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).


Message édité par B00lay Ier le 17-01-2018 à 21:28:42
n°10313215
lulunico06
Posté le 17-01-2018 à 22:07:48  profilanswer
0Votes positifs
 

B00lay Ier a écrit :

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


Message édité par lulunico06 le 17-01-2018 à 22:13:07
n°10313241
HashBoost
Posté le 17-01-2018 à 22:42:36  profilanswer
1Votes positifs
 

lulunico06 a écrit :

C'est moins efficace qu'un unique gros die mais niveau coût de production rien a voir.


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.

n°10313243
HashBoost
Posté le 17-01-2018 à 22:44:45  profilanswer
0Votes positifs
 

lulunico06 a écrit :

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


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.

n°10313267
B00lay Ier
Posté le 18-01-2018 à 00:13:03  profilanswer
0Votes positifs
 

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.


Message édité par B00lay Ier le 18-01-2018 à 00:13:42
n°10313371
lulunico06
Posté le 18-01-2018 à 10:14:51  profilanswer
0Votes positifs
 

HashBoost a écrit :


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.


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.

n°10313372
lulunico06
Posté le 18-01-2018 à 10:16:59  profilanswer
0Votes positifs
 

HashBoost a écrit :


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.


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.

n°10313443
HashBoost
Posté le 18-01-2018 à 12:57:56  profilanswer
0Votes positifs
 

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.

n°10314256
B00lay Ier
Posté le 19-01-2018 à 19:33:00  profilanswer
0Votes positifs
 

lulunico06 a écrit :

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.


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.

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Actu : Samsung atteint 2.4 Gbps en HBM2

 

Sujets relatifs
[HFR] Actu : CES: Un écran OLED 4K 21.6 pouces chez Asus ![HFR] Actu : CES: L'Exynos 9810 de Samsung en image
[HFR] Actu : CES: Thermaltake annonce son Level 20[HFR] Actu : CES: Un hybride laptop/smartphone chez Razer
[HFR] Actu : CES: Trois écrans DisplayHDR en démo 
Plus de sujets relatifs à : [HFR] Actu : Samsung atteint 2.4 Gbps en HBM2


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR