Reprise du message précédent :
Dans l'article, il y avait un petit passage qui disait que les GT étaient concernées. J'ai beaucoup participé aux commentaires de l'article afin de leur faire savoir que les particularité qu'ils décrivaient comme scandaleuse étaient en fait connues depuis déjà un moment !
 
Et je leur ai aussi signalé ce que précise Gonishi !

7960 3dmarks pour la gf6600 GT. ça peut le faire si le prix suit. Le rv410 sera annoncé (des cartes seront envoyées aux testeurs) dans 1 semaine aussi. Source : notre inquirer favori
 
Marc au fait, quant tu fais un comparatif de cgs, tu pourrais inclure les resolutions HDTV (1920x1080 , 1280x720 ) et aussi de voir quelles sont les resolutions qu'on peut faire passer par la sortie télé ? . Ce dernier point est souvent occulté dans la majorité des tests Avoir du 16/9e en tv out est pas toujours aisé.
 
 
[hs]kan on a été ban depuis 2 jours et aucun mail ne vous a dit pourquoi ou qui, on fait koi ? [/hs]

On calme un peu ses filtres antispam sur la boite mail correspondante?

Mais, question : comment ça fonctionne le HDTV, et comment on peut l'utiliser ?

 
la date (ati) et les perfs me semblent logiques (5950 @ 500/500 ca doit faire ca ~)

 
Je pense que c'est ça, grosso modo ils ont du constater le gros foutoir que ça avait été avec les PS2.0 et les caps dans tous les sens et donc ils ont voulu fixer les choses précisément avec le SM3.0. Pas de caps c'est du tout ou rien, le problème c'est que du coup ils y ont lié par la même occasion des choses qui n'ont rien à voir comme le Geometry Instancing.
 
Comme tu le dis : du grand n'importe quoi, c'est là où on apprécie le modèle OpenGL où tout n'est pas décidé par une même société selon ses humeurs du moment.

 
sur hotmail ? bien tenté mais c pas ça.
 

 
Vaste sujet... je te conseille http://www.tomshardware.com/consumer/20040805/ (anglais dsl)
 
en gros avant de lire l'article :
 
1- c'est quoi le hdtv
 
Une resolution plus élevée et un son haute qualité multicanal. (1920x1080 et son 5.1). Ca permet d'avoir plus de detail sur l'image, une meilleure qualité
 
2- les normes
 
voir article (mpeg2 ou 4, wmv9HD)
 
3- comment ca marche pour un pc.
 
Le but c'est de sortir ta haute resolution sur ta télé elle aussi compatible HD (Normalement ta télé classique comporte 576 lignes. Avec la HD on peut sortir du 720 lignes voire 1080). Or sur la plupart des sorties TV actuelles tu sortiras au mieux du 1024x768@60 ou 50 hz. c'est pas génial. Quelques cartes permettent de sortir plus, comme les Volari ou la derniere S3.
 
 
Voila le résumé en gros. l'article est bien fait et ya des images avant/apres. Meme si il se resume a la diffusion TV et non a l'utilisation PC (jeux, films HD).
 
ps : zut c'est pas le bon article... raaaaah zut celui que je voulais montrais un match de foot américain avant/apres. On pouvait presque voir chacun des visages des spectateurs dans les tribunes .

Ok, merci. J'étudie tout ça !

 
Je viens de voir que les 5950 ultra sont au minimum a 328 €. On attend la GT a 250€ max je crois... c'est bon, c'est tres bon  
 
Sinon pour HL2 les gf6xxx utilisent le meme codepath que les ATI ou doivent se taper les partial precison des gf5xxx ? Les problemes precedents (pas assez de registres, faiblesse en puissance "shaderique" brute, fp32 désavantagé par rapport au fp24) on été résolus il me semble  
 
edit : fp32

 
Il n'y aura pas de mode partial precision ni pour la geforce 6800 ni pour la radeon x800 (enfin là on s'en doutait).
 
Ceci dit si c'est toujours bénéfique d'utiliser la partial precision sur la geforce fx, c'est plus mitigé sur la geforce 6, la pression sur les registres est moindre et il n'y a que dans des cas bien précis où c'est un gain à tout coup (normalisation notamment). Enfin en tout cas la performance sur les 6800s devraient être plus qu'acceptable dans Half Life 2.

Je dirai même excellente

C'est sûr qu'ils prennent le temps de la réflexion...  

 
pour un ordi, aucune différence, il "suffit" de gérer le 1920x1080 (bon, c'est pas tout à fait aussi simple en fait, mais pas loin) et avoir un écran qui supporte cette résolution...
 
il me semble que le dvi est obligatoire pour le hdtv, aussi
 
(edit : oui parce que, dites moi si je me trompe, je crois pas qu'il soit possible de faire passer du hdtv par du rca ou du s-video. en tout cas, la seule télé hdtv que j'ai vue (la sagem présentée en ce moment dans les fnac) elle prend que du dvi pour faire marcher les hautes résolutions, d'après ce que j'ai vu. (mais c'est p't'être parce qu'aucun matériel ne sait faire transiter ces res. autrement)

 
arf là j'avoues, d'autant plus qu'il y a beaucoup de chances de pouvoir faire de l'Instancing avec une Geforce Fx, et nVidia ne voudra certainement pas en entendre parler, pour pas avoir le marketting de la 6800 qui s'écroule.
 
bref, rien n'est parfait.

 
Non ça c'est certain, DirectX a d'autres avantages
En règle générale le fait que seul MS tranche au final ça permet d'accélérer les choses contrairement à OpenGL où ça peut s'éterniser (cf commentaires de Carmack sur le render to texture lors du dernier QuakeCon) comme l'a fait remarquer mareek. Mais lorsque MS ne prend pas la bonne décision tout le monde en pati

 
http://www.pcinpact.com/actu/news/ [...] _Nitro.htm
 
Ils parlent d'un connecteur sortie YPbPr    
 
Sinon il y a aussi des videoprojecteurs hdtv, supportant au moins le 1280x720. Et ceux la en general peuvent etre branchés en VGA (dsub 15).
 

 
ah oui, c'est vrai !!! je crois qu'on peut faire passer du hdtv par ces connecteurs là (en tout cas, on s'en servait surtout pour faire du progressive scan jusque là, je crois, mais du coup, ça doit être possible aussi)
 
mais pour plus de détails, je te conseille de chercher un peu dans la cat video/son, il y a sûrement un topik avec des gens qui maîtrisent mieux ce domaine...

 
ouep.
 
ce que j'aimerai bien c'est justement puisqu'on en parle, que l'Instancing soit supporté par les Geforces Fx, ça permetterai au niveau développement de faire un moteur purement en Instancing.
 
car l'aspect bataille SM 2.0/3.0 ça n'a pas tellement d'implication au niveau architecture d'un moteur, alors que si les Gf Fx supporteraient l'Instancing, on pourrait programmer en se disant que l'on peut faire un moteur entièrement basé sur de l'Instancing.
 
surtout qu'à partir du moment où le hardware supporte les VS 2.0 et plusieurs flux de vertexs (juste 2), je pense qu'il est "assez facile" de faire le support de l'instancing au niveau driver.

Et tu fais quoi des possesseurs de cartes ne supportant pas l'instancing (les cartes, pas les possesseurs, hein ?)?
Ca me paraît radical comme solution... même si ce serait bien.

Pour un futur moteur comme l'Unreal Engine 3, la question se posera pas puisque ce sera DX9 mini, et toutes les cartes DX supportent l'instancing. Sauf les GFFX, enfin, on sait pas....

 
Non le support de l'instancing sur les 6800 est hardware. Cela va de paire avec le support d'un generic sampler dans les vertex shaders. D'ailleurs ce n'est pas toujours un gain en perf parce que ça demande au chip de faire une petite quantité de travail supplémentaire par vertex d'ou le conseil de n'utiliser cette optimisation que lorsqu'on dessine par petits lots de vertices.
 
La taille des batchs est un probleme general lié à l'architecture de Dx/windows et les drivers n'y peuvent que moyennement grand chose. Il y a plusieurs solutions envisagées, celle de l'instancing ne règle qu'une partie des problèmes, puis celle de Longhorn qui est d'avoir une partie du driver en mode "user" (plus proche de l'application).

oki.

Mais comment vous faites pour savoir tout ça ?  

entre des gérants (si le mot convient) de sites et des gens qui bossent directement chez les 2 grands, on est servis sur ce topic

Va falloir changer le titre alors, parceque bon, c'est pas du the Inq ici    

Je propose :
 
Graphical Open-Bar : Cours de GPUlogie :-d

 
c'est pas mal, ca correspond tout à fait à l'usage que j'en fais

 
Il y a un lien entre le geometry instancing et le sampler dans les vertex shader autre que l'appartenance au bundle SM3.0 ?

 
pour ceux qui veulent des infos techniques détaillées
les docs à destination des développeurs sont souvent très completes
http://developer.nvidia.com/object [...] _date.html
 
Et en meme temps assez différentes de la communication à destination du grand public (qui n'a que faire des conditions optimales de l'utilisation de telle ou telle feature).
(chez ATI: http://www.ati.com/developer/)

 
ca necessite un moteur de vertex remanié si c'est ce que tu veux savoir.
 
Après pour les détails..

 
Oui je m'en doute mais ça ne veut pas dire que ça a un rapport avec le sampler et encore moins qu'une carte qui n'a pas de sampler ne peut pas gérer en hardware l'instancing.
 
Ce n'est pas parce que pour les PS3 il faut supporter le FP32 et les branchements dynamiques que ça signifie que le FP32 est une nécessité au fonctionnement des branchements dynamiques. Ce sont juste 2 choses qui n'ont aucun rapport mais qui font partie d'un même bundle de features. D'ailleurs c'est possible de n'exposer que l'un ou l'autre.
 
Pour le geometry instancing et le sampler dans le vertex shader le lien est encore plus étroit voir complètement inexistant que ce soit au niveau de l'intégration hardware ou de la fonction. Alors qu'il faille supporter le sampler pour pouvoir exposer le geometry instancing je trouve ça complètement débile de la part de Microsoft.

Euh Marc, HKEPC a refait la boulette d'Anandtech, a savoir comparer les pommes avec des poires.
le shelton est comparé avec un C3 Samuel2, un vieux core comparé au Nehemiah (voire Esther qui sortira dans qq mois). De plus sur une carte mère PCchips basé sur un chipset SiS.
 
Autant comparer un A64 avec un P4 Willamette. ok oui j'exagere un poil mais le core Samuel date de debut 2001 qd meme... Depuis VIA a fait pas mal de progres (core Ezra, puis Nehemiah).  
 
Manque 1 chose sur cette carte.... plein de connecteurs. genre sortie tv, son 5.1, numerique, ... Les mini-itx sont imbattables sur ce point. A mon avis si Intel sort la carte comme ça c'est le bide assuré.
 
Sinon, pour les sorties TV et le HDTV, nVidia et microsoft considere le 1024x768 comme de la HD. Pour monter au dessus c'est VGA/DVI ou le truc YPbPr.

 
en fait le problème c'est la mises des donnés du flux de vertex d'instancing dans les registres du VertexShader non ?
 
je suppose que sur la 6800, tout est hardware (un registre de décompte pour le prochain fetch dans le flux d'instancing).
 
mais on peut aussi imaginer que le driver fasse le boulot de programmtion des registres de VertexShader, le hardware n'as pas vraiment de deuxième flux de vertex, mais a chaque fin de traitement du vertexbuffer(+indexbuffer) principal, le driver pourrait pousser les nouvelles valeurs et relancer le hardware, sont toucher à sa configuration.
 
je suppose que de cette manière, "même" si on a pas le rendement équivalent à une solution full hardware, on élimine tout les allez-retour App<->DirectX<->Driver dû aux changemet de constantes, et begin()/end() et autres DrawPrimitive non ?
 
d'un autre coté est-ce qu'il serait pas interressant de créer un buffer  à constantes, et pareil faire des DrawPrimitive() avec multiplicateur, et que le driver fetch les constantes dans le buffer entre chaque itération de traçage ?
 
--
 
en fait pour que ça marche que ce soit l'approche hardware complète, ou l'approche par mi-hardware/mi-soft, il faut que le hardware puisse conserver l'état des registres de VertexShader utilisés par l'instancing, et ce de vertex en vertex (du VB principal).  
En gros si le hardware est fait que pour remplir les registres depuis un VB à chaque nouveau vertex, ça peut pas marcher, vu qu'il faut que des registres soient invariants pour X vertexs traités.

A mon avis HKEPC c'est trompé, il n'existe pas de Samuel2 (.15µ) 1 GHz, donc c'est forcément un processeur plus récent.
 
Pour la carte mère, c'est seconde, ce qui est interressant ici est le processeur

 
Selon les quelques détails de son implémentation que veut bien donner ATI, le GI fonctionne grâce à des registres hardware.
 
De toute manière peu importe la manière dont ils le supportent du moment que ce qu'ils exposent réagisse comme le prévoit la fonction. Peu importe aussi que le GI d'ATI ne soit pas aussi performant que celui de NVIDIA dans certains cas (ce qui reste à démontrer).

bah c'est pas tellement le rendement de l'implémentation d'ATI qui me gêne, mais le pourquoi de ATI as pu le faire, et pourquoi les autres ne pourraient pas le faire, même avec des  restrictions de rendement (nVidia pour la famille Fx, on pourrait aussi citer les volari, mais bon ce serait inutile).
 
parceque, au niveau moteur coté C++, gérer des variantes de shader 1.x/2.x/3.x, c'est pas forcément chiant, par contre ça pourrait être sympa de pouvoir se dire: "je veux faire un jeu qui de toute manière nécessitera au moins une Radeon 9500+/Geforce Fx, autant utiliser ce qui développera le max de rendement pour cette génération et les générations à venir, au lieu de faire un truc bancal".

Je suis d'accord avec toi pour les 2 points. Ceci dit dans un monde idyllique le point 2 est censé imposer une réponse logique au point 1 Si ce n'est pas fait c'est que ce n'est pas possible / si simple.
 
Mais on ne vit pas dans un monde idyllique donc d'autres raisons peuvent entrer en jeu d'autant plus que Microsoft ne pousse pas vraiment à sa généralisation sur les cartes non SM3.0.
 
Sinon ce n'est pas compliqué d'utiliser le geometry instancing dans un moteur uniquement pour les cartes qui le supportent. Mais bon c'est clair que c'est plus intéressant pour un développeur de bosser sur une techno qui fonctionne sur une partie importante du parc que sur quelques machines de hardcore gamers.

http://www.hardware.fr/articles/513/page1.html
 

http://www.hardware.fr/articles/513/page2.html
 
Bon j'arrête d'enumérer les erreurs (de grammaire entre autre) mais y'en a pas mal par rapport à d'habitude.
Visiblement Marc n'a pas encore relu son article.

Plus de Direct 3D mais WGF 1.0 ?
 
http://www.clubic.com/n/n16279.html
 

En même temps il me semble que DirectDraw et Direct3D ont déjà fusionné, non ?

Gonishi> N'hésite pas à continuer en MP