Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 16 sur 22 PremièrePremière ... 68910111213141516171819202122 DernièreDernière
Affichage des résultats 451 à 480 sur 658

Discussion: Archi GPU et GPGPU

  1. #451
    Citation Envoyé par fefe Voir le message
    Si je cherchais une theorie du complot, je dirais que Larrabee etait juste une diversion pour forcer Nvidia et AMD a mettre trop de hardware generique pour faire de la place a Sandy Bridge mais ca serait probablement crediter Intel de trop d'intelligence...
    Quelle que fusse l'intention, le fait est que ça a très bien marché pour Fermi.

  2. #452
    Je ne sais pas si certains ont suivi Caustic Graphics, mais je trouve ceci très amusant : http://www.semiaccurate.com/2010/12/...stic-graphics/

  3. #453
    Bon, moi je vais parler de CUDA (un peu) et de Fermi vu que je dois me pencher dessus pour mes études.

    Basiquement, j'ai lu ça sur un whitepaper de chez Nvidia (à propos de Fermi) :

    Citation Envoyé par nvidia
    The Streaming Multiprocessor schedules threads in groups of 32 parallel threads called warps. Each SM features two warp schedulers and two instruction dispatch units, allowing two warps to be issued and executed concurrently. Fermi’s dual warp scheduler selects two warps, and issues one instruction from each warp to a group of sixteen cores, sixteen load/store units, or four SFUs.
    Donc le SM ressemble à ça et donc on remarque assez facilement les 4 groupes d'unités (2x16 cores, 16 l/s, 4 SFUs) dont le papier parle.

    Maintenant, il y a deux warp scheduler, donc si je comprend bien, le SM peut envoyer une instruction des threads du warp n°1 et une instruction du warp n°2, comme ceci.

    La où je suis un peu perdu, c'est que le whitepaper suggère que le scheduler n'envoie une instruction qu'à un seul groupe d'unités, donc finalement il n'y aurait que 16 threads qui sont traités à chaque cycle (au mieux) sur les 32 threads du warp. Alors soit c'est faux et chaque scheduler peut envoyer son instruction à deux groupes d'unités, soit c'est vrai et je vois mal (assez naïvement, je pense) comment Nvidia peut écrire qu'avec cette structure on arrive facilement à faire travailler le maximum d'unités en même temps, mais comme je n'ai pas trouvé plus d'infos que ce qu'il y a dans le papier made in Nvidia (notamment sur la vitesse à laquelle tourne le scheduler par rapport aux unités de calcul), je viens quémander ici. Je sais que dans le GT200 le warp scheduler tournait deux fois moins vite que les unités de calculs, mais après...

    Donc voilà, si l'un d'entre vous pouvait éclairer ma lanterne, je serais gratitude. Ça m'évitera de mettre des énormités dans mon rendu.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  4. #454
    Citation Envoyé par Thamior Voir le message
    Bon, moi je vais parler de CUDA (un peu) et de Fermi vu que je dois me pencher dessus pour mes études.
    Mhah ah ah, encore un padawan qui bascule du côté obscur.

    Je sais que dans le GT200 le warp scheduler tournait deux fois moins vite que les unités de calculs, mais après...
    Oui, c'est pareil sur Fermi.
    Le scheduler et tout ce qui n'est pas les unités de calcul dans le SM tourne à la moitié de la fréquence "shader". (Mais ce shader/2 n'est pas forcément la même que la fréquence "core".)
    Donc en 1 cycle de scheduler, chaque SP CUDA Core a le temps de démarrer 2 calculs.

    Le corollaire, c'est qu'il est plus facile de faire 2 schedulers à 750 MHz qu'un seul à 1,5 GHz, alors que pour les pipelines de calcul c'est le contraire.

    En fait, je suis persuadé que si Nvidia avait prétendu avoir 1024 unités à 750MHz plutôt que 512 à 1,5GHz, ça aurait été plus simple à expliquer pour tout le monde et il n'y aurait pas eu grand-monde capable de se rendre compte de la supercherie.

  5. #455
    Je vois, mais la question était plus simplement si le scheduler schedulait (Du verbe scheduler) les warps entier ou par paquet de 16 threads (donc un demi warp) comme le sous-entend le papier Nvidia (ou en tout cas comme je le comprends).
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  6. #456
    Le whitepaper dit que chaque scheduler sélectionne un warp complet (32 threads), récupère une instruction à exécuter sur ce warp, et envoie l'instruction [et les 32 données sur laquelle elle opère] à un groupe d'unités.

    Ce groupe d'unités peut être les 16 "cores" (pipelines FMA), ou 4 SFUs ("Super Funk Units") ou 16 unités "load/store" (unités de calcul d'adresse).

    Si c'est les cores, ils vont être occupés pendant 2 cycles rapides (=1 cycle scheduler) pour démarrer toutes les calculs. Si c'est les SFU, elles vont être occupées pendant 8 cycles rapides.
    C'est les infos de débits qu'on retrouve dans le CUDA Programming Guide.

    Hop, Goto à la rescousse :


    Les bulles sont les calculs, les lignes horizontales sont les cycles rapides, les flèches rouges sont les actions du scheduler.

    Source : http://pc.watch.impress.co.jp/docs/c...20_343352.html
    Et la comparaison avec le GF104 : http://pc.watch.impress.co.jp/docs/c...12_380148.html (Partiellement inexact ou au moins imprécis. En vrai il n'y a que 2 warps schedulers pour 4 dispatchers sur le GF104.)

  7. #457
    Ah ben voila, c'est nettement plus clair, merci
    Plus qu'à apprendre le chinois.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  8. #458
    C'est pas du Japonais ?
    fefe - Dillon Y'Bon

  9. #459
    Si, si, mais c'est du chinois pour moi
    Ahem.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  10. #460
    Google translate est ton ami
    fefe - Dillon Y'Bon

  11. #461
    Quelques infos sur Tegra 2 (enfin ULP GeForce) chez Anand, pour la première fois il me semble :
    http://www.anandtech.com/show/4098/n...-design-wins/3

  12. #462
    A propos d'Anand, sur sa review de SNB, il fait des tests de transcodage vidéo pour tester QuickSync, et il utilise Media Converter 7 (Arcsoft).

    Le truc c'est qu'il obtient des résultats assez catastrophique (au niveau qualité) avec le transcodage via CUDA sur une GTX460. La question que je me pose c'est de savoir si ça vient du logiciel (est-ce qu'un vieil algo utilisant de la simple précision alors que la GTX460 peut faire de la double précision pourrait aboutir à ce genre de résultat?) ou si quelqu'un a pu reproduire de tels résultats avec d'autres logiciels (Personnellement j'ai une ATI donc je ne peux pas trop tester).

    J'imagine que ça se saurait si c'était si mauvais, mais je suis quand même curieux de savoir.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  13. #463
    Citation Envoyé par Møgluglu Voir le message
    Quelques infos sur Tegra 2 (enfin ULP GeForce) chez Anand, pour la première fois il me semble :
    http://www.anandtech.com/show/4098/n...-design-wins/3
    Ca fait mal au cul de lire ça :
    Architecturally, the Cortex A9 isn’t very different from the Cortex A8. The main change is a move from a dual-issue in order architecture with the A8 to a dual-issue out-of-order architecture with the A9.
    Ca n'a pas de rapport, mais lire une telle ânerie ça me fout en rogne.

    Donc passer en OoO, des pipes de taille inférieure nous amène à pas très différent ? Ils ont besoin d'un cerveau ?

  14. #464
    Citation Envoyé par Thamior Voir le message
    J'imagine que ça se saurait si c'était si mauvais, mais je suis quand même curieux de savoir.
    À ce niveau de craditude de l'image, c'est de l'ordre du bug. Ou alors de la très mauvaise foi des développeurs (qui tiendraient absolument à montrer que le GPU va plus vite quitte à faire un calcul complètement différent).

    Le traitement vidéo, c'est typiquement fait en virgule fixe sur 16 bits, alors avoir de la double précision ou pas ça va pas changer grand-chose.

    Citation Envoyé par newbie06 Voir le message
    Donc passer en OoO, des pipes de taille inférieure nous amène à pas très différent ? Ils ont besoin d'un cerveau ?
    Bah c'est comme un Pentium Pro par rapport à un Pentium, c'est une version un peu plus haut de gamme c'est ça?

    Autrement si la hiérarchie mémoire n'a vraiment pas bougé entre A8 et A9, soit c'était que celle de l'A8 était surdimensionnée, soit c'est un bottleneck sur l'A9?

  15. #465
    Citation Envoyé par Møgluglu Voir le message
    Le traitement vidéo, c'est typiquement fait en virgule fixe sur 16 bits, alors avoir de la double précision ou pas ça va pas changer grand-chose.
    C'est generalement fait sur 16 bits fixed point alors qu'il en faut 17 , raison pour laquelle certains font leurs DCT en flottants (pour les algos qui utilisent des DCT classiques).

    ---------- Post ajouté à 18h05 ----------

    Citation Envoyé par newbie06 Voir le message
    Ca fait mal au cul de lire ça :

    Ca n'a pas de rapport, mais lire une telle ânerie ça me fout en rogne.

    Donc passer en OoO, des pipes de taille inférieure nous amène à pas très différent ? Ils ont besoin d'un cerveau ?
    Ben quoi, t'as pas l'habitude ? Si tu n as pas 15 mots cles super hype pour decrire ce que t'as change, ca veut dire que tu n as rien change...
    fefe - Dillon Y'Bon

  16. #466
    Citation Envoyé par newbie06 Voir le message
    Ca fait mal au cul de lire ça :

    Ca n'a pas de rapport, mais lire une telle ânerie ça me fout en rogne.

    Donc passer en OoO, des pipes de taille inférieure nous amène à pas très différent ? Ils ont besoin d'un cerveau ?
    Franchement, t'es de mauvaise foi, c'est évident que l'A9 n'est pas très différent de l'A8, rien qu'au nom : (9/8) = 1,125, soit +12,5 %. Clairement, c'est pas grand-chose.

    Le vrai changement viendra avec l'A15.
    Mon blog (absolument pas à jour) : Teχlog

  17. #467
    Qui sera probablement suivi par l'A2900 si des gens de marketing ont ete embauches .
    fefe - Dillon Y'Bon

  18. #468

  19. #469
    La grande question pour moi est le type de modele d'utilisation qu'ils visent avec ce projet:
    - carte PCI avec GPU et core ARM dessus
    - remplacement du socket CPU par leur socket CPU + GPU, avec un OS qui tourne sur leur plateforme.

    Dans le premier cas on se demande a quoi vont servir les cores ARM. Je suis sur qu'il y a des taches pour lesquelles ils seront plus efficaces que le GPU, mais de maniere generale je ne suis pas convaincu du benefice par rapport a utiliser le CPU qui est a l'autre bout du PCI.

    Dans le deuxieme, si on omet les histoires de legacy et d'OS en partant du principe qu'ils beneficient de la popularisation d'Android, IOS et compagnie, ils seront en competition directe avec AMD et Intel sur un marche ou les 2 auront des produits depuis 2 ans.
    Je suis pret a croire qu'ils developpent un core ARM haute performance, et probablement qu'ils ont deja quelques annees de boulot dessus. En revanche j'ai des gros doutes qu'ils arrivent a des performances comparables aux cores haut de gamme de Intel et d'AMD. Si il etait si facile de developper un core avec un IPC tres eleve il y en aurait plus sur le marche aujourd'hui. Bien sur il n'y a pas la difficulte d'implementer x86, mais c'est une difficulte uniquement pour un nouvel arrivant: pas pour Intel ni pour AMD qui ont tous les outils necessaires pour rendre la taxe x86 transparente au developement.
    Donc ce a quoi je ne crois pas est qu'une equipe qui fait son premier processeur sorte avec quelque chose d'aussi performant que ce que la competition a mis 15 ou 20 ans a faire. J'ai vu ce genre de promesses de nombreuses fois, et a chaque fois la premiere generation a ete mauvaise, la seconde meilleure, et les boites n'ont rarement eu assez d'argent pour finir leur 3 eme generation vu que les 2 premieres n'avaient pas ete vendues.

    Bien entendu il y a une 3 eme possibilite qui correspond a developper un core pour concurrencer le bas de gamme de AMD et Intel (Atom et equivalents) et les SOC ARM haut de gamme de la competition, ce pour quoi les core ARM existants sont une bonne base. Ca correspond exactement a ce qu'ils font deja avec Tegra et placerait le projet Denver juste comme un successeur de Tegra avec un core maison plutot que d'en licencier un. Pour moi c'est une non-news, si c'est le cas ils font ce qui est a la mode en ce moment qui est de pretendre qu'ils feront mieux que les equipes de ARM pour le developement d'un core performant et honnetement j'ai des doutes que ca soit si facile que ca de battre des equipes experimentees qui tunent leur bebe.

    Au final la 3 eme option me semble la plus probable, et meme si c'est interressant je n'y trouve rien d'exceptionnel: Ils se lancent dans les SOC ARM et essayent de se differencier du reste de la competition pas seulement par leur GPU mais aussi avec le core. Apres je ne dis pas que c'est une mauvaise idee, les core haute performance vont peut etre devenir marginaux et ca peut etre une tres bonne operation financiere pour eux, mais pour l'instant je ne vois rien d'excitant d'un point de vue technologie.
    fefe - Dillon Y'Bon

  20. #470
    Si j'ai tout bien compris, Maxwell est une carte orientée GPGPU non ? lien

    Nulle part je n'ai lu que ce serait une machine en soi, sauf bien entendu que le fait de dire que ça tournera un OS est un petit indice. D'un autre côté, n'est-il pas devenu quasiment nécessaire pour les CG GPGPU ou pas d'avoir un OS embarqué pour s'isoler de manière plus propre de l'hôte ? Ce qui me fait pencher pour une carte PCIexpress pour PC

  21. #471
    Maxwell a été annoncé à une conf de GPGPU, mais il n'y a pas de raison de penser qu'il s'agit d'une gamme distincte. (Exactement comme Fermi.)
    Après rien ne les empêche de réutiliser la même archi pour des GPU seuls dans des GeForce et des CPU+GPU dans des Tesla.

    Officiellement, Denver et Maxwell visent (entre autres) le marché des supercalculateurs. S'ils maintiennent leur progression actuelle dans le Top500, ils seront en position de force en 2013. Ajouter un CPU on-chip permettrait de se débarrasser des processeurs Intel et d'une partie de ce qu'il y a autour. Même si leur CPU est un peu moins performant, au niveau plate-forme ça semble crédible (au moins pour du Linpack ).
    Par contre ça ne suffira pas à amortir la R&D.

    L'autre débouché que je vois serait les consoles de jeu. Pour autant que je sache, la PS3 a été un succès commercial, malgré tous les défauts du Cell. Par comparaison, un CPU ARM avec un GPU Nvidia gérant OpenGL, CUDA et OpenCL (voire Direct3D), c'est du très classique.

    En tout cas je ne pense pas qu'ils se fassent la moindre illusion sur le destin des premières générations du CPU...

  22. #472
    j'ai l'habitude de ne pas me fier aux annonces de marketing sur ce qu'ils comptent faire avec un morceau de silicone, mais plutot regarder ce qui peut etre fait avec .
    fefe - Dillon Y'Bon

  23. #473
    Je me permet de citer une personne qui a posée sa question sur la partie anglaise du forum (qui m'a l'air déserte), puisque je suis curieux de connaître la réponse :

    Citation Envoyé par dadam
    Hi everyone!

    I'm posting here since it seems that the French version of this forum is a restricted area.
    Please excuse me if I'm doing any English mistake.

    So that's my today's epic questioning
    Does anyone knows why GPUs are based on floating point architecture (in opposition to integer) ?
    Nowadays GPUs are used to do some general purpose things so it seems useful that they have FPUs.
    But 5 years ago that was not the case and they were also based on FPUs.
    If I'm not mistaken, some not-so-old GPUs can only add 24bits integers in one cycle (which correspond ~ to the mantissa of a 32bits float).
    FPUs are quite expensive (silicon, ...), so i just don't understand why GPUs are/were full of FPUs and not embed/embedded just more integer units.
    So why do graphic computing (GPUs and everything on top of them) uses floating point ?
    32bits integers (and maybe 24bits) offer in my opinion enough range for storing values (dynamics of 10^9) in most cases, and 64bits is clearly more than enough.

    Is it again only an historical evolution (I imagine old GPUs use float to handle big numbers with short data width (8/16bits)) ?
    Do graphic computations really need huge dynamics and am I totally mistaken here ?
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  24. #474
    Dans le pipeline graphique traditionnel, il y a les calculs géométriques (vertex shader), et les calculs de couleur (pixel shader).

    De mémoire, vers 2002 et Direct3D 8, les pixel shaders étaient calculés en virgule fixe (genre 2 bits de partie entière et 8 de partie fractionnaire), et les vertex shaders en flottant Binary16 (10 bits de partie fractionnaire et 5 bits d'exposant).

    La virgule flottante est "nécessaire" pour les calculs géométriques car il est difficile de calculer a priori l'intervalle des valeurs manipulées. Le produit matrice-vecteur qui est fait peut manipuler de grandes valeurs qui cancellent ensuite, et après on divise par la profondeur. C'est plus simple de tout faire en flottant, et c'était comme ça que c'était fait sur CPU avant que ce soit géré par les GPU.
    Il y a aussi le fait qu'il faille convertir les données si les formats utilisés par le CPU et par les GPU sont différents.

    Pour les calculs de couleur c'est moins évident, mais il y a le rendu HDR qui demande plus de dynamique d'une part, et aussi le fait que les pixel shaders manipulent plein d'autres trucs que des couleurs. Des light maps, des bump maps...

    Enfin, à partir du moment où on unifie les unités de shaders, on n'a plus vraiment le choix...

    De point de vue de l'architecture, le calcul flottant ne coûte pas grand-chose. Ce qui coûte, c'est d'amener les données jusqu'aux unités de calcul et les faire repartir.
    Donc de l'entier 64 bits coûterait globalement plus cher que du flottant 32 bits.

    Sinon, pour l'accès ici :
    http://forum.canardpc.com/showthread.php?t=35031

  25. #475
    Merci pour la réponse.
    Effectivement je n'avais pas penser au surcoût de bande passante nécessaire pour les entiers.

    Concernant le SoC ARM+Nvidia, le segment performance/watt (et pour l'ARM c'est quand même mieux qu'un x86) a quand même de l'avenir à mon avis. Ca ne se limite pas au supercalculateurs et aux game boys. Il y'a aussi le côté serveur qui risque de devenir un marché prometteur pour ce genre de plateforme surtout avec le fameux "cloud" qui est poussé par tout le monde.
    Dam

  26. #476
    Citation Envoyé par dadam Voir le message
    Concernant le SoC ARM+Nvidia, le segment performance/watt (et pour l'ARM c'est quand même mieux qu'un x86)
    Je ne parierais pas là-dessus Et un autre facteur est la perf/mm², là non plus je ne parie pas

  27. #477
    Citation Envoyé par dadam Voir le message
    Merci pour la réponse.
    Effectivement je n'avais pas penser au surcoût de bande passante nécessaire pour les entiers.

    Concernant le SoC ARM+Nvidia, le segment performance/watt (et pour l'ARM c'est quand même mieux qu'un x86) a quand même de l'avenir à mon avis. Ca ne se limite pas au supercalculateurs et aux game boys. Il y'a aussi le côté serveur qui risque de devenir un marché prometteur pour ce genre de plateforme surtout avec le fameux "cloud" qui est poussé par tout le monde.
    Le calcul numerique haute performance est le sous-marche des serveurs ou le flottant est vraiment important (en flops/Watts). C'est d'ailleurs un domaine ou les GPU NVidia ont deja reussi a tres bien penetrer le marche mais c'est un domaine assez difficile. En effet les clients sont prets a reecrir les 3 applications qu'ils font tourner sur leur supercalculateur a chaque fois qu'ils en rachetent un nouveau et se fichent royalement de ce que les autres achetent. C'est un avantage pour prendre des parts de marche rapidement, c'est un inconvenient car tu gardes rarement tes clients.
    La plupart achetent en fonction de la metrique flops / $ (la conso a une influence non negligeable sur le $ mais pas que) histoire de maximiser les flops qu'ils peuvent acheter avec le budget qui leur a ete alloue (tres differents du reste du marche ou ils achetent une certaine puissance de calcul pour le moins cher possible), et profitent des offres genereuses que font les constructeurs quand ils veulent faire la promotion d'une nouvelle architecture (tu fais des soldes pour essayer de penetrer un marche). Le probleme est que les constructeurs ne font pas tous des soldes a chaque generation, et c'est pour ca que en 20 ans il y a eu beaucoup de rotation sur l'archi favorite dans ce domaine.

    Pour le reste du marche des serveurs (la tres grande majorite - celle ou il y a de grosses marges sur la vente du produit), le calcul flottant est relativement moins important, suffisament peu important que beaucoup n'iront pas utiliser un modele de programmation specifique pour leurs besoins en flottant (ils compilent leur appli ecrite dans un langage standard et c'est tout). La fiabilite est quelque chose de tres recherche, aussi bien d'un point de vu materiel que d'un point de vue resistance aux erreurs soft et pour l'instant Nvidia est tres loin de ca (il suffit de regarder combien de temps AMD a mis a convaicre que ces Opterons valaient le coup). Bref tout ca pour dire que Nvidia va avoir pas mal de difficulte a convaincre le reste du marche des serveurs que leurs puces ont un quelconque interet.
    fefe - Dillon Y'Bon

  28. #478
    Espace mémoire unifié et transferts peer-to-peer avec CUDA 4.0 :
    http://www.anandtech.com/show/4198/n...ounces-cuda-40

  29. #479
    Sortie de Molehill, la nouvelle API 3D de FlashPlayer 11

    Ca tourne sur DirectX pour Windows, et sur OpenGL pour *nux et Mac.
    Des frameworks utilisant Molehill commencent à sortir. Par exemple.

    Technically, "Molehill" is a set of programmable shader-based 3D APIs, exposing features like z-buffering, stencil color buffer, fragment and vertex shaders, cube textures and more. "Molehill" will enable developers to leverage the GPU where possible, while providing the flexibility to fallback to a CPU software rasterizer if the hardware is incompatible.

    Today, Adobe Flash Player 10.1, renders thousands of non z-buffered triangles at approximately 30 Hz. With the new 3D APIs, developers can expect hundreds of thousands of z-buffered triangles to be rendered at HD resolution in full screen at around 60 Hz. Using the new 3D APIs in Flash Player and AIR will make it possible to deliver sophisticated 3D experiences across almost every computer and device connected to the Internet.
    Dernière modification par Yasko ; 02/03/2011 à 10h37.

  30. #480

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
  •