Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 6 sur 22 PremièrePremière 123456789101112131416 ... DernièreDernière
Affichage des résultats 151 à 180 sur 658

Discussion: Archi GPU et GPGPU

  1. #151
    Le problème, c'est que ce genre de chose n'est possible pour les boîtes que sur de très bons produits, sinon c'est contre-productif. Si AMD faisait la même chose pour le Phenom par exemple, ça ferait un peu 10 pages de "bon OK, on a couillé". D'un point de vue marketing, c'est pas très adroit.

  2. #152
    Comme il faut que les histoires se terminent bien, ils finissent par le faire, mais rétrospectivement, pour comparer avec le produit qui a succédé et qui fut meilleur, et pour montrer qu'ils apprennent de leurs erreurs. Intel l'a fait avec Netburst (indirectement peut être, on a pas eu d'interview de ce genre, mais des analyses très détaillées du fonctionnement et de ce qui n'a pas marché). Pour AMD, peut être qu'il parlera des phenom 1er du nom, une fois que les phenom 2 auront complètement inondé le marché.

    Ou pas.
    (l'inondation)

  3. #153

  4. #154
    C'est assez impressionnant de la part de l'équipe AMD Stream
    Spoiler Alert!
    quand on voit qu'ils ne savent pas calculer 14 / 7
    .
    Même si ce genre de benchmark a un fort risque de n'importe quoi (pas les mêmes règlages, pas la même qualité/bugs en sortie), ça reste un facteur 2.

    Que ça ne tourne que sur 4xxx n'est pas choquant, c'est la première génération à permettre les Compute Shaders DX11 à la CUDA/OpenCL, le reste est du bricolage.

    Mine de rien le RV770 a pas mal de features intéressantes que le GT200 n'a pas (registres temporaires, registres partagés, registres généraux indexables...)
    Vivement que la couche software suive

  5. #155

  6. #156
    Merci pour le lien

    Tiens y'a des des farceurs chez Nvidia...

    The mandated minimum double
    precision floating-point capability is
    CL_FP_FMA |
    CL_FP_ROUND_TO_NEAREST |
    CL_FP_ROUND_TO_ZERO |
    CL_FP_ROUND_TO_INF |
    CL_FP_INF_NAN |
    CL_FP_DENORM.
    Donc pour la double précision, le Radeon 4xxx n'est pas compatible OpenCL, le Cell non plus, probablement pas le Power6, le Core et le Phenom certainement pas, reste éventuellement l'Itanium et, tiens, le GT200.

    Réponse à DirectX 10.1 et la GDDR5?

  7. #157
    123

    NVIDIA INTÈGRE OPENCL À SON ENSEMBLE D’OUTILS GPU COMPUTING

    L’architecture informatique parallèle révolutionnaire CUDA de NVIDIA prend en charge OpenCL.

    SIGGRAPH ASIA 20008 – 9 DECEMBRE 2008 – NVIDIA Corporation annonce la prise en charge de la nouvelle spécification OpenCL 1.0 du Khronos Group. OpenCL (Open Computing Language) est une nouvelle API qui permet aux développeurs de s’appuyer sur l’énorme puissance de calcul parallèle du GPU. L’intégration d’OpenCL est une nouvelle étape significative dans la révolution GPU et elle donne aux développeurs NVIDIA une nouvelle puissante option de programmation.

    NVIDIA a démarré la révolution GPU Computing avec l’introduction de NVIDIA CUDA, architecture matérielle et ISA massivement parallèle. CUDA a été conçu pour prendre en charge nativement toutes les interfaces de calculs parallèles, et notamment OpenCL. Activé sur plus de 100 millions de GPU NVIDIA, CUDA a permis des gains en performances sans précédent sur une large gamme d’applications et dispose d’une énorme base installée pour déployer des applications de calculs sur OpenCL. Prenant également en charge les autres langages de l’industrie comme C, Java, Fortran et Python, seule l’architecture CUDA apporte aux développeurs un choix d’environnements de programmation pour permettre de développer rapidement des applications de calculs sur le GPU.

    CUDA, annoncé au début avec le GPU NVIDIA® GeForce® 8800 et en standard avec tous les GPU récents de NVIDIA, est le fondement de la stratégie de calcul parallèle de NVIDIA. CUDA a reçu un énorme succès auprès de la communauté de la recherche où les scientifiques voient leurs applications accélérées d’un facteur 20 à 200 avec CUDA par rapport à un traitement sur CPU. L’architecture CUDA est intégrée dans une large gamme de systèmes informatiques allant du supercalculateur et la station de travail au PC domestique, permettant à plus de 25 000 développeurs de développer activement sur CUDA.

    « L’arrivée d’OpenCL est une excellente nouvelle pur l’industrie informatique et NVIDIA est ravie de jouer un rôle de premier plan dans l’établissement d’un nouveau standard qui promeut l’informatique sur GPU », a déclaré Manju Hegde, general manager de CUDA chez NVIDIA. « Nous sommes ravis qu’Apple nous ait aidés à promouvoir OpenCL. Le fait qu’ils aient reconnu que le GPU jouera désormais un rôle essentiel dans les applications grand public est une étape significative dans l’histoire informatique ».

    Neil Trevett, vice président du contenu chez NVIDIA, préside également le groupe de travail OpenCL chez Khronos.

    « La spécification OpenCL est le fruit d’une opportunité clairement reconnue par les leaders comme NVIDIA pour faire croître le marché informatique parallèle hétérogène par une multi-plate-forme ouverte », a déclaré M. Trevett. « NVIDIA continuera d’être très active dans le groupe de travail OpenCL pour gérer l’évolution de la spécification et prendra en charge l’OpenCL sur toutes ses plates-formes, pour que les développeurs puissent s’appuyer davantage sur la puissance de calculs de nos GPU ».

    À propos de NVIDIA

    NVIDIA est le leader des technologies de traitement visuel et l’inventeur du GPU, processeur de hautes performances qui génère des graphiques interactifs à couper le souffle sur les stations de travail, les PC, les consoles de jeux et les appareils mobiles. NVIDIA sert le marché des loisirs et grand public avec ses produits GeForce®, le marché de la conception et de la visualisation professionnelle avec ses produits Quadro et le marché informatique de hautes performances (HPC) avec ses produits Tesla. NVIDIA a son siège à Santa Clara, en Californie, et possède des bureaux en Asie, en Europe et sur le continent américain.

  8. #158
    Eh oui, Nvidia ça ne leur suffit pas que CUDA devienne le X86 du GPU, ils veulent aussi qu'il devienne le X87 du GPU :
    on sort un produit vite fait et puis on noyaute le comité de normalisation pour inclure tous ses
    Spoiler Alert!
    bugs
    features dans la norme...

  9. #159
    Citation Envoyé par Møgluglu Voir le message
    Eh oui, Nvidia ça ne leur suffit pas que CUDA devienne le X86 du GPU, ils veulent aussi qu'il devienne le X87 du GPU :
    on sort un produit vite fait et puis on noyaute le comité de normalisation pour inclure tous ses
    Spoiler Alert!
    bugs
    features dans la norme...
    Et les autres membres du comité (AMD, Intel notamment) tu crois qu'ils laissent faire nVidia comme il veut ?

  10. #160
    Citation Envoyé par newbie06 Voir le message
    Et les autres membres du comité (AMD, Intel notamment) tu crois qu'ils laissent faire nVidia comme il veut ?
    Oui.
    Exemple donné plus haut.

    On peut aussi prendre le MUL24, le MAD pas IEEE-754, la division à 2 ulps... Toutes les features arithmétiques que Nvidia supporte sont obligatoires et les autres sont facultatives. Voire même pas dans la norme pour les features du RV770.

  11. #161

  12. #162
    Notons l'agencement des blocs, habilement placés sur une exponentielle imaginaire... Ah, les merveilles du marketing !

  13. #163
    J'ai abandonne la lecture de la spec CL. Je ne supporte pas les gros documents generes par Word. Encore un standard de m....

  14. #164
    Citation Envoyé par newbie06 Voir le message
    J'ai abandonne la lecture de la spec CL.
    C'est pas grave, tu as un résumé là :
    http://developer.download.nvidia.com..._Guide_2.0.pdf


    Sérieusement, même si on s'y attendait, je suis vraiment déçu que ça ait évolué comme ça, avec une norme bâclée en 6 mois calquée sur CUDA.

    Quel est le retour sur CUDA de la part des codeurs expérimentés?
    Si on prend la présentation de Vasily Volkov à SuperComputing 2008
    - Il commence par casser tout le marketing bullshit de l'archi "scalaire" et du SIMT. Le G80 est purement vectoriel, et ça se programme comme un Cray. Les branchements, j'en ai pas, je fais de l'algèbre linéaire pas du graphisme moi môssieu .
    - Conséquence, on gâche énormément de registres et de ressources de calcul pour tout ce qui est scalaire (boucles, contrôle, adresses).
    - Donc faut faire tout le contraire des guidelines de NV pour être efficace : diminuer le parallélisme de données en strip-minant les boucles pour factoriser le contrôle (l'anti-SIMT) et récupérer du parallélisme d'instruction (l'anti-scalaire).
    - En faisant ça, il explose le code optimisé par NV des cuBLAS de 60%, et il atteint 90% de la puissance crête "avec mémoire partagée" sur le produit de matrices.
    - Il recommence pour la facto LU : bottleneck, pas de barrière de synchro globale efficace. Il en bricole une avec un algo sans lock en ignorant royalement les instructions atomiques.

    À côté qu'est-ce que propose AMD (en hardware au moins) :
    - Du VLIW pour exploiter le parallélisme d'instructions et des vecteurs courts.
    - Des boucles gérées par une unité et des registres spécifiques.
    - Un ordonnancement non préemptif des threads, permettant d'utiliser un maximum de registres pour l'arithmétique tout en ayant assez de threads en vol pour masquer les latences mémoire (au lieu d'un partitionnement total statique des registres entre les threads).
    - Des barrières de synchro globales et une mémoire partagée globale rapide.

    Tient ça alors, plein de solutions aux problèmes rencontrés par Volkov...

    Et OpenCL passe totalement à côté de tout ça (à part ptet les vecteurs courts). D'où ma frustration.

  15. #165
    Pas tres technique mais je ne savais pas qu'un tel calculateur etait dans le TOP500.

    http://goodgearguide.com.au/article/270416

  16. #166

  17. #167
    ATI Avivo Video Converter, la suite de l'histoire :
    http://www.anandtech.com/video/showdoc.aspx?i=3475

    Moralités :
    - Un benchmark qui ne prend pas la qualité de sortie en compte ne sert à rien.
    - On peut encoder 2 fois plus vite que Badaboom sur GTX 280 avec juste un Core i7 en sacrifiant éventuellement la qualité.
    - AMD sont des ptits rigolos.

  18. #168
    Citation Envoyé par Møgluglu Voir le message
    - On peut encoder 2 fois plus vite que Badaboom sur GTX 280 avec juste un Core i7 en sacrifiant éventuellement la qualité.
    Le problème des tests de codecs dans le genre c'est qu'il y a manque d'informations cruciales pour faire une comparaison correcte : quels sont les algo de ME utilisés par les encodeurs "gpu" et autre processus décisionnels qui font de x264 l'excellent encodeur qu'il est mais "lent" vu que par défaut, il est plutôt orienté qualité. Sans compter la relative "incompétence" (le mot est un peu fort) en compression video des journalistes publiant ces tests.

    J'attends encore un test qui comparerais la vitesse de x264 configuré à qualité similaire (mais faut-il avoir toutes les infos nécessaires...), si tu vires toutes les options "intéressantes", il y a moyen d'aller sacrément vite.
    Je me porterais bien volontaire mais j'ai qu'une 8400GS foireuse sur mon laptop

    Bon je vais lire en entier cet article

    edit : la grosse loose Handbrake 0.9.3 est sorti avant le commit des optim SSE4/i7 dans x264... donc comparaison foireuse encore une fois
    Dernière modification par bill_baroud ; 16/12/2008 à 12h48.

  19. #169
    Mouai, j'ai vecu une histoire un peu similaire : un mec de FFmpeg ecrit une routine optimisee aux petits oignons pour calculer une iDCT. Je montre ce code a un specialiste en interne qui me dit "Ha ha ha, j'ai un truc presque deux fois plus rapide". Bien entendu, il s'est trouve que le rigolard se tapait de la precision. Et dans mon cas, on parle de specialiste, pas de journaliste...

  20. #170
    Bah disons que c'est comme ca que tu as CoreAVC, et le reste quoi

  21. #171
    Ah, moi qui croyais que c'était mon imagination : la qualité de CoreAVC, c'est pas vraiment ça !

  22. #172
    et encore, vous avez pas vu TMPEGenc...

    j'ai un test prévu bientot : sans les filtres accélérés CUDA (qui sont dans 90 % des cas inutiles), ça va moins vite avec CUDA activé :D

    et par rapport à l'AVIVO : sur une 4670 et une 4870, j'ai exactement le même temps...

  23. #173
    CoreAVC pire que quoi ? Quand je voit VLC/X264 ou FFDshow/H.264 je préfère nettement le rendu de CoreAVC ! Pour l'article de 'nand, y'a deux choses distinctes, la critique des Catalyst, et la ouais visiblement y'a des problèmes avec le Core i7, mais vu le nombre de personne qui ont du Core i7 à l'heure actuelle... pour les autres j'ai pas eu un pépin avec les Catalyst depuis bien longtemps. Pas de problème non plus avec les pilotes NVIDIA hein.
    Pour l'AVIVO la c'est plus chiant, et vraiment très bizarre. Un gros coup foireux de leur part la (AMD)

    [EDIT] Au final le truc qui me faisait plus chier avec les deux autres codecs c'est le deblocking, j'aime bien me balader dans mes vidéos, et sans un bon deblocking t'a soit un rendu foireux, soit tu attends une plombe qu'il retrouve ses marques... Ceci dit maintenant j'utilise plutôt MPC Classic HC et le DXVA, ça marche bien et c'est gratos. Une fois tout les 36 ca bug par contre, deux vidéos en même temps et paf freeze et reboot, ca pourrait venir des Catalyst d'ailleurs, mais sans preuve que c'est pas l'implémentation du soft...

  24. #174
    Citation Envoyé par Alexko Voir le message
    Ah, moi qui croyais que c'était mon imagination : la qualité de CoreAVC, c'est pas vraiment ça !
    Non, y'a quelques soucis avec des macroblocs très spécifiques qui sont pas forcement décodés comme il faut (mais en même temps y'a pas de codec qui les décode comme il faut), et ils font une conversion d'espace colorimétrique pour corriger les pbs de rendu, mais sinon c'est sensiblement similaire aux autres ... pour 50% de charge en moins

  25. #175
    Citation Envoyé par dandu Voir le message
    et encore, vous avez pas vu TMPEGenc...

    j'ai un test prévu bientot : sans les filtres accélérés CUDA (qui sont dans 90 % des cas inutiles), ça va moins vite avec CUDA activé :D
    Ha ben je vois que je ne suis pas le seul

    edit: sur un Q6600 et une 8800GT

  26. #176
    Ouais, mais vous êtes pas la cible !
    La cible c'est Pentium E2000 et GTX 280 \o/

  27. #177
    J'ai testé sur Core i7 (920) avec une GTX280 et une 9800GT, ça va nettement plus vite en soft. Même chose sur un Core 2 Merom 2,2 GHz et une 8600M GT.

    Sinon, j'ai pas eu de problèmes sur Core i7 et Catalyst pour l'encodage, en dehors du fait que le temps est le même sur 4670 et 4870 (et donc que le GPU est pas trop utilisé a priori)

  28. #178
    On parlait d'encodeurs et vous voilà partis sur les décodeurs, ben merde alors :D
    D'ailleurs c'est louche ces histoires de décodeurs H264, c'est la seule chose que défini la norme donc ils sont "censés" sortir la même chose, à toi de te démerder pour être plus rapide que la concurence :P
    C'est effectivement à mon sens, le seul emploi intéressant des GPU dans l'encodage vidéo : quand tu transcode une video H264, tu la décodes sur le GPU et tu balances direct à l'encodeur sur CPU qui n'a plus que ca à faire du coup

    Merci Donald Graft

  29. #179
    Je trouve ca assez amusant que les applis de demo sensees faire adopter le GPGPU au grand public et leur faire acheter un GPU cher et un CPU le moins cher possible aient au final des performances similaires aux CPUs modernes. On m'a tellement martele des accelerations de plusieurs x sur tout et n'importe quoi que au final je suis surpris de voir quelques dizaines de pourcent d'acceleration sachant que le CPU est massivement utilise.

    Une autre question, le core i7 qui a l'air de s'en sortir aps trop mal en soft contre le haut de gamme de Nvidia, il consomme combien par rapport au GTX280 qui encode ? J'ai un doute que la conso soit vraiment differente. Donc ~1x le power, ~1x la perf (si on met un CPU faible avec un gros GPU contre un gros CPU en soft), nettement moins de softs, mmmm. ...
    ...
    Ca me rappelle l'eternel debat linux contre windows (je suis deja dehors...)

    D'un autre cote, on voit enfin arriver des applis completes accelerees pour GPU et ce sont les premieres hors rasterisation. Il y a donc certainement une marge d'optimisation non negligeable, et des plateformes de tests/comparaisons vont etre developpees et ameliorees (en general la premiere generation de tests a des defauts de methodologie quel que soit le domaine). Les CPUs encodent de la video depuis un bon moment, et tout le monde s'est acharne depuis des annees a optimiser pour, donc finalement 1x a la sortie c'est pas mal du tout.
    fefe - Dillon Y'Bon

  30. #180
    Citation Envoyé par fefe Voir le message
    D'un autre cote, on voit enfin arriver des applis completes accelerees pour GPU et ce sont les premieres hors rasterisation. Il y a donc certainement une marge d'optimisation non negligeable, et des plateformes de tests/comparaisons vont etre developpees et ameliorees (en general la premiere generation de tests a des defauts de methodologie quel que soit le domaine). Les CPUs encodent de la video depuis un bon moment, et tout le monde s'est acharne depuis des annees a optimiser pour, donc finalement 1x a la sortie c'est pas mal du tout.
    En général, la méthodologie en GPGPU c'est :
    1. J'ai une appli quelconque.
    2. Je code l'algo vite fait en C monothread.
    3. Je lis le manuel CUDA.
    4. Je recode l'algo en CUDA en essayant de suivre les recommandations de Nvidia.
    5. Je mesure les perfs.
    6. J'augmente la taille de mon jeu de données jusqu'à atteindre le speedup maxi.
    7. J'écris un papier de conf et j'envoie le lien à Nvidia pour compléter leur applet Flash.


    Sachant qu'il n'y a en général pas d'existant sur GPU pour comparer l'implémentation à plate-forme identique, et qu'on trouve toujours des conditions où le GPU a l'avantage, la phase d'optimisation est totalement laissée de côté.
    C'est aussi un problème d'outils, c'est pas avec le profiler ridicule de Nvidia qu'on va optimiser quoi que ce soit. Du coup on fait de l'optimisation a priori en suivant des recettes de cuisine, et sans point de comparaison qui fera la différence entre un speedup de 5, 10 ou 20? Surtout que ça varie d'un facteur 10 suivant les conditions et le "degré de triche" des tests.

    Mais effectivement on commence maintenant à passer du papier de conf à l'appli complète, et c'est là que ça coince...

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
  •