Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 13 sur 22 PremièrePremière ... 356789101112131415161718192021 ... DernièreDernière
Affichage des résultats 361 à 390 sur 658

Discussion: Archi GPU et GPGPU

  1. #361

  2. #362
    Interressant ce retour aux groupes Samplers/Execution Units dans les memes clusters.
    fefe - Dillon Y'Bon

  3. #363
    Citation Envoyé par fefe Voir le message
    Interressant ce retour aux groupes Samplers/Execution Units dans les memes clusters.
    Ouais... Mais sur le G80/GT200 le cache de texture était déjà splitté statiquement entre chaque SM, probablement pour éviter des famines et simplifier la gestion...

    Vu que c'est le même shader qui tourne sur tous les SM d'un cluster (au moins jusqu'à Fermi), il n'y a pas vraiment d'équilibrage de charge à faire...

    Et à partir du moment où les samplers tournent dans le même domaine d'horloge que les SM il y a moins d'intérêt à séparer les deux?
    Ou c'est pour simplifier l'interconnect, parce que la différence de bande passante nécessaire entre l'amont et l'aval des unités de texture est énorme?

  4. #364
    Je pencherais pour la derniere option personellement,, que le cout du reseau d'interconnection necessaire est trop eleve par rapport aux benefices d'utilisation plus elevee.

    Le routage dans un GPU est vraiment difficile, et plus tu shrink, moins le routage scale par rapport a la logique (et plus il y en a besoin vu que tu multiplies souvent les blocs a interconnecter a chaque shrink). Donc a terme il est preferable de gacher un peu de logique pour garder la proximite entre des unites qui cooperent meme si tu n'es pas sensible a la latence et reduire (relativement) les capacites de routage.
    fefe - Dillon Y'Bon

  5. #365
    Nouvelle interview des ingés d'ATI par Anand, ou comment humaniser la conception d'un GPU :

    http://www.anandtech.com/video/showdoc.aspx?i=3740
    Dernière modification par Møgluglu ; 17/02/2010 à 00h08.

  6. #366
    Article interressant car il montre indirectement comment beaucoup de grosses boites fonctionnent en interne et ce qu'un projet de microprocesseur moderne represente. Ce que je regrette c'est que c'est a la gloire d'un project lead qui est presente comme un super heros. Le gars est probablement tres bon et a certainement fait de bons choix, mais il ne l'a pas fait tout seul (et j'imagine que l'intro a ete ajoutee apres qu'il ait lu l'article), et les contributeurs majeurs ne sont probablement pas tous des techniques non plus (en lisant entre les lignes je pense qu'il avait un tres bon analyste financier qui a bosse tout du long avec lui par exemple).
    fefe - Dillon Y'Bon

  7. #367
    Le principe du "moi le chef, je me garde ma killer feature de côté en secret pendant que je fais dégager toutes celles des autres qui sont pas indispensables" me semble assez limite aussi, niveau esprit d'équipe...

  8. #368
    Surtout que le muti-écran comme ça, pour l'utilisateur final, c'est inutilisable : il faudrait pouvoir avoir des dalles LCD contiguës, parce que là

  9. #369
    ben c'est surtout qu'il faut obligatoirement un écran en DisplayPort ou un adaptateur actif à 80 €, parce qu'ils ont pas cru bon de mettre trois TMDS (et donc le troisième écran peut pas utiliser le DVI en passif)

  10. #370
    Citation Envoyé par dandu Voir le message
    ben c'est surtout qu'il faut obligatoirement un écran en DisplayPort ou un adaptateur actif à 80 €, parce qu'ils ont pas cru bon de mettre trois TMDS (et donc le troisième écran peut pas utiliser le DVI en passif)
    Sauf que ca fait sans doute partie des compromis d'implémentation qui ont été fait pour limiter la taille de la fitioure.

    Par contre, je serai moins sévère sur l'impact que ca a sur l'esprit d'équipe: Certes ca n'incite pas les uns et les autres à communiquer fortement, en revanche, c'est nécessaire dans un tel milieu de cloisonner et compartimenter certaines fitioures "révolutionnaires". Le support de DX11 est connu par tout le monde, c'est plus sur les fonctions tierces bien supportées que les puces modernes vont faire aussi la différence. Là ou le team manager a sans doute fait quelques erreurs c'est de ne pas inclure assez tot le software (car on subit encore aujourd'hui les effets de ca avec une intégration toujours pas aboutie de Eyefinity dans les drivers, ce qui explique je pense aussi en partie le retard relatif dans la sortie de la SIX)

  11. #371
    Ca ne bousille pas l'ambiance vu que tout est deja fait comme ca ... Le probleme est que c'est bien pour surprendre la competition, c'est moins bien pour developper de bons produits quand tu l'appliques trop... Les specialistes que tu choisis d'inclure sur "la liste" ne vont pas necessairement etre ceux qui auraient eu les bonnes idees.
    fefe - Dillon Y'Bon

  12. #372
    En l'occurence, si l'on en croit l'article d'Anand, c'est pas juste par peur de l'espionnage, c'est aussi pour faire passer exceptionellement ladite fitioure malgré le régime strict d'amaigrissement de la puce appliquée à tout le reste de l'équipe...

    Through some very clever maneuvering he managed to keep it off of the radar while engineering hammered out the PRS, and even managed to keep it off of the chopping block when the GPU was cut down in size. He knew that if anyone got wind of it, they’d ask him to kill it while the chip was being scaled down.
    [Comprend enfin pourquoi les managers et VP ont toujours l'air uber-occupés mais qu'on ne les vois jamais rien produire ]

  13. #373
    Deux specs OpenGL le meme jour, 3.3 et 4.0. On croit rever

  14. #374
    Bon, launch de Fermi, toussa...

    Je suis un peu déçu par les reviews (pas les résultats, les reviews elles-mêmes).
    Ça fait 6 mois qu'on nous dit que c'est un monstre pour le GPGPU, on nous parle des caches, la double précision, l'ECC...
    À peu près toutes les reviews d'aujourd'hui rabachent ça en introduction.

    Mais y'en a pas un pour lancer un bench synthétique sur la puissance de calcul ou les caches histoire de pouvoir commencer à séparer le vrai du bullshit...
    (Anand Ryan essaye, mais les résultats sont un peu trop bons pour être convaincants...)

    Sinon, 300W en charge, ça fait beaucoup pour un TDP de 250W:
    http://www.hardware.fr/articles/787-...e-gtx-480.html

  15. #375
    Je me faisais la même réflexion sur le GPGPU. Mais il va sans doute falloir attendre un peu parce que si j'ai bien compris un des avantages majeurs est la présence de sauts indirects, qui demandent une exploitation spécifique non ?

    Pourquoi penses-tu que les résultats d'Anand sont foireux ?

    Quant à la conso, clairement ça chie, c'est pour moi rédhibitoire. Et le bruit aussi. Et la température. A part ça, je m'attendais à des performances en jeu plus pourries, mais ce n'est pas le sujet

  16. #376
    C'est normal qu'il n'y ait presque rien en GPGPU, les reviewers ont reçu leurs cartes il y a seulement quelques jours et se concentrent sur les jeux parce que c'est ce qui intéresse la majeure partie de leur public. Les tests en GPGPU viendront plus tard.

    Et effectivement, la conso de taré (malgré le TDP mensonger)... non merci !

  17. #377
    Ca va limiter grandement les boitiers capable d'accueillir un sli pour du gpgpu
    De plus la température élevé en charge est pas bonne du tout pour du calcul h24, voir la première série des gtx280 qui avaient une espérance de vie assez courte sous F@H.

    j'ai du mal à comprendre le positionnement de cette carte, mi calcul, mi gaming, 100% chère du coup.

  18. #378
    Citation Envoyé par newbie06 Voir le message
    Je me faisais la même réflexion sur le GPGPU. Mais il va sans doute falloir attendre un peu parce que si j'ai bien compris un des avantages majeurs est la présence de sauts indirects, qui demandent une exploitation spécifique non ?
    Ça ne me parait pas le plus important/urgent les sauts indirects... Les fonctions virtuelles, c'est bien pour du Java haut niveau, mais pour des boucles de calcul pour le HPC / multimédia ça me semble hautement dispensable. Il y a encore plein de problème bien plus urgents à régler dans CUDA...

    Comme avantage majeur potentiel, je verrai plutôt le cache L1 qui devrait permettre d'implémenter une pile avec des perfs raisonnable, ce qui permettra à terme de définir une ABI et de supporter le concept de... procédure.
    Oui, on en est là.

    Quant à la conso, clairement ça chie, c'est pour moi rédhibitoire. Et le bruit aussi. Et la température. A part ça, je m'attendais à des performances en jeu plus pourries, mais ce n'est pas le sujet
    Si, il y a des chances que les 2 soient liés. Si l'on en croit Charlie, la tension aurait été poussée jusqu'à la limite du raisonnable pour que les cartes restent compétitives (oui, ça fait un grand 'si'). Coïncidence ou pas, 300W c'est la limite de la norme PCIe...
    Quelqu'un à mesuré/récupéré la tension en load?

    À la limite ce qui est inquiétant c'est la conso idle, alors que le tension devrait être réduite au minimum et plein de composants clock- voire power-gatés...

    [Edit: dommage pour Charlie, 1,01V contre 1,15V pour la Radeon 5870, ça reste raisonnable:
    http://ht4u.net/reviews/2010/nvidia_...80/index10.php
    C'est la tension idle qui craint plus...]

    Citation Envoyé par Alexko Voir le message
    C'est normal qu'il n'y ait presque rien en GPGPU, les reviewers ont reçu leurs cartes il y a seulement quelques jours et se concentrent sur les jeux parce que c'est ce qui intéresse la majeure partie de leur public. Les tests en GPGPU viendront plus tard.
    Oui je sais, c'était plus une perche lancée aux reviewers qui lisent le forum.


    Citation Envoyé par hellsing Voir le message
    Ca va limiter grandement les boitiers capable d'accueillir un sli pour du gpgpu
    De plus la température élevé en charge est pas bonne du tout pour du calcul h24, voir la première série des gtx280 qui avaient une espérance de vie assez courte sous F@H.

    j'ai du mal à comprendre le positionnement de cette carte, mi calcul, mi gaming, 100% chère du coup.
    Les GeForce ne visent que le marché grand-public : gaming (avec DX 11 et PhysX) et multimédia. F@H n'en fait pas partie.
    Le GPU par contre est le même pour le HPC.
    Mais les cartes Tesla sont en général downclockées, sous-voltées et autres cherry-pickées.
    Celle basée sur Fermi a une conso "typique" de 190W et fournit officiellement entre 1040 et 1260 Gflops, contre 1345 pour la GTX 480.
    Dernière modification par Møgluglu ; 28/03/2010 à 06h11.

  19. #379

  20. #380
    Hu c'est très mauvais ça. Problème de driver ?

  21. #381
    Si ma mémoire est bonne, Charlie a en fait dit l'inverse : que NVIDIA voulait une tension très faible, et que du coup ils ont dû augmenter l'intensité (ça me paraît un peu trop simple, mais j'y connais rien) et que par conséquent, s'ils doivent augmenter la tension avec la granularité qu'ils ont, la consommation monte très vite parce que l'intensité est élevée. Pour le coup ça me paraît fumeux mais effectivement, la tension est basse.

    D'après Damien, les performances en DP sont limitées par les drivers sur les GTX, pour ne pas faire de l'ombre aux Tesla, donc ça explique les mauvaises perfs en DP sur le bench ci-dessus.

    Edit : "Emulated results using 32-bit float are uses due to lack of native double (64-bit) floating-point support in OpenCL drivers." Donc en fait, va savoir ce que la GTX 480 peut faire en DP...

    Quelle est l'unité du résultat SP ? Ça ne peut pas être des GFLOPS, la GTX 480 serait au-dessus de son maximum théorique. Score synthétique ?
    Dernière modification par Alexko ; 28/03/2010 à 15h09.

  22. #382
    Sandra passe par CUDA/ATI_Stream ou par OpenCL

  23. #383
    Dans ce bench-là, c'est ATI Stream (CAL) et "C for CUDA".
    C'est marqué dans le titre et les résultats collent bien:
    http://www.sisoftware.net/?d=qa&f=gpu_opencl

    L'unité est le MPixel/s, whatever that means...

    Le plus drôle, c'est que les Radeon sont 75% plus rapides sous OpenCL que sous CAL, donc même les résultats d'ATI sont du n'importe quoi.

    Citation Envoyé par newbie06 Voir le message
    Hu c'est très mauvais ça. Problème de driver ?
    Je dirais, problème de codepath CUDA qui n'a pas été mis à jour depuis le G92 au motif que la version portable OpenCL offrait des perfs comparables voire supérieure... Donc je dirais mauvais benchmark, faudrait voire la version OpenCL...

    Citation Envoyé par Alexko Voir le message
    D'après Damien, les performances en DP sont limitées par les drivers sur les GTX, pour ne pas faire de l'ombre aux Tesla, donc ça explique les mauvaises perfs en DP sur le bench ci-dessus.
    Ah y'en a quand-même qui suivent!

    Personne pour lancer un petit cublasSGEMM et cublasDGEMM sur des matrices 1024x1024?
    Il va falloir les tests plus en profondeur de Damien et de Rys et Arun de Beyond3D...

  24. #384
    Le probleme est que les courants de fuite augmentent exponentiellement avec la temperature. Ca varie suivant les process, mais grosso modo c'est 5x pour de 0 a 100C alors que rien que de passer de 90C a 100C les augmente d'un facteur 2.

    En gros les watts au dessus du TDP c'est probablement que du leakage...

    Alexko, tu ne controles pas l'intensite, tu ne controles que le voltage. Bien entendu si tu augmentes la conso a iso voltage tu vas augmenter l'intensite et ca demande un etage de power delivery plus complexe, cher et qui en general dissipe plus.

    Dans les benchs d'Anand c'est clair que Fermi est plus efficace pour le GPGPU que Tesla, mais c'est surtout la difference avec AMD et leur VLIW qui est impressionante. Le rapport entre FLOP utile te Peak FLOP devient assez bon.
    Dernière modification par fefe ; 29/03/2010 à 18h53.
    fefe - Dillon Y'Bon

  25. #385
    Citation Envoyé par fefe Voir le message
    En gros les watts au dessus du TDP c'est probablement que du leakage...
    Ah forcément, si on mesure le TDP sous refroidissement LN2...

    Alexko, tu ne controles pas l'intensite, tu ne controles que le voltage. Bien entendu si tu augmentes la conso a iso voltage tu vas augmenter l'intensite et ca demande un etage de power delivery plus complexe, cher et qui en general dissipe plus.
    J'ai l'impression que ce dont Charlie (et Alexko) parlait, c'est de tuner le process pour favoriser le fonctionnement à basse tension aux dépends du scaling en tension-fréquence. (faut que je retrouve l'article)

    Sinon, un article de Charlie raisonnable et même pas scandaleux sur le binning, pour changer :
    http://www.semiaccurate.com/2010/03/...-hacked-gtx480


    Dans les benchs d'Anand c'est clair que Fermi est plus efficace pour le GPGPU que Tesla, mais c'est surtout la difference avec AMD et leur VLIW qui est impressionante. Le rapport entre FLOP utile te Peak FLOP devient assez bon.
    Je doûte que les perfs sous-optimales de Cypress soient dues au VLIW. Le compilo commence à être bien tuné depuis le temps, et sur du code à forte densité arithmétique il se débrouille bien (crypto et algèbre linéaire dense). Par contre j'ai l'impression qu'ils ont encore des gros problèmes de perf au niveau de la hiérarchie mémoire GPGPU...
    (Bien qu'il y ait eu des gros progrès entre le RV770 et Cypress comme le montre les bench d'Anand.)

    Et surtout, toutes les couches logicielles font aussi la différence, pas juste le back-end du compilo...

  26. #386
    Pour revenir sur le power, une carte de 250W a en general entre 180 et 200W sur le GPU et 50 a 70W sur la carte (voltage regulators, GDDR etc...). L'optimisation typique choisi a la production est souvent aux alentours de 2/3 de power dynamique et 1/3 de leakage. Ca fait donc 60-70W de leakage du GPU dans ce qui je pense etait leur target de 250W. Si tu augmentes la temperature un peu trop et te prend 2x le leakage tu te retrouves dans les 300W. L'autre option est qu'ils ont du decaler le point d'optimisation du process pour obtenir plus de vitesse (en general tu te prends 2x le leakage pour quelque chose comme 15% de gain de frequence). Vu que c'est a peu pres la difference avec le 5870 ca peut paraitre une explication raisonable.


    Pour les optimizations du process a basse tension, c'est une bonne idee pour reduire le power, si de l'autre cote ton design a des problemes de timing et que tu dois le pousser ca te feras plus de mal que de bien, mais la cause du probleme est plus un design qui a des problemes de timing que la maniere de target le process (en pratique tu as beaucoup de flexibilite entre leakage et vitesse/voltage pour un process donne donc tu peux choisir assez tard ce que tu sacrifies).

    Pour Cypress vs Fermi, meme en dehors du GPGPU, tu as une difference de puissance de calcul crete tres importante pour des differences mineures de eprf au final. Ca ne peut pas etre lie que a la hierarchie memoire pour le GPGPU vu que ca se produit meme pour la 3D (et leur archi est sensee etre tunee autour de ca).
    fefe - Dillon Y'Bon

  27. #387

  28. #388
    Tiens encore des features activables par fuse ? L'ECC je veux bien que ce soit pour les cartes de calcul, mais le double precision il doit y avoir une raison plus terre a terre: genre ca doit reduire les yields ou depasser le budget power/current delivery. Parce que tu desactive rarement une des features phare d'un produit sur la version haut de gamme de celui-ci...
    fefe - Dillon Y'Bon

  29. #389
    La restriction des DP ne serait pas plutot faite au niveau des drivers/BIOS plutot que par fuse ?

  30. #390
    Ca serait d'une stupidite redoutable: quelqu'un va forcement trouver comment le reactiver...
    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
  •