Reprise du message précédent :
Toutes les carttes vieillissent mal
Enfin celle qui s'en tirent le mieux c'est sur leurs perfs brutes plutôt que grâce à leurs fonctionnalitées (GF DDR, GF3, Radeon 9700)

Tiens en fait je pensais à un truc par rapport au Sli (c'est plus pour Zeross/LeGreg/Tridam)
 
comme le moteur de l'appli 3D ne sais pas comment la scène du frustum va être traçée, si le driver vidéo va utiliser 2 ou plusieures cartes qui se répartissent le frustum en découpant horizontalement (ou verticalement ou les deux en cas d'un mur de moniteur)...
 
des cartes qui ne verront pas des objets dans leur sous-frustum vont recevoir des commandes de changement de texture pour rien, vu que l'élémination se fera après le vertexshader au niveau du triangle setup... (je suppose)
 
il serait donc assez tentant de faire évoluer les API pour proposer une encapsulation par une bounding-box (ou sphère/cylinde) des divers changement d'états et des commandes de traçage, ceci afin de permettre au driver vidéo de balancer dynamiquement les commandes aux cartes vidéo se chargeant d'une portion de frustum....
 
z'en pensez-quoi ?  
 
ça se repproche ptet un peu d'une API pouvant plustard évoluer vers du RT (je suppose qu'OpenRT possède un système de hiéarchie de scène avec des volumes englobants)....

J'en pense que le ghoule du coté scure de la force a suspendouillé tes last neurones
 
Sinon..... bah g compris mais je peux rien dire de plus

 
Tu peux déjà faire ça au niveau de l'App mais c'est pas forcément très efficace. Enfin pour le SLI c'est raté puisque tu n'adresses pas les deux GPU séparément.
 
Pour ce qui est de l'API il est plus probable de voir ça arriver du coté d'OpenGL. (edit: dans le sens, tu as plus de chance de voir de ton vivant l'ascenseur orbital que la fusion.).

voui, je pensais bien sûr d'abord à une évolution coté DirectX 10 / OpenGl.

 
C'est pas bien de se moquer des idées d'AC Clark

Surtout que ca va fonctionner l'ascenseur

c qui ce AC Clark ?

 
C'est un écrivain de SF du Sri Lanka (2001 l'odyssée de l'espace).
 
A part ça je me moquais pas, au contraire
puisque je disais que tu avais plus de chance de voir ça de ton vivant que la fusion comme source d'energie générique .

comme je le pensais j'ai l'air très con maintenant  

 
tu penses vraiment que les développeur vont se faire chier à faire pls path pour le SL 2.0 et vont pas en faire un générique 2.0 et un générique 3.0 ?
 
ie: la puissance brute de la x800 xt pe vaut elle le coup de se passer des sm3.0 et de la gestion de ombres volumétrique de la 6800 ultra?

A partir des SM 2.0, normalement les outils doivent faciliter la création des path.. Evidemment, si faut pas passer sa vie à les optimiser/retoucher......

 
haa l'ignition, y ont du mal

Dis tout de suite qu'on est trop con pour comprendre
 
(en même temps t'as pas vraiment tort)

Marrant, j'aurais dis le contraire
 
 
P.S. l'idée n'est pas de lui

vous pensez que ati risque de rattrapper son retard en opengl / nvidia?
 
les fonctionnalités des SM 3.0 sont elles vraiment un plus par rapport aux 2.0 où sont elles gadget?

1- Non
2- Ca dépend

 
Non . j'ai des copains qui bossent sur le fameux rewrite.
Leur seul espoir c'est de s'allier avec 3DLabs pour basher les quadros au maximum auprès des clients (ce qu'ils font maintenant).  
 
Enfin ça dépend.. Si tu parles des performances dans Doom 3 ou de l'avance en part de marché dans les stations de travail.
 
Pour les performances dans Doom3, ils peuvent essayer de réduire un peu leur retard en faisant un "driver orienté Doom 3" mais ce n'est pas leur priorité (ils préfèrent payer Valve ).
 
Pour ce qui est des stations de travail.. C'est un travail de longue haleine. Qui nécessite beaucoup de travail de minage (FUD, benchmarks) et aussi une relation de confiance auprès des clients qui peut se sapper rapidement. Pour info, ATI a racheté sa branche professionnelle à FireGL et a simplement renommé ses radeon en FireGl. Puis ils ont décidé en 2003 de virer tout le monde (littéralement). Y compris les commerciaux dans la branche professionnelle, ceux qui sont censé instituer une relation de confiance.  
 
Ceci dit comme les gens savaient qu'ils allaient se faire virer ils n'ont probablement pas été très motivés pour faire un bon boulot.
(et comme maintenant plus personne ne comprend le code qui a été hérité de l'époque FireGL, on comprend mieux le sens d'un rewrite..)
 

 
Comme dirait Evildeus, ça dépend. En terme de trivialité d'implementation ce n'est pas un gadget. Si ATI avait pu ils auraient sorti leur carte SM3.0 aussi (ils ont été l'une des principales sources d'inspiration du modèle auprès de Microsoft). Mais d'autres choses se sont mis en travers de ce plan (xbox next? nv40? nintendo revolution ? who knows..).  
Pour ce qui est des développeurs, la nv40 est largement devant la derniere radeon en terme de fonctionalité meme si toutes les fonctionalités ne sont pas liées au support des SM3.0. Mais en l'absence d'autre point de référence, difficile de ne pas prendre les fonctionalités dans leur globalité (floating point filtering et blending, support inconditionel des surfaces non puissance de 2, dynamic flow dans les pixel/vertex shaders etc..).  
Pour ce qui est du joueur, tout dépend de ce que les développeurs en feront et ce n'est pas dit que ce soit les joueurs PC qui en bénéficieront vraiment en premier.
 
Enfin il y a quelques trucs vraiment faciles à faire: instancing, utilisation de maps dans l'espace de l'écran en dimension normales puisqu'il n'y a plus de restrictions (1024x768 prend moins de place en mémoire que 1024x1024). Écrire tous les shaders avec le plus haut instruction count possible, et prévoir un fall back en plusieurs passes ensuite etc...

 
merci de vos réponses.  
 
En terme de fonctionnalité, si on compare les gamme R420 / 6800, il ne manque juste aux chip 6800 d'avoir une correction de l'alpha lors de l'AA.
 

Et aussi le 3Dc
Mais en contre partie les NV40 ont le SM3.0 ... donc au final c'est dur de les departager

3dc ca change rien (ou quasiment), comme l'a montré LeGreg.
 
sinon ceux qui veulent se marrer un bon coup:

http://www.radeonthetop.com/a/106-7.html
Me suis bien marré moi en tout cas

Ouais, moi aussi j'ai lu ça, et je me suis dit "Merde, c'est quel site déjà ? Ha ouais ! Radeonthetop ! C'est pour ça !"
 
M'enfin, moi, je pense que ce qu'il dit se passera, mais à l'inverse, c'est à dire en faveur de nVidia ! Mais bon, c'est qu'une idée perso, pas pour troller !

Non, mais Knyz, meme radeonthetop l'a viré...
Franchement c'est un gros golios ce mec... Ces drivers optimisé, j'ai meme pas vu la différence avec les Catalyst...
 
En plus le mec il a tout compris, depuis quand une compression améliore la precision ? Depuis quand le SM2b peut permettre d'allé plus vite que le SM3 lorsqu'il y aurai trop d'instruction pour le SM2b ? Depuis quand Far Cry est une cata sur 6800 comparé a sur X800 ? Depuis quand le FP16 est pas dans les specs DX9 ? C'est pas du Full Precision, mais c'est dans les specs quand meme

Clari, c'est un golio. Sinon, le Pp a été introduit dans DX9.0a il me semble, non ? au départ il devait pas exister. Enfin, je me rappelle peut-être plus très bien.

Il a été introduit dès DX9.0.

Moi ce que j'aime pas chez ce mec, c'est qu'il nous sort des pilotes, soit disant de la mort, les meilleurs, avec de optimisations super puissante, mais qu'il explique rien du tout quand a ce qu'ils fait vraiment...
 
C'est bien jolie de dire "DOOM3 y va plus vite..." mais c'est mieux de dire "... grace a l'activation forcé du Geometry Instancing dans le pilote OpenGL ATI." non ?
 
Enfin bon, les Omega a priori sont tout aussi perfs sans etre autant instable/incomptabile que les Spirits... Du coup

 
Ok, c'était dans la béta que c'était pas (en meêmt emsp, la béta, c'est ATI qui l'avait demandée officieusement

 
Déjà, quand tu vois le discours du mec, tu te demande si c'est bien lui qui bidouille les pilotes

tu sais c'est pas dur le copier/coller des autres pilotes
 
avec un peu de chance et de bidouille sans rien comprendre, ca peut marcher (suffit de bencher et de voir quoi)

Surtout qund y'a pas de vrai progra derrière

héhé
 
j'suis sur que c'est plus facile de tweaké un pilote ATI que de faire un script pour Nullsoft Installation System (et pourtant c'est deja easy vu que j'ai reussi )

bah il doit bien exister des outils pour comparer du code, ca doit pas etre dur à trouver.

 
oui, ca s'apelle diff

bon stop.
 
le 3Dc n'est pas mauvais en soit, et le S3TC n'est pas adapté à compression des normales, point, et ce de manière générale.
 
Si Doom 3 en high, compresse -tout- sauf les textures de normales c'est pas pour rien (c'est le meilleur compris pour la qualitée générale).
 
Pour l'Instancing je ne sais pas si il l'utilise, et je ne pense pas que ça change grand chose (Doom3 n'est pas un cas d'application pouvant tirer du jus de l'Instancing de manière intense, un simulateur de vol, un jeu de combat spacial, ou un jeu utilisant un moteur de terrain oui, sauf peut être pour les effets de particule/fumée dans le cas de Doom3).
 
bon par contre le gars il est un peu trop pro-Ati.
 
c'est marrant de voir des gens qui ont une inertie.
il a fallu du temps pour que les pro-Geforce Fx s'écrasent.
il faudra du temps pour les Pro-radeon puisse redevenir objectif façe à nVidia.
 
par je suis d'accord que les drivers moddés X ou Y, de manière générale, ils font rien d'autre que foutre des réglages dans la base du registre, et qu'il serait peut-être plus judicieux de distribuer un utilitaire de 300Ko, que de distribuer un package de 10/20Mo dans lequel seul le .inf de 700 octets est modifié. (après c'est vrai qu'il y'a les trucs pour soft-modder).
 
ça éviterai de "polluer" internet dans le sens bande-passante, (pomper une dizaine de Mo pour 1 à 300Ko de différence), et ça permetterai d'éduquer les utilisateurs finaux.

Perso je respecterais plus un programmeur d'un bon vieux tweaker comme du temps de 3Dfx, qu'un modification d'INF de drivers...
 
Surtout qu'en general les programmeurs de tweaker garde pas secret leur trouvaille quoi

 
Oui mais non, un truc qui serait capable de te dire que 2 progs aux exé différents viennent de 2 codes sources à la meme structure et ke l un serait le plagiat de l autre.
 
Bref je me comprends et c est le principal.

 
Plait-il ?

 
si c'est le même exécutable, c'est le même code et le même compilateur qui a compilé le code source.
 
tu as une chance infinitésimale (voir une impossibilitée logique) d'avoir deux code source différents qui produisent le même binaire avec des compilateurs différents.
 
c'est même impossible si les binaires sont pour le même os, même cpu.
 
à la limite il serait possible d'avoir une portion de code qui fasse un truc ressemblant au niveau octet entre deux code source l'un pour une machine l'autre pour une autre (genre PC en x86 et Max en PowerPC), même ce serait une curiosité scientifique car improbable
 
donc si les exe/dlls/sys sont les mêmes, c'est la même chose.
 
pour en revenir à nos moutons, de toutes manières c'est très clair:
le code source est uniquement chez ATI & nVidia.
 
tous les drivers annexes (Omega et autres....) sont des drivers dont juste le .INF a été modifié pour mettre des valeurs dans la BDR, des soft-mods en plus, ou des DLL/SYS modifiés via un éditeur de ressources,  ou un coup de WinHex ou autre pour changer des constantes ou du code (après un coup de SoftIce/déasm).
 
bref ça peut être pratique d'avoir des drivers moddés (c'est vrai), mais personne à l'extérieur d'ATI/nVidia n'a les compétences pour comprendre leur code et faire des drivers compétitifs à ceux fait en interne.
 
bon généralement il faut aussi reconnaitre que les distribs de drivers moddés (Omega, Spirit...) ne se présentent pas comme quelque chose de totallement écrit part eux, hein ils présentent bien qu'ils se basent sur les drivers officiels.

Ben si c'est lui ca fait peur, parce que il doit faire ca au petit bonheur la chance