Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 12 sur 22 PremièrePremière ... 24567891011121314151617181920 ... DernièreDernière
Affichage des résultats 331 à 360 sur 658

Discussion: Archi GPU et GPGPU

  1. #331
    Il ne va pas falloir faire trop de calculs d'addresses donc, ou attendre qu'une version 64 bits du hw arrive (ont ils des instructions de propagation de la retenue ? Parce que sinon ca va pas etre drole le calcul d'addresse...)
    fefe - Dillon Y'Bon

  2. #332
    Citation Envoyé par Møgluglu Voir le message
    En CUDA, les pointeurs GPU sont de la même taille que les pointeurs CPU. Fermi supporte indifféremment des pointeurs de 32 et 64 bits, c'est un bit dans les instructions load et store qui dit la taille de l'adresse.
    Le hic, c'est qu'il n'y a plus de registre d'adresse dédiés et d'instructions de calcul d'adresse comme sur Tesla, et que les unités arithmétiques sont toujours 32-bit. Donc surcoût non négligeable en code, registres et temps sur x64...
    C'est pas un peu surprenant pour une architecture qui se veut plus orientée (HP)computing que celle à laquelle elle succède ?

  3. #333
    Citation Envoyé par fefe Voir le message
    Il ne va pas falloir faire trop de calculs d'addresses donc, ou attendre qu'une version 64 bits du hw arrive (ont ils des instructions de propagation de la retenue ? Parce que sinon ca va pas etre drole le calcul d'addresse...)
    Oui, il y a un flag carry, apparemment dissocié du système de prédicats.
    À mon avis la limitation viendra plus de la pression sur les registres, en occupation et en bande passante.

    Autant les adresses 64-bit se justifient pour la mémoire unifiée, je vois mal l'utilité pour la mémoire de constantes "1MB will be enough for everybody". Probablement juste une simplification dans le compilateur pour éviter les casts dans tous les sens.

    Après tout, ils ont tout le temps d'optimiser leur compilo. Avec le back-end Tesla, on avait encore parfois des +15% d'une version à l'autre jusqu'à récemment...

    Citation Envoyé par Alexko
    C'est pas un peu surprenant pour une architecture qui se veut plus orientée (HP)computing que celle à laquelle elle succède ?
    Les registres d'adresse, c'est un truc directement hérité des langages de shaders et des pipelines simples d'époque.
    Maintenant, utiliser des registres généraux et des unités classiques se justifie assez. Dédier du hardware pour, c'est en enlever autant au calcul... Et il faut aussi que le compilo soit capable de l'exploiter efficacement (c'était pas vraiment le cas avec Tesla).

    Par contraste l'archi d'AMD a des registres et du matos dédiés aux adresses, au compteurs de boucle...

  4. #334
    Citation Envoyé par Møgluglu Voir le message
    Les registres d'adresse, c'est un truc directement hérité des langages de shaders et des pipelines simples d'époque.
    Maintenant, utiliser des registres généraux et des unités classiques se justifie assez. Dédier du hardware pour, c'est en enlever autant au calcul... Et il faut aussi que le compilo soit capable de l'exploiter efficacement (c'était pas vraiment le cas avec Tesla).

    Par contraste l'archi d'AMD a des registres et du matos dédiés aux adresses, au compteurs de boucle...
    OK. Je disais ça parce qu'on trouve des AGU sur les CPU, ça me paraissait donc paradoxal que Fermi, qui tend à se rapprocher des CPU, prenne une direction opposée sur ce point. Mais quand on a plusieurs centaines d'unités de calcul, c'est vrai que ça se justifie plus facilement, en effet.

    Tout ce qui est HPC a tendance à se faire en 64 bits donc sur le coup ce surcoût m'a paru gênant, mais de toute façon le surcoût est le même sur tous les autres calculs donc ça ne change pas grand-chose.

  5. #335
    Je suppose que c'est pour des raisons de simplicite. Ils peuvent certainement tuner le compilo pour passer en 32 bits la ou ca a un impact sur la vitesse...
    fefe - Dillon Y'Bon

  6. #336
    Citation Envoyé par Møgluglu Voir le message
    que les unités arithmétiques sont toujours 32-bit.
    Mes propos n'engagent personne, même pas moi.

  7. #337
    Citation Envoyé par Neo_13 Voir le message
    Les unites arithmetiques de Willamette etaient 16 bits (ok double pumped...)
    fefe - Dillon Y'Bon

  8. #338
    On commence à s'interroger sur l'efficacité de Fermi (par ex sur HFR)...

    Un exemple sur le code de la boucle interne du produit de matrice (version pas trop optimisée) :

    Le code calcule un produit scalaire ligne x colonne dans un bloc en mémoire partagée. (somme de m[j,k] * m[k,i]).
    Avec Tesla :
    Code:
    mov.b32 a3, r10 << 2  # adresse colonne &m[0, i]
    mov.b32 a2, r3 << 6   # adresse ligne ~m
    ...
    mov.b32 r0, s[a3+0x0000]  # charger m[0, i]
    mad.rn.f32 r6, s[a2+0x0030], r0, r6  # s += m[j, 0]] * m[0, i] 
    
    mov.b32 r0, s[a3+0x0040]  # m[1, i]
    add.b32 a4, a3, 0x00000080
    mad.rn.f32 r6, s[a2+0x0034], r0, r6 # * m[j, 1]
    
    mov.b32 r0, s[a4+0x0000]
    mad.rn.f32 r6, s[a2+0x0038], r0, r6
    
    mov.b32 r0, s[a4+0x0040]
    add.b32 a4, a3, 0x00000100
    mad.rn.f32 r6, s[a2+0x003c], r0, r6
    
    mov.b32 r0, s[a4+0x0000]
    mad.rn.f32 r6, s[a2+0x0048], r0, r6
    
    mov.b32 r0, s[a4+0x0040]
    add.b32 a4, a3, 0x00000200
    mad.rn.f32 r6, s[a2+0x004c], r0, r6
    
    mov.b32 r0, s[a4+0x0000]
    mad.rn.f32 r6, s[a2+0x0050], r0, r6
    ...
    41 instructions pour 16 mads (32 flops)
    13 registres.

    On a des registres d'adresse dédiés, les mads peuvent prendre un opérande en mémoire partagée avec indirection et un petit offset immédiat. La taille limitée de l'immédiat oblige à intercaler un calcul d'adresse externe une fois sur 2 pour les colonnes.
    Si le compilo était intelligent il pourrait utiliser les post-incréments à la ARM ([a4+=0x40]).
    Si le programmeur était intelligent il pourrait garder la ligne dans les registres (c'est le cas dans les BLAS).

    Fermi :
    Code:
    mov.b32 r6, s[r8+0x0000]    # 1 float colonne : m[0,i]
    mov.b128 r3:r0, s[r10+0x0000]  # 4 floats ligne : m[j, 0..3]
    
    mov.b32 r5, s[r8+0x0040]   # m[1,i]
    fma.rn.ftz.f32 r0, r0, r6, r4
    
    mov.b32 r4, s[r8+0x0080]   # m[2,i]
    fma.rn.ftz.f32 r1, r1, r5, r0
    
    mov.b32 r0, s[r8+0x00c0]
    fma.rn.ftz.f32 r2, r2, r4, r1
    
    mov.b32 r1, s[r8+0x0100]
    mov.b128 r7:r4, s[r10+0x0010]
    fma.rn.ftz.f32 r2, r3, r0, r2
    
    mov.b32 r0, s[r8+0x0140]
    fma.rn.ftz.f32 r2, r4, r1, r2
    
    mov.b32 r1, s[r8+0x0180]
    mov.b32 r4, s[r8+0x01c0]
    fma.rn.ftz.f32 r0, r5, r0, r2
    
    mov.b32 r5, s[r8+0x0200]
    fma.rn.ftz.f32 r6, r6, r1, r0
    
    ...
    36 instructions pour les mêmes 32 flops.
    28 registres en 64-bit, 20 en 32-bit.

    On n'a plus les opérandes en mémoire partagée, mais le compilo charge les éléments de la ligne 4 par 4 (reste à connaitre le débit de la mémoire shared/cache). Le programmeur a donc moins besoin d'être intelligent sur le coup.
    Par contre il ne me parait pas possible de descendre à moins de 32 instructions par itération, soit 50% des flops crête. Sur Tesla on monte à 66% (des flops MAD).

    Notons au passage l'espace mémoire unifié avec des instructions différentes pour accéder à chaque bout de l'espace unifié.

    Edit: le code Fermi est aussi bien mieux schedulé pour exploiter de l'ILP sur une archi in-order. Au prix d'une empreinte sur les registres doublée...
    Dernière modification par Møgluglu ; 17/11/2009 à 18h35.

  9. #339
    Vu comment tu as tabule le code je suppose que tu pars du principe que tu peux executer un load et un fma en parallele, mais je suppose que tu ne peux pas faire un mad avec une source en memoire et un add sur tesla ?
    fefe - Dillon Y'Bon

  10. #340
    Citation Envoyé par fefe Voir le message
    Vu comment tu as tabule le code je suppose que tu pars du principe que tu peux executer un load et un fma en parallele, mais je suppose que tu ne peux pas faire un mad avec une source en memoire et un add sur tesla ?
    Non, c'est purement esthétique (pour mettre l'accent sur l'overhead associé à chaque MAD/FMA). Les instructions qui sont exécutés en parallèle appartiennent à des threads différents, donc on ne peut pas vraiment les faire apparaître dans le code et ça dépendra du scheduling.

    Sur Tesla on peut envoyer les MOV sur le deuxième pipe (interp/SFU/MUL), mais c'est à peu près tout, et la bande passante de la mémoire shared va limiter.
    Sur Fermi on peut a priori dual-issuer n'importe quoi de threads différents.

    Le scheduling du code Fermi laisse quand-même penser qu'il y a une dose raisonnable d'ILP qui est utilisée, alors que le code Tesla a essentiellement un ILP de 1 sur du in-order sans renommage, et se repose exclusivement sur le parallélisme de données/threads.

    Avec 1024 registres vectoriels/SM sur Fermi, divisés par 28/warp, on a maxi 36 warps. À l'IPC crête de 1, on peut masquer 36 cycles de pipeline sans toucher au parallélisme d'instruction.

    Par comparaison sur GT200, 512 regs/13, on atteint la limite de 32 warps. Avec l'IPC crête de 0.5, on peut absorber 64 cycles.

    Le pipeline du GT200 fait de l'ordre de 30 cycles, dont 24 entre lecture des opérandes et writeback.
    Dans cet exemple jouet sur Tesla il y a de la marge, sur Fermi moins...
    Dernière modification par Møgluglu ; 17/11/2009 à 21h35. Motif: Cinquième version des calculs et de la conclusion...

  11. #341
    Ca ne va pas être du même niveau que la diatribe de Møgluglu, néanmoins on semble atteindre des limites de cohérence de plateforme avec les dernières 5970. Arriver à saturer les processeurs avec autant de puissance, et saturer les ponts PLX d'interco, ca commence à devenir violent.

    Conséquence, je me demande si queque soit les perfs brutes de Fermi, en dehors du HPC qui sera plus "local" et moins dépendant du CPU, les perfs hybrides (comprendre raster) seront directement limitées par: Les perfs CPU, l'efficacité du compilo de shaders onthefly du driver.

    Qu'on ait 4.5TFlops ou 3TFlops, j'ai bien peur que ca donne quelque chose de très similaire.

    Pour ce qui est du HPC, je mets quelques billes encore sur nV qui semble avoir de l'avance sur l'efficacité de leur compilateur CUDA par rapport à Steam/OpenCL/ComputeShaders coté ATI. Le CTM d'ATI serait sans doute le plus efficace mais j'ai l'air de comprendre que c'est aussi simple que de parler klingon ou esperanto

  12. #342
    Le site Bright side of News relaie une rumeur du twitter de Nvidia ,avec les specs des gtx360 et gtx380 (à confirmer bien sûr ,rumeur quand tu nous tiens ).
    On a droit à une autre rumeur (fin de la news) qu'Amd préparerait ,pour la sortie de Fermi ,une radeon "5890" (vu la capacité des 5870 à monter en fréquence ,ça ne devrait pas poser problème, à part le soucis de production...) .

    Et PCWorld annonce ,pour le soucis de display port pour profiter de l'Eyefinity ,un convertisseur actif DP vers DVI (sorti au Japon) alimenté par USB et disponible la-bas pour environ 165€ (pour le jeu c'est plus un gadget qu'autre chose ,mais pour certaine application ça peut devenir rentable de pouvoir prendre des écrans plus "classique" avec cet adaptateur...).

  13. #343
    BS News, comme d'habitude, BS... Par contre pour la 5890 c'est assez évident qu'AMD prépare quelque chose dans le genre.

  14. #344
    Citation Envoyé par Lionel33 Voir le message
    Le site Bright side of News relaie une rumeur du twitter de Nvidia ,avec les specs des gtx360 et gtx380 (à confirmer bien sûr ,rumeur quand tu nous tiens ).
    On a droit à une autre rumeur (fin de la news) qu'Amd préparerait ,pour la sortie de Fermi ,une radeon "5890" (vu la capacité des 5870 à monter en fréquence ,ça ne devrait pas poser problème, à part le soucis de production...) .

    Et PCWorld annonce ,pour le soucis de display port pour profiter de l'Eyefinity ,un convertisseur actif DP vers DVI (sorti au Japon) alimenté par USB et disponible la-bas pour environ 165€ (pour le jeu c'est plus un gadget qu'autre chose ,mais pour certaine application ça peut devenir rentable de pouvoir prendre des écrans plus "classique" avec cet adaptateur...).
    Et on se plaint d'Apple qui vend ça 100 €

    Plus sérieusement, les adaptateurs actifs pour du DP (enfin, miniDP dans mon cas) que j'ai testé, c'est moisi : le VGA, il déconne de temps en temps avec certrains écrans, le DualLink, il marche mal et monopolise un USB. Y a que le passif, vers DVI SingleLink, qui m'a pas encore posé de problèmes.

  15. #345
    Citation Envoyé par dandu Voir le message
    Y a que le passif, vers DVI SingleLink, qui m'a pas encore posé de problèmes.
    Encore heureux, pour un câble avec 3 fils et 2 résistances dedans.

    Le DisplayPort, c'était pas censé faire baisser le prix des écrans en éliminant un paquet d'électronique et les royalties associées au DVI, au départ?

  16. #346
    Le jeu d'instruction d'Evergreen documenté :
    http://developer.amd.com/gpu/ATIStre..._Microcode.pdf

    Par reverse-engineering de leurs instructions, voici la gueule que doit avoir leur FPU :


    J'ai pas mis les unités d'arrondi, mais il y en a une derrière chaque additionneur et une optionelle derrière chaque multiplieur. Chaque fil normal est un flottant simple-précision, les fils épais sont des résultats exacts (~double précision).
    J'ai pas mis les crossbars des shuffles en haut non plus.

    La configuration de la FPU pour faire 1 FMA ou 2 ADD en double précision est laissée en exercice...

    J'ose pas imaginer la latence de ce machin.

    Edit: il va de soit que cette unité fait aussi les comparaisons, les min-max, le calcul entier, logique, les décalages, les conversions, le comptage de bits, les insertions et extractions de bits et d'octets, le café, et gère les 4 modes d'arrondi IEEE et les dénormaux.
    Dernière modification par Møgluglu ; 22/12/2009 à 18h51.

  17. #347
    C'est possible de faire tourner ca a 3+ GHz en 12 clocks sans trop de difficultes
    -1 cycle de frontend
    -3 cycles de mul
    -1 cycle pour l'add dont les sources sont pretes
    -3* 2 cycles pour les autres adds (preparations des operandes1 + add 1)
    -1 cycle de rounding et normalization

    Donc a 1GHz, meme en gardant de tout petits devices ca ne doit pas prendre tant que ca . Rien de catastrophique pour une machine aps orientee latence...
    fefe - Dillon Y'Bon

  18. #348
    Pas convaincu...

    En virgule fixe en gardant les données en carry-save tout le long, je veux bien, mais ici le chemin critique passe en tout par 2 mul, 2 add, 4 arrondis et normalisations avec codage/décodage des dénormaux et une ribambelle de mux (bien plus que ce que j'ai dessiné...)

    Rien là-dedans ne semble pouvoir être fusionné (arrondi intermédiaire IEEE à chaque fois)...

    Leur concurrent est à environ 10 cycles à 1,5 GHz pour une unité mul+add avec un seul arrondi simplifié sans gestion des dénormaux. Sur de la logique custom, alors qu'il me semble que les datapaths d'ATI sont synthétisés?

  19. #349
    Je ne comptais qu'un seul etage d'arrondi et normalization a la fin, ca t'ajoute 3 cycles si il faut faire des intermediaires. Tes mux ne devraient pas etre visibles si ce sont des 2->1 ou 3->1 si comme dessines ici.

    La difference fondamentale dans la latence vient du choix de la taille de tes devices plus que de ta synthese ou ton design custom (il y a tres peu de difference aujourd'hui entre une bonne synthese et un design custom aux frequences auquelles operent les GPUs).
    Si tu es pret a consommer de l'energie tu fais un mul-add en 6 clocks a 3GHz en 45nm. Si comme ici tu cherches a optimiser l'energie/operation tu fais un circuit 3 ou 4x plus lent. C'etait l'essentiel de ce que je voulais dire, tu peux faire ce type d'operations a faible latence si tu utilises des gros devices, et tu peux grapiller les derniers ps en faisant de la logique dynamique. La raison pour laquelle la latence des GPUs est elevee n'est pas vraiment la complexite des operations, mais le fait qu'il faut les faire pour un minimum d'energie.
    fefe - Dillon Y'Bon

  20. #350
    Citation Envoyé par fefe Voir le message
    (il y a tres peu de difference aujourd'hui entre une bonne synthese et un design custom aux frequences auquelles operent les GPUs)
    Allez hop je me tape un hors-sujet magistral
    Qu'est-ce que tu appelles "une bonne synthèse" ? Parce que les dc and co, même à "basse fréquence" ce n'est pas la joie...

    Et pour recoller juste un peu au sujet : http://www.semiaccurate.com/2009/12/...-fermi-448sps/
    Franchement Charlie me gave de plus en plus. La belle affaire, on baisse de 12% le nombre d'unités pour augmenter le yield.

  21. #351
    Citation Envoyé par fefe Voir le message
    La raison pour laquelle la latence des GPUs est elevee n'est pas vraiment la complexite des operations, mais le fait qu'il faut les faire pour un minimum d'energie.
    OK, merci pour l'explication.

    Reste que l'archi a aussi son rôle à jouer, genre j'ai du mal à imaginer ce genre d'unités dans un CPU conventionnel... (et vice-versa)

    Pour revenir au RV800, le passage à un VLIW "vertical" est quand-même une petite révolution (ouais, on va encore me sortir une archi de DSP exotique d'il y a 20 ans pour me dire qu'ils ont rien inventé... D'ailleurs même dans les GPU le NV40 n'est pas loin...)

    C'est un peu une généralisation des instructions composites genre mul+add. Avec en plus le droit à des négation et des valeurs absolues gratuites un peu partout. On peut construire notamment :
    - a * b + c * d + e * f + g * h (DOT4)
    - a * b + c * d deux fois (2xDOT2 ou interp)
    - a * b + c quatre fois (4xMAD)
    - a * b * c + d deux fois (MMAD!)
    - a * b * c + d * e * f
    - a + b + c + d (HADD)
    - max(a, b, c, d)
    - |a - b| + |c - d|
    - ...

    Le tout avec un débit de 1. Par rapport à un VLIW "horizontal", on doit économiser des ports dans le banc de registres et/ou du réseau de bypass...

    C'est les compileux qui doivent s'amuser pour scheduler tout ça, ça les change des VLIW traditionnels trop faciles.
    Dernière modification par Møgluglu ; 22/12/2009 à 21h45.

  22. #352
    Une bonne synthese= tu parts avec une bibliotheque de blocs tres tunes. La derniere fois que j'ai fait la comparaison sur quelques blocs prevus pour tourner a basse frequence (dans les 1GHz) une synthese basee sur une bibliotheque qui avait ete optimisee par des specialistes etait plus rapide, consommait moins de surface et de power, pour 2 fois moins de temps de design qu'un circuit custom. Bien entendu le designer en question n'etait pas aussi bon que les specialistes ayant bosse sur la bibliotheque (mais c'est toujours le cas). La synthese avait ete faite par des designers aux competences comparables. Un design custom fait par un de ces specialistes aurait probablement ete un peu meilleur que la synthese, mais en pratique tu as une armee de designer competents et 1 ou 2 types tres forts...

    Qu'est ce qu'une bibliotheque "optimisee" ? C'est une bibliotheque avec plus de blocs de base qui ont ete adaptes pour les conditions specifiques de leur future utilisation. Ici je suis certain que leur bibliotheque contient beaucoup de circuits destines uniquement a rentrer dans certains etages de leurs operateurs flottants.

    Au final ca ressemble un peu a du design custom je sais, mais les outils de synthese ne supportent que la logique statique, alors qu'avec un design custom tu peux mettre tous les dominos et autres circuits dynamiques que tu veux.

    ---------- Post ajouté à 22h49 ----------

    Citation Envoyé par Møgluglu Voir le message
    OK, merci pour l'explication.

    Reste que l'archi a aussi son rôle à jouer, genre j'ai du mal à imaginer ce genre d'unités dans un CPU conventionnel... (et vice-versa)

    Pour revenir au RV800, le passage à un VLIW "vertical" est quand-même une petite révolution (ouais, on va encore me sortir une archi de DSP exotique d'il y a 20 ans pour me dire qu'ils ont rien inventé... D'ailleurs même dans les GPU le NV40 n'est pas loin...)

    C'est un peu une généralisation des instructions composites genre mul+add. Avec en plus le droit à des négation et des valeurs absolues gratuites un peu partout. On peut construire notamment :
    - a * b + c * d + e * f + g * h (DOT4)
    - a * b + c * d deux fois (2xDOT2 ou interp)
    - a * b + c quatre fois (4xMAD)
    - a * b * c + d deux fois (MMAD!)
    - a * b * c + d * e * f
    - a + b + c + d (HADD)
    - max(a, b, c, d)
    - |a - b| + |c - d|
    - ...

    Le tout avec un débit de 1. Par rapport à un VLIW "horizontal", on doit économiser des ports dans le banc de registres et/ou du réseau de bypass...

    C'est les compileux qui doivent s'amuser pour scheduler tout ça, ça les change des VLIW traditionnels trop faciles.
    Oui, travailler sur des chaines d'operations est assez a la mode depuis quelques annees mais c'est la premiere archi que je vois implementer ca vraiment (et non je ne comparerai pas a des machines systoliques des annees 80 c'est assez different). Je crois meme me souvenir que certaines personnes a P.XI. bossaient sur la compilation et le hard pour ce type de series d'instructions...

    ---------- Post ajouté à 22h50 ----------

    Citation Envoyé par newbie06 Voir le message
    Et pour recoller juste un peu au sujet : http://www.semiaccurate.com/2009/12/...-fermi-448sps/
    Franchement Charlie me gave de plus en plus. La belle affaire, on baisse de 12% le nombre d'unités pour augmenter le yield.
    Surtout que ce n'est pas comme si c'etait la premiere fois dans le monde des GPUs... Ils font ca depuis bien longtemps, c'est intelligent, raisonable, etc... Et quand le process et les yields montent, tu sors une version avec un peu plus d'actives...
    fefe - Dillon Y'Bon

  23. #353
    Citation Envoyé par Møgluglu Voir le message
    Reste que l'archi a aussi son rôle à jouer, genre j'ai du mal à imaginer ce genre d'unités dans un CPU conventionnel... (et vice-versa)

    Les CPUs conventionnels commencent a exploser au dela de 3 sources et une destination (certains diront meme que ca commence deja avec la 3 eme source). Dans un superscalaire, le nombre de ports de lecture necessaires dans des structures a faible latence est effectivement le nombre d'operations que tu peux faire en parallele multiplie par le nombre d'operandes. Il y a beaucoup de machines avec 4 a 6 ports d'execution, et meme si ils n'ont pas tous jusqu'a 3 operandes on se rend vite compte qu'acceder en 1 cycle a un registre avec plus de 12 ports de lecture devient une catastrophe (c'est d'ailleurs l'armutentation de ceux qui proposent des machine clusterisees ).

    Par contre, le controle pour gerer toutes ces operations, meme si ca semble gros, reste limite par rapport a ce qui est necessaire sur une unite entiere sensee supporter toutes les generations de code x86 existant .
    fefe - Dillon Y'Bon

  24. #354
    Citation Envoyé par newbie06 Voir le message
    Et pour recoller juste un peu au sujet : http://www.semiaccurate.com/2009/12/...-fermi-448sps/
    Franchement Charlie me gave de plus en plus. La belle affaire, on baisse de 12% le nombre d'unités pour augmenter le yield.
    Charlie est alarmiste mais en même temps, devoir désactiver 2 clusters d'ALU pour des raisons de yields sur des cartes à 2500-4000$, c'est légèrement inquiétant...

  25. #355
    Citation Envoyé par Alexko Voir le message
    Charlie est alarmiste mais en même temps, devoir désactiver 2 clusters d'ALU pour des raisons de yields sur des cartes à 2500-4000$, c'est légèrement inquiétant...
    Je suis persuade qu'il n'y a rien de nouveau la-dedans. Et comment en attribuer la faute a nVidia, alors qu'on sait que TSMC a (ou a eu ?) de gros problemes avec le 40nm ?

  26. #356
    Citation Envoyé par newbie06 Voir le message
    Je suis persuade qu'il n'y a rien de nouveau la-dedans. Et comment en attribuer la faute a nVidia, alors qu'on sait que TSMC a (ou a eu ?) de gros problemes avec le 40nm ?
    Comment ça, rien de nouveau ? Sur les modèles Tesla actuels les 240 SP sont activés, et ce depuis le lancement (à ma connaissance, du moins).

    Quant à savoir si c'est la faute de TSMC, Nvidia, ou les deux, c'est une autre histoire...

  27. #357
    Citation Envoyé par fefe Voir le message
    Oui, travailler sur des chaines d'operations est assez a la mode depuis quelques annees mais c'est la premiere archi que je vois implementer ca vraiment
    Et après on dit que les GPU ne font que se rapprocher de plus en plus des CPU, qu'AMD se contente d'augmenter le nombre d'unités de calculs dans ses GPUs, tandis que NVidia se lance dans plein de changements qui n'apportent rien pour le rendu graphique.

    Citation Envoyé par fefe Voir le message
    Par contre, le controle pour gerer toutes ces operations, meme si ca semble gros, reste limite par rapport a ce qui est necessaire sur une unite entiere sensee supporter toutes les generations de code x86 existant .
    ... D'où le choix d'implémenter le "legacy" en microcode sur Atom.
    Mais vu le coût d'une ALU par rapport à tout ce qui est autour, ce n'est pas plus simple de séparer en plusieurs unités plus ou moins spécialisées plutôt que de faire des unités multi-fonctions? Ou bien le coût en latence de dupliquer les opérandes d'entrées et muxer les sorties est significatif?

    Aussi, pour la surface, il vaut mieux une seule unité multi-fonction comme sur un GPU. Pour la latence il vaut mieux spécialiser. Mais quid de la conso?
    Avec une unité plus petite je consomme moins en statique et dynamique, mais avec plusieurs unités je peux faire du clock-gating à grain moyen plus efficace...

  28. #358
    Citation Envoyé par Alexko Voir le message
    Comment ça, rien de nouveau ? Sur les modèles Tesla actuels les 240 SP sont activés, et ce depuis le lancement (à ma connaissance, du moins).
    Et ils sont faits sur un process eprouve et apres plusieurs revisions du chip non ?
    Mais je ne faisais pas forcement reference a nVidia. Le Cell a connu le meme genre de problemes au debut, avec 1 SPU desactive par exemple.

    Quant à savoir si c'est la faute de TSMC, Nvidia, ou les deux, c'est une autre histoire...
    Les deux evidemment : nVidia pour avoir voulu un truc enorme, TMSC pour manque de maitrise du process

    ---------- Post ajouté à 16h05 ----------

    Citation Envoyé par Møgluglu Voir le message
    Aussi, pour la surface, il vaut mieux une seule unité multi-fonction comme sur un GPU. Pour la latence il vaut mieux spécialiser. Mais quid de la conso?
    Avec une unité plus petite je consomme moins en statique et dynamique, mais avec plusieurs unités je peux faire du clock-gating à grain moyen plus efficace...
    Le clock gating ne va pas empecher le leakage, il faudrait faire du power gating, c'est plus dur

    Enfin c'est ma comprehension, j'y connais rien en implementation.

  29. #359
    Citation Envoyé par newbie06 Voir le message
    Et ils sont faits sur un process eprouve et apres plusieurs revisions du chip non ?
    Mais je ne faisais pas forcement reference a nVidia. Le Cell a connu le meme genre de problemes au debut, avec 1 SPU desactive par exemple.


    Les deux evidemment : nVidia pour avoir voulu un truc enorme, TMSC pour manque de maitrise du process

    ---------- Post ajouté à 16h05 ----------


    Le clock gating ne va pas empecher le leakage, il faudrait faire du power gating, c'est plus dur

    Enfin c'est ma comprehension, j'y connais rien en implementation.
    Hum le GT200 faisait 576 mm² sur un process éprouvé, le 65 nm de TSMC, et le GT200b faisait quelque chose comme 480 mm² sur le 55 nm de TSMC, qui était également assez éprouvé à ce moment-là. Cela dit, les 240 SP étaient activés dès le début. Au passage, les cartes Tesla dont il est question ici sont prévues pour Q2'2010, donc ça sera sûrement la révision A3 si ce n'est B1.

    Pour le Cell y'avait bien un SPU désactivé sur la PS3, produit grand public s'il en est, mais pas sur les serveurs/super-calculateurs et compagnie, c'est-à-dire le marché visé par Tesla.

    Ah et on a la même compréhension du leakage sans power gating

  30. #360
    Citation Envoyé par newbie06 Voir le message
    Le clock gating ne va pas empecher le leakage, il faudrait faire du power gating, c'est plus dur

    Enfin c'est ma comprehension, j'y connais rien en implementation.

    Oui, le clock gating reduit de maniere significative le power dynamique quand le circuit n'est pas utilise. Le cout est faible et ca peut s'implementer a une granularite assez fine.

    Le power gating addresse les courants de fuite (leakage), mais a pour l'instant des latences qui se comptent en microsecondes, et la taille d'une power gate est tellement importante que cela ne peut se faire qu'a une granularite elevee. Qui plus est le fait d'etre derriere une power gate requiert en general un peu plus de voltage et fait que le bloc en question consommera un peu plus quand allume (la power gate fuit en quelque sorte). Bref aujourd'hui quand on reflechit a mettre des power gate la question est plutot: je power gate les cores 1 par 1 ou 2 par 2. Est ce que je power gate tout le PCIe, tout le cache ?
    Dans un futur plus ou moins proche les technos permettant de power gate un cluster (au lieu d'un core) vont arriver, avec des latences beaucoup plus raisonables, permettant de controler la power grid a un grain beaucoup plus fin que ce qui existe aujourd'hui.

    Pour en revenir aux ALU de x86, le probleme est toute la gestion a la con des flags et les versions 8,16,32,64 bit du jeu d'instruction. Je te rappelle que si tu fais une operation 16 bits sur un registre de 64 bits plein, c'est sense fonctionner (et donner le bon resultat qui part du principe que tu operes sur une partie du registre). Les dependances partielles et les nombreuses sources (chaque flag est effectivement une source, compte les et rigole ) te forcent effectivement a tout faire dans la meme unite. Le P4 avait essaye une approche differente ou seul un mode (le plus courant) etait vraiment supporte dans les ALU rapides, et des que tu sortais de ce type d'operation/dependance, tu devais merger le resultat d'une unite lente et complexe qui maitrisait tous les details de legacy... Le resultat est que ca arrivait tellement souvent que certains vieux code entier ramaient terriblement (bien entendu ce n'etait que la moitie des raisons, l'autre etait la speculation d'addresse ou autre et le replay). Au final tu n'as pas vraiment le choix et es oblige de faire une ALU d'une complexite phenomenale (mais tu ne vas pas la changer d'une generation a l'autre ).
    fefe - Dillon Y'Bon

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •