Reprise du message précédent :
me souviens plus, c'est laquelle ?  

 
elle a pas d'ame  

 
ca me troue de voir la taille surtout en fait ...

 
http://www.msi-multimedia.com/inde [...] id_prod=20
 
(y a bien marqué 850MHz (425 donc pour la RAM), mais ça précise pas la freq du core)
 
donc 400 ou  450 comme l'ultra ? on sait pas encore vraiment...

 
Ah, parce que Fr-08 a une âme ?  

 
       
Oh mon dieu!!!
Comment est-ce possible???
Tout ca dans 64ko???
Ahhhhhhhhhhhhhhh!!!
(tombé par terre)

 
c'est "facile" (en fait non, mais bon : au lieu de stocker les textures, tu stockes uniquement de "micro-programmes" qui fabriquent ces textures, idem pour les ziques (le principe du midi en un peu différent), et pour les objets, ben là, c'est plus courant)

J'aimerais revenir encore une fois sur cette histoire de prècision parce que je pense que c'est bien important de bien en saisir toutes les nuances. En gros on a deux courants de pensée groso modo :

• Le premier illustré par MagiSim qui pense que l'on ne doit pas se soucier du hardware sous jacent, le but est l'efficacité maximale après tout malgré les progrès dans le domaine de la programmabilité les GPU restent des DSP et doivent donc rester suffisamment simple pour ne pas se retrouver avec des problèmes d'efficacité courants des CPU par conséquent une prècision fixe est l meilleure solution (j'extrapole un peu mais c'est ton point de vue non ? si je me plante corrige moi...).

• Le second que prône mareek, fendnts et moi même consiste à dire qu'utiliser un type fixe est un gâchis de ressources et surtout que ce n'est pas très satisfaisant intellectuellement pour le programmeur (et ça mine de rien je connais beaucoup de programmeurs qui y font attention, après tout on a pour la plupart une formation scientifique et on a gardé cet aspect d'esthétisme d'une solution). Plusieurs types de diverses prècisions doivent donc être privilégiés surtout qu'avec  le passage au HLSL ça permettra encore un peu plus de se rapprocher d'un langage standard.

Maintenant il y a plusieurs choses qu'il faut prendre en compte, comme je l'ai déjà dit, à mon avis MagiSim a raison sur un point : à terme les GPU n'utiliseront sans doute qu'une seule prècision en interne. Pour diverses raisons : j'ai déjà évoqué la fusion probable des VS et des PS (tout du moins le partage des ressources dans un premier temps) mais ce n'est pas la seule il y en a au moins deux autres la simplicité et l'"efficacité".  
 
En effet implémenter un seul type tout au long du pipeline reste quand même nettement plus simple à gérer et moins coûteux en transistors. Je suis d'accord qu'il s'agit d'une approche de force brute mais c'est ce qui est souvent privilégié dans le cadre de GPU un exemple de ce genre de méthodes : les branchements.  
 
Traditionnelement les branchements sont problèmatiques pour un processeur : à l'origine il était bloqué en attendant le résultat du test pour choisir quelle était la suite d'instructions à exécuter. Avec le développement des pipelines ce type de solutions n'étaient plus acceptables : elle aurait engendré des bulles dans le pipeline et auraient considérablement ralenti son rendement. On a donc vu arriver des méthodes de prédiction de branchement basé sur des algorithmes de plus en plus évolués : une méthode élégante pour résoudre ce problème.  
 
Avec les GPU a priori ça ne fonctionne pas du tout comme ça : ils disposent de beaucoup de ressources de calculs mais en contrepartie doivent compter sur un comportement simple et surtout prévisible (pas question d'ordonnacement complexe ou d'algorithme complexe mais à l'efficacité aléatoire comme dans un CPU) par conséquent les branchements sont effectués de la méthode la plus simple qui soit : les deux possibilités sont évalués en parallèle jusquà ce que le résultat de l'évaluation du test soit connue à ce moment là une des deux est éliminée : simple et efficace pas très élégant mais ça respecte le principe de base d'un GPU. C'est pour cette raison qu'à terme je pense comme MagiSim que les problème des prècision ne se poseront plus.
 
MAIS car il y a un mais évidemment je ne me suis pas placé dans l'autre camp pour rien je persiste à dire que du point de vue du programmeur il ne faut pas faire de supposition sur le hardware sous jacent et privilégié l'efficacité même si en pratique ça n'apporte rien.  
 
Désolé MagiSim mais il y a un point sur lequel je ne suis pas du tout d'accord c'est lorsque tu sous entends (voire tu affirmes ) que ça implique de la complexité où la nécessité de faire plusieurs versions : Non Non et Non !!! En prenant l'exemple d'un programme codé en utilisant un HLSL utiliser un type half float ou int à la place de float ça n'a jamais demandé d'être un génie ! On le fait tout le temps lorsqu'on programme avec un langage classique alors pourquoi pas avec un HLSL ?  
 
Mais comme je l'ai dit ça ne veux pas dire optimiser pour une architecture : c'est simplement une question de bon sens qui consiste à n'utiliser que la prècision nécessaire. Après le hardware en fait ce qu'il veut : il peut tout traiter en float de 32 ou 64 bits s'il veut ça m'est bien égal moi j'ai l'esprit tranquille parce que mon code est cohérent et surtout plus compréhensible.  
 
Un autre exemple : quasiment toutes les architectures traitent les instructions sur des vecteurs de 4 nombre flottants encore une fois parce que c'est plus simple ainsi et que c'est le plus courant : x,y,z,w ou r,g,b,a en 3D on se retrouve fréquemment à manipuler ce genre de vecteurs. Ce qui ne veut pas dire qu'on utilise jamais les scalaires mais en pratique les hardware utilisent un vecteur pour le stocker donc niveau efficacité utiliser un scalaire ou un vecteur ça revient au même. Pourtant si je veux utiliser un coefficient spéculaire pouvant prendre 256 valeurs différentes et bien moi je préfère le déclarer sous la forme d'un type scalaire d'un octet que sous un vecteur de 4 flottants question de principe .  
 
Et même si dans 99.9% des cas ça ne changera rien peut être que ça pourra favoriser une architecture (par exemple le R3x0 a une arhitecture ingénieuse qui permet d'utiliser des instructions sur 3 nombres flottants et un nombre scalaires concuremment, lorsque tu traites un vecteur de 4 flottants ça ne change rien par contre lorsque tu traites un vecteur de 3 flottants alors tu peux également te servir de l'unité scalaire te permettant d'effectuer du coup deux instructions c'est un peu plus compliqué à gérer mais je trouve ça très bien) sachant que ça ne me demande pas plus de temps et que ce n'est pas vraiment plus dur et même qu'au contraire c'est nettement plus élégant alors je te le demande pourquoi m'en priver ?
 
Bon voilà j'ai finis mon discours vous pouvez reprendre vos discussions
 
Kenshin>Je ne me trompe pas tu es bien le Kenshin de Playfrance ? Mes connaissances sont pas si étendues que tu sembles le croire au contraire ça reste toujours plus ou moins limité à la 3D où je commence à avoir une petite expèrience mais dans d'autres domaines de l'informatique je n'y connais strictement rien.

 
dans un genre totalement different et avec une taille normal
 
ftp://ftp.scene.org/pub/parties/2 [...] o/vip2.zip
 
Avec le son bien fort

3eme ligne g craqué==>2 aspirines    
aère un peu la prochaine fois

Y a de l'ambiance par ici    
 
Je connais pas le monde de la programmation 3D. Par contre je programme. Ce qui est clair, c'est que plus tu t'abstrais du materiel, plus tu cherches a faire des trucs portables, et moins c'est performant (en vitesse d'execution). Java c'est bien, parce que c'est portable, c'est de l'objet et tout et tout, mais en perfs, un bon vieux programme C, c'est encore ce qu'il y a de mieux
D'ailleurs un OS comme Linux ou Solaris (pour la reponse a la question  ) est ecrit en C quand meme.
 
Donc, bien que n'etant pas competant en programmation 3D, je me demande si on retrouve pas la meme chose. C'est ce que semble dire Zeross si je comprend bien son point de vue
 
Sinon il ne me viendrait jamais a l'idee dans un de mes programmes de declarer toutes mes variables en float    
 
Mais j'ai quand meme l'impression que le coup de la precision, 12, 14, 24 ou 32 bits, c'est un peu different de cette analogie avec les types primitifs des langages de programmation. Effectivement, on va surement se retrouver comme ca a ete dit, avec une utilisation que de haute precisions en permanence dans les futurs chips (et comme le fait les R3XX), meme si le programme demande de la basse precision. D'ailleurs, c'est comme la profondeur de couleurs. Avant y avait un impact fort entre de l'utilisation de 16 bits ou de 32 bits, maintenant (si je me plante pas) les calculs se font toujours en 32 bits meme si l'utilisateur choisit du 16 bits.

 
Très juste là je peux vraiment pas t'en vouloir. C'est un peu mieux ? Pas vraiment facile la mise en forme dans un petit cadre comme ça surtout lorsqu'en même temps tu réfléchis àce que tu tapes. Mais je dois avouer que je ne me suis pas relu, sans ça j'aurais vu que c'était vraiment un énorme pavé illisible

 
VOILA !
 
Tu mélange ça avec ce que Zeross a compris de mon avis, et tu as mon avis pur.
 
Y'a un MANQUE de puissance dans un coin.
 
Pour résumer, et revenir sur les archis actuelles, les Fx ont plus de transistor que les R3x0 à cause du FP32. MAIS y'en a pas encore assez, le FP32 nécessite (d'après certains concepteurs de chips) 50% de transistors en plus que le FP24 (cf B3D, toujours).
 
Cette quantité économisée sur le R3x0 a été utilisée à des fins plus utiles, à mon avis, pour assurer une vitesse honorable dans TOUS les modes proposés.
 
Grossièrement, les transistors dans les archis actuelles, ils sont investis dans le FP32, ou dans l'efficacité du FP24.
 
Et ne rigolez pas les loupiots, Reverend (Anthony Tan de B3D) se voit déjà à rêver au FP64 ! ! ! ! !  
 
Mon sens est : à chaque jour suffit sa peine, et tant qu'à intègrer quelque chose dans un chip, autant qu'il carbure.
 
Après, lesprogrammeurs ont l'air de vouloir jongler entre les précisions. Pas de pb, c'est compréhensible !
 
Mais je résumerai mon sentiment à : c'est dommage d'avoir mis la charrue (FP32) avant les boeufs (puissance de traitement).
 
C'est de là que j'estime qu'il y a un manque d'équilibre. Et l'équilibre en 3D, c'est nécessaire.
 
Mais au final, tout finira par tourner ensemble, VS, PS, le tout en FP32........ Et là, tout le monde sera content, ce sera re une course pure à la vitesse..... En fait en ce moment elle est déguisée, mais faut pas le dire.... chut !

 
Je l'ai lu et aprécié.  

On en sait un peu plus sur les fréquences des gf 5900 (ultra, normales et value)?

Au cas ou tu ne l'aurais pas compris, je racontait n'importe quoi. je ne pense pas que les pocesseur de Geforce sont des débiles, je ne bosse pas sous solaris et l'ifop n'a jamais fait une telle étude. enfin bref

Je crois qu'on ne pouvait pas mieux résumer la situation  

Ce que tu décris là, c'est un peu le problème de chaque nouvelle fonctionnalité dans le monde des CG. La carte graphique qui introduit une nouvelle fonctionnalité est rarement assez puissante pour en tirer la quintescence. En contrepartie ça permet aux developpeurs de se familiariser avec cette nouvelle fonctionnalité. Ce qui fait que lorsqu'un jeu exploitant vraiment cette fonctionnalité sort , il y a des cartes assez puissantes pour en profiter sans que les perfs s'écroulent.
 
P.S. je parle de manière générale, pas de la GFFX en particulier.

 
Y'a quand même de grandes exceptions, heureusement...... L'idéal étant quand même que le hard soit développé de façon à tout faire direct correctement.
 
Genre, V1 et accélération 3D.....
 
V5 et FSAA
 
GF256 et T&L (même si il aété réellement utilisé que tard, ce qui est dommage)
 
GF3 et PS (bah ouais, ça tourne encore bien une GF3 avec les shaders actuels)...
 
A priori : R3x0 et FP......

 
 
je te conseille de lire le .plan de carmack alors
 
http://www.webdog.org/plans/1/

 
Ben les .plan de Carmack sont ptet pas très accessibles mais sont quand même bien découpés en paragraphe contrairement à la première version de mon speech   (j'ai honte d'autant que c'est pas la première fois qu'on me fait la remarque...)

S't'en forgeant qu'on devient forgeron

bon, je vais un peu chipoter vue j'adore ça (et qu'il y a matière à chipoter)
-V1 spas la première carte accélératrice 3D grand public
-V5 spas la première carte avec le FSAA, la GF256 le faisait avant  
-GF256 +1    
-GF3 j'attends encore un jeu qui exploite vraiment les shaders 1.x
-R3x0 même remarque que pour la GF3 mais avec les shaders 2.0
 
 

 
1) t'as vu les daubes en face de la 3DFX?
2) ouh là, les perfs abysmales en FSAA
 
le reste :

 
V1 première carte 3D potable. Vraiment potable. pas gadget.
 
V5 première carte à pas faire un simili FSAA pour le joueur, et qui plus est utiilisable dans tous les jeux.
 
La farce du FSAA sur GF256, c'était un truc dans les pilotes pour contrer 3dfx...... Rien d'utilisable sérieusement....... Juste un truc pour dire : nous on le fait, nananèreuh....  
 
R300 : au moins il est pas obligé d'utiliser une précision moindre que celle qu'il est marketté pour, pour éviter de ramer...  

 
Ma Matrox  Mystique n'a pas été une carte acceleratrice 3D non potable... Tomb raider en 640*480 en 25 images sec ça en jetait aussi

Au moins y'avait un bon LOD de base sur la GF256

ouais, j'l'avais oublié celle là, honte à moi, j'en ai eu une. M'enfin, c'était du software rendering accéléré.... Pas d'lpha blending propre, pas de bilinear....    
 
Mais sque je me marrais bien avec Destruction Derby 2 !

 
Ouais, spour ça que 3dfx a sorti le lod bias de sa manche. Et avec le FSAA, poussé à fond, on croirait de l'aniso, trop fort !  

Comment ose tu parler d'un anisotropic vu la gueule qu'avait le trilinear (au debut tout du moins)
 
Sinon oué le FSAA permettait de virer le scintillement du au changement du LOD ... mais bon sans FSAA, voilà quoi

c'est exactement ce que je disait: les premières cartes à apporter une nouveauté le font mal, il faut attendre la suite pour avoir qqch de potable

 
Et ça donnait l'impression d'un aniso (avec FSAA). ET à vrai dire, à partir du moment où j'ai eu la V5, je jouais toujours à lod -1.5 + FSAA4x, donc la gueule du trili........ C'était tellement loin....
 
ça n'avait d'intérêt qu'avec FSAA.
 
Mais ça n'excuse pas le Trili bancale des 3dfx.

 
Pour le FSAA, je manifeste, on ne peut pas qualifier le FSAA du GF256 de premier FSAA réel. Sinon, appelle les GF4Ti premiers GPU DX9 grâce à nVEmulate.  

 
le premier et seul FSAA sans perte de perf excessive
c'etait celui de la powervr sg
(aussi sur dreamcast)
 
A cette epoque les voodoos en etaient reduit
a faire du edge antialiasing.
 
LeGreg

 
PowerVR SG alias Neon 250.
 
Effectivement, fait le FSAA.
 
http://www.beyond3d.com/reviews/vi [...] index1.php
 

 
Et voilà, même méthode que pour le GF256, appliquée au Tile, et en hardware a moins. C'est mieux que rien.
 

 
Niveau qualité, ça doit se tenir au niveau des cartes d'un GF256 pour le FSAA. En vitesse, il faut voir, le Neon 250 se tape quand même une sacré pénalité sous certains jeux en 1600*1200.
 
Enfin, dommage qu'il y ai eu un an 1/2 entre l'annonce et la dispo (on a trouvé un ancien qui fait passer notre ami nV30 pour un amateur), ça aurait un bon outsider.
 
Enfin, c'est un des pbs des chips PowerVR aussi...
 
Sinon, ouais, y'a bien eu du FSAA avant la V5. Mais on connaît pas les conditions... dommage (les reviewers s'en foutaient à l'épouque )

 
heu, la voodoo1 faisait pas déjà un AA ???  
c'tait marqué sur la boite en tout cas (et il me semble bien me rappeler que POD était très anti-aliasé)

 
non. Pas de FSAA, ni d'edge antialiasing. C'était l'apparente douceur du bilinear face au software qui doit te blouzer.
 

 
ben peut-être mais ils appelaient bien ça de l'anti-aliasing !

 
Edge antialiasing deja dit.
 
LeGreg

 
http://digilander.libero.it/F1Land/3dfxarchive/
 
Il était effectivement listé, mais je ne me souviens pas de l'option edge antialiasing. Et je n'ai jamais vu de jeu anti alisé sur VG. Pourtant, je l'ai gardée longtemps....  
 
Je pense comme Legreg que ça devait être de l'EA mais qu'ils n'ont jamais mis l'option à notre portée, ou alors, certains fabricants avec leurs pilotes. Je vais approfondir pour voir.