Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 19 sur 22 PremièrePremière ... 9111213141516171819202122 DernièreDernière
Affichage des résultats 541 à 570 sur 658

Discussion: Archi GPU et GPGPU

  1. #541
    De la bouche de Moore.
    En bref : le nombre de transistors double tous les 24 mois. Et un autre gars a dit la performance double tous les 18 mois.

  2. #542
    Ça permet déjà de normaliser grossièrement par rapport au nombre de transistors disponibles pour un prix donné, et de voir que le nombre d'unités de calcul SP augmente plus vite que le nombre de transistors disponibles.

    Je verrais au moins 3 facteurs:
    - La surface des dies GPU haut de gamme a augmenté (de +50% à +100%).
    - L'accent est davantage mis sur les unités de calcul généralistes qu'avant. Des opérateurs dédiés ont été supprimés pour être remplacés par plus d'unités FP (les mini-ALU chez Nvidia, l'interpolateur d'attributs chez AMD). La puissance de calcul FP a augmenté plus vite que le texturing rate ou le fillrate, donc l'équilibre entre les types d'unités a changé.
    - Les architectes ont bien travaillé, et les GPU sont plus efficaces qu'avant. Mais ce dernier point est très contestable et difficile à quantifier...

  3. #543
    Citation Envoyé par newbie06 Voir le message
    Tendance : ATI rattrape nVidia et va se heurter aux memes problemes (ils pourront toujours dire que c'est la faute de GloFo si ca marche pas ).
    Goto dispose peut-être d'informations que je n'ai pas à propos de GCN, mais s'il ne base son estimation de la taille du die que sur l'extrapolation de la tendance observée, il néglige un point très important : Cayman, le plus gros GPU actuel d'AMD, était à la base un design 32 nm, porté « lock, stock and barrel » vers le 40 nm de TSMC quand celui-ci a annulé son process 32 nm. Donc Cayman était prévu pour faire quelque chose comme 270 mm² (236 avec un scaling parfait) pas 369. En tout cas, plus petit que Cypress (334 mm²) et finalement assez proche de RV770 (256 mm²).

    Notez au passage que quand AMD a remarqué des problèmes de vias sur le process de TSMC, elles ont toutes été doublées pour Cypress. Je ne sais pas exactement quel peut être l'impact d'un tel niveau de redondance sur la surface, mais ça a dû jouer.
    Mon blog (absolument pas à jour) : Teχlog

  4. #544
    Il y en a ici qui travaillent avec CUDA ?
    J'envisage d'y passer, vu que je commence à en avoir marre du GLSL, et je souhaiterais savoir combien de temps ça vous a pris pour vous faire la main dessus.
    ⚜ Une foi, une loi, un roi.
    Senscritique

  5. #545
    Oui, on trouve des gens qui bossent avec CUDA par ici...

    Moi ça m'a pris 4 ans et j'en suis pas sorti.

    Sérieusement, si tu connais le C et même GLSL, tu devrais pouvoir t'y mettre très vite sans problème.

    Je suis toujours impressionné par la quantité de non-informaticiens (genre physiciens, chimistes, biologistes...) qui se mettent à CUDA... et y arrivent. Leurs principales difficultés, c'est des choses comme les subtilités du C, l'arithmétique flottante ou même la compilation. Mais avec le parallélisme, là, aucun souci.

    Donc je t'encourage à installer le CUDA Toolkit et les exemples du SDK, et attaquer les premiers exemples de la doc. Malgré les vrais bouts de propagande qu'il contient, le Programming Guide de CUDA est plutôt bien fichu, surtout les dernières versions.

  6. #546
    D'ailleurs avec ces outils, on peut aussi bien faire du CUDA que de l'OpenCL et du DirectCompute ou alors c'est très orienté vers leur API maison ?

    edit: c'est moi où nVidia utilise le terme "CUDA" à toutes les sauces

  7. #547
    Citation Envoyé par Foudge Voir le message
    D'ailleurs avec ces outils, on peut aussi bien faire du CUDA que de l'OpenCL et du DirectCompute ou alors c'est très orienté vers leur API maison ?
    Le Toolkit contient le compilo et les bibliothèques pour CUDA C for CUDA.

    Il y a aussi les en-têtes OpenCL avec, mais tu peux aussi bien les récupérer chez Khronos, ou utiliser le toolkit d'AMD ou de n'importe qui : OpenCL c'est juste une bibliothèque C, et le principe c'est que c'est portable.

    Pour DirectCompute, ça vient avec DirectX, mais je ne touche pas à ces choses-là.

    edit: c'est moi où nVidia utilise le terme "CUDA" à toutes les sauces
    Nvidia + Calcul généraliste = CUDA. Il y a les architectures CUDA, le C pour CUDA, le C++ pour CUDA, le Fortran pour CUDA, OpenCL pour CUDA, les BLAS pour CUDA, le clone de FFTW pour CUDA, le clone d'IPP pour CUDA, etc.


    ... pardon, j'avais oublié Java et Python pour CUDA.

  8. #548
    Et les CUDA Cores, n'oublie pas les CUDA Cores ! :D
    Mon blog (absolument pas à jour) : Teχlog

  9. #549
    CUDA Everywhere!


    (Je n'invente rien, c'est dans une présentation officielle de notre commercial à nous
    Spoiler Alert!
    avec aussi des vrais morceaux de Theo Valich qui cite PC Impact
    .)

  10. #550
    Je vois 2 courbes qui suivent la loi de Moore depuis 2007 -2008 . C'est evident que si tu choisis bien le point ou ton archi etait la moins efficace pour faire une courbe de CAGR tu vas avoir de beaux resultats.
    Aujourd'hui il y a quelques points a regarder:
    -les multipliers/adder embarques dans les GPUs sont extremement efficaces en area/perf/power et il reste tres peu a ameliorer d'un point de vue hard => leurs ameliorations suivront quasiment parfaitement le process de ce point de vue la (donc ce que Moore projetait a moins que les fabs trouvent un moyen d'acelerer, alors qu'elles ont plutot tendance a ralentir).
    -l'ajout de hardware dedie a des taches specifiques plutot que l'utilisation de hardware generique permet toujours d'aller plus vite que la loi de Moore, a chaque fois qu'une nouvelle fonctionallite cablee est ajoutee le processeur en question depasse la courbe de la loi de Moore (dessiner un graph des perfs de CPUs intel avant et apres AES-NI pour s'en convaincre). A chaque fois que les GPUs font quelque chose de "nouveau" accelere par du hard (je me trompe probablement dans mon exemple mais un truc comme la tessellation pourrait faire l'affaire), ils vont naturellement depasser la loi de Moore. Le rythme auquel ils ajoutent du hard dedie est en reduction significative, et donc la vitesse de croissance reduit (et ca se voit sur les graphes de perf des GPUs, surtout si tu commences en 1995).
    -l'efficacite a laquelle ce hard est utilise lui a encore de la marge pour evoluer, c'est la source potentielle d'ameliorations plus rapides que la loi de Moore. Sauf que il y a un moment ou les ameliorations d'archi/software deviennent de plus en plus difficiles et il y a un point ou elles sont egales aux effets de la loi d'Amdahl et ou tu cesses de gagner en efficacite. Il est difficile de juger si c'est le cas aujourd'hui, mais encore une fois il y a un ralentissement certain de la croissance des perfs des GPUs.

    Donc, bien sur que les GPUs ont eu une croissance plus rapide que la loi de Moore, par definition ca arrive toujours quand tu ajoutes du hard dedie a des taches specifiques, et est en phase d'amelioration de ton archi. La loi de Moore n'est meme pas vraiment une conjecture, c'est juste la vitesse a laquelle le leader de l'industrie a decide de progresser pour les 20 dernieres annees. Il est donc normal que quiconque essaye de le doubler doit depasser cette vitesse . Ca n'a rien d'une loi physique qui n'est pas depassable .
    En revanche, ca ralentit la .
    fefe - Dillon Y'Bon

  11. #551
    Oui, en fait c'est surtout que le nombre d'unités FP n'est pas une métrique représentative, surtout par rapport aux GPU de 2004...

    D'ailleurs, depuis 2004, les unités arithmétiques ont certainement perdu en perf/surface. Sur le NV40 et le R500, ils tronquaient les poids faibles des produits partiels du multiplieur comme des sagouins. Maintenant on a des FMA full-IEEE-754, des multiplieurs entiers 32x32… Faire les choses bien ça a un coût.

    Entre 2004 et 2007, j'ai l'impression que la quantité d'unités dédiées a plutôt baissé, et je suppose que c'est ce qui explique en grande partie l'augmentation supramooresque du nombre d'unités FP pendant cette période. Si on faisait le graphe avec les perfs réelles, je soupçonne qu'on aurait une évolution bien plus raisonnable...
    (Ça va, j'ai pris assez de précautions oratoires? )

    Pour le reste, tes explications sont convaincantes.

  12. #552
    Oui d'un cote les unites FP se sont alourdies de precision et de modes d'arrondis plus avances, mais j'ai l'impression qu'ils ont compense ca en passant a des methodes de design plus optimisees. En pratique, la surface des unites FP est mesurable sur diverses photos de dies et il est possible d'en extraire a process constant (les ratios de surface entre noeuds de process et sur de la logique tournent generalement tres pres de 0.56 donc ca peut servir de base) les ratios de surface par unite FP.
    Bien entendu vu que les archis ont change et le bloc de base replique a change ce n'est pas si simple que ca, mais quand j'avais regarde ca il y a 2-3 ans j'avais vu que la densite avait augmente chez ATI malgre le passage a une plus grande precision et le support de IEEE-754.

    Apres, l'augmentation de la bande passante en DP, l'agrandissement des bancs de registres partages et autres fonctions destinees a ameliorer le throughput computing ont eu un effet assez negatif sur la densite chez Nvidia. D'ailleurs je suis sur que si tu regardes la perf en DP au lieu de la perf en SP la tendance recente est largement superieure a la loi de Moore .

    Au final il y a une seule chose dont je suis sur, c'est qu'a taille d'equipe de dev constante on ne peut pas maintenir une vitesse de croissance de la perf superieure a la loi de Moore pendant tres longtemps (surtout si on mesure la perf sur un large eventail d'applis). La complexite des mechanismes necessaires a ameliorer la perf plus que ce que ne donne le process ne cesse d'augmenter et le resultat final est que la vitesse d'augmentation des perfs ne cesse de decroitre une fois que les grosses "decouvertes" ont ete faites (si on dessine la perf d'un seul cpu iso process, ca se voit).
    fefe - Dillon Y'Bon

  13. #553
    Citation Envoyé par Møgluglu Voir le message
    Entre 2004 et 2007, j'ai l'impression que la quantité d'unités dédiées a plutôt baissé, et je suppose que c'est ce qui explique en grande partie l'augmentation supramooresque du nombre d'unités FP pendant cette période. Si on faisait le graphe avec les perfs réelles, je soupçonne qu'on aurait une évolution bien plus raisonnable...
    Je ne sais pas, on a perdu l'interpolateur, mais quoi d'autre ? Dans le même temps on a gagné le hardware dédié à la tessellation, des petits bouts pour la vidéo, et les unités dédiées existantes (e.g. TMU & ROP) gagnent régulièrement en qualité et fonctionnalités. Par exemple les TMU deviennent progressivement capables de traiter plus de formats, le filtrage est indépendant de l'angle (chez AMD), etc.

    Cela étant, il me semble bien que le ratio (unités_généralistes/fixed_function) a tendance à augmenter, ce qui implique que les unités généralistes ont droit à une plus grosse part de la taille du die, taille qui a elle-même tendance à augmenter.

    Donc j'expliquerais l'augmentation « supramooresque » — pas mal comme mot ! — de cette façon.

    Citation Envoyé par fefe Voir le message
    Oui d'un cote les unites FP se sont alourdies de precision et de modes d'arrondis plus avances, mais j'ai l'impression qu'ils ont compense ca en passant a des methodes de design plus optimisees. En pratique, la surface des unites FP est mesurable sur diverses photos de dies et il est possible d'en extraire a process constant (les ratios de surface entre noeuds de process et sur de la logique tournent generalement tres pres de 0.56 donc ca peut servir de base) les ratios de surface par unite FP.
    Bien entendu vu que les archis ont change et le bloc de base replique a change ce n'est pas si simple que ca, mais quand j'avais regarde ca il y a 2-3 ans j'avais vu que la densite avait augmente chez ATI malgre le passage a une plus grande precision et le support de IEEE-754.
    Il y eu une grosse augmentation de la densité lors du passage de RV670 à RV770, d'ailleurs AMD s'en était pas mal vanté à l'époque :



    Si j'étais mauvaise langue, je dirais que le foirage assez conséquent que R600 a été — et sur lequel RV670 était basé — n'y est pas étranger.

    De RV770 à Cypress, en normalisant — comme on peut — par rapport au process, je ne pense pas que la densité ait augmenté. D'un autre côté, DX11 est aussi passé par là. Avec Cayman ils sont passés de blocs VLIW(4+1) à VLIW4, donc ce n'est plus tellement comparable, même si ça a peut-être effectivement abouti sur une augmentation des perfs/mm² de leurs shaders.

    C'est difficile à dire parce que le reste de l'architecture a aussi changé, et on n'a pas de die shot.

    Citation Envoyé par fefe Voir le message
    Apres, l'augmentation de la bande passante en DP, l'agrandissement des bancs de registres partages et autres fonctions destinees a ameliorer le throughput computing ont eu un effet assez negatif sur la densite chez Nvidia. D'ailleurs je suis sur que si tu regardes la perf en DP au lieu de la perf en SP la tendance recente est largement superieure a la loi de Moore .
    Ben vu que GT200 supportait la DP à 1/8 de la vitesse SP et que Fermi est passé à 1/2, y'a intérêt !
    Mon blog (absolument pas à jour) : Teχlog

  14. #554
    Un serveur HPC avec du vrai Llano dedans : http://www.penguincomputing.com/file...vers/A2A00.pdf

    A priori, c'est le premier du genre.
    Mon blog (absolument pas à jour) : Teχlog

  15. #555
    Et c'est une bonne idee . J'etais surpris de ne pas en avoir encore vu.

    Merci
    fefe - Dillon Y'Bon

  16. #556
    C'est sûr qu'à priori, niveau transfert mémoire, doit yavoir un gros avantage à avoir le GPU et le CPU sur le même die.
    On a quoi comme amélioration au niveau de la bande passante CPU/GPU sur un Llano comparé à un couple CPU/GPU plus classique ? Et niveau puissance de calcul, on est à quel distance des Tesla !

    Concrètement ça en est où l'utilisation des GPU intégré aux CPU pour le HPC ? Aux dernières nouvelles, yavait toujours pas d'implémentation openCL pour les HD3000 de Sandy Bridge. Ça doit probablement être dans les cartons mais la dernière fois que je me suis renseigné, la ligne d'Intel c'était plus ou moins ça : "Nous souhaitons promouvoir OpenCL mais nous ne communiquons pas sur ce sujet" (ce sujet étant le support d'openCL sur les HD3000 )

  17. #557
    Citation Envoyé par Sp1d3r Voir le message
    C'est sûr qu'à priori, niveau transfert mémoire, doit yavoir un gros avantage à avoir le GPU et le CPU sur le même die.
    On a quoi comme amélioration au niveau de la bande passante CPU/GPU sur un Llano comparé à un couple CPU/GPU plus classique ? Et niveau puissance de calcul, on est à quel distance des Tesla !
    La bande-passante passe de 7 Go/s à 27 Go/s :



    Et dans le futur, euh, ce sera mieux :



    Sinon, Llano, c'est 400 SP à 600 MHz, soit 480 GFLOPS, contre 1030 GFLOPS sur le plus gros Tesla (tout ça en SP). Mais bon, en pratique, Tesla se montre souvent plus efficace.

    Et sinon, AMD a promis +50% de puissance brute pour Trinity, début 2012, avec un passage d'une archi VLIW5 à VLIW4, typiquement plus efficace (surtout en compute). D'ici-là, ou peut-être 3~4 mois après, la nouvelle génération de Tesla sera sortie.


    Citation Envoyé par Sp1d3r Voir le message
    Concrètement ça en est où l'utilisation des GPU intégré aux CPU pour le HPC ? Aux dernières nouvelles, yavait toujours pas d'implémentation openCL pour les HD3000 de Sandy Bridge. Ça doit probablement être dans les cartons mais la dernière fois que je me suis renseigné, la ligne d'Intel c'était plus ou moins ça : "Nous souhaitons promouvoir OpenCL mais nous ne communiquons pas sur ce sujet" (ce sujet étant le support d'openCL sur les HD3000 )
    Oui, aux dernières nouvelles, pas d'OpenCL sur HD3000. Mais bon, vu la puissance du GPU par rapports aux cores CPU, ce serait pas super utile. Ivy Bridge supportera DirectX 11, donc au minimum DirectCompute.
    Mon blog (absolument pas à jour) : Teχlog

  18. #558
    Citation Envoyé par Alexko Voir le message
    La bande-passante passe de 7 Go/s à 27 Go/s :

    [...]

    Sinon, Llano, c'est 400 SP à 600 MHz, soit 480 GFLOPS, contre 1030 GFLOPS sur le plus gros Tesla (tout ça en SP). Mais bon, en pratique, Tesla se montre souvent plus efficace.
    Surtout, j'imagine, que lorsque le volume de données dépasse la taille de cache APU, c'est forcément beaucoup moins efficace que d'utiliser un GPU standalone avec son débit dédié de folie sur plein de VRAM. J'aime bien claquer des évidences, c'est le week-end, faut pas forcer

  19. #559
    Quelques infos sur Kepler : http://imgur.com/a/aQmuA

    Pour résumer, le SM (pour le coup rebaptisé SMX) passe de 32 (GF 100) ou 48 (GF 104) « CUDA Cores » à 192. Le RF, en revanche, ne passe que de 32 768 à 65 536 × 32 bits, et la taille du L1 ne bouge pas (64 ko). D'après les rumeurs et selon toute vraisemblance, il n'y a plus de hot clocks, tout le GPU tourne à environ 1 GHz. Le cache L2 reste à 768 ko, comme sur GF 100 (contre 512 sur GF 104, je crois).

    Quelques benchmarks : http://www.hkepc.com/7672/page/6#view
    Dernière modification par Alexko ; 16/03/2012 à 23h09.
    Mon blog (absolument pas à jour) : Teχlog

  20. #560
    On dirait que nVidia se réveille ; même s'il va falloir attendre un peu de plus de benchmarks, si j'ai bien compris les jeux testés là favorisent nVidia. Enfin bon je suis un peu déçu, le prix supposé de cette carte est dans les 500 Euros, trop au-dessus des 300 Euros que je suis prêt à mettre dans une CG Va falloir attendre les modèles suivants.
    Dernière modification par newbie06 ; 17/03/2012 à 09h13.

  21. #561
    Au final, entre 0 et 6 % de mieux que la Radeon HD 7970, selon les définitions : http://www.hardware.fr/articles/857-...formances.html

    Consommation maîtrisée, mais toujours pas de power gating.
    Dernière modification par Alexko ; 22/03/2012 à 23h15.
    Mon blog (absolument pas à jour) : Teχlog

  22. #562
    C'est rigolo, maintenant NVidia se met à faire du scheduling d'instructions statique pendant qu'AMD est passé au scheduling dynamique.

  23. #563
    Citation Envoyé par Alexko Voir le message
    Pour résumer, le SM (pour le coup rebaptisé SMX) passe de 32 (GF 100) ou 48 (GF 104) « CUDA Cores » à 192. Le RF, en revanche, ne passe que de 32 768 à 65 536 × 32 bits, et la taille du L1 ne bouge pas (64 ko). D'après les rumeurs et selon toute vraisemblance, il n'y a plus de hot clocks, tout le GPU tourne à environ 1 GHz. Le cache L2 reste à 768 ko, comme sur GF 100 (contre 512 sur GF 104, je crois).
    On connaît le nombre de threads concurrents par SMX (ou par scheduler) ? Le whitepaper de Nvidia évite soigneusement la question.

    Si j'interprète bien le whitepaper, l'ordonnancement des instructions reste dynamique, mais chaque instruction est statiquement annotée avec les délais à respecter par rapport à l'instruction suivante/précédente. Pour du multi-thread in-order, ça me semble pas débile.
    Ça existe ou a existé ailleurs ce genre de chose ? Ça revient vaguement à avoir du VLIW avec delay slots et une représentation compressée des NOPs. Mais avec du multithreading et du scheduling dynamique en plus pour boucher les trous dans le pipeline. Kepler et Poulson, même combat ?
    Dernière modification par Møgluglu ; 23/03/2012 à 20h10.

  24. #564
    Citation Envoyé par Møgluglu Voir le message
    Ça existe ou a existé ailleurs ce genre de chose ? Ça revient vaguement à avoir du VLIW avec delay slots et une représentation compressée des NOPs.
    Jamais vu un truc pareil non plus. Ca permet d'éliminer complètement les NOPs au prix de quelques bits dans chaque opcode. J'imagine que ça facilite le boulot côté driver pour le scheduling statique, mais pas certain que ça soit vraiment si génial que ça au final. Ou alors j'ai pas compris

  25. #565
    Par rapport à un superscalaire in-order, ça évite de faire appel à la logique de scoreboarding pour identifier les dépendances entre instructions arithmétiques.
    Par rapport à un VLIW, ça conserve les avantages du scheduling dynamique, vu qu'au final c'est le hardware qui décide quel warp va exécuter son/ses instruction(s). Le compilo étant incapable de scheduler les warps les uns par rapport aux autres, l'arbitrage des ressources entre les warps doit être fait dynamiquement.

    ---------- Post added at 12h46 ---------- Previous post was at 12h02 ----------

    Citation Envoyé par Møgluglu Voir le message
    On connaît le nombre de threads concurrents par SMX (ou par scheduler) ?
    Kanter a la réponse : 64 warps (qui ne sont pas des work-groups, mais passons...) par SMX, soit 16 warps par scheduler.
    http://www.realworldtech.com/page.cf...WT032212172023

    On a donc l'évolution du nombre de warps / scheduler, et du nombre de registres / scheduler :
    G80 : 24 warps, 256 registres
    GT200 : 32 warps, 512 registres
    Fermi : 24 warps, 512 registres
    Kepler : 16 warps, 512 registres

    Manifestement, la tendance est de simplifier le warp scheduler en exploitant plus de parallélisme d'instructions et moins de parallélisme de threads.
    Dernière modification par Møgluglu ; 24/03/2012 à 13h06.

  26. #566
    Je ne suis pas certain que le gros GPU de la famille (GK110) conserve les mêmes SMX que GK104, donc les comparaisons avec G80, GT200 et GF100 ne sont pas forcément pertinentes.
    Mon blog (absolument pas à jour) : Teχlog

  27. #567
    Oui, c'est vrai. Mais en l'occurence les chiffres sont les mêmes pour le GT21x et GF104 que pour le GT200 et GF100 respectivement, si je ne m'abuse.
    Dernière modification par Møgluglu ; 24/03/2012 à 14h16.

  28. #568
    C'est vrai aussi. Ce coup-ci je pense que les différences entre le plus gros GPU de la famille et les autres risquent d'être plus importantes, mais les nombres de warps et de registres ne changeront peut-être pas. David Kanter suggère ceci :

    [T]he cores need to be rebalanced to achieve a better balance of B/FLOP through shared memory and the data caches. The easiest approach is probably cutting the number of execution units per core in half, and scaling up the core count. It is possible that Nvidia will have more scheduling hardware, to avoid relying on the compiler, but that seems like a rather large investment with an unclear return. Last, the register files, caches, shared memory and DRAM need error protection in the form of ECC.
    Même comme ça, le ratio cache/flop, que ce soit en capacité ou en débit, resterait nettement plus faible que celui de GF100, à moins d'aggrandir le cache. Idem pour les registres.
    Dernière modification par Alexko ; 25/03/2012 à 03h56.
    Mon blog (absolument pas à jour) : Teχlog

  29. #569

  30. #570
    La news date d'hier soir, c'est vieux. On devrait avoir un peu plus d'infos à la fin du talk sur Kepler, dans 30 minutes.

    Edit: et hop :
    http://www.hardware.fr/news/12302/gt...ils-gk110.html
    Dernière modification par Møgluglu ; 17/05/2012 à 16h45.

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
  •