Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 17 sur 22 PremièrePremière ... 7910111213141516171819202122 DernièreDernière
Affichage des résultats 481 à 510 sur 658

Discussion: Archi GPU et GPGPU

  1. #481
    Comme Itanium
    fefe - Dillon Y'Bon

  2. #482
    J'attends impatiemment la resurrection de l'iAPX 432

  3. #483
    Tu rigoles, mais avec les features de virtualisation et de sécurité, les systèmes à base de capabilities reviennent en force...

  4. #484
    Une implémentation de CUDA pour les GPU AMD (expérimentale, prototype, semi-académique, toussa...)
    http://www.ece.neu.edu/groups/nucar/.../dominguez.pdf

    C'est pas juste que c'est CUDA, ça fait surtout une chaîne de compilation quasi-entièrement libre, qui contourne la boîte noire OpenCL d'Apple...

  5. #485
    Citation Envoyé par Møgluglu Voir le message
    Une implémentation de CUDA pour les GPU AMD (expérimentale, prototype, semi-académique, toussa...)
    http://www.ece.neu.edu/groups/nucar/.../dominguez.pdf

    C'est pas juste que c'est CUDA, ça fait surtout une chaîne de compilation quasi-entièrement libre, qui contourne la boîte noire OpenCL d'Apple...
    Classe!

  6. #486
    Il me semblait qu'on avait parlé de simulation RTL et de GPU, mais je ne retrouve plus.

    Une société israelienne semble prête à mettre sur le marché un tel bidule : rocketick. Je trouve le nom à chier, mais sur le papier ça a l'air séduisant.

  7. #487
    Les explications sur leur site sont assez lège, mais ils font apparemment un scheduling statique de leur graphe de dépendances en essayant d'équilibrer parallélisme et localité, et génèrent du code GPU selon ce scheduling. Par contre, il semble qu'ils ne font pas grand-chose, voire rien, pour favoriser la cohérence — grouper les opérations similaires ensemble pour profiter du mode d'exécution SIMD.
    Ils ont aussi l'air de considérer implicitement que toutes leurs opérations élémentaires ont la même durée. En pratique, je m'attendrais à ce qu'ils perdent pas mal de temps sur les synchronisations.

    Mais si leurs heuristiques de scheduling sont bonnes, ça peut avoir des chances de marcher. Le fait de connaître tout le graphe de dépendances et pouvoir estimer les durées d'exécution à l'avance est un gros plus, par rapport à d'autres applis irrégulières où on ne sait pas où on va genre raytracing.

  8. #488
    C'est beaucoup plus GPU que GPGPU, mais Anand vient de tester la version desktop de Llano en DDR3-1333 et -1866 : http://www.anandtech.com/show/4448/a...ance-preview/3

    Clairement, la bande-passante limite beaucoup les performances. Il va être intéressant de voir comment AMD gérera ça dans le futur, quand les prochaines finesses de gravure les inviteront à mettre des GPU beaucoup plus gros.

    Edit : dans la foulée et pour revenir vers le GPGPU, brève description d'un GPU AMD "Next Gen" par D. Kanter : http://www.realworldtech.com/forums/...20411&roomid=2
    Mon blog (absolument pas à jour) : Teχlog

  9. #489
    Dire que ça fait des mois qu'Intel dit que c'est la BP qui déterminera les performances des CPU+GPU !

  10. #490
    Et ça fait des années qu'on sait l'importance de la bande passante mémoire sur les perfs GPU.

    Citation Envoyé par Alexko Voir le message
    Edit : dans la foulée et pour revenir vers le GPGPU, brève description d'un GPU AMD "Next Gen" par D. Kanter : http://www.realworldtech.com/forums/...20411&roomid=2
    C'est marrant, à part le retour au vec4 ça ressemble pas mal à ce que fait Nvidia. (Mais avec ce niveau de détail, tout ressemble forcément à autre chose qui n'a rien à voir.)

    Edit: ah non, par 16x4 DK doit vouloir dire 4 cycles sur 16 unités comme sur les archis AMD actuelles, point de SIMD explicite ici.
    Dernière modification par Møgluglu ; 15/06/2011 à 09h18.

  11. #491
    Citation Envoyé par PeGGaaSuSS Voir le message
    Dire que ça fait des mois qu'Intel dit que c'est la BP qui déterminera les performances des CPU+GPU !
    Ils disent ça parce que Sandy Bridge a plus de bande-passante, notamment interne. Ça n'empêche pas le GPU de Llano de mettre des baffes à celui de SB.

    Citation Envoyé par Møgluglu Voir le message
    C'est marrant, à part le retour au vec4 ça ressemble pas mal à ce que fait Nvidia. (Mais avec ce niveau de détail, tout ressemble forcément à autre chose qui n'a rien à voir.)

    Edit: ah non, par 16x4 DK doit vouloir dire 4 cycles sur 16 unités comme sur les archis AMD actuelles, point de SIMD explicite ici.
    4 cycles sur 16 unités ?

    Les slides montrent bien 4 unités SIMD 16-way, cf. l'article de Damien avec tout plein d'images : http://www.hardware.fr/news/11648/af...-gpus-amd.html




    Tiens, ça me rappelle quelque chose, ça…
    Dernière modification par Alexko ; 16/06/2011 à 02h22.
    Mon blog (absolument pas à jour) : Teχlog

  12. #492
    Citation Envoyé par Alexko Voir le message
    Les slides montrent bien 4 unités SIMD 16-way, cf. l'article de Damien avec tout plein d'images : http://www.hardware.fr/news/11648/af...-gpus-amd.html
    Des unités scalaires dans un GPU!

    Tiens, ça me rappelle quelque chose, ça…
    Les salauds, ils m'ont pris mon idée.
    (Ouais, je devais pas être le seul à l'avoir cette idée...)

    Maintenant, la question c'est comment ils vont identifier les calculs scalaires dans leur compilo...

  13. #493
    Citation Envoyé par Alexko Voir le message
    Ils disent ça parce que Sandy-Bridge a plus de bande-passante, notamment interne. Ça n'empêche pas le GPU de Llano de mettre des baffes à celui de SB.
    En regardant d'un peu plus pres tu remarqueras qu'ils sont 1.5x plus rapide avec ~2-3x plus de hardware. Le resultat est un produit nettement plus performant surtout a des budgets power eleves, en revanche cela ne dit pas grand chose sur l'archi en elle meme. Je peux aussi comparer un produit a 6 cores vendu au meme prix (ou moins cher) avec un dual core et conclure que le 4 - 6 cores est beaucoup plus performant, mais mon analyse ne se porterait effectivement que sur ce qui a ete decide par le departement de marketing (prix de vente et prix de production) et non sur la technologie elle meme. J'attend avec impatience des comparaisons techniques
    fefe - Dillon Y'Bon

  14. #494
    Citation Envoyé par fefe Voir le message
    En regardant d'un peu plus pres tu remarqueras qu'ils sont 1.5x plus rapide avec ~2-3x plus de hardware. Le resultat est un produit nettement plus performant surtout a des budgets power eleves, en revanche cela ne dit pas grand chose sur l'archi en elle meme. Je peux aussi comparer un produit a 6 cores vendu au meme prix (ou moins cher) avec un dual core et conclure que le 4 - 6 cores est beaucoup plus performant, mais mon analyse ne se porterait effectivement que sur ce qui a ete decide par le departement de marketing (prix de vente et prix de production) et non sur la technologie elle meme. J'attend avec impatience des comparaisons techniques
    Certes, mais on ne peut pas non plus supposer a priori que le GPU de Sandy pourrait scaler jusqu'au niveau de Llano. Cela étant, des versions de Llano avec « seulement » 160 SP actifs sont prévues, donc ça permettra des comparaisons plus directes.

    Accessoirement, je lis ici et là que le rendu est meilleur sur Llano, qu'il y a souvent des bugs et autres problèmes avec le rendu de Sandy, mais ça c'est la faute des drivers — sauf pour le filtrage anisotropique. Enfin, il y a aussi le support de DX 11, qui n'est pas gratuit en hardware.
    Mon blog (absolument pas à jour) : Teχlog

  15. #495
    Tout a fait d'accord avec toi, la performance de Sandy bridge ne dit rien sur la capacite de l'archi a scaler a de meilleures performances avec plus de hardware. Etant donne qu'il n'y a qu'une unite de texture sampling j'irai meme plus loin en disant qu'a priori l'architecture telle quelle ne peut pas scaler au dela dans son implementation actuelle (passer de 1 a 2 demande becoup plus de microarchitecture que de 2 a n). En revanche, comme tu le dis, ce sera interressant de regarder les demi llanos contre Sandy Bridge pour faire des comparaisons de performances d'uarch.

    Les drivers d'Intel restent nettement moins bons que ceux d'AMD et Nvidia. Il y a du progres par rapport aux generations precedentes (les applis tournent maintenant !) mais il y a encore du boulot au niveau de la qualite. Enfin le dernier parametre interressant est que Intel sort une nouvelle archi graphique par an ces dernieres annees et AMD tous les 2 ans (pour ce qui est des GPUs integres au chipset ou au CPU). Llano sort 6 mois apres Sandy Bridge et est clairement plus avance dans son support de features (DX11...), drivers, et perf. En revanche si tu fais le graph des perfs respectives en fonction du temps tu trouveras que l'avantage d'AMD se reduit fortement avec le temps.

    Tout ca pour dire quelque chose de somme toute banal: AMD a investi beaucoup dans le GPU et peu dans le CPU, Intel l'inverse (et part avec beaucoup de retard sur le GPU) et les resultats de Llano semblent montrer que les investissements respectifs ont paye. Apres quelle est la meilleure balance entre graphique et CPU, c'est une bonne question et je suis nettement plus convaincu par les choix d'AMD que d'Intel de ce point de vue la.

    Si vous trouvez de bons articles qui comparent l'architecture dans le scenario que tu decris (demi-Llano vs Sandy Bridge), postez le lien, je suis interresse.
    fefe - Dillon Y'Bon

  16. #496
    Citation Envoyé par fefe Voir le message
    Tout a fait d'accord avec toi, la performance de Sandy bridge ne dit rien sur la capacite de l'archi a scaler a de meilleures performances avec plus de hardware. Etant donne qu'il n'y a qu'une unite de texture sampling j'irai meme plus loin en disant qu'a priori l'architecture telle quelle ne peut pas scaler au dela dans son implementation actuelle (passer de 1 a 2 demande becoup plus de microarchitecture que de 2 a n). En revanche, comme tu le dis, ce sera interressant de regarder les demi llanos contre Sandy Bridge pour faire des comparaisons de performances d'uarch.

    Les drivers d'Intel restent nettement moins bons que ceux d'AMD et Nvidia. Il y a du progres par rapport aux generations precedentes (les applis tournent maintenant !) mais il y a encore du boulot au niveau de la qualite. Enfin le dernier parametre interressant est que Intel sort une nouvelle archi graphique par an ces dernieres annees et AMD tous les 2 ans (pour ce qui est des GPUs integres au chipset ou au CPU). Llano sort 6 mois apres Sandy Bridge et est clairement plus avance dans son support de features (DX11...), drivers, et perf. En revanche si tu fais le graph des perfs respectives en fonction du temps tu trouveras que l'avantage d'AMD se reduit fortement avec le temps.
    C'est vrai que les progrès de Sandy Bridge par rapport à Arrandale sont déjà considérables, et il me semble qu'Ivy Bridge prévoit un doublement des ressources du GPU. Mais AMD a aussi l'intention de passer à une cadence annuelle : ils appellent ça Velocity — parce que ça fait cool — et en pratique, l'année prochaine, Trinity aura un nouveau GPU. Mais Rick Bergman a parlé d'une augmentation des performances qui n'est « que » supérieure à 50 %, et je ne sais pas vraiment s'il parlait des GFLOPS bruts, des perfs du CPU, du GPU, d'une sorte de vague moyenne de tout ça… En tout cas il est clair que le fait d'être limité au 32 nm en 2012 entravera les efforts d'AMD par rapport à Intel qui passe au 22 nm, mais finalement semble rester un peu timoré, comme tu le déplores plus bas.

    Citation Envoyé par fefe Voir le message
    Tout ca pour dire quelque chose de somme toute banal: AMD a investi beaucoup dans le GPU et peu dans le CPU, Intel l'inverse (et part avec beaucoup de retard sur le GPU) et les resultats de Llano semblent montrer que les investissements respectifs ont paye. Apres quelle est la meilleure balance entre graphique et CPU, c'est une bonne question et je suis nettement plus convaincu par les choix d'AMD que d'Intel de ce point de vue la.

    Si vous trouvez de bons articles qui comparent l'architecture dans le scenario que tu decris (demi-Llano vs Sandy Bridge), postez le lien, je suis interresse.
    Je n'en ai pas encore vu, mais ça ne saurait tarder, je pense.

    Sinon, une question intéressante posée à Eric Demers (CTO GPU chez AMD) par Damien :

    Enfin, nous avons demandé au CTO d'AMD s'il envisageait d'inclure à l'avenir dans les GPUs plus de CUs que ne le permet le TDP, tout en sachant qu'ils ne pourraient pas tous être exploités en rendu 3D (limités par PowerTune), mais en supposant qu'ils pourraient l'être en mode compute qui n'exploite pas certaines parties du GPU très gourmandes telles que les unités de texturing. Eric Demers nous a répondu qu'AMD envisageait effectivement cela et qu'une telle possibilité pourrait éventuellement être retenue à l'avenir, si les simulations le justifiaient, notamment pour un GPU qui viserait le HPC.
    http://www.hardware.fr/news/11656/af...r-gpu-amd.html

    Je pense qu'en pratique, vu qu'AMD a déjà PowerTune sur Cayman, il serait plus logique de gérer ça par des variations sur la fréquence que par une activation/désactivation de Compute Units, mais en tout cas c'est intéressant.
    Mon blog (absolument pas à jour) : Teχlog

  17. #497
    Tu n as de bonnes raisons de desactiver des shaders que si tu e deja au voltage minimum. Desactiver des blocks a un effet lineaire sur le power et la perf, alors que baisser le voltage a un effet cube sur le power et lineaire sur la perf. Il suffit d un algo de power management basique pour controler ca.

    Si tu es deja au voltage minimum, desactiver des blocks est plus efficace que de baisser la frequence a condition de disposer de power gates pour eliminer le leakage. Power gates qui viennent avec leur lot d' inconvenients...(tu dois booster le voltage pour alimenter des blocks derriere une power gate donc ca coute du power quand le block est actif)

  18. #498
    Du power-gating avec une granularité d'une Compute Unit (sachant qu'il devrait y en avoir une trentaine) c'est un peu excessif, non ? Même avec une granularité de 4, par exemple, ça me semblerait assez lourd.

    Citation Envoyé par fefe
    Power gates qui viennent avec leur lot d' inconvenients...(tu dois booster le voltage pour alimenter des blocks derriere une power gate donc ca coute du power quand le block est actif)
    De quel ordre de grandeur doit être cette hausse de tension ?
    Mon blog (absolument pas à jour) : Teχlog

  19. #499
    C'est assez dependant de la techno, mais de 1% a 5% est probablement le plus courant, ca depend de la taille du bloc en question aussi. Mais au mieux tu payeras 2% de power en plus quand le bloc est allume et au pire 10%. Qui plus est une power gate prend de la place et meme quand tu coupes le courant vers le bloc qui est derriere elle leake un peu. Donc oui tu ne mettras jamais 1 power gate par shader, mais plutot 1 power gate pour 80 shaders semble beaucoup plus raisonable.
    fefe - Dillon Y'Bon

  20. #500
    Citation Envoyé par fefe Voir le message
    C'est assez dependant de la techno, mais de 1% a 5% est probablement le plus courant, ca depend de la taille du bloc en question aussi. Mais au mieux tu payeras 2% de power en plus quand le bloc est allume et au pire 10%. Qui plus est une power gate prend de la place et meme quand tu coupes le courant vers le bloc qui est derriere elle leake un peu. Donc oui tu ne mettras jamais 1 power gate par shader, mais plutot 1 power gate pour 80 shaders semble beaucoup plus raisonable.
    OK merci, le coût en power est un poil plus élevé que ce que je pensais.

    Compute Unit = 64+1 shaders (plus précisément 4 unités SIMD 16-way + 1 unité scalaire). Donc une power gate par CU ça te semble raisonnable ? Ça en ferait 32 pour un GPU comptant autant de CU, ce qui correspond à peu près à ce qu'on attend pour le prochain modèle haut de gamme. Sur Llano apparemment, la power gate du GPU est globale, i.e. elle éteint tout le GPU ou rien, exception faite de l'UVD, et peut-être un buffer quelque part pour maintenir un signal video correspondant à une image fixe ?

    Du coup, 32 power gates… Quand tu dis que ça prend de la place, encore une fois, quel ordre de grandeur environ ? Ouais je sais, je pose beaucoup de questions, désolé…
    Mon blog (absolument pas à jour) : Teχlog

  21. #501
    Citation Envoyé par Alexko Voir le message
    Compute Unit = 64+1 shaders (plus précisément 4 unités SIMD 16-way + 1 unité scalaire). Donc une power gate par CU ça te semble raisonnable ?
    Ils ont probablement un niveau hiérarchique au dessus des CU : les caches L1 scalaires et d'instructions sont partagés entre 4 CU si j'ai bien suivi. Gérer du power-gating à ce niveau-là pourrait être raisonnable.

    L'intérêt de faire du power gating à cette granularité doit être surtout de faire tourner les effets 3D des UI sans vider la batterie...
    Mais ça a moins d'intérêt sur un GPU que sur un CPU. Si la perf de l'appli scale linéairement avec le nombre de cores, alors on aura aussi un gain linéaire en power en faisant du power-gating sur toute la puce.

    Je suppose que la réponse à la question de Damien veut simplement dire qu'ils pourraient calculer le TDP et ajuster les fréquences de leurs cartes GPGPU en prenant en compte le fait que les unités graphiques ne servent jamais. C'est assez raisonnable, et il est probable que Nvidia fassent déjà ça pour leurs Tesla.

    Sinon il y a pas mal de trucs intéressants dans ces slides :

    - Les loads en mémoire partagée peuvent lire 2 sources à la fois, pour les réductions (avec 32 bancs mémoire pour 16 unités).
    Mais ce n'est pas clair qu'on puisse faire venir l'adresse directement d'un registre scalaire, façon strided load.

    - L'unité scalaire reçoit le même débit d'instructions que les 4 unités SIMD réunies. Elle a 8 Ko de registres, soit 2048 registres scalaires, contre 1024 registres vectoriels. Ça me semble beaucoup.
    Soit ils sont sûrs de leur coup, soit ils ont fait comme ça parce que c'était plus simple et ça ne leur coûtait pas cher.

    - Plus de SIMT à la Nvidia. Retour à du SIMD explicite, avec des masques que le compilateur gère à la main, comme au temps des Connection Machine, des Larrabee et des Maspar. (D'où l'utilité de l'unité scalaire pour calculer les masques.)
    C'est décevant, mais ça me semble une décision pragmatique et tout à fait dans l'esprit des GPU AMD jusqu'ici.

    - Le nombre de waves annoncé "at least" est ridiculement faible par rapport au nombre de registres et à la latence mémoire à couvrir. On peut s'attendre à ce qu'il y en ai beaucoup plus. Ou bien le "at least" est à interpréter comme la valeur minimale en dessous de laquelle les performances s'effondrent.

  22. #502
    Pour des blocs qui font des calculs je n'ai pas vraiment vu de power gate a une granularite plus fine que 10mm^2 aujourd'hui. Pour les GPUs integres a l'heure actuelle comme Sandy Bridge et Llano, la plus petite granularite que j'aie vu est >20mm^2 (et c'est pour l'entree de gamme). La surface devrait etre mesurable sur une photo de die donc je te laisse compter les pixels ( la power gate doit entourer le bloc en question).
    N'avoir qu'un seul bloc de power pour le graphique simplifie considerablement les algos de power management et c'est une raison supplementaire pour laquelle tu n'as pas de power gate partout.

    ---------- Post added at 21h41 ---------- Previous post was at 21h32 ----------

    Qui plus est, allumer/eteindre une power gate prend du temps donc il faut un bon algo pour detecter quand l'utiliser et quand ne pas l'utiliser (il faut une bonne prediction de la future necessite du bloc en question). Une des grosses difficultes des algos de power management est que le meilleur indice pour t'aider a prendre une decision est ta consommation actuelle. Et malheureusement c'est particulierement difficile a mesurer avec precision a la vitesse ou tu en as besoin. Soit tu mesures le courant en hard et tu as en gros 30% a 50% d'erreur du a la variabilite du process, soit tu implementes un algo a partir de compteurs d'activite et un sampling des patterns de donnees qui passent sur tes bus principaux. Bref il n'y a pas de methode miracle, donc au final la question qui peut t'aider a comprendre combien de power gate tu peux mettre est la suivante: Si je ne connais mon power qu'a 30% pres quelle granularite puis-je allumer/eteindre avec certitude d'obtenir des gains. La reponse est en gros, a coup sur la moitie de ton bloc graphique, peut etre 1/4. Aller a des granularites plus fines ne t'apportera pas grand chose tant que tu ne seras pas capable de determiner que cela te sera benefique...
    fefe - Dillon Y'Bon

  23. #503
    Citation Envoyé par Møgluglu Voir le message
    Ils ont probablement un niveau hiérarchique au dessus des CU : les caches L1 scalaires et d'instructions sont partagés entre 4 CU si j'ai bien suivi. Gérer du power-gating à ce niveau-là pourrait être raisonnable.
    Oui, ils appellent ça Compute array, je crois. Effectivement ça me semble être un candidat crédible pour la granularité.

    Citation Envoyé par Møgluglu Voir le message
    L'intérêt de faire du power gating à cette granularité doit être surtout de faire tourner les effets 3D des UI sans vider la batterie...
    Mais ça a moins d'intérêt sur un GPU que sur un CPU. Si la perf de l'appli scale linéairement avec le nombre de cores, alors on aura aussi un gain linéaire en power en faisant du power-gating sur toute la puce.

    Je suppose que la réponse à la question de Damien veut simplement dire qu'ils pourraient calculer le TDP et ajuster les fréquences de leurs cartes GPGPU en prenant en compte le fait que les unités graphiques ne servent jamais. C'est assez raisonnable, et il est probable que Nvidia fassent déjà ça pour leurs Tesla.
    Tu as probablement raison. C'est plus simple et comme il reste toujours PowerTune, ils peuvent garantir que le TDP ne sera jamais dépassé même si le nouveau propriétaire d'une FirePro décide, tout fier, de lancer FurMark pour voir ce qu'elle a dans le ventre.

    Citation Envoyé par Møgluglu Voir le message
    - Le nombre de waves annoncé "at least" est ridiculement faible par rapport au nombre de registres et à la latence mémoire à couvrir. On peut s'attendre à ce qu'il y en ai beaucoup plus. Ou bien le "at least" est à interpréter comme la valeur minimale en dessous de laquelle les performances s'effondrent.
    Tu trouves ? 2560 work-items par CU, en supposant un GPU de la taille de Cayman, ça en fait 61440… Soit 2,5 fois plus que Fermi. Ou alors il y a quelque chose qui m'échappe ? C'est vrai qu'il y a 3 fois plus de registres que Fermi, mais la latence devrait être similaire.

    Citation Envoyé par fefe Voir le message
    Pour des blocs qui font des calculs je n'ai pas vraiment vu de power gate a une granularite plus fine que 10mm^2 aujourd'hui. Pour les GPUs integres a l'heure actuelle comme Sandy Bridge et Llano, la plus petite granularite que j'aie vu est >20mm^2 (et c'est pour l'entree de gamme). La surface devrait etre mesurable sur une photo de die donc je te laisse compter les pixels ( la power gate doit entourer le bloc en question).
    N'avoir qu'un seul bloc de power pour le graphique simplifie considerablement les algos de power management et c'est une raison supplementaire pour laquelle tu n'as pas de power gate partout.

    ---------- Post added at 21h41 ---------- Previous post was at 21h32 ----------

    Qui plus est, allumer/eteindre une power gate prend du temps donc il faut un bon algo pour detecter quand l'utiliser et quand ne pas l'utiliser (il faut une bonne prediction de la future necessite du bloc en question). Une des grosses difficultes des algos de power management est que le meilleur indice pour t'aider a prendre une decision est ta consommation actuelle. Et malheureusement c'est particulierement difficile a mesurer avec precision a la vitesse ou tu en as besoin. Soit tu mesures le courant en hard et tu as en gros 30% a 50% d'erreur du a la variabilite du process, soit tu implementes un algo a partir de compteurs d'activite et un sampling des patterns de donnees qui passent sur tes bus principaux. Bref il n'y a pas de methode miracle, donc au final la question qui peut t'aider a comprendre combien de power gate tu peux mettre est la suivante: Si je ne connais mon power qu'a 30% pres quelle granularite puis-je allumer/eteindre avec certitude d'obtenir des gains. La reponse est en gros, a coup sur la moitie de ton bloc graphique, peut etre 1/4. Aller a des granularites plus fines ne t'apportera pas grand chose tant que tu ne seras pas capable de determiner que cela te sera benefique...
    Voici Llano :


    Je vois effectivement un cadre blanchâtre autour de chaque core — c'est donc la power gate ? Mais je ne discerne rien autour du GPU, idem pour Sandy Bridge et même ses cores (photo ici).

    J'avais pas pensé au problème de la mesure de consommation avant de jouer sur le power gating, mais effectivement ça réduit sensiblement les possibilités.
    Mon blog (absolument pas à jour) : Teχlog

  24. #504
    Citation Envoyé par Alexko Voir le message
    Tu trouves ? 2560 work-items par CU, en supposant un GPU de la taille de Cayman, ça en fait 61440… Soit 2,5 fois plus que Fermi. Ou alors il y a quelque chose qui m'échappe ? C'est vrai qu'il y a 3 fois plus de registres que Fermi, mais la latence devrait être similaire.
    Cayman a déjà autour de 80000 threads en vol.

    Et surtout il faut normaliser par le débit d'exécution. En débit crête, GCN traite 4 instructions par cycle, tout type confondu. Avec 40 waves / CU, ça fait seulement 10 cycles de latence masqués par le multithreading/multiwaving. C'est peu pour un GPU.
    Cela dit, Nvidia est apparemment sur la même voie, d'après l'évolution du G80 au GF104.

    Concernant les registres, ça fait 26 registres vectoriels et 51 registres scalaires par wave au minimum. C'est généreux, et ça suggère qu'ils ont confiance dans leur compilo pour exploiter l'ILP.

    J'aime bien les commentaires "AMD abandonne le VLIW, ça va devenir tout facile pour le compilateur d'atteindre les perfs crête". L'ordonnancement pour VLIW, c'est dur mais c'est étudié depuis longtemps.
    Pour l'identification de scalaires dans du code SPMD, on n'a rien de satisfaisant pour l'instant (même si on aura bientôt ). Et ça pose plein de problèmes techniques pénibles.
    L'allocation de registres dans un contexte où le nombre de registres disponible n'est pas fixé et où l'on doit faire un compromis entre parallélisme et localité, c'est absolument ignoble et on ne sait pas faire.

    C'est un pari qu'il font, sur le fait que le code GPGPU reste suffisamment simple pour que l'allocation de registres, la détection de scalaires et la gestion statique des branchements dans leur compilateur reste efficace.

    Maintenant il faut s'attendre à voir Nvidia insister lourdement sur les bienfaits des fonctions virtuelles, de la récursivité, et des kernels monstrueux répartis en pleins de modules compilés séparément et utilisant plein de bibliothèques différentes.

  25. #505

  26. #506
    Citation Envoyé par PeGGaaSuSS Voir le message
    http://newsroom.intel.com/community/...cale-computing

    Knights Corner : 50 coeurs x86 en 22 nm Tri-Gate
    x86 t'es sûr ? Je crois pas

    EDIT : ce que je veux dire c'est que je ne suis pas sûr que ce soit 50 coeurs x86.

    EDIT 2 : ouai ben du coup je doute.

  27. #507
    Les MIC sont tous à base de cœurs x86 a priori. Knights Ferry avait 32 cœurs x86 avec chacun du SIMD x16.

    Mais c'est pas (plus) un GPU.

  28. #508
    Sisi c'est un x86. La comm. ne se fait plus autour des capacite graphiques mais ca ne veut pas dire que ca ne peut pas etre utilise pour.
    fefe - Dillon Y'Bon

  29. #509
    [trollkiserépète]OMFG 50 décodeurs x86 quel gâchis de power et de surface

    (pas la peine de répondre )

  30. #510
    Tu oublies, 50+ stack X-87 !!!
    fefe - Dillon Y'Bon

Page 17 sur 22 PremièrePremière ... 7910111213141516171819202122 DernièreDernière

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
  •