Reprise du message précédent :

 
Oui, enfin, il est obligatoire de passer par des phases d'essai où le GPGPU n'est pas très convaincant pour qu'il le devienne...

c'est la même chose pour l'IGP dans les CPU de pc de bureau, useless, alors qu'on pourrait probablement avoir un CPU avec plus de coeur.

J'ai fait mon doctorat dans le domaine du HPC, je suis un petit peu au courant des usages du GPGPU en fait
 
Et les conclusions auxquelles je suis arrivé sont les suivantes.
 

• Je pense que le GPGPU se développe énormément à cause d'un effet de mode. C'est une technique qui a permis de sortir des tonnes de publications quasi gratuitement dans le monde de la recherche en utilisant le schéma j'ai un code qui tourne sur CPU => je le porte sur GPU => OMG mon portage GPU va 10 fois plus vite (quel scoop), du coup c'est un peu devenu le must have des labos de R&D.

• Le truc vraiment magique (comprendre scandaleux) avec le GPGPU, c'est que pour mettre son intérêt en avant, on en vient à faire des choses parfaitement inutiles. Du genre utiliser des algorithmes inutilement précis (parfois au-delà de l'erreur machine, logique) mais monstrueusement coûteux. Alors certes, ça balance des FLOPS sur GPU mais le résultat ne profite d'aucun gain qualitatif.

• Le gros problème du GPGPU, ça reste l'incompatibilité X86. Faut voir que les labos de R&D disposent de millions de lignes de code qu'il faudrait réécrire pour faire du GPGPU. Ce qui suppose également que tout nouveau développement doit être optimisé pour CPU et GPU. C'est une démarche complètement irréaliste, beaucoup trop chère en termes de main d'oeuvre. Il y a bien des tentatives pour pallier ce problème, notamment des techniques de génération automatique de code optimisé GPU par l'insertion de directives de précompilation (à l'image des directives OpenMP pour le multithread, voir ce que fait la société CAPS avec HMPP notamment) mais je doute que ça prenne. Ce genre d'approche supposerait que l'intégrité du code repose sur un produit fourni par une entreprise extérieure, leur déploiement me semble donc peu crédible. Intel a un gros coup à jouer avec le MIC sur ce point.

Bref, le GPGPU c'est sympa pour faire joujou dans son coin mais à mon sens, ça s'arrête là. Pour conclure, je tiens à rappeler que le plus gros supercalculateur du TOP500 est complètement dépourvu de GPU et fout une branlée de classe mondiale au numéro 2 du classement.

Pour le moment car pas démocratisé suffisamment mais c'est en se démocratisant que ça deviendra utile.

Mouais, j'ai un doute. Au final, ton CPU a plus de coeurs mais l'un d'eux est spécialisé en rendu. C'est pas idiot en soi, ça permet d'avoir un produit polyvalent et relativement économe en énergie.

D'accord mais pour quoi faire ? Que pourrait faire un GPU que le CPU ne sait pas faire aussi efficacement, sinon ce que le GPU fait déjà aujourd'hui ?
 
L'une des grosses pistes de démocratisation, c'était l'encodage et on voit le résultat. Intel a ridiculisé NVIDIA et AMD avec Quick Sync Video.

Qu'est ce qui empêche AMD de concevoir une puce optimisée pour le GPU-Computing pour ceux que ça intéresse (superordinateurs, monde pro), et une version "lite" dépourvu de DP/ECC/GPGPU qui pourrait satisfaire les besoins de 80% des gamerz, et qui serait plus abordable (taille, yields) tout en étant aussi performante (optimisée game only) ?
 
nVidia, serait surpris (copyright Wirmish) par une telle tactique, et n'aurait qu'une puce monstrueuse (taille, conso, prix) à mettre devant celle d'AMD.
AMD prendrait dès lors les devants sur les parts de marché, et le caméléon aurait besoin d'au moins une année entière pour répliquer, peut-être même deux.
 
D'un autre côté, si personne ne possède de carte GPGPU-ready, ça limite le développement des applis compatibles.
Mais ne dit-on pas que le client à toujours raison ? Si personne ne veut du GPGPU, alors pourquoi leur imposer ?
Si c'est si incroyable que ça alors les gens finirons bien par acheter les versions GPGPU, sinon c'est que c'était pas utile/intéressant dès le début.

J'avoue qu'une puce de même taille optimisé jeu pourrai poutrer.

Plusieurs choses que fait le cpu mais que peut faire plus rapidement le gpu comme ce que fait le gpu depuis 15 ans avec le graphisme.
 Dans le domaine des moteurs physiques, le physx montre (laisse entrevoir surtout vu qu'aucun jeu n'utilise réellement le physx accéléré par gpu à part pour quelques effets annexes mais pas pour la physique du jeu dans son ensemble) ce qu'un moteur physique accéléré peut faire qu'un cpu même multicore ne peut pas. Par contre va falloir qu'un moteur physique libre de droit et accéléré sorte car ce n'est pas le cas du physx (propriété nvidia oblige) ce qui empêche au physx de montrer la pleine puissance d'un moteur physique utilisant le gpu car les développeurs ne vont pas faire un jeu fonctionnant que sur carte nvidia (il  ya 10 ans oui mais plus aujourd'hui surtout sur PC). Et l'havox avec intel derrière n'est pas prêt à être accéléré par les gpus.
La physique est un domaine très demandeur de puissance comme le graphisme voir beaucoup plus et le cpu ne suit pas car on est à la physique aujourd'hui avec les cpus ce qu'était le graphisme dans les années 90 avec les cpu càd l'age de pierre en gros.

C'est sure que toutes ces choses ne concernent pas forcément le joueur mais nvidia et ati ne font pas des cartes graphiques spéciales pour les pro et d'autres pour les joueurs (ils pourraient peut être le faire mais ils ne le font pas)

Parce que deux puces conçues en simultané, ça coûte plus cher qu'une seule qu'on décline. Il faut payer les R&D, les chaînes de prod différentes, les drivers adaptés, pour satisfaire un public minoritaire qui ne rapporterait rien sauf à vendre les cartes à 300€ pour la moins chère. Bref... C'est pas très rentable, tout ça.

Tout à fait

Y'en a qui ont pas l'air de réaliser que les effets physiques dans les jeux peuvent être calculés grâce à ces fameux transistors soit disant sur-numéraires. ^^
 
C'est ce que fait PhysX. Il n'y a pas de puce PhysX sur les nvidia. C'est juste une nieme API propriétaire qui fait du GPU computing, en utilisant la FPU de la carte graphique.
 
Pour réponde à Marc,  je comprends tout à fait vos réticences, ce n'est pas un domaine très accessible pour les personnes qui ne baignent pas dedans. Mais Anandtech suit ces performances depuis pas mal de temps déjà (il a déjà eu des tableaux publiés à l'époque des GTX580/570/560 à traver SLG) et au moins un autre site a publié un bench sous Luxmark. AMD a même un slide avec le gain en "efficacité" sous Luxmark.
 
Alors c'est vrai que c'est une application de raytracing qui n'est pas forcément représentatif de l'ensemble des possibilités en GPUComputing mais c'est intéressant néanmoins. Le raytracing c'est déjà un stade plus complexe en matiere de programme, ce n'est pas le ptit algo super particulier qui va mettre en lumière qu'une partie très ciblée de l'architecture. Non c'est déjà pas mal de lignes de code et c'est certainement pas écrit pour faire plaisir à une marque ou une autre, ou pour favoriser la carte du moment (ce doit être future proof). D'ailleurs ce qui différencie CUDA de l'OpenCL, d'après ce que j'ai compris, c'est un peu ça. CUDA c'est un langage assez bas niveau qui, dans l'esprit, peut permettre des optimisations de la mort sur une architecture (et en plus sur celle d'un seul fabricant) au risque d'avoir du code qui marchera moins bien sur une prochaine génération de carte, alors qu'OpenCL est prévu à la base pour fonctionner sur diverses plateformes et même sur des CPU.  
 
Et c'est amusant de lire que AMD ne fait que rattraper son retard en GPU computing. Car en fait si Nvidia a pas mal fait de com sur le GPGPU en fait les GTX580 ne sont pas des championnes en raytracing OpenCL. Pourtant ce n'est pas un domaine qui est complètement neuf non plus. Je dirais qu'il rentre dans une phase déjà bcp plus établie.  
 
Mais si une carte comme la HD7970 sans optimisation ni rien fait déja 2x mieux qu'une GTX580 en raytracing, c'est pas une petite nouvelle.

On est bien d'accord pour dire qu'on parle de rendu là. Pas de GPGPU. Le GP dans GPGPU, ça veut dire General Purpose, ça suppose donc qu'on parle d'autre chose que de rendu

Alors ça c'est l'exemple typique de l'utilisation débile du GPGPU.

• D'une part, on sait parfaitement faire des moteurs physiques évolués sur CPU. Aucun besoin de GPU dans ce domaine. Alors évidemment, faudrait commencer par ne pas désoptimiser la gestion de la physique sur CPU comme l'avait fait NVIDIA.

• D'autre part, l'évolution actuelle des CPU et GPU me fait penser qu'on a tout intérêt à ne pas confier la physique au GPU. D'un côté, on a des GPU qui peinent à accomplir correctement les tâches de rendu. De l'autre, on a des CPU dont les cores se multiplient mais restent sous-exploités par les développeurs de JV. Je te laisse en tirer la conclusion qui s'impose.

Non mais comme dit, le raytracing c'est pas du GPGPU. Arrêtez avec cet exemple.

 
tu oublie comme même le très très gros problème du raytracing supposé être LA technique rendu du future, et jusqu'au jour, aucune solution, la seule approche valide aujourd'hui passe par le GPGPU en OpenCL, et je pense que AMD et Nvidia l'ont bien compris. Donc dans 10 ans par exemple, on peut avoir des monstres de GPGPU capablent de raytracing sans doute les GPU de la XBOX 3*pi et la PS5  
 
 

Ouais sauf que dans dix ans je serai peut être mort quoi
On s'en fout que ce soit la techno de dans X années, aujourd'hui, à part pour retailler des vidéos pour trucs portables à la con, on en a rien à talquer du GPGPU

 
effectivement t'as raison, mais tout le monde passe par là.
 
 

Le raytracing est une technique de rendu, ça n'a rien à voir avec du GPGPU. Je sais pas si c'est bien clair pour tout le monde mais le boulot de base d'un GPU, c'est le rendu. Et par GPGPU, on désigne les utilisations du GPU à des fins autres que le rendu, d'où le General Purpose dans GPGPU.
 
Le jour où AMD décide de passer au raytracing, l'architecture des GPU sera modifiée pour effectuer le raytracing de la manière la plus efficace. Comme ça a été le cas avec les shaders il y a quelques années.

hum...Je sais pas si vous avez vu mais le lien donné page précédente avec un stock de 28 cartes, annonce le prix de 605 dollars. C'était quoi le prix officiel 549 dollars? Nan parce que si on connait la même inflation dès la sortie en France - quelqu'en soit la cause d'ailleurs - ça risque de devenir difficile à justifier Franchement, à plus de 550 euros, voilà quoi...

 
le problème ce que je sais pas si AMD et nvidia ne peuvent pas ou ne veulent pas avoir des solutions dédiées pour le raytracing genre Ray HD 7970 à côté des Radeon, tout ce que je sais, ce que c'est truc marche plutôt bien avec des CPU genre power 7 ayant des dizaines de threads, et que AMD et nvidia ne sont jamais prononcé ouvertement sur le sujet, et aiment plutôt faire régner la confusion      

Malheureusement tu tires des conclusions bien trop hâtives avec les résultats dans un seul moteur
 
Et qui dit OpenCL ne dit pas portabilitée assurée, cf les applis OpenCL qui ne fonctionnent pas sur 7970 (FLACCL, Folding...)
 

 
Je suis le GPU computing de très près depuis ses débuts, on doit d'ailleurs être la première publication à avoir publié des résultats à ce sujet  
cf http://www.hardware.fr/articles/67 [...] t-1-2.html
 
Je n'ai encore vu aucune publication tester réellement le GPGPU. Lancer des benchs sur 5-6 softs trouvés à gauche et à droite permet certes de cocher la case "page gpgpu" mais n'est pas très pertinent compte tenu de l'influence que peut avoir le moindre détail dans le code, impossible d'en tirer une autre conclusion que "l'algorithme machin en version xxx écrit par bidule est plus rapide sur tel GPU". Définir un protocole de test intéressant pour le GPGPU, qui donne une information fiable et utile, est loin d'être aussi simple que ce que fait par exemple Anandtech à l'heure actuelle. On peut bien entendu dire que c'est mieux que rien ceci dit.
 
OpenCL est en fait plus bas niveau que CUDA (il correspond au mode driver de CUDA, une version bas niveau du CUDA classique), ce qui explique toute la problématique : un code OpenCL est conçu en vue d'une architecture particulière. Certes il peut potentiellement tourner sur différentes architectures, mais il ne tournera efficacement que sur l'architecture pour lequel il a été conçu. A termes on s'oriente vers des langages de plus haut niveau tels que C++ AMP avec qqs fonctions très sensibles pour les performances  codées via un langage de plus bas niveau voire en asm et optimisées finement pour les architectures principales.
 
Pour info, bien avant que le GPU computing ne soit abordé publiquement par les fabricants de GPU et que CUDA débarque, c'est chez AMD que j'avais été invité pour en parler d'une manière informelle. AMD s'est cependant fait doubler joliment par Nvidia hehe

Explication ?
Pilote surement, non

Edith : après retour en arrière des pages non lues (5 environ, flemme toussa ...)
http://forum.hardware.fr/hfr/Hardw [...] m#t8161356

 
 
quand tu vois le temps que ça a mis pour le 64bits pour convaincre et encore (c'est franchement loin d'être le cas, et y a des baffes qui se perdent chez plusieurs éditeurs qui se complaise à nous refourguer la nouvelle merde 32bits remillésimée chaque année, alors qu'une version 64bits aurait des avantages certains sous windows)... car microsoft pousse au cul en ne proposant plus que des windows server only 64bits
 
en même temps intel aussi doit bien y mettre de l argument sur le 64bits maintenant, c'est un des arguments qu'ils ont pour le moment dans le domaine serveur face à un ARM, qui lui n'est présent plutôt sur du matos genre "nas grand public"
 
 
le gpgpu 5ans qu'on en parle avec l'arrivée de la 8800gtx en nov 2006
 
pour au final avoir eu quoi... un premier encodeur video "badaboom" en octobre 2008 car nvidia à un peu poussé au cul de voir que son argument à 2 centimes "gpgpu" tenait pas la route pour justifier l'explosion de transistor dans les gtx2xx
 
bien sur n oublions pas de dire que l'encodage était de merde
 
et encore aujourd'hui décembre 2011 l'encodage via gpgpu reste de merde
 
bref y a que les accro du calcul scientifique qui sont heureux...., car la R&D de ces "gpu" pour scientifique est en grosse partie épongé par les utilisateurs lambda
 
qui a rêver j'ai plus d'espoir dans un "coprocesseur" quantique ou d'un système trinaire que dans le gpgpu
 
donc encore heureux qu'au moins il nous ai pondu le "powertune" chez AMD histoire de calmer la joie de transistor qu on utilise pas "dans notre monde" de non scientifique

 
si je me rappel bien, c'était du CTM ou CMT, mais effectivement nvidia coupé l'herbe sous les pieds d'ATI à l'époque avec CUDA      

oui c'est sur que le "gpgpu" existait déjà sur des carte non dx10 de Mr nvidia
 
pour les trucs genre boinc ... c'est sur qu'avec tout les super calculateur sur la planète notamment commandé par les service armée de chaque pays  
faut surtout demandé au quidam de donné de sa machine et de son électricité pour "de temps en temps" peut être trouvé des remèdes à des maladies, face au supercalculateur militaire chèrement payer avec les sous des administrés de chaque gouvernement pour calculer comment pondre de nouvelles armes (bactériologique ou non) pour se foutre plus rapidement sur la gueule et donc se foutre en l'air
 
pour se foutre sur la gueule on trouve toujours du pognon   pour sauver des vies bizarrement on trouve pas... histoire de bien engraisser les labo privé
 
d'ailleurs me vient une question conne, SI un gpu à un jeux d'instructions si simple...  pourquoi un gpu ne carbure toujours pas à des 3/4Ghz comme un cpu, pourtant lui censé être plus complexe
 
j'ai envie de dire que logiquement c est le cpu qui devrait plus en chier que le gpu à grimper en fréquence ????
 
car n'en reste pas moins qu'un gpu même en usage gpgpu ne se suffit pas à lui même... faut au moins 1 cpu pour gérer plusieurs gpu... donc qqpart un gpu peut pas gagner... vu qu'il a une dépendance au cpu qu'on vous nous faire croire "trop pourri" face à du gpgpu soit disant de roxor    
 
bref y a un juste milieu qqpart entre un cpu "x86" trop complexe et un gpu trop simple... faut pas chercher plus loin pourquoi microsoft lorgne coté ARM  
 
aaaaaah vivement des softs écris en WinRT sous windows 8 pour une nouvelle guéguerre ARM/x86, car la guéguerre cpu/gpgpu n'en est pas une, c'est de la poudre aux yeux
 
c'est juste chiant que cette guerre débute à arme inégal avec ARM qui n'a pas encore le 64bits  

Ça coute plus cher, ok.
 
Mais bon, AMD produit déjà des chipsets, des APU, des CPU, et des GPU, et plusieurs sortes pour chaque catégorie, alors c'est pas 2 puces de plus qui va couler AMD.
 
De plus les GPU "non-GPGPU" seraient vendus en plus grande quantité, les coûts de conception seraient donc facilement amortis, et grâce à une taille plus petite les coûts de production serait aussi plus bas.
 
Les versions optimisés GPGPU recycleraient l'archi de base, en ajoutant les trucs manquants, ce qui permettrait de réduire les coûts de développement.
Et puisque ces GPU s'adresseraient au monde pro, les prix de vente seraient plus élevés, et la marge de profit serait beaucoup plus élevée, compensant ainsi le faible nombre de cartes pro vendues.
 
Mais bon, il semble que tout le monde (sauf les joueurs) veut imposer le GPU computing à tout le monde.

Faux, avec un cpu on ne sait pas faire des moteurs physiques évolués ou alors ton terme évolué pour toi est le terme préhistorique pour la réalité.

Contre argument: l'havox ou un moteur physique maison et tu vois sans problème qu'on est encore à l'age de pierre.

La physique passera par les gpus obligatoirement (ou des chips dédiés) comme est passé le graphisme ou alors on va rester très longtemps avec des moteurs physiques digne des moteurs graphiques des années 80.

Quand on regarde la physique d'aujourd'hui dans les jeux et celle d'il  ya 10 ans, à pars 2 ou 3 effets à la mode rien. Et si le cpu était aussi puissant, pourquoi les effets made in physx acccéléré ne sont pas généralisés? Pourtant avec l'havox ou un autre moteur ils sont faisables et nvidia n'a rien à dire. Or pourtant rien mais alors rien (et ces effets sont pourtant que quelques petits effets) et nvidia n'a rien à voir là dedans pour peu que le développeur n'utilise pas le physx.

Non ça ne se passe pas bien vu que ces moteurs physiques ne gèrent rien ou presque. On se retrouve avec une physique primaire et pleins d'aberrations qu'on ne devrait plus avoir de nos jours sans parler de l'absence d'interaction entre de nombreux objets et je ne parle pas d'interactions un poil complexe).

Je peux comprendre que certains voient les moteurs physiques actuels comme évolués car il y a 2-3 effets rigolos comme le ragdoll ou le fait qu'on puisse interagir de manière primaire avec une caisse mais vous vous faites leurrer d'une par ce que vous voyez or la physique ce n'est pas comme le graphisme, beaucoup de choses n'est pas visuel et de 2 la politique exécrable de nvidia avec le physx vous donne une haine mal dirigés contre le moteur physique accéléré alors que la haine ne devrait aller que vers nvidia pour ceux qui en ont.

La physique par CPU cela ne peut pas fonctionner car un CPU n'est pas assez puissant (l'havox ou les moteurs propriétaires sont du même niveau que les premiers moteurs 3d software càd ne gèrent rien ou presque). C'est la même chose que pour le graphisme.

On n'est pas prêt alors d'avoir des moteurs physique un tant soit peu crédible si on va par là.

La physique n'est pas gadgets car sans physique point de jeu même si la physique est très succincte.

Cependant avec les portages consoles on est pas aidé.

je trouve pourtant que la dynamique des fluide d'un havok par exemple est très bien prit en charge par un "bête" cpu moi
 
sauf que tu va prendre le jeu moyen, qu'est ce qui se passe... on le vois très bien avec un crysis 2 comparé à un crysis 1
comment tu veux appliquer la dynamique des fluides à des objet grossier inerte
un objet ne peut pas être ne peut pas être juste "une peau"  
 
il lui faut une masse, il lui faut des paramètre de résistance, point de rupture, et surtout un objet n'est que la somme de plusieurs autre objet de base plus élémentaire (des vis, des plaques, des engrenages.....)
 
partant de là c'est bien beau d'avoir un moteur physique si genre dans un crysis 2 t'as un camion fait d'une seule pièce monobloc comme si c'était un bout de bois taillé ...
 
maintenant c'est sur c'est pas demain la veille qu'on aura un gestion de la physique poussé jusqu'à la réalité  
genre tu déglingue le radiateur d'un véhicule le moteur surchauffe et paf il arrive à son point de rupture et le véhicule est mort
 
mais en même temps qui veut unegestion des phénomène physique poussé jusqu'à là... personne
car ça reste un jeu, on a pas envie d'avoir les mêmes duré de dégradation que dans la vrai vie, car on a pas envie d'attendre 6 mois qu'un truc se casse... on joue qqheures par semaines à un jeu, on ne passe pas sa vie devant son jeu car on a une vrai vie à coté
 
on tombe alors dans la physique type "hollywood" spéctaculaire
 
genre t'es dans une pente tu fait coulé du carburant sur la route jusqu'à une unité ennemi, tu fout le feu au carburant
 
tu explose une bagnole, tu veux que des débris en ressorte avec une zone d'impact
 
bref tu veux une physique à la "domino"  
action/réaction/et effet(s) collatéral
 
exemple tu balance une grenade sur un toit, ça effondre le toit effet collatéral ça dégomme l'ennemi qui est dans la pièce en dessous du toit
 
partant de là mais pour moi ça ne peut impliquer qu'une chose, les devs de jeux doivent en passer par une bibliothèque "de pièces" "d'objets" qui sera réutilisé au fil de leurs jeux ce qui implique des bibliothèques à constituer par époque/genre
 
pourquoi, car chaque objet va demander bien plus de boulot à être travaillé pour ensuite pouvoir être réutilisé
LA ça donnerait une raison d'être au DLC j'ai envie de dire dans des mondes persistant
 
genre dans un GTA l"épisode V hop on verrait déjà une gestion de physique poussé des véhicules
ensuite paf 2ans plus tard GTA VI on pourrait entrer dans tout les immeubles
ensuite paf GTA VII le mobilier de tout les immeubles aurait leur gestion de physique
GTA VIII la physique des vêtements
etc...
 
il faut voir l'avenir de jeux physique comme un flight simulator avec des add-on de nouveaux avions
il faut qu'un scénario lié à un jeu (un jeu se doit d'avoir une gestion de multiple scénario) puisse profiter de nouvelle brique de conception sans devoir tout réécrire
 
il y a un énorme marché pour un éditeur à se faire avec un jeu modulaire qui intégrerait son propre "market"
tout à chacun pourrait créer de nouveaux objets comme on créé des applis sur un apple store, un android market
cet objet une fois acheté pourra être "ajouter à une liste aléatoire" géré par le jeu (genre une liste aléatoire de véhicule qu on croise dans une rue dans un GTA)
soit une possibilité de remplacer par un autre
(dans la liste je remplace le véhicule "taxi" générique de l'éditeur par mon véhicule taxi custom v3 acheté 1.3 euros que je peut exploser à mon bon vouloir)
 
bien sur on pourrait aussi mettre sur ce market des "éléments, objet"  tout ce qu'il y a de plus gratuit (tout comme un android market ou apple store)
 
l'idée de proposé le choix payant /gratuit est que
1) pour payant, un pourcentage revienne à l'éditeur (pour payer les serveurs etc...)
2) gratuit après y avoir motivé une plus grosse communauté à s'y mettre et fournir de nouveau truc
3) on pourrait même intégrer une règle, lorsqu'un objet payant a rapporté plus de tant de $/€ au moddeur qui l'a créé, celui ci devient gratuit (ce qui permettrait au bout d'un temps de pouvoir l'utiliser librement dans des scenario tout autant monnayable)  
 
un jeu qui pour moi est un modèle sur la philosophie que doit avoir un jeu video maintenant
c'est sur PS3: littlebig planet 1 et 2
 
sur PC, ubisoft semble vouloir le faire avec maniaplanet
 
mais en tout cas c'est certe pas avec un jeu cloisonné comme un "SIM's 3" que je conçois l'avenir du jeu video
 
bref le problème pour des jeux "évolué" ce n'est plus "le temps homme" pour un éditeur  
le problème c'est d'accepter et de rendre assé flexible un jeu avec des outils mis à dispo à chacun pour que "chaque homme" puisse fournir de son temps à faire évolué le jeu  
après une fois mis en ligne sur un "market" libre à chacun de valider ce temps homme de chacun à être mit dans son jeu localement ou pas
 
bref l'avenir c'est de donner une vrai place et une vrai légitimité au moddeur, avec retour financier possible pour celui ci
 
et certainement pas de cloisonner de partout un jeu pour qu'il ne soit plus moddable
 
d'ailleurs par rapport à ça on voit comment les éditeurs travail à l'envers avec leur moteur de jeu
tu prend les jeux actuel, il te propose LEUR add-on payant
qu'est ce qui se passe quand celui ci est mit en vente... TA VERSION LOCALE se tappe une mise à jours car ils force l'intégration de ces add-on quand bien même tu ne les débloquera pas en les achetants
ça prouve bien que la modularité est à chier ... on est à l'inverse d'un "flight simulator" ou tu n'ajoute que ce que tu veux utiliser
 
bref dans les jeux "actuel" en grande majorité si tu achète pas les dits DLC, ça n'empeches pas que le dossier de ton jeux fait pas ... je sais pas 20Go de données... alors que si t as pas payé les add-on... en fait tu n'en utilise peut être que 16Go
 
puré ça c'est à peine marché sur la tête en terme d'optimisation

Je maintiens, on sait parfaitement faire du moteur physique évolué sur CPU. Le problème vient à mon sens plutôt des développeurs qui n'ont pas les compétences pour faire ce type de moteur.
 

Excuse-moi mais tu racontes de la merde.
 
Premièrement, je sais pas si t'es au courant mais le développement de JV, c'est un peu l'empire du fake. Le principe est justement de donner au joueur un sentiment de réalité (que ce soit pour la physique ou les effets visuels) en utilisant une méthode qui souvent n'a strictement rien à voir avec la réalité. Par exemple, pour faire avancer des vagues, on ne résout pas les équations de Navier-Stokes, on se sert d'une bête fonction mathématique qui reproduit visuellement un mouvement cohérent avec celui qu'on s'attend à voir.
 
Tu dis que le CPU n'est pas assez puissant, pas assez puissant pour faire quoi ? Je sais pas si tu as quelques notions de physique mais en gros, la physique qu'on retrouve dans les démos de PhysX par exemple, c'est de la physique des chocs. L'approche dans ce cas consiste à résoudre un problème à N corps (c'est-à-dire qu'il s'agit de l'approche la plus basique qui existe, c'est pas comme s'il existait des hiérarchies de modèles) qui revient en première approximation à résoudre un système linéaire. Tu crois qu'on est infoutu de résoudre un système linéaire sur CPU ?
 
L'affirmation consistant à dire qu'un CPU est moins puissant qu'un GPU, c'est uniquement basé sur les FLOPS affichés, c'est vraiment l'argument du pauvre. Le truc, c'est qu'il est nettement plus facile d'exploiter un CPU à fond qu'un GPU : on a des compilateurs plus performants (icc 12 est une tuerie), des prédicteurs de branchement... De ce que j'ai vu dans la vraie vie, sur des cas "pratiques" (donc non idéaux) et où les optimisations sont faites sur CPU et GPU, on a maxi un facteur 2 en faveur du GPU. Peanuts quoi compte tenu de la marge dont disposent les CPU en termes d'enveloppe thermique.

Si tu maintiens quelque chose de faux, je ne peux rien dire.

Ton expression préféré que tu ressors à chaque occasion. Évite à l'avenir car on a pas élevé les cochons ensemble comme on dit même si cette phrase commence à relever du running gag donc les remarques comme ça tu te les gardes pour toi, merci

Tu t'es pas suffisamment décrédibilisé comme ça? On dirait pas pourtant. Désolé mais comme sur la HD7970 celui qui dit de la merde n'est pas moi.

Pour le reste, je n'ai pas envie de continuer le hors sujet. Je n'ai pas envie de te convaincre vu tes avis bien arrêté (trop) et ton manque d'ouverture (voir tes commentaires à la sortie des tests du hd7970).

Il y aurait tellement d'exemples pour te prouver que tu as tord que je n'ai même pas envie de m'attarder à le faire sans parler que dire de quelqu'un qu'il dit de la merde n'aide pas à la discussion (je ne sais pas quel métier tu fais mais si dans mon métier je traitais les gens de la même façon je serais au pôle emploi depuis longtemps or qu'on soit au boulot ou dans la vie, un minimum de civisme s'impose (ce n'est pas parce que tu es caché derrière un pseudo qu'il faut te permettre ce genre de remarque désagréable)). L'avenir te le montrera de toute façon sans que je n'ai à le faire.

 
un gros +1

Bon alors au vue de tous ça
 
Racheter une 6870  et une alim (350€ les 2) car j ai qu une 600w  
Ou revendre ma 6870 pour acheter une 7970 ?? (500€ - 100€ peut etre ??)

Il n'empêche, pour l'utilisateur lambda comme moi, le GPGPU n'a en l'état pas le moindre intérêt, et reste un aspect redondant, inutile, mais qu'on paie certainement quand même.
 
Alors WHY ?
 
Si ce n'est pas utile, pourquoi l'implémenter déjà?  Pourquoi ne pas continuer la R&D et sortir le truc quand il y a réellement cohérence et pertinence pour le marché et l'utilisateur final?
 
 

 
1) une hd7970 à 3Go là ou un crossfire de hd6870 ne restera que 1Go
 
2) moins de pb d'attente de "patch" de drivers en mono gpu qu'en bi gpu
 
3) hd7970 ça prend moins de place que 2 x hd6870
 
bref si t occulte l'aspect argent, tout est en faveur de la hd7970