Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 7 sur 22 PremièrePremière 12345678910111213141517 ... DernièreDernière
Affichage des résultats 181 à 210 sur 658

Discussion: Archi GPU et GPGPU

  1. #181
    C'est marrant ca me rappelle a peu pres toutes les comparaisons d'architectures differentes de la recherche de ces 15 sernieres annees (tout du moins la premiere phase), je suis passe par la (et j'ai ecrit des papiers comme ca, mais j'etais jeune):
    - Regardez on a un VLIW, il est 2x plus petit et va 4x plus vite que votre superscalaire OOO (ah oui desole on n'avait pas fini le compilateur alors on a compare du gcc -g avec du code asm schedule a la mimine pour 3 applis)
    - Regardez mon jeu d'instruction SIMD qu'il est beau, je vous fait du 20x en perf (avec des vecteurs de 4 de large si possible) sur 3 kernels.

    Mais au final quelques annees plus tard debarquent les vrais papiers avec des vrais compilateurs, une vraie baseline bien optimisee, et des ameliorations en dizaines de pourcents. Dans certains cas ca vaut le coup dans d'autres je ne sais pas.

    Je n'ai pas regarde mais ou en sont les BLAS pour GPGPU ? Parce que ca devrait bien s'accelerer quand meme et ca devient possible de tester de vraies applications (utilisant BLAS) dans un environement correct (cad avec des tailles de problemes realistes et une comparaison contre une appli optim sur CPU). Bien entendu ca fait moins de buzz qu'un encodeur video, mais au moins ca peut servir.
    fefe - Dillon Y'Bon

  2. #182
    Citation Envoyé par fefe Voir le message
    je suis passe par la (et j'ai ecrit des papiers comme ca, mais j'etais jeune):
    C'est marrant, j'ai reussi a resister, aucun papier publie. J'avais assez de recul pour me rendre compte que tous ces jolis papiers sur les compilos c'etait de la masturbation. Mais, etonamment je n'avais pas assez de recul pour me rendre compte qu'avec une telle attitude je ne finirais pas ma these

    - Regardez on a un VLIW, il est 2x plus petit et va 4x plus vite que votre superscalaire OOO (ah oui desole on n'avait pas fini le compilateur alors on a compare du gcc -g avec du code asm schedule a la mimine pour 3 applis)
    Va falloir que je me motive et que je fasse quelques benchmarks pour le DSP VLIW de TI. Leur compilateur est plutot bon. Naturellement, ca ne marchera bien que pour des bench bien specifiques, y'a pas de miracle.

    Mais au final quelques annees plus tard debarquent les vrais papiers avec des vrais compilateurs, une vraie baseline bien optimisee, et des ameliorations en dizaines de pourcents. Dans certains cas ca vaut le coup dans d'autres je ne sais pas.
    FFmpeg va deux fois plus vite sur ARM en utilisant des routines SIMD en langage d'assemblage, mais ca c'est une evidence surtout quand les compilos existants n'arrivent pas a vectoriser.

    Je n'ai pas regarde mais ou en sont les BLAS pour GPGPU ? Parce que ca devrait bien s'accelerer quand meme et ca devient possible de tester de vraies applications (utilisant BLAS) dans un environement correct (cad avec des tailles de problemes realistes et une comparaison contre une appli optim sur CPU). Bien entendu ca fait moins de buzz qu'un encodeur video, mais au moins ca peut servir.
    Pour BLAS and co, Møgluglu a poste un lien : http://www.cs.berkeley.edu/~volkov/volkov08-sc08talk.pdf

  3. #183
    Citation Envoyé par newbie06 Voir le message
    C'est marrant, j'ai reussi a resister
    /me essaie de se cacher

    Merci
    Et le papier correspondant :
    http://scyourway.nacse.org/conference/view/pap341

    Pour les BLAS/LAPACK, l'équipe de Demmel est sur le coup, je ne me fais pas trop de souci.

    Edit: par contre je suis pas d'accord avec eux sur le cache L1 et les TLB...
    Dernière modification par Møgluglu ; 17/12/2008 à 11h17.

  4. #184
    http://parlab.eecs.berkeley.edu/pubs...nchmarking.pdf pour ceux qui n'ont pas acces a IEEE library (j'ai acces qu'au boulot).

    En double precision (DGEMM): 2x la perf de leur quad core pour ~2x le power, sur LU et SGEMM 4.4x la perf pour ~2x le power. Je vois donc une efficacite doublee sur du simple precision (ce pour quoi le GPU est tune) et equivalente sur du double, a condition de manipuler des matrices de 2k-4k ou plus. C'est nettement moins sexy que ce que le marketing de Nvidia veut faire croire, mais ca reste tres interressant en simple precision.
    D'ailleurs pour ce qui est du power, il faudrait une vraie comparaison, pour l'instant je prends le TDP d'une carte Nvidia (~240W pour une GTX280) et compare au TDP d'un quad core a 3GHz + chipset + memoire. Il faudrait comparer le power total d'un rack optimise pour mettre dans un cluster avec: 1 ou plusieurs quad core, la memoire necessaire, pas de CG, 1 CPU et autant de cartes 3D qui peuvent tenir dans le rack. Avec une brique de base comme ca il devient possible de comparer l'efficacite des 2.

    La question qui vient a l'esprit est qu'est ce que ca donnerait si les CPUs avaient des vecteurs plus longs que SSE (comme AVX ou Larrabee).
    Dernière modification par fefe ; 17/12/2008 à 11h37.
    fefe - Dillon Y'Bon

  5. #185
    Cette histoire de BLAS me fait penser a un truc (limite hors-sujet, mais pas tout a fait) : les compilos FORTRAN sont consideres comme plus efficaces que les compilos C du fait des restrictions sur l'aliasing. C'est toujours le cas dans la vraie vie ? Y'a personne qui bosse chez Meteo France pour verifer ?

  6. #186
    La derniere fois que j'avais regarde (il y a 5 ou 6 ans) c'etait encore le cas, mais la justification principale etait que les programmeurs eux etaient en Fortran
    fefe - Dillon Y'Bon

  7. #187
    Allez ca faisait longtemps qu'on n'avait pas parle ray-tracing : http://www.intelsoftwaregraphics.com...2224&siteid=32

    Un Dunnington a 2.66 GHz, c'est forcement du 6 coeurs, non (ref)? Donc 6 coeurs x 4 sockets x 2.66 GHz pour du 1280x720 @20-35 fps., pour un jeu d'il y a 1 an.

  8. #188
    6*4*2.66*2*4= 510 GFLOP avec un reseau d'interconnection off-die, ca donne a reflechir a mon avis. Je ne sais pas si les GPUs sont capables d'utiliser leurs FLOPs aussi bien que cette machine pour le RTRT, mais un paquet de cores x86 sur un meme die avec un bon reseau d'interconnection devraient y arriver.
    Donc est-ce accessible a Larrabee ?
    Si on compte 16 core a 1.6GHz avec 32FLOP/cycle (512 bits, Mul+Add) on tombe sur 820GFLOPs, 1.6Tflops si on compte 32 cores. Ca semble etre tout sauf hors de portee, meme si les Dunnington ont tres certainement un meilleur IPC que les coeurs de LRB (mais ils souffrent de ne pas etre sur un meme die et de ne pas avoir de GDDR).
    fefe - Dillon Y'Bon

  9. #189
    C'est quoi, un réseau d'interconnection off-die ?

  10. #190
    QPI/FSB/HT par exemple. Le Dunnington a 4 sockets, les echanges de donnees entre socket = off-die sont plus lents que les echanges locaux = on die (en latence et en bande passante).

    PS: meme en reflechissant ca ne me vient pas en Francais, desole.
    fefe - Dillon Y'Bon

  11. #191
    C'est vrai qu'on est pas/plus à des ordres de grandeur de différence. Mais si on demande à nos amis canards qui serait prêt à jouer à 20 fps en 1280x720 sans antialiasing avec une carte à 500€ juste pour voir des dômes vitrés avec des effets de réfraction, je crois pas qu'on aura beaucoup de volontaires...
    À qualité visuelle perçue équivalente, le rendering a encore une bonne longueur d'avance...

  12. #192
    Tout a fait, mais on risque de voir de plus en plus de jolies demos, et d'ici quelques annees avoir les premiers jeux RTRT (et probablement pas des FPS). De la a dire que le RTRT remplacera le raster dans les jeux rapidement, je n'y crois pas, mais je pense que les 2 vont commencer a coexister bientot.
    fefe - Dillon Y'Bon

  13. #193
    Un truc me paraît peu clair dans cet article (et les précédents par ailleurs du même type) : me trompè-je en disant qu'il se contente de faire un moteur d'affichage ? Sur un jeu complet, la dynamique du monde ne va pas ralentir sérieusement le RT qui se plaît mieux sur des scènes plus statiques ?

  14. #194
    Je ne sais pas mais si ils font le rendering d'1 frame en 40ms en moyenne ca importe peu, tu ajoute encore un autre CPU sur le cote pour faire tourner le jeu et l'IA et c'est bon non ? .
    fefe - Dillon Y'Bon

  15. #195
    Citation Envoyé par fefe Voir le message
    Je ne sais pas mais si ils font le rendering d'1 frame en 40ms en moyenne ca importe peu, tu ajoute encore un autre CPU sur le cote pour faire tourner le jeu et l'IA et c'est bon non ? .
    Mon questionnement n'est pas là C'est plutôt de savoir si un monde trop dynamique n'est pas trop handicapant pour du RT ? Dans mon souvenir, le RT utilise énormément de structures statiques pour être rapide (un peu comme les BSP des débuts des FPS, mais avec encore plus de restrictions). Je me trompe ?

  16. #196
    Faudrait demander ca a ceux qui developpent du soft, pas a ceux qui font du hard
    fefe - Dillon Y'Bon

  17. #197
    Citation Envoyé par newbie06
    Mon questionnement n'est pas là C'est plutôt de savoir si un monde trop dynamique n'est pas trop handicapant pour du RT ? Dans mon souvenir, le RT utilise énormément de structures statiques pour être rapide (un peu comme les BSP des débuts des FPS, mais avec encore plus de restrictions). Je me trompe ?
    Effectivement, le RT (temps réel ou pas d'ailleurs) se repose sur une structure de partionnement des objets ou de l'espace (Diviser pour mieux régner). Tester l'intersection avec tous les triangles de la scène serait BCP TROP LENT. Il faut donc partitionner pour tester uniquement les triangles qui sont *potentiellement* intersectés par un rayon donné. Un kd-tree (BSP tree avec des plans alignés aux axes) est généralement très efficace lors de la traversée mais est couteux à construire. A contrario une hiérarchie de boite englobante (BVH) peut être construite en une poignée de milliseconds sur quelques centaines de milliers de triangles et reste toujours efficace pour la traversée des rayons.

    Aujourd'hui une BVH est la structure de données le plus utilisée pour un RTRT de scènes dynamiques. Certains diront qu'il est plus couteux de construire une structure spécifique que de ne rien construire du tout! C'est vrai mais même en raster plusieurs structures de partitionnement doivent être calculée dynamiquement (collision, occlusion culling, etc.). Bref, comme souligné dans l'article, ce qui pénalise les performances du RT aujourd'hui, se situe surtout au niveau des accés textures (très couteux en soft). Avec le larrabee et ses unités de texturing hard ce goulot d'étrangelement est en parti levé.

    En ce qui concerne l'article, l'argument des ombres reste toujours aussi moisi. Les shadow volume de l'id-tech4 faisait aussi bien en raster. Pour les objets alpha texturés, les "textured shadow volumes" règlent également le problème pour le raster. Par contre la réflexion/réfraction est un atout pour le RT mais le VRAI atout c'est la simplicité de programmation d'une boucle de rendu par RT. Quoiqu'il en soit, les résultats d'Intel sont clairement impressionants! Comme le souligne fefe il est fort probable que les renderer hybrides soient à court terme le standard des futurs moteurs. C'est d'ailleur en parti déjà le cas avec du RT local (Relief Maping, etc.)

  18. #198
    Merci, c'est beaucoup plus clair comme ca .
    fefe - Dillon Y'Bon

  19. #199
    On peut donc considérer que le partionnement n'est pas plus un problème en RT qu'en raster.

    En ce qui concerne l'article, l'argument des ombres reste toujours aussi moisi. Les shadow volume de l'id-tech4 faisait aussi bien en raster. Pour les objets alpha texturés, les "textured shadow volumes" règlent également le problème pour le raster. Par contre la réflexion/réfraction est un atout pour le RT mais le VRAI atout c'est la simplicité de programmation d'une boucle de rendu par RT. Quoiqu'il en soit, les résultats d'Intel sont clairement impressionants! Comme le souligne fefe il est fort probable que les renderer hybrides soient à court terme le standard des futurs moteurs. C'est d'ailleur en parti déjà le cas avec du RT local (Relief Maping, etc.)
    Ca m'étonnerait qu'un RTRT performant soit tellement plus simple qu'un raster hormis peut-être la boucle au top qui appelle le bouzin pixel/pixel Et encore je ne suis pas certain que cette boucle soit si simple dès lors qu'on commence à paralléliser en tenant compte du SIMD. Je me trompe encore ?

  20. #200
    Je ne crois pas que ça soit encore arriver ici :

    Programmation Larrabee:

    Multicore Made Simple
    http://www.spectrum.ieee.org/jan09/7129

    We should treat all the trivial things of life seriously, and all the serious things of life with sincere and studied triviality.[Oscar wilde]

    There is no such thing as a moral or an immoral book. Books are well written, or badly written. That is all.[Oscar wilde]

    No artist is ever morbid. The artist can express everything.[Oscar wilde]

  21. #201
    Citation Envoyé par newbie06
    Ca m'étonnerait qu'un RTRT performant soit tellement plus simple qu'un raster
    Ca l'est d'un point de vu algorithmique. Sans rentrer dans les détail de l'algorithme de rendu en lui même, l'exemple des ombres de l'article reste parlant de cette simplicité: Il suffit de lancer un rayon d'ombre (algorithme un peu à la base du lancer de rayon!) Avoir la même qualité d'ombre en raster est bien plus difficile (détection des arêtes de silhouettes, extrusion du volume d'ombre, rastérization du volume d'ombre, passe d'éclairage). Calculer ne serait-ce qu'une approximation par shadow map demeure plus difficile qu'un lancé de rayon. Pour se convaincre de la simplicité du RT, il suffit de regarder une implémentation en soft (pour ne pas biaiser le jugement avec une API) d'un lancer de rayon VS rastérization.

    Bref, un algorithme simple reste simple, même une fois optimisé. Que l'optimisation soit obscure est une chose. Mais elle n'en demeure pas moins obscure sur une algo plus compliqué.
    Dernière modification par Alice ; 02/02/2009 à 01h54.

  22. #202
    Citation Envoyé par Alice Voir le message
    Ca l'est d'un point de vu algorithmique. Sans rentrer dans les détail de l'algorithme de rendu en lui même, l'exemple des ombres de l'article reste parlant de cette simplicité: Il suffit de lancer un rayon d'ombre (algorithme un peu à la base du lancer de rayon!) Avoir la même qualité d'ombre en raster est bien plus difficile (détection des arêtes de silhouettes, extrusion du volume d'ombre, rastérization du volume d'ombre, passe d'éclairage). Calculer ne serait-ce qu'une approximation par shadow map demeure plus difficile qu'un lancé de rayon. Pour se convaincre de la simplicité du RT, il suffit de regarder une implémentation en soft (pour ne pas biaiser le jugement avec une API) d'un lancer de rayon VS rastérization.

    Bref, un algorithme simple reste simple, même une fois optimisé. Que l'optimisation soit obscure est une chose. Mais elle n'en demeure pas moins obscure sur une algo plus compliqué.
    Ben justement si on ne rentre pas dans les details, on a l'impression que c'est simple. Mais quand tu veux atteindre des vitesses correctes ca devient dingue, parce qu'il faut faire du tir groupe de rayons. Enfin c'est ce que j'en ai retenu de ma lecture en diagonale de la these de chai-plus-ki-ke-je-retrouve-plus

  23. #203
    Si tu veux rentrer dans les détails, demande toi quels types d'optimisations il faut pour arriver à des performances temps réel en rastérization. C'est loin d'être facile: Le black Book de Michael Abrash permet de voir de quoi il en retournait à l'époque de Quake. Même sans ça, dans tous les cas tu ne parles pas de la même chose. Si la rastérization est une technique de rendu rapide elle n'en demeure pas moins complexe à manipuler pour arriver à simuler des intéractions lumineuses complexes. Le RT est un outil bien plus simple pour gérer les effets globaux et ce indépendemment des optimisations sous jacentes. Ombres? RT: tirer des rayons; Raster: shadow map et son artillerie pour corriger ses artefacts moisis ou shadow volume. Reflets? RT: tirer des rayons; Raster: impossible à calculer proprement sauf sur peu de surfaces planes. Refraction? RT: lancer des rayons; Rasterization: impossible à calculer proprement etc. On en revient donc à l'idée du départ: le RT simplifie la boucle de rendu.
    Dernière modification par Alice ; 02/02/2009 à 22h59.

  24. #204

  25. #205
    J'imagine que la vision d'artiste sur le site représente une carte PCIe x4 qui embarque 2 gros FPGA et 2 barettes de DDR-2.

    (Le fait qu'ils "annoncent" un speedup x10 début 2010 par rapport à leur speedup actuel supposé de x20 veut dire qu'ils utilisent un FPGA aujourd'hui et qu'ils auraient un ASIC en cours.)

    Faut voir ce qu'ils arriveront à faire avec un circuit dédié optimisé qui a 20 fois moins de puissance de calcul brute et 20 fois moins de BP mémoire qu'un GPU/Larrabee...

  26. #206
    On peut faire du guessing la-dessus en utilisant cette reference et ce que l'on sait de Larrabee.

    The ray tracing performance of the FPGA prototype running at 66 MHz is comparable to the OpenRT ray tracing performance of a Pentium 4 clocked at 2.6 GHz, despite the available memory bandwith to our RPU prototype is only about 350 MB/s.
    On peut supposer qu'un CPU Larrabee aura 4x plus de FP crete qu'un P4 (128-bit vs 512-bit). Voire x8 avec le MUL+ADD (y'a bien ca dans AVX non ?). Donc le FPGA aurait une capacite de calcul entre x10 et x5 (MUL+ADD) a frequence egale.
    Naturellement il est peu probable que cette boite ait la capacite de fabriquer un chip qui atteigne les frequences qu'Intel peut se permettre. Mettons un x2 ? Ca nous ramenerait entre x5 et x2.5.

    Bon mes calculs ne servent pas a grand-chose ne connaissant pas leurs ameliorations algorithmiques (et j'ai pas le droit de lire des brevets ), mais leur CTO n'est pas un specialiste du RT : http://www.jamesmccombe.com/AboutMyself/resume.html

    Voila j'avais envie de meubler mon debut de digestion avant de faire la sieste

    EDIT : ci-dessus "capacite de calcul" est a lire "capacite de calcul a fonctionalite equivalente (en supposant ou pas que le MUL+ADD est critique en RT)".

  27. #207
    Citation Envoyé par newbie06 Voir le message
    On peut supposer qu'un CPU Larrabee aura 4x plus de FP crete qu'un P4 (128-bit vs 512-bit). Voire x8 avec le MUL+ADD (y'a bien ca dans AVX non ?).
    Il y aurait un FMA dans les Larrabee New Instructions, et le P4 a 1 add + 1 mul 64-bit, donc oui à peu près.

    Donc le FPGA aurait une capacite de calcul entre x10 et x5 (MUL+ADD) a frequence egale.
    Par rapport à 1 coeur de LRB? Pour 16 coeurs ça ferait entre x0,6 et x0,3...
    Sachant qu'on met bien plus de logique dans un ASIC, mais qu'ils ne peuvent pas trop se permettre de faire des dies de 700mm² comme Intel et Xilinx...
    Caustic donnent un facteur 10 entre leurs FPGA et leur ASIC, qui au pif pourraient tourner à 300MHz et 1,5 GHz et euh... bah là les calculs ont atteint plus d'un facteur 10 de marge d'erreur, j'abandonne

    Enfin en même temps, c'est pas comme s'ils espéraient autre chose que de se faire racheter par NVidia...

  28. #208
    Oui, c'est exactement ce que je voulais dire : je ne crois pas à leur succès

  29. #209

  30. #210
    The answers to all developer's needs

    AMD has just released a massive 392-page PDF reference guide on its R700-family Instruction Set Architecture (or RV700 GPUs) dated March 2009. The guide includes documentation for various ATI GPUs in the R700 family:

    RV710 (Radeon HD 4350/4550)
    RV730 (Radeon HD 4650/4670)
    RV740 (Radeon HD 4750/4770)
    RV770 (Radeon HD 4830/4850/4870)
    RV790 (Radeon HD 4890)

    More importantly, the guide serves to specify the instructions of the R700 architecture as well as the format of these instructions. This will provide guidelines for programmers and compiler writers to maximize processor performance. In other words, let's hope developers jump on this new documentation, as all too often the answer to a problem is already in data sheets like these.

    "This document is intended for programmers writing application and system software, including operating systems, compilers, loaders, linkers, device drivers, and system utilities; it is specifically for those who want to maximize software performance. It assumes that programmers are writing compute-intensive parallel applications (streaming applications) and assumes an understanding of requisite programming practices."

    One interesting detail that Guru3D pointed out is the fact that the current high-end RV770's memory read instructions do not support "burst reads." According to the documentation, "Burst memory reads are not supported by the RV770; however, the 710, 730, 740, and 790 do support it. Chips after the R770 support burst reads in memory-read instructions. This allows up to 16 consecutive locations to be read into up to 16 consecutive [General Purpose Registers]."

    Surprisingly, the PDF is only 1.88MB and can be downloaded =>
    http://developer.amd.com/gpu_assets/...chitecture.pdf

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
  •