Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 10 sur 22 PremièrePremière ... 2345678910111213141516171820 ... DernièreDernière
Affichage des résultats 271 à 300 sur 658

Discussion: Archi GPU et GPGPU

  1. #271
    Intel les rachetera pour utiliser la techno dans LRB 2.

  2. #272
    Du NV40 à Fermi, avec tout plein de zolies jimages :

    http://pc.watch.impress.co.jp/docs/c...23_323529.html

    Si on compte les bubulles dans le pipeline, on voit que :
    - Le taux d'utilisation max des unités (débit de dispatch des instructions / nombre d'unités) diminue.
    - Le nombre de threads / unité diminue. On reboucle plus souvent sur les mêmes threads, donc soit le pipeline et la latence mémoire sont plus courts, soit il y a plus de mécanismes pour exploiter l'ILP (à commencer par le cache), soit le taux d'utilisation effectif diminue.

    En continuant à spéculer sauvagement, le communiqué de Patterson indique le passage d'un jeu d'instruction complexe à un jeu d'instruction RISC load/store, ce qui pour moi veut dire qu'il faudra plus d'instructions pour faire le même boulot... Donc perfs plus faibles à IPC égal.

  3. #273
    Donc IPC superieur sinon c'est foutu

  4. #274
    plus d unites tu veux dire
    fefe - Dillon Y'Bon

  5. #275
    Mais si on met plus d'unités et qu'on veut conserver le ratio calcul/mémoire, on a besoin de plus de ports à un niveau ou un autre de la hiérarchie mémoire...
    ce qui fait augmenter la latence mémoire moyenne.

    Et pour masquer cette latence mémoire, il faut avoir plus de threads en vol par core, sinon l'IPC est limité par la latence et c'est plus un GPU.
    Et donc les many-core à mémoire partagée ça scale pas.

    C'est un truc dont je suis persuadé et que j'essaie de montrer/quantifier depuis un moment. Mais c'est pas facile de trouver des chiffres.

    Dans ma todo list, il y a : coder un microbenchmark de mesure de latence en OpenCL et faire un appel à volontaires chez les canards pour tester ça sur tous les GPU des 3 dernières années pour essayer de dégager une tendance...
    Parce qu'une tendance avec 3 points c'est pas ça.

  6. #276
    Si tu fais un truc qui tourne sous Linux, je pourrai le tester sur ma GTX275 (mais pas en OpenCL, sauf si t'attends que ça soit dispo en package pour F11, je suis une flemmasse ).

    Et pour me remercier, tu m'expliqueras la blague de l'engineer.

  7. #277
    J'ai un sacre packet de CG sur mon bureau donc si ton truc tourne sous windows et que je trouve le temps je peux essayer de contribuer a la science .
    fefe - Dillon Y'Bon

  8. #278
    nvcc suffit, donc ça devrait aller

  9. #279
    Citation Envoyé par newbie06 Voir le message
    nvcc suffit, donc ça devrait aller
    Ouep, mais nvcc à encore quelques petits soucis de compatibilité avec les GPU AMD (et autres...), il parait.

    Merci newbie et fefe pour votre contribution à la Science...

    Chez NVidia il y a clairement eu une augmentation de la latence entre le G80 et le GT200. C'est assez flagrant dans la gamme Tesla (mais la mémoire est passée de 1.5 à 4 Go avec une fréquence moindre aussi). C'est partiellement compensé par la hausse des fréquences, mais en gros l'augmentation serait de l'ordre de 5-10% par génération (G80, G92, GT200).

    (Sur CPU, la latence baisse de quelques % par an en moyenne, non?)

    Dans le haut de gamme "consumer" avec GDDR3, ça reste entre 320 et 350 ns.
    Par contre les cartes apacher avec DDR2 (8500 GT) ont une latence énorme (530ns).
    Ça montre que l'archi est optimisée seulement pour le HDG, et qu'on se contente de copier-coller en baissant les fréquences pour faire le BDG...

    Wanted : une GeForce 8800 GTX originale pour avoir un vrai point de référence. Si j'ai bon, la 8800 Ultra devrait détenir le record de latence, avec la GTX pas loin derrière.

  10. #280
    La machine sur laquelle je compte tester a une 8800GTX premiere generation dessus en ce moment...
    fefe - Dillon Y'Bon

  11. #281
    Citation Envoyé par Møgluglu Voir le message
    Mais si on met plus d'unités et qu'on veut conserver le ratio calcul/mémoire, on a besoin de plus de ports à un niveau ou un autre de la hiérarchie mémoire...
    ce qui fait augmenter la latence mémoire moyenne.
    La seule chose qui importe c'est le rapport calculs executes/memoire. Si tu ajoutes des unites et les utilises moins efficacement tu n'as pas besoin d'augmenter ta bande passante memoire. Bien entendu ca te rajoute de la bande passante sur ton reseau d'interconnexion.

    En revanche pour ajouter des unites tu es oblige de descendre la frequence si ton budget power est limite: donc tu ajoutes on va dire 30% d'unites pour masquer une baisse de 20% d'IPC et tu descend la frequence et le voltage de 10% ce qui te gagne 30% de power. Baisser la frequence sans changer d'archi augmente ta latence si tu as beaucoup de cycles (en allant vers ta memoire) dans le domaine de frequence que tu viens de reduire.

    Et pour masquer cette latence mémoire, il faut avoir plus de threads en vol par core, sinon l'IPC est limité par la latence et c'est plus un GPU.
    Et donc les many-core à mémoire partagée ça scale pas.
    Et oui tu as ajoute pas mal de cores donc tu finis par ajouter plus de threads et de stockage dans tes buffers (ou a mieux partager l'espace de buffer entre threads) pour pouvoir recouvrir la latence memoire. C'est la meme chose sur CPU (pour les applis server) d'ailleurs. Pour tes buffers vu qu'en general ils sont accoles aux unites de calcul' en augmentant de 30% tes unites de calcul tu as ajoute 30% d'espace de buffer, et tu ajoutes 30% de threads en plus. Et Voila .

    Bien entendu c'est horriblement simplifie parce que je parts du principe que tous les threads qui tournent sont homogenes et que ajouter de la bande passante sur le reseau d'interconnexion (le switch ou le ring ont plus d'agents) est simple...
    fefe - Dillon Y'Bon

  12. #282
    Citation Envoyé par Møgluglu Voir le message
    Wanted : une GeForce 8800 GTX originale pour avoir un vrai point de référence. Si j'ai bon, la 8800 Ultra devrait détenir le record de latence, avec la GTX pas loin derrière.
    J'ai une GTS640 sous Vista 64
    Mes propos n'engagent personne, même pas moi.

  13. #283
    C'est un peu passé inaperçu, mais S3 annonce que sa nouvelle puce embarquée est compatible OpenCL.
    Vu qu'elle est basée sur la même puce que les Chrome 400/500 on peut espérer que ces dernières deviennent compatibles.
    Bon en même temps vu le nombre de personnes qui ont pu avoir une de leur carte entre les mains

  14. #284
    Citation Envoyé par Narm Voir le message
    Bon en même temps vu le nombre de personnes qui ont pu avoir une de leur carte entre les mains
    Et un de leurs drivers...

    OpenCL ne demande rien de spécial en matériel en plus de DX 10.1 (à part un accord pour utiliser les brevets de Nvidia), par contre pour écrire le driver/JIT c'est une autre histoire...

  15. #285
    Mais OpenCL c'est pas un langage pour le GPGPU gratos supporté par le groupe Kronos ?

    Sinon j'ai eu une 440GTX entre les mains : les drivers ne sont pas aussi pourris que je le pensais

  16. #286
    OpenCL est largement inspiré de Cuda si je me rappelle bien, Nvidia ayant été un des principaux contributeurs de ce standard. C'est d'ailleurs un des reproches qui lui a été fait. Bon faut dire qu'à l'époque ATI avec son CTM était pas au top. Il se rattrape maintenant avec DX11.

  17. #287
    Ouep, en gros OpenCL est la standardisation a posteriori de CUDA, et le Compute Shader de DX11 est la standardisation de CAL d'AMD.

    Comme ça au lieu d'avoir 2 API propriétaires on a 2 standards, ça change tout.

  18. #288
    Il y avait 2 API proprietaires et 1 standard (j'ignore volontairement OpenGL), maintenant il y a 2 standards , ca va quand meme dans le bon sens...
    fefe - Dillon Y'Bon

  19. #289
    DirectX et standard côte à côte, vous me foutez la gerbe

  20. #290
    C'est un standard de facto... D'ailleurs je ne serais pas supris qu'à terme, Direct Compute soit bien plus utilisé qu'OpenCL, un peu comme Direct3D et OpenGL.

  21. #291
    Pour qu'un truc soit un standard, il faut un machin genre spec implémentables partout ?
    Mes propos n'engagent personne, même pas moi.

  22. #292
    Ouai, et c'est exactement pour ca que ca me fout la gerbe. Comme le x86 est le standard de facto, comme Windows est le standard de facto, comme ARM est le standard de facto en telephonie.

    Je vais me reprendre un cafe

    ---------- Post ajouté à 10h27 ----------

    Citation Envoyé par Neo_13 Voir le message
    Pour qu'un truc soit un standard, il faut un machin genre spec implémentables partout ?
    Pour moi un standard, c'est au moins une masse critique de competiteurs qui se mettent d'accord.

  23. #293
    Citation Envoyé par newbie06 Voir le message
    Je vais me reprendre un cafe
    Noir avec un sucre, pour moi, stp.
    Mes propos n'engagent personne, même pas moi.

  24. #294
    Pas de sucre pour moi...
    fefe - Dillon Y'Bon

  25. #295
    C'est à cette heure là qu'on se lève ?
    Pfuu...

    Il fait déjà nuit chez nous.

  26. #296
    Et encore, là c'est bien parce qu'il est une semaine à la bourre pour le changement d'heure, d'habitude je suis sûr qu'il se lève encore plus tard.

  27. #297
    Ha, je vous surprends à tirer des conclusions sur une heure de levée sans rien pour l'étayer : on ne prend pas de café uniquement au lever.

    Si le reste de vos commentaires est tout aussi infondé, je vais plus viendre ici moi.

    Je suis passé au paracétamol, ça a moins de goût que le café, mais ça me soignera ptet au moins

    Et pour pas faire 100% hors-sujet : http://www.pcinpact.com/actu/news/53...-fps-19539.htm

  28. #298
    Oui j'arrive au boulot a l'heure a laquelle vous en partez grosso-modo .
    fefe - Dillon Y'Bon

  29. #299
    C'est cool par chez toi, ça veut dire que t'arrives à 10h

  30. #300
    J'ai dit grosso modo, j'arrive vers 7h30...
    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
  •