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

Discussion: Archi GPU et GPGPU

  1. #511
    Citation Envoyé par fefe Voir le message
    Tu oublies, 50+ stack X-87 !!!
    Han ! Et les instructions 16-bit, elles y sont j'espère, sinon l'univers va s'effondrer !

  2. #512
    Ben oui, la voute celeste reste solidement ancree dedans .
    fefe - Dillon Y'Bon

  3. #513
    Cool, on va pouvoir utiliser un BIOS standard pour démarrer, ouf

  4. #514
    Et booter DOS
    fefe - Dillon Y'Bon

  5. #515
    Citation Envoyé par Møgluglu Voir le message
    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.
    Donc ils parieraient sur une latence moyenne plus faible qu'avant, notamment grâce aux caches ?

    Citation Envoyé par Møgluglu Voir le message
    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.
    AMD a peut-être une super technique secrète qu'ils ont soigneusement cachée au monde entier…

    Citation Envoyé par Møgluglu Voir le message
    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.
    Oui, et comme l'architecture Southern Islands est capable de gérer N primitives par cycle (selon la configuration) et dispose d'un cache L2 R/W, il y a des chances qu'elle soit égale ou un poil meilleure que Fermi pour la tessellation. Donc NVIDIA va nous dire que la tessellation n'a pas grande importance et que ce qui compte, dans la vie, c'est PhysX ! :D

    Citation Envoyé par fefe Voir le message
    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.
    C'est la question que je me suis posée quand j'ai lu les news : y a-t-il toujours des TMUs, des ROPs, etc. ? Ou du moins, l'architecture est-elle prévue pour en accueillir ?

    Parce que quand on pense au marché grand public, Intel devra prendre une décision sur le GPU à intégrer dans les APU de 2013 et plus — bon, la décision a probablement déjà été prise, mais on ne la connaît pas. Si c'est du Knights, ça veut dire que c'est toujours un GPU, ou du moins assez modulaire pour accueillir du hardware dédié aux graphismes. Si c'est une évolution du GPU actuel de Sandy, ça veut dire qu'Intel ne s'intéresse pas à OpenCL pour le marché grand public… ou a l'intention d'améliorer son iGPU pour le compute. Mais dans ce cas, pourquoi ne pas utiliser Knights ? Drôle de situation…
    Mon blog (absolument pas à jour) : Teχlog

  6. #516
    Je ne comprends pas ton commentaire sur OpenCL et Sandy Bridge.
    fefe - Dillon Y'Bon

  7. #517
    Intel fait du OpenCL sur les GPU, comme nVidia fait du PhysX sur les CPU

  8. #518
    Citation Envoyé par Alexko Voir le message
    Donc ils parieraient sur une latence moyenne plus faible qu'avant, notamment grâce aux caches ?
    Ou bien sur une exploitation de l'ILP au moins aussi bonne qu'avant pour masquer les latences.

    Citation Envoyé par newbie06 Voir le message
    Intel fait du OpenCL sur les GPU, comme nVidia fait du PhysX sur les CPU
    En théorie, les GPU d'Intel devraient pouvoir faire tourner OpenCL sans trop de difficulté... Mais en pratique non, et j'ai l'impression que le GPGPU est tout sauf une priorité pour Intel (c'est pas du x86, donc ça peut pas marcher )

    OpenCL sur AVX, par contre, c'est activement développé. Un quad-core avec AVX a une puissance de calcul pas totalement ridicule par rapport à un GPU intégré. Et il est potentiellement plus efficace sur du code qui n'est pas tuné pour GPU.

    Le processeur Intel généraliste de la roadmap du futur serait un multi-core x86 avec vecteurs larges et un GPU juste pour le rendu graphique?

  9. #519
    Si tu actives OpenCL sur l'iGP tu tues l'interet d'AVX (sauf en double precision) et nuit a l'image de marque du x86 .
    fefe - Dillon Y'Bon

  10. #520
    Citation Envoyé par fefe Voir le message
    Je ne comprends pas ton commentaire sur OpenCL et Sandy Bridge.
    C'est de ma faute, c'était pas très clair. Je veux dire par là qu'Intel ne semble pas spécialement intéressé par le GPGPU (en pratique, surtout via OpenCL) sur Sandy Bridge, ce qu'à vrai dire on peut comprendre quand on voit la part de silicium allouée au GPU. N'empêche qu'à peu près tout le monde est d'accord pour dire que le computing hétérogène, c'est l'avenir du futur, donc je vois deux options pour Intel sur leurs APU — pour une fois qu'un terme marketing est à peu près cohérent, autant l'adopter — grand public s'ils veulent aller dans cette direction :

    — Mettre des cores de type Knights, ce qui implique que l'architecture soit effectivement un GPU, parce qu'il faut que ça tienne la route dans les jeux face à Fusion, ou du moins relativement bien adaptée.
    — Conserver l'architecture du GPU actuel de Sandy Bridge, qu'il faudra bien développer, améliorer et adapter à la fois pour les graphismes et pour le compute si Intel souhaite qu'elle soit compétitive avec celles d'AMD et NVIDIA… Auquel cas, pourquoi ne pas opter directement pour Knights, si c'est pour se retrouver avec deux architectures parallèles, compute-friendly, et plus ou moins proches d'un GPU ?

    Edit : ah, et la troisième option, si Knights n'est vraiment pas un GPU du tout, serait d'avoir à la fois des cores CPU, GPU dérivés de ce qu'on trouve actuellement dans Sandy, et Knights… Mais question optimisation du budget silicium, c'est pas la joie.
    Mon blog (absolument pas à jour) : Teχlog

  11. #521
    Il faudrait que le concept de Larrabee soit suffisament bon pour la 3D pour qu'ils remplacent leur GPU integres. Parce que meme si le computing heterogene c'est l"avenir du futur" les utilisations actuelles d'un GPU sont surtout pour du rendu graphique aujourd'hui et pas pour du computing heterogene en dehors du marche limite du HPC. Cela va peut etre changer, mais on nous annoncait deja ca quand le Cell est sorti et on attend encore. La seconde utilisation dans les APU est pour l'instant du transcodage video, pour lequel des accelerateurs hard sont deja disponibles et font le meme boulot pour une fraction du power.
    fefe - Dillon Y'Bon

  12. #522
    Alexko> Pour l'Atom Intel a opté pour une toute autre solution : abandonner le GMA au profit d'un PowerVR (le SGX545, avec support d'OpenCL 1.0).
    Mais est-ce que ce genre de solution est transposable sur Desktop, j'en sais rien du tout

  13. #523
    Si tu regardes de pres ce n'est pas un abandon: il n'y a jamais eu de SOC Atom avec "Gen". La seule raison pour laquelle il y a eu des GMA avec Atom est la reutilisation de chipsets existants .
    Dernière modification par fefe ; 22/06/2011 à 20h23. Motif: Replaced GMA by "Gen"
    fefe - Dillon Y'Bon

  14. #524
    I am tout perdu là... GMA recouvre à la fois des trucs faits par Intel en interne des trucs faits par Imagination. Et à ma connaissance il existe exactement zéro SoC Atom sur le marché (au sens ARMesque du terme). En plus le Z600 a bien un PowerVR sur le chip principal et pas dans le PCH, non ?

  15. #525
    Vaguement hors-sujet, mais l'IGP HD 3000 semble avoir quelques soucis de qualité : http://techreport.com/articles.x/21099/11

  16. #526
    Es tu surpris que le GPU d'intel ressemble a un GPU d'ATI d'il y a 5+ ans ?
    fefe - Dillon Y'Bon

  17. #527
    Oui, je suis surpris, je reste un grand naïf

    Je me demandais si ça pouvait avoir un impact sur certaines options des effets bureau de Windows ou autre. Si ce n'est pas le cas, ça n'est pas bien grave, de toute façon 'l'IGP n'est pas fait pour jouer.

  18. #528
    Normalement tout ce qui est utilise par windows est l'objet de la certification WHQL. C'est assez strict et si tu passes ca veut dire que tu fais ce que Microsoft veut que tu fasses. Le GPU de Sandy Bridge passe la certification donc a priori il ne devrait pas y avoir de problemes.
    Essayer de jouer avec du filtrage trilineaire et anisatropique 16x sur un GPU integre c'est un peu du masochisme (je doute qu'il existe un jeu recent jouable en HD avec ce genre de settings sur un HD3000). Apres c'est evident que ce genre de problemes devrait faire l'objet de correctif dans l'hypothese qu'un jour Intel arrive avec un GPU integre suffisament puissant pour permettre de jouer a des jeux PC recents.

    Soit dit en passant, les perfs derniers IGP Intel et AMD depassent celles des GPUs de la PS3 et de la XBOX, donc ce n'est pas impossible de jouer dessus ... Il ne faut pas etre trop exigeant c'est tout.
    fefe - Dillon Y'Bon

  19. #529
    Citation Envoyé par fefe Voir le message
    Soit dit en passant, les perfs derniers IGP Intel et AMD depassent celles des GPUs de la PS3 et de la XBOX, donc ce n'est pas impossible de jouer dessus ... Il ne faut pas etre trop exigeant c'est tout.
    Beuuuuuuh ! Nan le GPU de la PS3 c'est en gros une 7900 GT si je me souviens bien, donc :
    Code:
                             HD3000 1350 MHz     HD7900 GT
    vertex shaders           12                  8
    ROPs                     2                   16
    textures/clock           4                   24
    pixel shaders            12                  24
    pixel fill rate MP/s     1700-2700           7200
    texture fill rate  MT/s  3400-5400           10800
    mem BW  GB/s             10.7                42.2
    Ref : http://www.techarp.com/showarticle.aspx?artno=88

  20. #530
    Tu ne te souviens pas bien

    Sandy Bridge, 2 channels DDR1600 = 25.6GB/s shared with CPU, je ne sais pas d'ou tu sors ton 10.7 ... Ca fait 1 channel de DDR1333 alors que tu as 2 channels

    Texture/Vertex Memory Bandwidth
    Xbox 360 - 22.4 GB/sec (shared with CPU)
    PS3 - 20.8 GB/sec (shared with frame buffer)


    Un peu moins de 2x le throughput de pixels pour les consoles au final
    Pixel Fill Rate without Anti-Aliasing
    Xbox 360 - 4.0 Billion Pixels/sec (8 ROPS x 500MHz)
    PS3 - 4.0 Billion Pixels/sec (8 ROPS x 500MHz)

    Filtered Texture Fetch
    Xbox 360 - 8.0 Billion Texels/sec
    PS3 - 12.0 Billion Texels/sec

    Si tu comptes les shaders en additionnant les vertex et pixel shaders pour ta 7900 GT multiplie par la frequence, tu arrives grosso modo au meme nombre de flops shaders que le HD3000.

    Donc bande passante equivalente, a peu pres la meme quantite de shaders, un peu moins de pixels, un cpu beaucoup plus performant. Tous les programmeurs a qui j'ai parle m'ont dit que Sandy Bridge aurait la meme perf que la PS3 si le driver n'etait pas aussi merdique .
    fefe - Dillon Y'Bon

  21. #531
    Arf, si à hardware égal, les PC étaient au niveau des consoles, ça se saurait ! Heureusement que le hardware est généralement très supérieur.
    Mon blog (absolument pas à jour) : Teχlog

  22. #532
    Citation Envoyé par fefe Voir le message
    Sandy Bridge, 2 channels DDR1600 = 25.6GB/s shared with CPU, je ne sais pas d'ou tu sors ton 10.7 ... Ca fait 1 channel de DDR1333 alors que tu as 2 channels
    J'ai filé ma source Le 10.7 semble correspondre au 1350 MHz du HD3000 avec un bus data 64-bit. Toi tu parles de la capacité totale du chip. T'es certain que le HD3000 a accès à tout ça ?

    Tous les programmeurs a qui j'ai parle m'ont dit que Sandy Bridge aurait la meme perf que la PS3 si le driver n'etait pas aussi merdique .
    C'est vraiment lamentable...

    De toute manière Alexko a raison. Les dév console se fichent un peu des drivers, ils tripotent le HW en direct ou à travers une couche très fine.

  23. #533
    Citation Envoyé par fefe Voir le message
    Donc bande passante equivalente, a peu pres la meme quantite de shaders, un peu moins de pixels, un cpu beaucoup plus performant. Tous les programmeurs a qui j'ai parle m'ont dit que Sandy Bridge aurait la meme perf que la PS3 si le driver n'etait pas aussi merdique .
    Un Llano, avec son GPU plus performant et son driver correct, pourrait donc servir de base pour une console de jeu ?
    D'ailleurs sur PC, serait-il théoriquement possible de concevoir un jeu ultra optimisé pour un hardware donné (et uniquement 1 seul), avec la même efficacité que sur console ? Si non, qu'est-ce qui l'empêcherait ? L'OS, son modèle de driver, l'API (D3D/OGL), la qualité du driver, autre chose ?

    Citation Envoyé par newbie06 Voir le message
    C'est vraiment lamentable...

    De toute manière Alexko a raison. Les dév console se fichent un peu des drivers, ils tripotent le HW en direct ou à travers une couche très fine.
    Sur PS3, ils touchent vraiment tous le hardware de près, ou ils utilisent plus généralement un middleware ultra-optimisé ? (vraie question)

  24. #534
    Citation Envoyé par Foudge Voir le message
    Si non, qu'est-ce qui l'empêcherait ? L'OS, son modèle de driver, l'API (D3D/OGL), la qualité du driver, autre chose ?
    Tout ça l'empêche. En poussant le plus loin possible l'argument, tout software que tu ne maîtrises pas qui se trouve entre toi et le HW te ralentit potentiellement. Mais autant quand on dévelopait sur Atari ST on pouvait s'amuser à tout écrire, autant maintenant c'est devenu difficile et contre-productif la plupart du temps

    Y'avait une page Web dans laquelle un mec d'ATI se plaignait que sur PC l'API ralentissait beaucoup trop face à ce qu'on pouvait faire sur une XBox360. Je ne retrouve plus le lien histoire de changer

    EDIT : Et voilà : http://www.bit-tech.net/hardware/gra...l-to-directx/1

    Sur PS3, ils touchent vraiment tous le hardware de près, ou ils utilisent plus généralement un middleware ultra-optimisé ? (vraie question)
    Apparemment, d'après un dév avec qui j'avais discuté, certains tapent vraiment très bas. D'un autre côté, c'est un furieux et il est probable que la plupart utilisent des MW.
    Dernière modification par newbie06 ; 24/06/2011 à 15h57. Motif: Google Fu

  25. #535
    Vu les donnees de ta source originale, j'arreterais d'y aller ...

    La connection du HD3000 vers la memoire ne se fait pas par un bus 64 bits...
    Tu as un bus de 32 octets tournant a 2x la frequence du GPU qui le connecte au cache de dernier niveau, donc 2.7*32 ~=80GB/s vers le cache de dernier niveau. Apres du cache vers la memoire c'est comme pour tous ceux qui sont connecte au cache, tu peux saturer la bande passante memoire (qui est de 25.6GB/s peak).

    Les couches intermediaires imposees par le driver font pas mal de difference entre les PCs et les consoles, surtout quand ce driver est epais et lourd comme c'est le cas ici . Non seulement tu perds des perf graphique parce que tu n'utilises pas ton hardware au mieux, mais en plus tu gaches le power du CPU a faire des trucs somme toute inutiles.
    fefe - Dillon Y'Bon

  26. #536
    Citation Envoyé par fefe Voir le message
    Vu les donnees de ta source originale, j'arreterais d'y aller ...
    C'est clair Mais en cherchant vite fait, je n'avais pas trouvé d'info sur la connexion du HD sur sur le ring bus, j'ai donc tenté une déduction en partant de chiffres faux, j'ai honte... un peu Merci !

  27. #537
    C'est normal je ne pense pas que ce genre d'info ait vraiment ete publiee en dehors de confs specialisees. Et ca interesse peu de monde au final
    fefe - Dillon Y'Bon

  28. #538
    Pour ceux qui aiment essayer d'aligner des rectangles, Hiroshige Goto a encore frappé en dessinant plein de nouveaux graphes sur les caractéristiques des GPU des ... mettons 8 dernières années:
    http://pc.watch.impress.co.jp/docs/c...26_463041.html


    Une tendance ? Quelle tendance ?



    ATI > Moore

    Je vois un certain nombre d'interprétations possibles à ce dernier graphe à faire rêver un marketeux Nvidia (10x plus de cores que ce que prévoyait la loi de Moore!)...

  29. #539
    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 ).

    La loi de Moore ne parle pas de calculs SP Il aurait plutot fallu un graphe avec le nombre de transistors, non ?

    Si on rapproche les deux graphes, on se rend compte que la densite de calcul SP d'ATI est bien plus haute (ouai, tout le monde doit savoir ca).

  30. #540
    Ce serait d'ailleurs utile de rappeler la fameuse loi de Moore, ou plutôt celle qui a été utilisée pour leurs calculs, tellement cette "loi" a été triturée dans tous les sens pour essayer de coller à la réalité ou à ce qu'on a envie de montrer.
    Là on dirait que ça ressemble à "Le nombre de FPU double tous les 2ans"
    Dernière modification par Foudge ; 26/07/2011 à 14h27.

Page 18 sur 22 PremièrePremière ... 810111213141516171819202122 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
  •