[HFR] Actu : AFDS: Retour sur le futur GPU d'AMD

Actu : AFDS: Retour sur le futur GPU d'AMD [HFR] - HFR - Hardware

Marsh Posté le 16-06-2011 à 22:02:06   0  

Lors du dernier keynote de l'AFDS, Eric Demers, Chief Technology Officer pour la partie GPU chez AMD, est revenu sur la future architecture GPU qui a été ...
Lire la suite ...

Reply

Marsh Posté le 16-06-2011 à 22:02:06   

Reply

Marsh Posté le 16-06-2011 à 22:38:22   0  

Très intéressant, du bon boulot comme d'habitude !!
Merci !

Reply

Marsh Posté le 16-06-2011 à 22:39:07   0  

Si AMD ne connait aucun problème d'exécution, les solutions à venir de chez eux vont être très intéressantes.

Reply

Marsh Posté le 16-06-2011 à 22:39:41   0  

Merci damien ! ;)

Reply

Marsh Posté le 16-06-2011 à 23:46:00   0  

L'unité "scalaire" ne serait-elle pas une extension de l'unité de branchement qui existe depuis quelque chose comme la famille R500?
 
Il sera intéressant de voir les choix qu'AMD aura opéré et qui seront directement fonction du process utilisé, petit die et grosse fréquence (indiquant un process assez enclin à produire des fuites statiques) ou gros die et fréquence modérée (indiquant à l'inverse des fuites statiques minimes mais un process pouvant difficilement monter en fréquence, à cause de transistors lents).

Reply

Marsh Posté le 16-06-2011 à 23:48:08   0  

Visiblement il y a une unité scalaire + une unité de branchements.

Reply

Marsh Posté le 17-06-2011 à 05:30:54   0  

L'unite scalaire peut controler le "program counter" directement et prendre des decisions a partir des resultats mathematiques. Ou bien, tout simplement, elle peut charger le PC a partir d'un register, qui peut etre le resultat d'un calcul ou venir de memoire.  C'est tres flexible.  -ED

Reply

Marsh Posté le 17-06-2011 à 05:31:47   0  

En passant, la photos semble indiquer quelque chose sur ma joue.  J'espere que ce n'est pas vrai!

Message cité 1 fois
Message édité par sireric le 17-06-2011 à 05:33:36
Reply

Marsh Posté le 17-06-2011 à 08:39:35   0  

Ne reste plus qu'à espérer que nos amis de TSMC soient au point sur le procédé 28nm et que les développeurs ne mettent pas trop longtemps avant d'exploiter le potentiel de cette puce.


Message édité par Lyto le 17-06-2011 à 08:41:31
Reply

Marsh Posté le 17-06-2011 à 08:45:38   0  

Je suppose que ça dépendra en grande partie de la qualité des drivers dans un premier temps. Et c'est souvent là que la team Catalyst est pointée du doigt...
 
Espérons qu'il y ait eu de l'amélioration depuis la sortie des HD6900.
 
Mais c'est vrai que cette nouvelle architecture semble se vouloir nettement plus énergivore que la précédente... Syndrôme GF100 ?

Reply

Marsh Posté le 17-06-2011 à 08:45:38   

Reply

Marsh Posté le 17-06-2011 à 09:32:12   0  

Au passage, je lis "supporting next itération of graphics APIs" -> Y'a un nouveau DirectX qui doit sortir avec Windows 8 ?

Reply

Marsh Posté le 17-06-2011 à 09:49:31   0  

Zack38 a écrit :

Je suppose que ça dépendra en grande partie de la qualité des drivers dans un premier temps. Et c'est souvent là que la team Catalyst est pointée du doigt...
 
Espérons qu'il y ait eu de l'amélioration depuis la sortie des HD6900.
 
Mais c'est vrai que cette nouvelle architecture semble se vouloir nettement plus énergivore que la précédente... Syndrôme GF100 ?


Bah, faut pas exagérer. En général les bugs ne concernent qu'un ou deux jeux récents. Franchement, elle est loin l'époque ou l'openGL était à la ramasse et que les jeux DirectX étaient presque tous victimes d'artefacts visuels...

Reply

Marsh Posté le 17-06-2011 à 10:47:15   0  

Lyto a écrit :

Au passage, je lis "supporting next itération of graphics APIs" -> Y'a un nouveau DirectX qui doit sortir avec Windows 8 ?


 
C'est possible que Windows 8 inaugure une nouvelle version de DirectX. (11.1 ? 12 ?)
 
En revanche, j'ai beaucoup plus de mal à croire que les Radeon HD 7000 supporteront cette nouvelle API aussi tôt, c'est-à-dire plus d'un an avant le lancement de l'API...
Que ça commence à être implémenté histoire de tester en interne, je veux bien, mais pas au-delà, quoi. :D
 

Lyto a écrit :


Bah, faut pas exagérer. En général les bugs ne concernent qu'un ou deux jeux récents. Franchement, elle est loin l'époque ou l'openGL était à la ramasse et que les jeux DirectX étaient presque tous victimes d'artefacts visuels...


 
Je voulais parler de la progression dans les performances de l'architecture HD6900 par rapport aux précédentes, qui a été loin de convaincre tout le monde au lancement de ces fameuses HD6900.
 
On attend donc une amélioration à ce niveau-là dans la prochaine génération de cartes.

Reply

Marsh Posté le 17-06-2011 à 11:43:27   0  

Je viens de regarder les slides de l'architecture... à aucun moment AMD utilise le terme vec4. C'est "4 way VLIW SIMD" et ça décrit bien ce que c'est. Itanium n'est pas une archi vectorielle que je sache. Le vectoriel dans tout ça c'est le nombre de ligne (16) dans les SIMD. Et le seul scalaire présent c'est la nouvelle petite unité.
 
Forcement c'est confusionnant quand on utilise les termes marketing de nvidia pour décrire la technique de l'architecture AMD.
 
Et beaucoup de remarques pas très objectives qui laissent clairement voir une préférence de l'auteur pour une archi plutôt que l'autre.

Reply

Marsh Posté le 17-06-2011 à 12:36:09   0  

tigredubois a écrit :

voir une préférence de l'auteur pour une archi plutôt que l'autre.


 
+1, faire écrire un news AMD par un proNvidia, c'est useless :D

Reply

Marsh Posté le 17-06-2011 à 12:58:45   0  

tigredubois a écrit :

Je viens de regarder les slides de l'architecture... à aucun moment AMD utilise le terme vec4. C'est "4 way VLIW SIMD" et ça décrit bien ce que c'est. Itanium n'est pas une archi vectorielle que je sache. Le vectoriel dans tout ça c'est le nombre de ligne (16) dans les SIMD. Et le seul scalaire présent c'est la nouvelle petite unité.


Ah bon? [:gratgrat]  
 
Décidément, va falloir arrêter de sortir des âneries pareilles... le VLIW concerne justement 4/5 données et le SIMD s'effectue sur 16 unités VLIW.
 
La "future architecture" présentée pourrait par contre revoir cette organisation en VLIW de SIMD (situation actuelle chez nVidia même si ça n'est pas présenté comme ça), ce qui en ferait un processeur superscalaire orienté débit.

Reply

Marsh Posté le 17-06-2011 à 15:17:46   0  

Gigathlon a écrit :

Décidément, va falloir arrêter de sortir des âneries pareilles... le VLIW concerne justement 4/5 données et le SIMD s'effectue sur 16 unités VLIW.

Prends un café pour te réveiller et une cigarette pour déstresser et tu verra que je ne dis pas autre chose.
 

Gigathlon a écrit :

La "future architecture" présentée pourrait par contre revoir cette organisation en VLIW de SIMD (situation actuelle chez nVidia même si ça n'est pas présenté comme ça), ce qui en ferait un processeur superscalaire orienté débit.


T'es pas en train de dire que l'archi nvidia est superscalaire orientée débit ? Déjà quand il parlent de scalaire c'est un gros abus de langage puisque ce sont juste des SIMD 16 way. Avec la même logique l'archi AMD actuelle serait SIMD 16 way superscalar 4 way (le "superscalar" étant géré par des techniques statiques VLIW et non pas dynamique comme l'OO).
 
Et la nouvelle archi m'a l'air de converger vers le SIMD 16way (pas scalaire et encore moins superscalaire)
 
(remarque : le superscalaire nécessite de l'ILP)

Reply

Marsh Posté le 17-06-2011 à 17:04:53   0  

Si on réduit le SIMD à une largeur de 1, on obtient quoi?
 
Dans le cas de Cayman, un processeur traîtant 96 opérations différentes, dans le cas d'un GF1x0 un processeur traîtant 32 opérations différentes.
 
Superscalaire n'est probablement pas le terme le plus approprié puisque les "pipelines" ne sont pas des unités spécialisées, mais le comportement s'en rapproche fortement.
 
Les SIMD ne sont qu'une façon d'exécuter en parallèle de façon relativement peu coûteuse dans ce type d'architecture.

Reply

Marsh Posté le 18-06-2011 à 19:18:56   0  

> TigreDuBois : Tu es sur un site pro intel nvidia mon pote, comme la plupart des sites français , même si leurs articles sont en général très bien au demeurant sauf quand ça casse de l' amd /ati ;(


Message édité par PouicoPouic le 18-06-2011 à 19:23:56
Reply

Marsh Posté le 19-06-2011 à 01:39:57   0  

Assez marrant d'avoir ce genre de qualificatif alors qu'à d'autres périodes certains nous qualifiaient de pro ati ou pro Amd ... Comme quoi il doit y avoir autre chose ;)


Message édité par Marc le 19-06-2011 à 04:06:01
Reply

Marsh Posté le 19-06-2011 à 14:14:28   0  

Pouicopouic, trolleur expert, en même temps :jap:  
 
Je croyais qu'il avait été ban à vie du forum, comment se fait-il qu'il soit encore ici ? :o

Reply

Marsh Posté le 19-06-2011 à 15:51:06   0  

tigredubois a écrit :

Je viens de regarder les slides de l'architecture... à aucun moment AMD utilise le terme vec4. C'est "4 way VLIW SIMD" et ça décrit bien ce que c'est. Itanium n'est pas une archi vectorielle que je sache. Le vectoriel dans tout ça c'est le nombre de ligne (16) dans les SIMD. Et le seul scalaire présent c'est la nouvelle petite unité.
 
Forcement c'est confusionnant quand on utilise les termes marketing de nvidia pour décrire la technique de l'architecture AMD.
 
Et beaucoup de remarques pas très objectives qui laissent clairement voir une préférence de l'auteur pour une archi plutôt que l'autre.


 
J'utilise en général vec4/vec5 pour simplifier la description de l'architecture en reprenant le modèle qui en ressort du point de vue du programmeur. GeForce et futures Radeon : scalaire; Radeon : vec4/vec5. Ceci n'a strictement rien avoir avec le vocabulaire décidé par les équipes de com de Nvidia ou d'AMD.
 
J'ai par contre du mal à voir où les nouveautés présentées par AMD seraient critiquées ??? Toutes sont plus que bienvenues ;)

Reply

Marsh Posté le 19-06-2011 à 15:59:08   0  

sireric a écrit :

L'unite scalaire peut controler le "program counter" directement et prendre des decisions a partir des resultats mathematiques. Ou bien, tout simplement, elle peut charger le PC a partir d'un register, qui peut etre le resultat d'un calcul ou venir de memoire.  C'est tres flexible.  -ED


 
Merci pour les précisions :)
 

sireric a écrit :

En passant, la photos semble indiquer quelque chose sur ma joue.  J'espere que ce n'est pas vrai!


 
C'est le micro :D


Message édité par tridam le 19-06-2011 à 15:59:44
Reply

Marsh Posté le 20-06-2011 à 09:48:30   0  

Zack38 a écrit :

Pouicopouic, trolleur expert, en même temps :jap:  
 
Je croyais qu'il avait été ban à vie du forum, comment se fait-il qu'il soit encore ici ? :o


Les voies du trolleur sont impénétrables parait-il, ferme la porte ils reviennent par la fenêtre :) :lol:


---------------
L'innovation, c'est extra :)
Reply

Marsh Posté le 20-06-2011 à 19:25:05   0  

tridam a écrit :

J'utilise en général vec4/vec5 pour simplifier la description de l'architecture en reprenant le modèle qui en ressort du point de vue du programmeur. GeForce et futures Radeon : scalaire; Radeon : vec4/vec5. Ceci n'a strictement rien avoir avec le vocabulaire décidé par les équipes de com de Nvidia ou d'AMD.


Heu du point de vue programmeur t'es pas du tout obligé d'utiliser des float4 ou des int4, sur les deux architectures.
 
Par contre c'est conseillé (m'enfin pas par nvidia mouarfarf) pour les deux archis -> http://www.cs.berkeley.edu/~volkov/volkov10-GTC.pdf
 
Très très intéressant ce lien, mais je sais pas si c'est compréhensible quand on confond vectoriel et superscalaire vliw  :sarcastic:

Reply

Marsh Posté le 20-06-2011 à 21:01:38   1  

Je te rassure, je ne confonds rien du tout. Encore une fois, une description simplifiée liée au modèle qui ressort de l'architecture permet à un plus grand nombre de comprendre les évolutions alors que des tentatives de faire coller celles-ci avec une collection de qualificatifs préétablis d'implémentation hardware, en plus d'être discutables, limite la compréhension à une poignée de personnes.

Reply

Marsh Posté le 20-06-2011 à 21:25:26   0  


http://www.youtube.com/watch?v=Q-6fTaEyJz0
 
:)


---------------
該反思的是,往往有幫助
Reply

Marsh Posté le 21-06-2011 à 05:25:48   0  

tigredubois a écrit :

Très très intéressant ce lien, mais je sais pas si c'est compréhensible quand on confond vectoriel et superscalaire vliw  :sarcastic:


Tu veux appeler ça comment, sérieux?

 

"Processeur multi-cores vectoriel à exécution multi-thread simultanée"? :o

 

Sachant que chaque SIMD exécute les instructions de un ou plusieurs threads simultanément et que chaque CU peut être considéré comme un core, ça serait peut-être correct, va savoir, mais ça n'en reste pas moins avant tout une architecture orientée débit et ne nécessitant ni parallélisme de données (donc pas vectoriel) ni multiples threads (donc pas vraiment multi-cores).


Message édité par Gigathlon le 21-06-2011 à 05:28:27
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed