Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 8 sur 22 PremièrePremière 1234567891011121314151618 ... DernièreDernière
Affichage des résultats 211 à 240 sur 658

Discussion: Archi GPU et GPGPU

  1. #211

  2. #212
    Quand je vois des speedups de 1 ou 2 ordres de grandeur j'ai tendance a crier au marketing BS . Soit ils n'optimisent pas le code au meme niveau sur les 2 plateformes, soit ils ne font pas tourner la meme chose, soit ils ont fait tourner des micro kernels de quelques instructions qui sont completement hard-wired dans leur engine et bien lentes sur les CPUs.

    D'ailleurs c'est la meme chose pour GPGPU, quand on regarde des codes utiles et bien optimises sur GPU et CPU on est generalement bien loin des speedups d'un ordre de grandeur.

    Ca ne reduit pas l'interet de ce type de hardware, mais j'ai du mal a croire quand quelqu'un annonce des speedups de plus que 2 a 5x (a quantite de hardware ou power equivalent). Bien entendu je peux me planter completement et peut etre qu'il y a quelque chose de particulier au coeur du RT qui aime vraiment le HW dedie, mais vu qu'ils parlent d'une machine SIMD (un peu comme les processeurs ou GPUs actuels somme toute) ca laisse planer des doutes sur l'utilisation d'une approche revolutionnaire. Bien entendu j'ai peut etre rate l'equivalent du texture sampling dans la rasterization classique qui effectivement est accelere par du hard dedie par des facteurs depassant 1 ordre de grandeur et approchant 2 (sans ca les GPUs ne seraient pas a ce point meilleurs que les CPUs a faire du raster). Je comptes sur les experts RT pour m'expliquer ce que je rate .

    Je ne leur demande que de contrarier mon scepticisme...
    fefe - Dillon Y'Bon

  3. #213
    Ce qui me choque principalement, c'est qu'ils auraient trouvé un super truc pour les rayons secondaires.

    Avec seulement les rayons primaires, y'a eu des articles montrant un FPGA à 66 MHz équivalent à un P4 à 2.4 GHz (http://graphics.cs.uni-sb.de/~woop/r...SIGGRAPH05.pdf) faisant tourner du soft bien optimisé (OpenRT).

  4. #214
    Oui, bien sur, je parlais de "vrai" raytracing, pas d'approximation ou on ne rend que les rayons primaires ou il y a effectivement un parallelisme quasiment illimite (le nombre de pixels) et facile a exploiter .
    Reflections et refractions sont quand meme un des interets du raytracing si je ne m'abuse.
    fefe - Dillon Y'Bon

  5. #215
    Oui 100% d'accord

    Deux liens avant d'aller me coucher, il se fait tard en France
    http://www.youtube.com/user/CausticGraphics
    http://ompf.org/forum/viewtopic.php?f=3&t=1248
    (ce forum a l'air fréquenté par des mecs qui savent de quoi ils parlent, tout du moins certains me donnent cette impression)

  6. #216
    Citation Envoyé par fefe Voir le message
    Bien entendu j'ai peut etre rate l'equivalent du texture sampling dans la rasterization classique qui effectivement est accelere par du hard dedie par des facteurs depassant 1 ordre de grandeur et approchant 2 (sans ca les GPUs ne seraient pas a ce point meilleurs que les CPUs a faire du raster).
    Et encore, si le texture sampling marche aussi bien sur GPU c'est autant grâce à leur bande passante mémoire monstueuse exploitable proche du débit crête sur des motifs d'accès pas réguliers qu'à leur unités de filtrage dédiées.

    Si on suppose que leur CausticOne a de la DDR3-800 (le max supporté sur un Virtex-5) en 128-bit, ça fait léger en bande passante comparé à un GPU ou même un CPU. Même avec des structures de données optimisées et des gros caches, la recherche d'intersections en raytracing doit pas mal tirer sur la mémoire...?

    Et en passant sur un ASIC, ils pourront peut-être gagner leur facteur 14 sur la puissance de calcul (et encore si leur implémentation FPGA a été conçue juste pour le prototypage et pas optimisée), mais sur la bande passante mémoire et PCIe ça sera plus dur...

    S'ils gèrent les textures, ça devient encore pire. Et s'ils rajoutent des shaders, la différence avec les GPU s'estompera, voire s'inversera à prix égal...

    Enfin peut-être qu'ils ont une technique révolutionnaire qui résout tous ces problèmes...

  7. #217
    Apparemment leur FPGA ne fait que du calcul d'intersection.
    Tout le reste, shader compris, est fait par le CPU et le GPU.

    L'hypothèse émise par certains est que leur seul but est de se faire racheter ou de proposer leur IP pour que ce soit accolé au GPU, parce qu'ailleurs, comme tu le dis, la BP va être un vrai problème très rapidement.

    Ca sent des pieds comme AGEIA, ce truc. A un moment il ne restera plus que leur API

  8. #218
    Citation Envoyé par Møgluglu Voir le message
    Et encore, si le texture sampling marche aussi bien sur GPU c'est autant grâce à leur bande passante mémoire monstueuse exploitable proche du débit crête sur des motifs d'accès pas réguliers qu'à leur unités de filtrage dédiées.
    J'aurais dis, a commencer par l'avantage d'un cache de texture sur un cache normal. Tu economises une bande passante monstrueuse de cette maniere, et les acces 2D/3D a un cache classique c'est pas la joie vu son organisation.

    Apres oui tu as besoin d'une grosse bande passante, mais pas direct vers ta memoire. Tu as beaucoup de localite dans tes textures qui n'est pas exploitee par ton L1 Texture cache. Tu peux songer a mettre un L2 voire un L3 pour exploiter le rendu en plusieur passes. Au final tu ne charges pas tes 500M de textures 50x par seconde dans la plupart des applis, tu t'acharnes serieusement sur un sous ensemble et un gros cache, ou de l'EDRAM comme sur la xbox est la seule memoire qui a vraiment besoin de bande passante, le reste pas vraiment besoin de tes 16 canaux de GDDR pour les transferer.

    Donc il est possible de faire quelque chose pour la bande passante memoire sans avoir besoin de beaucoup de liens a haute frequence. En revanche je ne crois pas que les FPGA soient ideales pour implementer de gros caches . Donc si on revient au sujet de discussion, on dirait effectivement qu'ils veulent se faire racheter .
    fefe - Dillon Y'Bon

  9. #219
    Sinon, la lecture de ompf.org confirme avec des details ce que je suspectais. Il y a deja des solutions a base de FPGA pour accelerer le RT. Ca accelere effectivement les calculs d'intersection d'un ordre de grandeur, mais au final ca ne donne pas plus de 2-3x sur le rendu d'une scene et c'est loin d'etre suffisament flexible pour que ca soit vraiment utilise.

    A moins que caustic ait quelque chose de revolutionnaire face a ces solutions existantes, c'est juste du bruit pour essayer de se faire racheter par Intel, AMD, Nvidia (qui se livrent a des rachats a tour de bras pour eviter que les autres aient acces a l'IP )
    fefe - Dillon Y'Bon

  10. #220
    Citation Envoyé par fefe Voir le message
    Tu as beaucoup de localite dans tes textures qui n'est pas exploitee par ton L1 Texture cache. Tu peux songer a mettre un L2 voire un L3 pour exploiter le rendu en plusieur passes.
    Tu aurais des refs ou des chiffres sur la taille des working sets? Ça m'intéresse.

    Au final tu ne charges pas tes 500M de textures 50x par seconde dans la plupart des applis, tu t'acharnes serieusement sur un sous ensemble et un gros cache, ou de l'EDRAM comme sur la xbox est la seule memoire qui a vraiment besoin de bande passante, le reste pas vraiment besoin de tes 16 canaux de GDDR pour les transferer.
    On peut donc imaginer que les GPU intégreront bientôt tous un gros cache, quand le coût et la conso de la GDDR ne permettra plus de scaler?
    (Ouais mais Larrabee il compte pas )

    Citation Envoyé par fefe Voir le message
    c'est juste du bruit pour essayer de se faire racheter par Intel, AMD, Nvidia (qui se livrent a des rachats a tour de bras pour eviter que les autres aient acces a l'IP )
    Argh, mon plan secret est découvert.

  11. #221
    Tu peux hacker le rasterizer microsoft de reference (ou Mesa si tu veux regarder des applis OpenGL) pour qu'il te donne des traces d'addresses/samples et les passer a un simulateur de GPU et de caches pour faire l'etude .
    fefe - Dillon Y'Bon

  12. #222
    Citation Envoyé par fefe Voir le message
    Tu peux hacker le rasterizer microsoft de reference (ou Mesa si tu veux regarder des applis OpenGL) pour qu'il te donne des traces d'addresses/samples et les passer a un simulateur de GPU et de caches pour faire l'etude .
    J'avais déjà essayé de faire ce genre de choses avec Mesa, sauf que y'a pas des masses de benchmarks qui passent avec la pile Mesa software (juste les SPECViewPerf avec zéro shaders...)
    J'avais bien tenté de faire tourner 3DMark 2001 et 2003 sous Wine, mais il aurait fallu hacker Wine aussi pour cheater la détection des shaders en hardware, j'ai vite laissé tombé.

  13. #223
    Citation Envoyé par Møgluglu Voir le message
    J'avais déjà essayé de faire ce genre de choses avec Mesa, sauf que y'a pas des masses de benchmarks qui passent avec la pile Mesa software (juste les SPECViewPerf avec zéro shaders...)
    Et tu as essaye recemment ? Mesa est sense supporter OpenGL 2.1 et si ce n'est pas le cas, un bug report pourrait etre utile

  14. #224
    Citation Envoyé par Møgluglu Voir le message
    J'avais déjà essayé de faire ce genre de choses avec Mesa, sauf que y'a pas des masses de benchmarks qui passent avec la pile Mesa software (juste les SPECViewPerf avec zéro shaders...)
    J'avais bien tenté de faire tourner 3DMark 2001 et 2003 sous Wine, mais il aurait fallu hacker Wine aussi pour cheater la détection des shaders en hardware, j'ai vite laissé tombé.
    Il y a longtemps j'avais utilise un hack de GL Trace et Mesa pour faire ce genre de choses. Tu enregistres les appels de ton appli OpenGL tournant avec un driver qui va bien (sous windows), et tu replay le tout offline a travers un Mesa hacke. C'est pas bien grave si ca ne rend pas tout bien vu que tu cherches essentiellement a avoir une trace d'addresses memoire. Bien entendu ce n'est pas un hack de 5 minutes, mais ca marchait (enfin en mmm 1998 ).
    fefe - Dillon Y'Bon

  15. #225
    Un peu hors-sujet : un ami a moi s'est amuse a threader le driver nVidia sous Wine.

    L'idee en gros est de lancer WoW en OpenGL a partir de Wine et d'utiliser un wrapper GL specifique qui est dans un thread separe. Avec cela il desynchronise les appels GL. Le resultat est tres interessant avec des perfs jusque x3 dans les parties du jeu non CPU bound, et ce avec une CG performante, gtx260+.

  16. #226
    3x par rapport a la meme chose sous wine ou 3x par rapport a la meme chose sans emulateur ?
    fefe - Dillon Y'Bon

  17. #227
    x3 sous Wine (bencher un MMO est quasi impossible, le seul moyen est de pouvoir debrayer les optims specifiques en temps reel, ce que son wrapper permet).
    Enfin a priori je pense que l'implementation OpenGL de WoW n'est pas pourrie (MacOS oblige) et le cout du wrapper GL de Wine est negligeable (il a mesure).
    En revanche certains appels system Windows sont tres mal implementes avec l'utilisation abusive de trucs du genre gettimeofday...

  18. #228
    Citation Envoyé par newbie06 Voir le message
    Et tu as essaye recemment ? Mesa est sense supporter OpenGL 2.1 et si ce n'est pas le cas, un bug report pourrait etre utile
    Oui, ça s'est certainement amélioré. Faudra que j'essaie de faire tourner un UT2004 ou un Quake 4 à l'occasion...

    Après ça reste de l'émulation. Les shaders ne sont pas optimisés, donc on fait des calculs pas très représentatifs de ceux qu'un vrai GPU ferait. La partie SIMD et MIMD saute complètement, et va t'amuser après à rejouer les traces en essayant de reconstituer une exécution en parallèle, avec les branchements en SIMD...

    Citation Envoyé par fefe Voir le message
    Il y a longtemps j'avais utilise un hack de GL Trace et Mesa pour faire ce genre de choses. Tu enregistres les appels de ton appli OpenGL tournant avec un driver qui va bien (sous windows), et tu replay le tout offline a travers un Mesa hacke.
    Encore faut-il avoir le driver qui va bien sous Windows... Bon, je sais que ça existe, et même pas loin de chez moi, mais effectivement c'est pas un hack de 5 minutes.

  19. #229
    Citation Envoyé par Møgluglu Voir le message
    Après ça reste de l'émulation. Les shaders ne sont pas optimisés, donc on fait des calculs pas très représentatifs de ceux qu'un vrai GPU ferait. La partie SIMD et MIMD saute complètement, et va t'amuser après à rejouer les traces en essayant de reconstituer une exécution en parallèle, avec les branchements en SIMD...
    Ca a du s'améliorer aussi avec Gallium, même si je ne sais pas trop où ça en est...

    Encore faut-il avoir le driver qui va bien sous Windows... Bon, je sais que ça existe, et même pas loin de chez moi, mais effectivement c'est pas un hack de 5 minutes.
    En plus je ne sais pas trop ce que tu vas en tirer niveau trace mémoire, parce que j'imagine que chaque driver, Mesa inclus, adresse les textures et le reste de ce qui est en mémoire, de manières très différentes non ?

  20. #230
    Citation Envoyé par newbie06 Voir le message
    En plus je ne sais pas trop ce que tu vas en tirer niveau trace mémoire, parce que j'imagine que chaque driver, Mesa inclus, adresse les textures et le reste de ce qui est en mémoire, de manières très différentes non ?
    Oui et non, les addresses physiques seront differentes, mais une fois tes mimaps alignees correctement tes patterns d'acces aux textures restent les memes (meme ordre, memes offsets), ce qui te permet de passer tes traces d'addresse a travers un simulateur de cache. Tu n'auras pas exactement les memes taux de succes (surtout sur des caches a faible associativite) mais si tu cherches a savoir si le hit rate est 20-30 50 70 ou 90% c'est tres efficace.
    fefe - Dillon Y'Bon

  21. #231
    Citation Envoyé par fefe Voir le message
    Oui et non, les addresses physiques seront differentes, mais une fois tes mimaps alignees correctement tes patterns d'acces aux textures restent les memes (meme ordre, memes offsets), ce qui te permet de passer tes traces d'addresse a travers un simulateur de cache. Tu n'auras pas exactement les memes taux de succes (surtout sur des caches a faible associativite) mais si tu cherches a savoir si le hit rate est 20-30 50 70 ou 90% c'est tres efficace.
    Je pensais que la facon d'acceder a la texture serait tres dependante de chaque implementation. Quoique en y reflechissant c'est peut-etre idiot, puisque le pattern d'acces a la texture est dicte par l'ordre d'acces au pixel (vs texel) qui doit etre de gauche a droite, puis de haut en bas, c'est ca ?

  22. #232
    Citation Envoyé par newbie06 Voir le message
    Je pensais que la facon d'acceder a la texture serait tres dependante de chaque implementation. Quoique en y reflechissant c'est peut-etre idiot, puisque le pattern d'acces a la texture est dicte par l'ordre d'acces au pixel (vs texel) qui doit etre de gauche a droite, puis de haut en bas, c'est ca ?
    Oui si tu restes au niveau d'abstraction d'OpenGL et que tu traces les coordonnées (u,v) et gardes tous les paramètres du sampler (taille, mode de filtrage, mipmaps...).
    Après tu peux simuler le mode d'adressage que tu veux (linéaire, tilé, courbe de Peano...), en considérant que ça fait partie des paramètres de la simulation.

    Ce qui va être dépendant, c'est l'ordre dans lequel tu fais tes accès. Mesa va traiter les pixels séquentiellement au lieu de les traiter par paquets, et l'ordre de rasterization sera certainement très différent.
    Donc il faut en plus un scheduler pour trier les traces...

    (En relisant ce que tu as écrit je me rends compte que tu parlais bien de l'ordre de rasterization. Non il n'est pas évident du tout, par exemple pour le G80 : http://www.icare3d.org/GPU/CN08.)

  23. #233
    Bon entre ce que tu dis et ce que Fefe raconte, moi j'y comprends plus rien, je retourne a mes benchmarks bien connus

  24. #234
    Si tu captures le comportement du traffic lie aux textures tu as entre 50 et 90% de tes acces memoires. Ajoute 10 a 30% pour tes vertice, jusqu'a 10% pour Z, et il te reste 5 a 30% pour la rasterization. Ces derniers seront dependants de ta methode de fragmentation/binning mais justement le fait que tu puisses bloquer la rasterization pour qu'elle tienne dans de petites memoires locales (ou caches) te permet assez rapidement de determiner le hit rate sur ceux-ci sans avoir vraiment a simuler un ordre exact. Bien entendu quand tu as un simulateur capable de les scheduler correctement tu gagnes en precision, mais vu la part de la rasterization dans le traffic memoire l'erreur n'est pas enorme.
    fefe - Dillon Y'Bon

  25. #235

  26. #236
    Pas encore vu la vidéo de Carmack, mais dans les slides de Sweeney le Cell s'en prend plein la gueule. Et Larrabee c'est le futur ça va résoudre tous les problèmes toussa...

    Par "current GPGPU", je suppose qu'il parle du DX9 du 2004. Parce que sinon CUDA offre la plupart de ce qu'il demande (pour le code data-parallel), à part les instructions scalaire-SIMD (réduction), et la mémoire totalement cohérente avec le CPU. Bien sûr c'est pas encore portable...

  27. #237
    Mouai, ils me font rire les mecs qui croient que la cohérence va tout résoudre (je parle pas de TS là). La cohérence simplifie surement grandement certains problèmes, mais je me marre à l'idée de la tête que va faire le premier naïf venu qui se dit que LRB va lui fournir un bon speedup magiquement. Le pauvre risque de se retrouver avec son ring bus engorgé de requêtes L2 allant d'un coeur à l'autre.

    Donc ouai la cohérence c'est bien, mais ça ne suffira largement pas.

    Et puis le Cell, c'est bien, nah

  28. #238
    Sweeney est ultra pro-LRB, Carmak nettement moins et ca se voit dans les articles en question.
    En revanche quand ils parlent de coherence, ils ne pensent pas performance, c'est toi qui te trompe la. La coherence n'a que tres rarement apporte de la performance et n'est generalement pas la pour ca. La coherence est la pour simplifier l'ecriture de code et la reduction des couts, chose pour laquelle on est generalement pret a sacrifier de la performance.

    La coherence reduit la performance des architectures, augmente leur cout, et un programmeur intelligent a qui on fournit les bons outils de communication entre plusieurs unites de calcul fera nettement mieux dans la majorite des cas (quand il pourra predire les communications necessaires de maniere statique. En theorie dans la majorite des problemes un programmeur pourra eliminer l'essentiel des snoop qui "miss".

    Le seul cas ou tu gagnes est le cas ou les dependances sont resolues dynamiquement a l'execution, et la sans coherence il faut faire du code auto modifiant pour obtenir la meme chose sans et ca devient inefficace, lent, inmaintenable... Donc oui il y a des cas ou la coherence sera plus rapide que du soft, mais ce n'est pas le cas de l'essentiel du code graphique dont Sweeney parle.

    De ce que je comprends, la seule raison pour laquelle il veut la coherence, c'est pour reduire ses couts de developement d'applis paralleles.
    fefe - Dillon Y'Bon

  29. #239
    Je ne me suis pas trompé : je crains juste que des gens croient que juste parce que ça fonctionne tout seul correctement, ça suffit. Avec 4 coeurs OK, avec 16 ou 32, ça m'étonnerait. Du coup, je ne suis pas 100% convaincu que ça soit vraiment un facteur permettant de baisser les coûts, parce que de toute façon, l'efficacité mémoire il va falloir se la palucher à la main, et avec plein de coeurs ça ne va pas être facile.

    C'était tout ce que je voulais dire, faut pas chercher plus loin, je suis en vacances, j'ai débranché le cerveau

  30. #240
    Citation Envoyé par newbie06 Voir le message
    Je ne me suis pas trompé : je crains juste que des gens croient que juste parce que ça fonctionne tout seul correctement, ça suffit. Avec 4 coeurs OK, avec 16 ou 32, ça m'étonnerait. Du coup, je ne suis pas 100% convaincu que ça soit vraiment un facteur permettant de baisser les coûts, parce que de toute façon, l'efficacité mémoire il va falloir se la palucher à la main, et avec plein de coeurs ça ne va pas être facile.

    C'était tout ce que je voulais dire, faut pas chercher plus loin, je suis en vacances, j'ai débranché le cerveau
    Sans parler du côté redondant de l'expression, t'es sûr que c'est "palucher" le mot que tu cherches ?

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
  •