Reprise du message précédent :
Classement ICI.
A la louche et d'après le graphique: 30% d'une HD4670 ou 25% d'une 9600GT...

d'apres vous ca vaut quoi une 4870 1Go par rapport a un sli de 8800Gt pour du 1920x1200 ?

similaire mais plus puissant et plus consistant.

oui parce que ma 2eme config (speciale sims3 pour ma nana) a des problemes avec la X1900 qu'il y avait. donc je dois changer.
bon je pensais mettre une 4850 mais vu la diff de prix avec la 4870 je me dis que je pourrais me prendre une 4870 pour mon pc et mettre donc mon sli de 8800GT 512Mo sur la 2eme config
 
aaah ces geeks!

Une X1900 pas assez puissante pour cette chose ?

nsi si c juste qu'elle plante
corruption d'affichage avec les poly qui s'etirent de partout et plantage. meme sur les videos j'ai des points qui apparaissent (c'est general)
j'ai bien essayé de l'underclockée mais je pense que la ram deconne.
la temperateur ne montant pas

Un truc à tester : http://sourceforge.net/projects/cudagpumemtest/

Sous Windows, il y a un module d'OCCT v3 qui fait la même chose :
http://img29.imageshack.us/img29/7 [...] emtest.png

Pour blaz
 
http://www.youtube.com/watch?v=a4iKpB6Dt-Y

Tiens c'est marrant, l'auteur a oublié la GeForce FX

merciii!

 
Faudrait que je regarde dans mes vieux trucs si j'ai un jeu à mettre sur mon serveur (qui a une Voodoo 3 2000). Je dois avoir POD qqpart.
 
Certains jeux de la vidéo, tu te dis : ya vraiment besoin d'une carte dédiée pour ça ?

un bon petit counter strike 1.5 à 100fps (jouable sur le net )

Bof c'est pas trop mon truc CS
 
Bon je vais poster ça ici vu que ça a un lien avec les tests de SSD. Marc a fait un bon boulot pour chercher des poux aux SSD et qu'on comprenne comment ils marchent, leurs faiblesses, etc., mais une "nouveauté" est là et il n'a pas pu encore s'en occuper (faire un article dessus, du moins), j'ai nommé le garbage collector.
 
Je pense qu'il est implémenté aux SSD Intel mais sans preuve. Une chose est sûre, il est dans les OCZ Vertex/Agility/Summit, avec le dernier firmware. Ce garbage collector fonctionne indépendamment de l'OS, nous disent les techos OCZ. Je les crois, mais jusqu'à un certain point. Pour moi, il est impossible que le SSD sache qu'un fichier a été effacé, sans la fonction trim (qui pour l'instant n'est pas implémentée). Donc le GC fonctionne certes indépendamment de l'OS, en ne pouvant tout simplement rien faire pour la majorité du disque. En fait, il profite, tout comme le wear levelling (je pense d'ailleurs que le GC fait partie de la même routine que le wear levelling), des blocs en rab que possèdent les SSD.
 
Pour rappel, OCZ vend des disques aux capacités "rondes" : 30Go, 60Go, 120Go, 250Go. Ils font réellement cette taille (à qqchose près), contrairement à l'habitude avec les DD. Les concurrents ont des chiffres "memory style" (32, 64 etc.) mais font au final la même taille que les OCZ. Si on démonte un 60/64Go, on trouve, par exemple, 16 puces de 4Go. Des vrais Go binaires, c'est de la mémoire. Donc si au final on n'a que 60Go utilisables, c'est que 4Go sont cachés. OCZ décide de ne pas les "vendre", peut-être parce qu'ils fabriquent de la mémoire à la base donc veulent afficher ce qui est utilisable, ou alors parce qu'ils se sont dit que les SSD sont tellement petits que si on "ment" comme les fabricants de DD, on va se mettre les consommateurs à dos. Peu importe, ce qui compte ce sont ces Go en rab. Ils sont utilisés, de façon évidente, pour le wear levelling. Dès qu'un bloc est cramé, on va le décommissionner et le remplacer par un bloc jusque là caché.
 
Revenons-en au garbage collector. Selon OCZ il fonctionne quand le disque est en "idle", il efface les blocs "invalides" et permet de refaire le stock de blocs vides, prêts à être écrits à vitesse maximale (écrire sur un bloc non vide prend plus de temps, d'où baisse des perfs). Le problème que j'ai avec les techos OCZ, c'est que selon eux, le SSD peut savoir qu'un fichier a été effacé, et donc que ses 0 et ses 1 sont invalides. Ainsi, en lui laissant suffisamment de temps, le garbage collector va pouvoir nettoyer tout l'espace libre, exactement comme le wiper (voir test vertex si vous ne savez pas ce que c'est). Pour moi, et d'autres, ceci est impossible, le SSD ne peut pas savoir que ces 0 et ces 1 sont invalides, et s'il essaie de deviner en ayant une certaine "awareness" du système de fichiers, on est sûr qu'à un moment il va se planter et corrompre des données.
 
Et pourtant, elle tourne ! Euh il marche Effectivement les utilisateurs ont bien constaté qu'après avoir rempli leur disque, puis effacé ces fichiers de test, le SSD était lent, et que s'ils le laissaient dormir un peu, il redevenait rapide (tout ceci via benchs, crystaldiskmark et atto en général). Même chez ceux qui ont OSX ou linux, ou encore qui sont en RAID (là on est sûr que le SSD ne peut pas voir les fichiers).
 
Ma théorie, à laquelle je suis arrivé au bout de plusieurs jours de lecture/réflexion, et où d'autres arrivent aussi (je n'ai rien inventé, mais j'ai quand même beaucoup réfléchi à la chose, quoi), c'est que le GC utilise les blocs cachés pour faire sa popote. Càd qu'il peut nettoyer 4Go (sur un 60) en transférant les données sur les 4Go cachés, qui sont forcément vides du point de vue de l'OS. Je dis bien du point de vue de l'OS, car si on remplit le disque, puis qu'on le vide, puis qu'on écrit, comme ce qu'on a vidé ne l'est pas pour le SSD, il va d'abord écrire sur les Go cachés (non encore écrits, si on part d'un SSD neuf), en changeant les adresses à la volée. Mettons qu'on écrive juste 4Go, on a donc toujours eu de bonnes perfs. Si à ce moment on écrit encore, les perfs chutent, car il n'y a plus du tout de bloc libre. Si on laisse le disque idle, le GC entre en action. Les 4Go anciennement visibles et maintenant cachés contiennent des 0 et des 1 invalides, ça il en est sûr puisqu'il les a marqués lors du changement d'adresse. Il peut donc les effacer. Et voilà, on a à nouveau 4Go prêts à être écrits à vitesse maxi.
 
Je pense que les gens ne testent pas assez longtemps pour voir les perfs baisser à nouveau, et c'est pourquoi ils croient aux miracles. Je pense que les techos OCZ ont été mal informés par Indilix (ou leurs supérieurs), ou qu'ils mentent, au choix
 
Voilà, donc maintenant, il reste à trouver qq1 avec un OCZ pour faire un test qui prouverait cette théorie. Ce qu'il faut faire, c'est : remplir le disque, puis effacer ces fichiers inutiles, 2 fois, afin d'être sûr d'avoir rempli les Go cachés. Bencher pour bien voir la perte de perfs. Laisser le PC idle pour que le GC fasse son travail (ne surtout pas utiliser wiper). Bencher, avec un bench qui écrirait plus de 4Go (pour un 60). On devrait voir une chute des perfs en arrivant à la barrière fatidique des 4Go. Je ne sais pas trop quel bench serait le plus adapté, à vos avis. S'il pouvait fonctionner sur un DD comprenant l'OS, ce serait mieux.
 
J'espère que c'est pas trop long et que vous avez compris qqchose (et idéalement êtes d'accord avec moi ). Je n'ai pas détaillé le point de vue d'OCZ et de leurs "believers" car ils ne donnent pas plus de détails que ça, comme si c'était magique
 
PS : j'ai lu qqpart que la mémoire flash, comme la mémoire vive, a toujours quelques blocs cramés d'origine, et qu'il y a toujours du rab de prévu. Si c'est le cas, ça voudrait dire que par exemple une puce de 4Go ferait "4,1Go" et pourrait supporter un certain nombre de blocs cramés avant de perdre en capacité. ça ne change pas mon post mais c'est juste pour le dire, si vous en savez plus ça m'intéresse.
 
PS2 : j'ai volontairement éclipsé l'aspect bloc/page et tout ce qu'il implique, car si le wear levelling et le GC doivent bien en tenir compte, et que ça a clairement un impact sur les perfs et l'usure, ça ne change pas non plus la nature de mon explication, et ça complique les choses, je ne voulais pas perdre tout le monde.

Bon bah c'est un beau pavé

Si c'est un vrai garbage collector, au sens qu'on l'entends vraiment, le firmware devrait ecrire dedans puis en Idle, as soon as possible, transferer du garbage collector au SSD (on s'en fou si c'est lent le SSD fait rien d'autre), puis nettoyer le garbage collector (possible sans TRIM vu que c'est le firmware qui ecrit dedans).
 
Par contre ça m'etonnerais que ce soit du code OCZ vu qu'au mieux ils communique avec Indilix pour des retours d'expérience sur les perefs, donc si Indilix/Samsung ont la meme techno, Intel/JMicron aussi je pense. Parce qu'en réalité ça doit etre une sorte de b-a ba du SSD.

Je sais que c'est un terme utilisé en programmation à la base, j'ai fait un peu de java il y a longtemps, mais je ne sais pas si ça correspond.
 
Que veux-tu dire par "le firmware devrait écrire dedans" ?
 
L'idée c'est que le machin utilise un peu d'espace disque, enfin le même que le wear levelling, pour stocker des infos sur les cellules. Je me demande comment ça marche en détail pour ne pas utiliser énormément de place, au passage. Dans ces infos il marque les pages invalides, et plus tard en idle il va les effacer (ce qui va souvent demander de faire une sorte de défragmentation pour être utile, puisque parmi les 128 pages d'un bloc, toutes ne seront pas forcément à effacer). Comme les éboueurs qui viennent vider les poubelles, quoi
 
Sinon je suis d'accord avec toi que ça semble le b a ba du SSD, mais visiblement les samsung avec l'ancien firmware, et les indilix avec l'ancien firmware, ne l'avaient pas. Ils devaient simplement marquer les pages invalides et les effacer à la volée lors d'écritures, empirant ainsi des perfs déjà dégradées par le manque de blocs libres.

Bah j'imaginai ça un peu comme une file d'attente.
 
On réserve une zone de stockage, qu'on rempli tant qu'on peu, sur cette zone on connait les infos puisque seul le firmware s'en sert. Du coup on écrit direct dans des blocs vide. Ce qui accélère l'écriture.
 
Après quand on a le temps on vide au fur et a mesure cette zone de stockage en déplaçant vers une zone normalement dédiée au stockage.

Mais dans ce cas difficile d'avoir une usure égale de toutes les cellules, non ? Et en plus ça userait plus le SSD puisque tu bougerais tout, alors qu'une fois les choses écrites, il est plus logique de les laisser là et d'utiliser les cellules "anciennement vues" comme nouvelle "zone de stockage".

http://www.clubic.com/actualite-29 [...] -2009.html
 
Yeah ça c'est méga cool.
Mon patron bosse sur un moteur du même acabit (sph,wavelets,volumes de radiances et tout le bordel), c'est vraiment potentiellement seske comme rendu
 
Par contre sur une de leur vidéo ont voir leur shadowmap aliaser

Le pb c'est que le CryEngine est surestimé a cause de flop des concurents.
 
Parce que si on regarde le moteur de Capcom (qui equipe Lost Planet & co), ça reste pas mal, et le moteur EGO de Codemasters pour les jeux de caisse là c'est ENORME. Mais en FPS rien que dalle. L'Unreal Engine est crédible que sur les environnements où on a pas besoin de textures super realisté. BioShock est p'tet le meilleur representant du moteur avec les Gears of Wars. Mais ca fait toujours un peu plastique.
 
Le Source Engine est bon qu'en animation faciale en gros.
 
L'id Tech 4 a été boudé et un peu comme l'UE3 (mais moins depuis le megatexture) fait plastoc.
 
Mais CryEngine 3 vs id Tech 5 là ça va faire mal. Car là où id vise 60fps sur les 3 plateforme. on sais que CryTek aura ptet 30fps sur PC en taquet.
 
Et vu que pour le moment ce qui fait defaut ce sont les textures haut resolution. (les textures S3TC de UT99 sont encore limite plus detaillés que celle de certains jeux actuels) plus que des nieme algo d'ombre/eclairage...
 
Pour l'instant je reste plus convaincu par l'approche d'id que celle de Epic/Crytek. D'autant plus qu'Epic fait plus grand chose.
 

l'idTech 5 a un éclairage simpliste mais un système de texturing avancé (dont le coût a peut-être réduit le budget d'éclairage), mais là avec cette annonce c'est le (vrai, pas le truc à deux balles redimensionné pour les consoles) CryEngine 3 qui a l'éclairage le plus avancé.
 
Maintenant c'est deux situation différentes.
 
Pour l'outdoor le terrain "plat" sera mieux sur l'idTech 5, en indoor le mégatexture ne doit pas vraiment être exploitable (tu peux pas mettre une texture 32K sur un mur, ça sert artistiquement à rien et le megatexture n'a de sens que si tu as le working set qui rentre dans le budget de ressource hardware, donc en extérieur où tu vois toujours qu'une fraction des surfaces).
 
Sur les détails du terrain (arbustes, herbe), les vidéos de Rage sont -vides-. (Crysis est plus riche en "features" de terrain).
 
Par contre en indoor, le CryEngine était très blaireaumétrique et là il se hisse au top en termes de techniques employées

http://www.pcworld.fr/2009/08/12/m [...] mpaign=rss
 
tiens vous en pensez quoi de ce chip LucidHydra des SLI/crossfire hardware?

Moi comme ça je dirais que c'est du VaporWare... mais bon Intel a mis de la thunes dedans...
 
Sinon pour le cas particulier de la MSI P55, quasi sur que c'est un switch PCIe 16X -> 48X pour avoir la compatiblité Tri-SLI.

Perso je penche aussi pour un simple switch, mais j'espère que l'avenir ne me donnera pas raison

arf désolé j'avais pas vu ta news sur HFR

C'est la description donnée par Lucid.
Un switch programmable pour assister le SLI/Crossfire. En même temps c'était une évolution logique.
 
Mais bon il faut arrêter avec l'histoire de la mise en parallèle techno-magique de plusieures cartes de modèles & fabricants différents, ça n'a jamais été mis en avant par Lucid.

Ah non ils mettent en avant un peu plus quand même

Par exemple dans la présentation de l'hydra 100 :

Together with its Parallel Graphics Software driver,
the HYDRA 100 provides a unique solution for scaling
graphics performance using two GPUs. The Parallel
Graphics Software driver intelligently distributes the
graphics processing tasks between the two GPUs using
multiple parallelization algorithms. The parallelization
algorithms are dynamically applied based on the
current bottleneck and system feedback.

+ dans la PR il y'a + d'un an

The first HYDRA real-time distributed processing engine is a solution that efficiently load-balances graphics processing tasks, delivering linear performance improvement with two or more graphics cards. Because it is the industry’s first parallel graphics technology that works with any GPU, any CPU or chipset and on any application, the HYDRA engine allows people to customize and optimize their PC to achieve the price and performance balance they want – whether it is a mainstream system or a high-performance gaming package.

Bah ouais, mais y'a pas écrit qu'ils vont mettre en parallèle par voie magique des cartes de marques différentes à l'insu des constructeurs.
 
Pour moi c'est aux fabricants d'en tirer parti (soit en haut-niveau via une api, soit en bas-niveau avec direct du code au niveau asic du switch PCIe).

Non mais d'un point de vue MKGT il mettent tout de même en avant le fait de mettre en // par voie magique des GPU uniquement via leur Parallel Graphic Software Driver + la puce.
 
Si c'est juste un switch en tout cas (ce que je pense) c'est bcp de bruit pour rien et pas sûr que ca ai un quelconque interêt (cf le nforce 200 qui n'apporte rien)

D'un coté j'vois pas comment on peut "creer" de la bande passante. Vu qu'on a toujours de PCIe 16X vis à vis du chipset/CPU. Du coup au mieux on exploite mieux cette bande passante (à la maniere d'un port multiplier SATA quoi), au pire ça sert à rien.
 
Vu que les deux cartes ne communique jamais entre elles via le PCIe (les ponts SLI/XFire etant fait pour ça...)
 
Après si ça avait vraiment un intéret ça aurait deja percé. Le seul interet c'est que c'est p'tet moins cher qu'un nForce200 ou qu'un pont PLX.
 

 
Si tu as deux cartes, tes textures sont transférées deux fois. Si tu mets un switch PCIe qui peut multicaster, tu divise la pression en bande-passante mémoire.

Oui sauf que j'vois pas comment le switch va deviner comment multicaster tout ça en fait.

 
Il devine pas, c'est le driver vidéo qui lui dit.

parraitrait que les prochaines ATI vont gérer direct 3 ecrans    
ca devrait etre trés bien ca pour faire du triple head!
ca serait vraiment interessant d'ailleurs si ca pouvait etre géré direct dans leur drivers comme ca y aurait ptete un meilleur support de cette fonction dans les jeux
http://www.revioo.com/news/radeon- [...] 13029.html (source du "eye infinity" ) le reste ce sont des doux reves de ma part  

Ca va dans le sens de l'augmentation du nombre de connecteurs sur la face arrière en tout cas
On avait deux écrans pour trois prises, pourquoi pas trois écrans pour quatre prises

Augmentation du nombre de connecteurs, pas forcément, il y en a 3 depuis longtemps avec la prise TV, la différence serait là qu'on puisse utiliser les 3 en même temps. Avec 2 DVI et 1 HDMI ? Du display port ?
 
En tout cas je suis en train de me chercher une petite CG pour faire du triple écran, c'est une info qui tombe à pic, ou pas, je sais pas si je pourrais attendre
 
moggbomber : le triple écran dans les jeux a pris du plomb dans l'aile avec le développement du 16/10ème, encore un peu plus avec son remplacement par le 16/9ème.

Y'en a 4 (2 x DVI + HDMI + DisplayPort) sur certaines futures ATI en design de référence
Et on peut faire du triple dans le sens vertical aussi

J'vois pas l'interet du Dual DVI perso Y'a encore des gens qui font du dual screen avec 2 ecran en VGA ?  
 

il ya une explication très terre à terre pour cela : regardez les radeon X2 actuelles et passées, certaines ont deux DVI, d'autres en ont quatre .