Reprise du message précédent :

Exactement comme ton chéri de QuickSync...

Mais c'est pas grave puisque en gpgpu, on ne peut faire que du transcodage
Donc Intel a choisi la bonne solution, tu peux pas test.

Faut lire c'est ce que j'ai dit... j'ai néanmoins nuancé sur le fait que même si y'a Badaboom sur CUDA, une GTX 580 avec ces 244W de TDP serait fait démonté par une unité dédié de moins de 10W de TDP...

Retourne au CP apprendre la lecture et la grammaire je crois... je n'ai jamais dit qu'on ne pouvais faire que ça, simplement qu'il n'y avait que ça et PhysX sur le marché pour le moment en GPGPU...
 
Et personne ne ma démontré le contraire jusqu'à présent...

Pourtant, tu insistes lourdement. Et si tu étais si balèze que ça, tu saurais vers quoi le domaine tend.  
Mais j'ai peur que tu ne sois qu'un autre monsieur "jesaistoutmieuxquelesautrescarjefaisdujavamoimossieur"  
Donc retourne apprendre tes figures de style et ton orthographe/ta grammaire par la même occasion. Je trouve ça cocasse que ce soit toi qui me vannes à ce sujet vues les immondices que tu commets dans 3/4 de tes posts

Moi au moins je comprends ce que les gens écrivent...
 
Après je n'insiste pas la dessus, j'expose les faits... et comme dit, comme il n'y a que ça comme application pratique au GPGPU (tu n'as toujours pas trouvé de contre-exemple...  ) je peut pas trop parler d'autre chose.
 
Néanmoins vous pouvez croire au messie et qu'avant qu'on soit à la 3 ou 4e génération d'APU on est une révolution dans les perfs grâce au GPGPU et que de tout miser sur le GPU plus que sur le CPU dans un APU était le bonne solution.
Mais en attendant, aujourd'hui Llano vs Sandy Bridge, le GPGPU n'aura aucun poids dans la balance des performances...

C'est sur qu'avec des gens comme toi qui croient dur comme fer qu'Intel a choisi la bonne solution car le gpgpu/opencl/directcompute c'est du caca qui sera jamais utilisé...
ARM, Nvidia, AMD/ATi sont déjà à fond derrière. Je sais pas, ça me parait déjà pas mal quand même non ?
Si tu crois que la situation n'évoluera pas à la longue...
Surtout avec l'embarqué, tant qu'on peut exploiter de la ressource gratis, on ne s'en prive pas.
Mais vu que tu ne lis que ce qui t'intéresses, de toutes façons...

edit: les contre exemples, j'en ai déjà donné.  Mais cf. ligne au dessus
Et pitié, vanne sur l'orthographe/la grammaire mais essaie un peu de t'appliquer, j'ai les yeux qui saignent là

Déjà faut pas confondre tout. J'ai jamais dit qu'OpenCL/DirectCompute où le GPGPU en général était inutile, mais qu'aujourd'hui il n'était pas utilisé et que donc parié sur le GPGPU pour avoir de meilleur perfs c'était se fourvoyer...
 
Faut pas confondre API et programme, ni même théorie et pratique quoi...
 
On va remettre les choses au clair, le GPGPU ça a commencé avec les GeForce 8, il y a 4 ans et demi...
 
En 4 ans et demi, les seules application qu'on a vu naitre on été sponsorisées voir entièrement développées par NVIDIA où ATI...
Comme dit en gros on a :  
- PhysX via CUDA (massivement en production) / Bullet Physics via OpenCL (inutilisé en mode GPU dans un jeu fini à priori )
- l'API vidéo de NVIDIA qu'entre autres Badaboom utilise ou bien CoreAVC (pour la lecture).
- Les clients GPU pour folding@home.
 
Pour l'instant le GPGPU ça reste principalement cantonné aux applications de calcul scientifique ni plus ni moins.
 
Et pour moi le GPGPU n'a de toutes façons un intérêt que si le GPU >> CPU...
 
NB : Quels exemples pratique, car franchement a part du "tout le monde soutient OpenCL..." je ne vois pas grand chose...

Bon, finis, jugé et condamné, ca ne serviras à rien pour les années à venir.
Bon, MEI, tu fatigues là.

Ce qui est bien c'est que je dit totalement le contraire dans ce que tu cites...
 
Sérieusement, à la vitesse où ça va, le Llano et le Sandy Bridge seront dépassé quand le GPGPU sera utile...

Et je t'ai déjà donné la réponse... entre la recherche et les devs qui bossent sur les applis de môsieur Toulmonde, il y a une grosse différence, les seconds devant débiter et ne pouvant donc changer radicalement de méthode de programmation alors que les premiers ont justement pour objectif d'expérimenter.
 
Le fait est que dans pas mal de cas un GPU peut avoir un rendement énergétique au moins 2x meilleur que le meilleur des CPU, le problème c'est que, comme certaines têtes pensantes l'ont déclaré, on ne change de méthode que quand le ratio est >10x.

Bon ben vu qu'énormément de traitements (son, vidéo, signal en général) sont basés sur des fonctions mathématiques qui elles mêmes sont ensuite décomposées en multiplications/additions, je pense qu'une fois que les gens se pencheront comme il faut sur les ressources à dispo (et dans l'embarqué, je pense que ça se fera assez vite), le gpgpu décollera. Aujourd'hui, on en a encore du mal à avoir de l'appli multithreadée.  
Mais on y vient. Comme tu dis, les "proofs of concept" marche déjà pas mal. On a déjà un aperçu de ce que ça peut apporter potentiellement.
Et GPU >> CPU, à mon avis, c'est déjà le cas sur certains traitements. Le GPU ne remplacera jamais le CPU par contre.
Une fois que les mecs comme toi l'auront compris...
 
Flash accéléré comme l'a déjà dit gliterr. Les navigateurs dernières moutures. Il n'y a pas aussi Linux pour "remplacer" le moteur UVD pas dispo ?
Bref, le GPU apporte déjà.

 
Voyons cela:

 
Voila "donc parier sur le GPGPU pour avoir de meilleures perfs c'était se forvoyer".
 
Qu'ais je loupé ?

- Flash comme dit ce n'est pas du GPGPU, c'est juste un accès direct à l’accélération vidéo. C'est juste un bypass de DXVA en fait.
- Les navigateurs utilisent Direct2D/DirectWrite, c'est qu'une API d’accélération graphique, c'est juste le boulot d'un GPU (si si, ça fait même 25 ans... )
 
Faut pas tout confondre, l'accélération vidéo/2D on les as depuis des lustres... C'était GDI/VfW à l'époque, aujourd'hui c'est Direct2D-DirectWrite/DXVA, mais au final ça fait la même chose et c'est fait par les mêmes composants qu'auparavant.
 
Pour Linux qui font de la lecture vidéo en GPGPU, peut-être, m'enfin c'est le truc le plus farfelu qu'on aurai pu imaginer en GPGPU...

 
Peut-être sur le fait qu'aujourd'hui le GPGPU n'apporte rien et que donc il ne va pas pouvoir peser dans la balance.

Je sais pas ce qu'il te faut. On sort des exemples. L'accélération vidéo, c'est pas juste le moteur UVD/je ne sais plus quoi Nvidia potentiellement...
Continue à te palucher sur les processeurs Intel mais stp quitte le topic alors
Tu n'y apportes que mauvaise foi et troll en tout genre

Pourquoi faire un décodeur vidéo en GPGPU alors que :
- pour cettes tâche la majorité des CPU du marché suffisent
- les GPU qui savent faire du GPGPU ont aussi un moteur de décodage vidéo performant (sauf en faite le G80 en gros...)

Oui oui, bien sur.
Le truc c'est que si j'achète un proc à la rentré, c'est pas pour l'utiliser une seule journée en septembre 2011 et le mettre à la poubelle.
C'est l'utilsier pendant des années, et là ... à voir ce qu'il y auras.

Si on se projette même sur 2 à 3 ans, on a quand même pas grand chose de prévu niveau GPGPU...
En fait a part les rumeurs d'ajout de DirectCompute dans Windows 8 et la suite Live "2013" associée.
 
En plus dans 3 ans, quoiqu'il arrive tant la partie CPU que la partie GPU du Llano commenceront à être un peu à la ramasse, vu à la vitesse que ça va et que c'est basé sur des technos déjà anciennes...
 
Franchement, le Llano aurait des cœurs Bulldozer et des SP de Cayman, à la rigueur j'aurai été plus confiant pour une utilisation sur le moyen/long terme. Là franchement faut pas miser sur le futur, d'autant qu'AMD semble être décidé à accélérer et presser le pas.
 
---
 
Après on peut parier sur le futur, mais pour moi dans les 3 ans a venir on verra plus de logiciels qui implémentent l'AVX que de logiciels qui implémentent le GPGPU. Parce que ça reste plus simple, les gains sont limités mais profitable au plus grand nombre. Quand je dit plus simple je pense a deux choses :
- moins de modifications de code
- pas a connaitre plusieurs archis GPU afin d'en tirer le meilleur
- pas a être tributaire de la version x ou Y de tel ou tel pilote
 
Alors on va me dire que c'est complémentaire... Oui bien sur, mais après l'AVX on va avoir le FMA3/FMA4 qui va arriver, etc.
Tant que finalement les CPU apporterons des solutions, on privilégiera toujours améliorer le code existant en priorité.
 
Et même si le GPGPU est assurément utile, c'est pas demain la veille que ça se bousculera au portillons. D'autant qu'en pratique les tâches gourmandes c'est quoi :
- lire une vidéo (MPEG-4/H.264)
- lire une musique (MP3/AAC)
- afficher une image (JPEG/PNG)
- traitement photo
- traitement video
- jeux video
 
Pour la lecture vidéo et son transcodage, les GPU on des unités dédiée - le GPGPU n'apporte rien de plus.
 
Pour le son, ouf c'est un truc que même un Pentium 75 pouvais faire.
 
Pour les image, oui peut-être que point de vue perf/W on pourrai imaginer décoder ça matériellement, des DSP existent pour ça pour les SoC, à la rigueur je pense qu'on pourrai imaginer sacrifier quelques milliers de transistors pour ça dans le GPU si on voulais vraiment avoir des perfs de folie.
 
Pour le jeux video, bah là c'est déjà utilisé, mais là c'est pas l'IGP du Llano qui changera la donne... A moins qu'un jour on arrive à deporter des tâches DirectCompute sur l'IGP facilement... (je ne sais pas si c'est plus une question de pilote/DirectX ou code, mais ça ne semble pas possible aujourd'hui)
 
Pour les traitements vidéos/photos là y'a de la marge, mais même si Adobe se bouge le cul et arrête ces bricolages en OpenGL, ça reste des tâche que l'on ne fait pas de manière régulière et donc même si on aurai un gain de confort, ça ne changera pas drastiquement la vie de l'utilisateur.

Amen. Ainsi MEI a parlé

 
Ah bon... c'est très clair en effet.    
 
Moi qui croyais que c'était ATi qui avait été le 1er sur le GPGPU avec son R580 en mai 2006.
 
 

Dommage qu'ils se soient égarer en chemin car le GPGPU chez AMD c'est beaucoup d'effets d'annonce et peu de réalisations ...
 
Même les chinois ont préféré passer sur l'énergivore Fermi pour remplacer leur supercalculateur vedette ...
 
Unleash the teraflops ... Oui, mais quand ? ...

1. nVidia a payé les mecs de Folding@Home pour qu'ils abandonnent ATi/AMD et passent du côté vert de la force.
 
2. nVidia a pratiquement donné ses GPU aux chinois.
 
Finalement c'est celui qui a le plus gros compte bancaire qui gagne.

AMD n'a pas mis les moyens, c'est pas pareil ...
Attendre que les autres développent des outils à sa place a permis à CUDA de faire son petit bonhomme de chemin. Parallel Nsight est un bon exemple de l'implication de nVidia dans le domaine.
Par contre, AMD a tout un tas d'Opterons X86 en stock, peut-être que c'est juste un question de priorité ...

Pas avec une API publique, fonctionnelle et documentée.
 
La différence est là. Avec les GF8 NVIDIA a rapidement sortie CUDA, ATI avec les R580 c'est du bricolage, et il a fallu attendre les RV670 pour commencer à voir un SDK ATI Stream pointe le bout du nez...

Ouais ça déchire le GPGPU pour la vidéo, c'est clair
 
http://www.hardware.fr/marc/h264/i [...] eption720b
 
Ou pas

Ça manque juste de Badaboom dans l'article ... (qui scale +/- avec les GPU NVIDIA... p'tet qu'ils sont plus à jour niveau SDK CUDA )
 
Après comme dit ça reste le meilleur utilisation du "GPGPU" pour l'utilisateur final...

Sympa ce dossier

ce cher badaboom + cuda qui sort de la qualité pire que du divx3 une passe, mais bon c'est très très rapide.    
 
pour regarder une vidéo sur son téléphone portable pas retina & écran 3pouces c'est bon, mais sinon.....
 

A priori, Badaboom = Arcsoft Media Converter sur nVidia... donc oui, mais non quoi.
 
Sans aller jusqu'à dire que c'est plus rose en face, ça reste quand même du bricolage.

Dans Badaboom y'a juste Intel 2x plus perfs qu'une GTX 580 et ça scale car c'est ~25% plus rapide sur une GTX 580 que sur une GTX 560 Ti.
 
Donc à prori non c'est pas la même chose.

Ca reste de la bouillie de pixels, plus ou moins rapide

+1
 
Un encodage CPU avec 2 passes y il a que ça de vrai  
 

La TNT c'est du single passe la qualité est là...  

On a clairement pas la même notion de qualité.
 
Quand on passe d'une scène à un plan sombre (ou une image noire) et que la scène précédente persiste pendant 1s, c'est pas franchement de la qualité.

 
 
A condition d'aimer le 1080i

J'ai jamais vu ça sur les flux TNT...
 
En MPEG-2 c'est p'tet possible, mais en H.264 sauf à avoir un encodeur en carton.

Ce n'est pas la résolution qui fait la qualité d'un encodage...

ça me faite sourire ce que tu dis.
Tu parle de qualité sur la TNT.
Alors que la norme c'est du SD MPEG2 avec des bitrates inférieur au DVD donc bon    
Sauf pour les chaine HD où c'est du H.264, mais la plus part du temps l'espace de couleur est massacrée.

C'était juste un peu implicite vu qu'on parlais d'H.264...