Reprise du message précédent :

 
la possibilité d'exécuter plusieurs kernels en même temps va probablement arranger les choses pour le physx, i.e. plus besoin de l'exécuter sur un second GPU pour avoir de bonnes perfs (ce qui jusqu'ici nie un peu l'intérêt du truc!)
http://www.hardware.fr/articles/77 [...] uting.html
 
pour ton autre post.. tu mentionnes les compute shaders en tant que partie du pipeline 3D.. moi qui croyait que leur intérêt c'est de ne pas en faire partie . je crois pas que ce soient des shaders.

La gestion simultanée de plusieurs contexte est une chose, mais ça demandera toujours d'exporter et réimporter des données.
 
Pour les Compute Shaders, ils font bel et bien partie de Direct3D, par contre ils sont accompagnés de DirectCompute qui permet de les exploiter en dehors.

 
Il semble surtout que la gestion ECC soit réalisée directement par Fermi et pas "par la RAM". Conséquence prévisible, les perfs mémoires seraient amputées en raison de la gestion "software" de l'ECC.
 
Du coup, sur une version "sans ECC" utilisée sur les GF, on pourrait récupérer une partie des perfs utilisées uniquement pour la gestion de l'ECC...
 
Spéculation, toussa

Je crois pas que ça demande beaucoup de boulot l'ECC, c'est ultra simple, ça bouffe juste de la mémoire et ça ajoute des latences. Vu que les contrôleurs mémoire sont prévus pour, les latences devraient être assez bien masquées, j'ose espérer.

 
C'est bien le seul intérêt, oui.

Pour l'Overclocking par exemple?

il vont peut etre mettre en place un mode un peu comme le mode turbo d'intel....  
 
(profil 2D , 3D , 3D full charge?  ) afin de gerer au mieux la dissipation et la conso?

Ca fait plus de 5 ans que c'est en place sur les cartes graphiques, même une antiquité de Radeon 9700 était en full solid caps... comme quand MSI parle de "condensateurs de qualité supérieure", c'est bien de ça qu'il s'agit, des condensateurs à électrolyte solide qualifiés à 105°C...
 
A croire que c'était une réponse au "pure ceramic capacitors" du slide vantant l'overclocking de la HD5970, tout aussi stupide.

On parle de Tesla donc je sais pas ce qu'ils vont faire, mais c'est certainement pas pour l'OC ^^

 
Sans déconner, il serait temps que t'aille faire un peu de dev 3D ça te ferait du bien.

1699,99 $    
 

Tout ce que je vois, c'est que d'un point de vue conceptuel, le comportement physique d'un objet modélisé est à son squelette (ou plus d'ailleurs) ce qu'une texture procédurale est à une surface.
 
Après, que très peu de moteurs voire aucun moteur ne fonctionne de la sorte, ça n'est pas le problème, le fait est qu'il est bien plus logique de lier un compute shader que d'exporter des données pour en réimporter de nouvelles.

Bah 1699.99$ pour une carte mère à 500~600$ + 4 x GPU à 300~400$ c'est pas trop cher.
C'est ce qui se fait de mieux sur nVIDIA à l'heure actuelle et eVGA est le seul à le proposer.
 
De plus ils proposent l'évolution vers le prochain GPU HDG nVIDIA.
Je trouve que c'est un super coup marketing.

ya moins cher en carte-mère mais après cela ne fait peut-être pas marcher quatre GTX285 en SLI.
http://www.topachat.com/pages/deta [...] ine=clubic
 
je suis "curieux", ou plutôt j'ai envie de me foutre de la gueule de quiconque achèterait ça pour jouer.. en toute probabilité le 4-way aura les perfs du 3-way.

Oui y'a moins cher, d'un autre côté quelle carte mère permet de faire tourner 4 GTX285 ensemble?
A priori les test effectués sont positifs.

 
C'est EVGA. Tout ce qu'ils vendent est 100€ trop cher, mais comme ça ils font une réduc' de 100€ à ceux qui enchaînent les cartes EVGA.

La supercomputer a 4 ports 8X et le tri-SLI donc ce quad SLI peut marcher, faut trouver le pont, quoi. De toute façon aux dernières nouvelles c'est pas standard, si ?

Ces cartes sont conçues par EVGA
Il est le seul à les fabriquer

 
+1
Le Quad-SLI ne fonctionne que sur la (ou les ?) carte(s)-mère eVGA équipées de quatre ports PCI-Express 16x 2.0 .

et part taper les benchs ca sert a quoi cette config?

 
A sortir EDF de la crise, pourquoi ?

C'est réellement si puissant que ça ?  

 
Elles ont quoi de spécial, des decelerator NF200, comme dit charlie ?
 

 
Par rapport à 2 5970, la question se pose.

Ah ah je viens de remarquer un truc qui va faire bondir Tridam :
 

 
Les 285 EVGA ont 3*6 pins PCIe ! Au lieu de 8+6.
 
ça va être chaud de faire un boîtier bien rangé ^^

Ca va surtout être chaud de trouver une alim qui a 12 câbles pcie 6 pins ...

Je me disais bien aussi qu'il y avait un truc zarbi sur ces cartes ...
 
N'empêche une config qui doit consommer près de 1 000 W (si ce n'est plus   ) en burn juste pour jouer ça me laisse pantois

Faut aussi avoir un boîtier gigantesque et pourvu d'une ventilation solide ... parce que ça doit chauffer !  
M'enfin, c'est aussi inutile qu'un SLI de GTX295, ce genre de machin ... enfin, ça l'est encore plus, puisque ça consomme/chauffe plus et que ça prend bcp de place ...

pour une bécane cuda ça fait une bonne affaire, reste à trouver un boîtier noir et rouge.

pas besoin de nf200, sur ce socket tu peux avoir 4x8 lignes PCIexpress pour les cartes vidéo en natif. (pareil avec un AMD 790FX)

Ou un CF de HD5970...

Nan mais pour du 3 WAY / 4 WAY SLI il faut le NF200

justement un comparo Xfire SLI  
http://www.hexus.net/content/item. [...] 212&page=1
bon y a pas de quad ou tri certes mais on voit clairement qui est devant (remarquez c'est normal, c'est pas la meme génération de revisions non plus)

 
Pas besoin de nf200 pour avoir ces ports, je sais, mais pour avoir du quad SLI @nvidia, pas sûr.
 
Sinon il y a des fous qui ont des farm de GTX295 avec 3 ou 4 par mobo, juste pour SETI    
 
Bon, d'un côté, ça consomme moins que l'équivalent avec uniquement des CPU (faudrait genre 2 i7 920 par GTX295).

http://www.presence-pc.com/actuali [...] 200-33096/
 

 
Cultive-toi au lieu de penser et de parler comme si tu avais toujours raison .

Rien compris  

On dirait que l'image de facebook est un fake :
 

Ca revient au problème de la DLL C# faisant des appels système utilisée dans un prog C++: on fait les calculs sur le GPU, mais on passe par une couche intermédiaire qui en fait sortir les données et les lui renvoie.
 
Quand on utilise un GPU dédié "PPU", ça ne pose pas de problème, mais quand on tourne sur un seul GPU, ça saccage tout.
 
Mon avis est que plutôt que de proposer une bête interface comme le fait PhysX, il faudrait développer un moteur 3D intégrant une interface similaire pour le développeur de contenu mais générant un code directement exécutable, sans changement de contexte comme c'est le cas avec PhysX, ce qui reviendrait à utiliser les compute shaders et leurs cousins des geometry shaders. Le seul souci que ça pourrait poser, c'est une certaine consommation de mémoire, mais dans pas mal de cas on la gaspille déjà (textures énormes et non compressées en tête).
 
Un exemple tout con de "gestion physique" qui me vient à l'esprit, c'est la désintégration lors d'une explosion: on peut casser le maillage et associer à chaque vertex résultant des données de vélocité et de masse, ce qui aura pour effet des débris retombant de façon plus ou moins réaliste. Ca ressemble assez à l'approche "particle physics" du SDK DirectX au passage, donc ça n'est pas totalement irréaliste.
 
On peut d'ailleurs penser à plusieurs niveaux de "réalisme" dans cette simulation, pouvant aller jusqu'à gérer les déformations par tessellation avec rupture à des joints faibles, mais évidemment on arrive à un niveau de complexité qui n'a plus rien à voir avec ce qu'on a pu voir de PhysX jusqu'à présent.

on arrive pas bien a distinguer ...

C'est un photoshopage où l'image de l'écran a été mal collée ?

Bah c'est toshopé d'une manière ou d'une autre, après quoi est collé sur quoi, j'en sais rien.

 
http://hardocp.com/news/2009/11/23 [...] umors_good
 
Un retard une fois de plus confirmé (ce qui n'étonnera pas certains   ), HardOCP évoque Avril 2010.  
 
La bi-Fermi, déjà mentionnée dans de précédentes rumeurs, refait surface, et aurait comme nom de code "Gemini". La mono-Fermi ne serait pas assez puissante pour rivaliser avec la 5970 ?    
 
edit : info similaire chez DriverHeaven :
 

 
http://www.driverheaven.net/news.p [...] z0Xhun3tPA

 
A terme le couplage D3D/OpenGl et PhysX via Cuda sera plus optimal. Le SDK 3 est pour l'année prochaine et sera complètement refactorisé.
Après l'implémentation optimale au sein d'un moteur est une autre chose Mais oui il y a encore du jus à tirer d'un point de vue optimisation globale.
Si tu prends Havok, PhysX, Bullet, PhysX a fait quelque trucs drôles, Bullet semble assez capable et fait son petit bonhomme de chemin, Havok a jamais fait de démos de simulation des fluides (mais ils y travaillent).
Fin rien n'est parfait, mais c'est pareil partout.

http://techreport.com/articles.x/17815

Je parle en 3x/4x 16x inculte