Reprise du message précédent :
comme quoi y'a des optis qui sont encore envisageables du coté d'ati (on attend chez nv maintenant, c pas drole sinon )
 
pour prévenir, ils étaient sans doute plus occupés avec leurs pbs de brilinéar

faut dire que ça t'a bien emmerdé en faite, et ct pas prévu    
Ou comment gâcher une journée non ?  

Une demi

Le test est fini alors  

pkoi aquamark me dit que ma 9800xt fait 253MB et pas 256MB ?

c normal, ya souvent une petite partie qui manque à l'appel
dxdiag me dit que j'ai 30.5Mo de mémoire vidéo, 3dmark 2000 me dit que j'en ai 26735K, le 2001 en voit 32Mo (cas particulier, ma carte a 64Mo de mémoire vidéo mais on peut la décrire comme une 2x32Mo, d'où le truc..)

Il y aura une MàJ du test de la X800 ?
Parce que ca sent les pilotes optimisés pour les tests, dans un but assez obscure laaaaaaaaaaa !!!!  

vive les trolls ...

ouaiiiii

Le but obscure c'est de proposer des drivers stables.

 
Les tests hors aniso ne sont soumis à aucunes réserves dans le pire des cas...  

oui brilinear chez ATI comme chez Nvidia  
 

Donc visiblement dans les tests sans aniso l'optimisation du trilinear est activé vu qu'il n'est pas possible de la desactivé avec les 61.11 ?  

 
ok

 
ouais mais sur les autres profils de tes sur le site d'aquamark, toutes les 9800xt affichent bien 256MB c'est pour ça que je m'inquiète...

 
je viens de refaire les tests sur ma x800pro et effectivement les 4.5 béta boostent le résultat.
 
http://forum.hardware.fr/hardwaref [...] 311-16.htm

je me posais la question : le lissage des polices, ça ralentit vraiment ou c'est une connerie ? (genre 0.05% indécelable)

 
ça peut ralentir.
 
mais si le serveur graphique est intelligent, il va cacher les polices lissées en texture (et faire un traçage en alpha blending).
 

 
serveur graphique ?  
 
je parle sous win, pas sous nux

et ?
 
ça change quoi au niveau concept ?

tu sais entre nux et windows, l'implémentation est différente, les concepts sont les mêmes.

 
moui m'enfin j'ai jamais entendu l'apellation "serveur graphique" sous windoze...
 
mais donc, est-ce que sous windows ça ralentit vraiment ou pas, quoi ?

bah au moment de la génération des polices.
 
t'as déjà senti la différence à l'époque des pentiums 66 ?

 
à l'époque des 66, le lissage n'existait pas sous ce que j'utilisais (win 95) (il est apparu avec IE4, je crois)

 
bin voila tu l'as entendue.
 
tous les OS modernes sont structurés avec un noyau, un ordonnanceur, un serveur graphique, des queues de messages...
 
après que ce soit nommé autrement, implémenté différement...

 
mm voodoo 5500    ...   elle est bien planante cte carte    !!!

mmh ... c'est longhorn qui apporte une gestion vectoriel de l'interface graphique?
 
J'espere que non c'est un truc qui doit en faire baver à la machine!!!

 
ha ouai c'est trop top d'avoir une fraction de la ram vidéo réellement utilisable    
 
sla la classe, c'est comme les vielles caisses américaines qui bouffent du 30litres au 100

 
Tout était utilisé, sauf que DXDiag n'a jamais sû compter pour les V5

Quand meme bizarre qu'ils nous sortent les 4.5 WHQL non optimisés quand on lit ca

http://www.driverheaven.net/terrymakedon2/
 

 
en SLI y'a duplication des textures. enfin je suis médisant je les aimais bien mes voodoo2...

ouais mais les textures ne sont pas complètes, si ?    
 
C'est pas 2 fois la même chose dans la mémoire, y a que ce dont le gpu concerné a besoin non ??

si, toutes les textures sont dupliquées, et chaque GPU s'occupe de l'ensemble de la scène  
vu que chaque GPU calcule une ligne sur deux c'est comme s'ils s'occupaient chacun de calculer une image en 1024x384 par exemple, pour former une image en 1024x768
ainsi chaque GPU s'occupe de son framebuffer, les données ne sont pas dupliquées à ce niveau -> avec deux voodoo2 qui ont chacune 4Mo pour le framebuffer et 8Mo pour les textures on se retrouve avec 8Mo pour le fb et 8mo pour les textures
et sur voodoo5 on se retrouve avec un peu plus de 32Mo effectifs (~ 35Mo, ça dépend de la taille du framebuffer (plus ou moins gros suivant la résolution, le fsaa, couleurs 16 ou 32bits, utilisation ou non de triplebuffer)

nouveau driver win9x pour les voodoo 4 et 5
on les doit à Raziel64 qui avait pondu un driver permettant de faire tourner plein de jeux récents sur voodoo banshee (ut2003, vice city, neverwinter nights etc.)
 
http://www.3dfxzone.it/dir/news/3dfx/evolution_0.9/
 
il est basé sur le dernier core beta de 3dfx (février 2001)
je vais enfin pouvoir jouer à painkiller

surtout que painkiller est très fluide même avec aa, dis-nous ce que ça donne sur V5  

rien pour l'instant (avec la démo), c comme avant et 3dAnalyze marche toujours pas. mais je perd pas espoir (je vais essayer 3dAnalyze 2.34 qui vient de sortir !?!)
 
je vais essayer la démo de halo aussi

de toutes facons les 2 ram (32Mo) sont utilisées parce que les 2 pross sont utilisés. enfin il me semble que sur les voodoo 5, 32 Mo sont alloués à chaque pross, donc si les 2 pross sont utilisés les 64 Mo sont utilisés ...  non?

Tout à fait, comme l'a dit BJOne, les textures étaient dupliquées. Par contr,e le framebuffer était partagé.
 
En fait, on avait la RAM divisée en FB + 2*TM=64Mo.
 
Forcément, DXDiag pouvait que s'emmèler les miches.

dxdiag donne ce que le driver lui dit...

Ouai mais en gros on pouvais assimilé les V5 a des cartes 32Mo vu qu'elles ne pouvais avoir qu'a peine plus de mémoire a allouer aux textures qu'une carte 32Mo, même si avec pas mal d'optimisations et des cas extremes on doit pouvoir avoir des cas ou les deux GPU ont chacuns des textures différente dans leur RAM, mais cas rares...

Ces cas étaient même quasi improbables v la répartition de charge entre les puces par le SLI.
 
Par contre, en 1024 FSAA 4x triple buffering en 32bpp, on était loin d'une carte 32Mo (vu que le FB prenait pas mal de place).

Hmmmmm......
 
 
  Les gars de Belfast