Reprise du message précédent :

A l'époque l'aniso bouffait énormément. Et l'impact de celui-ci sur les perfs était vraiment énorme. Maintenant c'est différent. Je ne condamnes pas un peu fort, je remets les choses dans leur contexte.
 
Pour le HDR in Valve : c'est peut-être du bricolage, mais ça fonctionne, apparemment. C'est ce qu'on leur demande. Pour l'isntant c'est encore la seule implémentation artistiquement convaincante... Far Cry est mieux question méthode, mais leur HDR et tout ce qui s'ensuit est vraiment artistiquemetn à côté de la plaque

J'ai retrouvé :
http://forum.e46fanatics.com/showt [...] =half-life
http://forums.facepunchstudios.com [...] hp?t=21286

Toujours aussi belles.... Quand on verra ça dans les jeux....

 
Là n'est pas la question : tu accuses Nvidia de privilégier les features qui font vendre au détriment du filtrage alors que pendant longtemps leur filtrage a justement été trés bon. S'ils l'ont sacrifié c'est un peu aussi parce que la plupart des joueurs ne regardent que les scores des benchs et se fout du reste
 

 
Les PS1.1 alias registers combiner aussi ça marchouillait pas mal pour faire du bump, n'empêche j'suis bien content qu'on se soit débarassé de cette merdouille
 
Bref à bas le bricolage, surtout que je sais pas trop comment marche la méthode de Valve mais tout ce que j'ai lu sur le sujet concernait justement leurs ressources statiques (skybox, lightmaps etc) mais dés que tu veux combiner les contributions de plusieurs lumières dynamiques là tu n'as plus trop le choix.

 
On est d'accord, la majorité qui achète ne regarde que les barres.
 
C'est sûr, c'est mieux sans bricolage. Néanmoins ça a le mérite de fonctionner pas trop mal sur du vieux matériel quand même, et avec une perte de perfs honorables. En attendant qu'une bone proportion puisse faire du HDR complet et pas bricolé, c'est un bon compromis. D'autant qu'apparemment c'est surtout le développeur de contenu qui se prend la tête avec leur méthode...
 
Le bricolage, c'est chiant. Mais parfois ça peut être intéressant, en attendant mieux. Toute façon, c'est certain que la méthode de Valve n'est pas vouée à être pérenne.....

La 3D c'est du bricolage

C'est pas faux du tout ça

Normal, à l'époque l'aniso n'avait qu'un interêt moyen étant donné la puissance des cg

Quand je pense qu'à cette époque là je bouffais els 3/4 de mon framerate avec le FSAA
 
Miam !

c'est ça les geeks  

Il apportait quand même

HS
 
 
Questions G72 :  
 
Evolution du G70 càd 7900, 7800 Ultra, ou bien milieu de gamme 7600 ?  
 
Sinon il est question d'une possibilité, comme ce fut le cas avec les 6X00, de voir sortir des CG avec deux GPU par l'intermediaire du SLI.  
Question : Si une telle CG existera, sera-t-il possible d'en utiliser 2 en SLI ? Car la technologie SLI étant deja utilisée sur une CG entre ces deux GPU ...  
 
PS: je sais que cela n'a rien d'interressant au point de vu perf/prix, mais ce qui m'interesse est de savoir si c'est possible car je ne connais pas les caractéristiques de la technologie SLI emploiée par Nvidia.
 
 
 
HS

La CM Gigabyte avec 4 ports PCI-E 16x/8x supporte 2 3D1, donc 4 GPUs, mais les pilote sne le permettent pas encore (bridage).
 
http://www.tomshardware.fr/article [...] &NumPage=1

question pour Tridam/Legreg:
 
L'adaptive AA coté ATI / eq coté Nv, je suppose que ça ne s'actives que lorsque on active l'alpha test, voir sans blending ?  
 
vu qu'on peut avoir TEST OFF/BLEND OFF, TEST ON/BLEND OFF, TEST OFF/BLEND ON, TEST ON/BLEND ON, vi à vis du canal alpha.
 
y'aurait moyen d'avoir de la doc pour savoir quand ça se déclenche ?
 
parceque pour un moteur de particule, il peut y avoir méchamment de l'overdraw, l'adaptive aliasing ça peut méchamment avoir un effet de bords sur les perfs.
 
le must serait un renderstate pour autoriser au non l'AA. (perso je serai pour avoir un jeux de renderstates pour spécifier l'AA au rendu, histoire de le distribuer intelligemment).
 
parceque par exemple pour un rendu de fourrure ou des particules (étincelles dans Fear, fummée/gerbes de sang dans Quake 3), serait bien de pouvoir limiter l'AA a du 2x, passke bonjour le kill de framerate si ça se déclenche là aussi.
 
en même je supposes aussi que si c'est lié au test alpha, ça se déclenche que pour les fragments qui sont à la limite du test. (ce qui permetterait de limiter les dégats).
 
d'ailleurs y'a ptet une différence entre X800/GF7/X1000 à ce niveau non ? (si le hard est pas optimisé pour, sur X800 ça a ptet plus tendance a faire l'AA dès qu'il y a de l'alpha test sur tout les pixos, alors que ptet sur GF7/X1000 c'est par pixos en limite de test ?)

 
C'est pas trés clair mais moi aussi ce que j'avais compris c'est que ça ne marche que dans le cas TEST ON/BLEND OFF
Autrement dit alpha testing sans alpha blending, pour la doc il n'y a guère que ça que tu as surement déjà lu et qui ne nous apprend pas grand chose.
 
Pour le contrôle de l'AA en OpenGL il y en a une certaine forme vu que si tu as choisi un pixel format supportant l'AA tu peux ensuite activer ou désactiver l'AA par batch en utilisant glEnable/glDisable (MULTISAMPLE_ARB); mais en fait j'ai jamais testé si ça marchait vraiment en pratique

Chez ATI (et NV aussi à priori), ils l'activent par triangles dès qu'ils utilisent l'alpha test mais pas l'alpha blending. La détection est totalement logicielle donc ça augmente la consommation CPU.
 
Les X1K sont censées avoir des optimisations hardware mais je ne sais pas à quel niveau exactement. Il y a aussi un mode performance qui n'est pas encore visible via le CCC.
 
 

et bien écoute non, je ne l'avais pas lu, et a priori ça semble good, puisque  si c'est avec alpha testing sans alpha blending, et avec un renderstate pour l'activer, ça devrait permettre d'être contrôllé correctement.
 
donc effectivement ça semble être une bonne opération d'utiliser l'adaptive AA face à la solution avec blending pour adoucir les contours mais sans les artifiacts du blending si les triangles sont pas triés.
 
maintenant il serait interressant du faire un outil de bench pour voir qui a l'implémentation la plus efficace.  
comme ça semble enfoui assez profond  dans les pipelines, je m'attends à ce que les X800 soient moins efficaces que la GF7 & X1000 à ce niveau.

 
ok (mon post d'avant suivait le post de Zeross), donc a priori ça va dans le sens auquel je m'attendais (X1000 >> X800 à ce niveau).
 
en fait tout la question est de savoir si on fait l'AA sur tout le triangle ou juste sur les pixels/fragments en limite de test je suppose. (ce qui pourrait permettre de méchamment gagner en vitesse sans pour autant perdre en qualité)

 
Je ne comprends pas comment tu pourrais faire ça ?
 
Mais je n'ai pas dormi de la nuit et je suis crevé donc c'est peut-être normal

 
C'est le mode qui utilise deux fois moins de samples de texture que de samples géométriques ?
C'est intéressant mais par contre la position des samples de texture laisse un peu à désirer visiblement :

Oui c'est ça.

 
en fait je sais pas, donc c'est ptet effectivement une idée à la con  

je me suis pas installé le SDK d'octobre, y'a des renderstates propres pour controller ça ? (passke je vois dans le PDF de nV, que y'a des FourCC a gogo).

 
Non y'a que les fourcc c'est devenu le mécanisme d'extension non officiel de Direct3D. Ça permet à la fois d'exposer des caps non prévues (via format de texture), et d'enabler des capacités spéciales. Faut juste faire gaffe que le debug runtime peut potentiellement invalider des appels, donc l'utilisation duy mode release est préférable.
 
Note que si tu l'actives depuis l'appli en suivant la doc de chez Nv, tu n'es pas limité à l'alpha testing, ça te permet aussi de supersampler les pixel shaders, faut juste faire gaffe à ne pas le faire sur une trop grosse partie de la scène.

par contre y'a un truc qui me chiffonne sur les X1000, la filtrage des textures flottantes, qui n'existe pas, ça peut se faire par shader avec le même niveau de perfs que si c'était une unitée dédiée ?
comment on résout le cas avec un/une cubemap ?
ça m'intrigue cette restriction.

 
C'est vrai que ça pourrait être interressant ce genre de trucs.

Vous avez vu le coup de nV avec ses sockets pour GPU ?

 
Avec le même niveau de perfs qu'une unité dédiée je pense pas vu que le filtrage est "gatuit" sur NV4x/G7x (même si l'impact qu'il a sur la texture cache n'est lui pas gratuit vu qu'elle n'a pas assez de bande passante pour fournir 4 valeurs FP16) alors que sur X800 tu dois faire 4 sampling de textures + 3 lerp. Maintenant le filtrage FP16 est-ce que c'est vraiment primodial ? Moi je pense que son principal intérêt c'est lors du tone mapping pour calculer la luminance moyenne en scalant la scène et pour les effets de blooming pour accélérer le blur. Mais pour les données statiques je pense pas que le FP16 soit nécessaire ceci dit j'me suis pas penché sèrieusement sur la question.
 
Pour le cube map je crois que la question du filtrage correct des faces aux arêtes n'est géré par aucune carte donc ça ne doit pas changer grand chose.

 
Moi qui me plaignait des extensions OpenGL finalement on est pas si mal lôtis

 
Sur le haut de gamme c'est ingérable, les fréquences sur les pins sont telles qu'il faut que ca soit soudé pour avoir des fréquences aussi élevées ...
Sur le bas de gamme, je sais que les puces ATI sont déjà pin to pin compatibles (enfin genre la R9000 l'était avec la R7500 et pitet avec les 9600 aussi ?)
 
Bref, le pin 2 pin est a mon avis bcp plus intéressant (pas de redesign à effectuer) qu'un socket GPU qui est trop lourd et trop couteux

 
oki, mais un cubemap dynamique en fp16 (ça pourrait être supra relou de se taper le filtrage dans le shader des surfaces des objets) ?
après c'est vrai qu'il y a ptet moyen de changer le format à la volée du cubemap fp16 en autre chose qui accepte le filtrage.

 
c'etait pas plutot pour les portable ca
 
sinon il est ou l'interet? juste pouvoir changer le gpu sur ca carte graphique?    
vu les conso qui grimpent a chaque fois je vois pas comment ca serait envisageable d'ailleurs  

 
ouep.
 
bon en même temps ça fait pas de points d'entrées supplémentaires.
enfin bon on aura ptet une update du SDK pour normaliser ça, si c'est juste des renderstates a déclarer.

Décidément, ATI parlerait de ça pour son R580 mainteant, apparemment.......
 
http://www.presence-pc.com/actualite/socket-ati-12477/

C'est in c'est tout
Cepandant il a tjrs été dit que c'etait pas possible d'un point de vue de qualité de signal... Donc c'est apparement devenu possible.
 
Le vrai pb c'est que ca changera rien a l'evolutivité vu que la RAM restera un des facteurs limitant les perfs.
 
Sinon 7500-->9600 c'est +/- pin compatible. Seulement comme c'est pas la meme RAM sur les gros modele 9600 (BGA au lieu de TSOP) ca a pas été trop utile pour le prix des 9600 Pro/XT.

 
si c'est integrer sur la carte mere on peut imaginer qu'a terme il y aura un socket pour GPU et des ports pour des barettes de ram qui seront utilisé par le GPU

Le problème resterait entier, regarde la disposition des puces de RAM autour d'un GPU, cette edrnière n'est pas là par hasard.

on a moyennement la surface sur une mobo pour caller un GPU haut de gamme, son étage d'alimentation, et sa ram.
 
par contre, il se pourrait que dans la mesure où on va progressivement avoir plus d'opération arithmétiques que d'accès mémoire à cause des shaders (cf radeon 9800 / 6600gt), ils se pourrait qu'avec le même chassis (pcb+ram), ATI & nVidia proposent des "overdrives".
 
on pourrait très bien imaginer un mec qui achètes une RAFORCE Z6100 (moyenne gamme année 2008), puis qui change le gpu avec la moyenne gamme de génération d'après qui sera plus performant et aura plus de feature.  
un peu comme un mec qui achèterai une 9800pro pour acheter plus tard un overdrive 6600gt pour avoir le SM 3.0.
 
mais bon d'une part, la revente existant toujours je sais pas si il est plus interressant en rapport perf/prix de changer le gpu sur socket pour un nouveau modèle sans le revendre (ce sera difficile pour les premières générations) que de revendre toute la carte et prendre un nouveau modèle.
 
on peut aussi imaginer des carte 3D multi GPU avec plusieures sockets, avec par exemple un seul socket occupé, après l'acheteur peut compléter au fur & à mesure la carte.
 
ce genre de solution peut être très utile pour le monde pro. (simulateurs,  CG de film accéléré hardware avec un gelato-like). ou tu fous 8 gpu dans un rack, un an ou deux après tu upgrades les gpus... etc.. etc..

 
c'est l'aspect disposition et le fait d'avoir quelque chose de fixe qui permet de gagner sur la qualité de signal.
c'est pas dit qu'avec un gpu sur socket bien conçu tu perdes énormément par rapport au même gpu soudé direct le pcb.

Ok. Enfin, on verra bien quoi

Pendant qu'on y ai on peu imaginé des modules "QIMM" (Quad ... ) de 128bits eu Dual Channel de DDR3 a 1,2GHz partagé pour le CPU et le GPU par le chipset.
 
Mais :
- Ca couterais cher.
- Ca ressemblerais plus a une console qu'autre chose.