Reprise du message précédent :

 
En static ça marche très bien mais en dynamic sans une très forte cohérence oublie.

/hs mylife
 
Je debute un emploi de helpdesk donc je n'aurais plus trop le temps de dweller ici.
 
magic-sim : et toi ton nouveau boulot ça marche ?
/hs mylife

[HS]
Ouiiiiiiiiiiiiii Je m'éclate ! Ambiance super sympa, collègues franchement au poil. Y'a du boulot en plein, mais c'est pas non plus une cata, juste ce qu'il faut. Je fais ma seconde formation là. ça va me porter à 3 semaines de formation sur Enterprise Application Environment (MCP/Unisys).  
 
Je m'éclate bien. Et je suis dans la plus bielle marie de France ^^
 

[/HS]

Ca fait plusieurs années qu'il y a 5000€ de bons d'achat à gagné. Est-ce que ça va augmenter l'année prochaine ?  
 
 
 
edit : je me demande, les X800SE 256 Mo elles ont un bus mémoire 256bits ou 128bits ?
 
Aussi est-ce qu'on sait pourquoi y'a autant de différences X800 <-> 6800 sur HL2, sur Doom3 on sait pourquoi mais sur HL2 ?

C'est la deuxième année
Dans 2 ans ce devrait être bien plus
 
Sinon c'est 256 bits pour les X800 SE normalement

Ah je croyais me souvenir que c'était la 3ème
 
ok 256bits, merci  
 
edit : à tu voulais dire que ce n'est que la deuxième année où c'est 5000€
http://www.hardware.fr/news/5760/C [...] ue-3H.html

Et sinon pour HL2 ? Qu'est ce qu'il utilise qui fait que les 6800 soient moins performantes ?

bah la famille des gf6 est pas spécialement moins performante sous HL² que la famille des Xxxx (font chier avec leur X ).
 
après y'a l'avantage d'avoir des pipelines plus simples, plus de fréq, etc, etc, bref des petits détails de compromis d'implémentation.  
d'autant que bien évidemment c'est plus facile d'avoir un meilleur rapport perf/coût avec du hard "que" sm 2.0 par rapport à du hard sm 3.0 sous une application sm 2.0.

 
Ca je suis pas forcement d'accord, car quand tu regardes, les GF6 sont tjrs plus rapides en T&L qui n'est pourtant plus que realise via les unites de SM si j'ai bien suivi

J'avais pensé à la fréquence, mais vu le comportement des GF6 sous Far Cry par exemple ça n'explique pas tout. Et une X800XL n'est pas plus rapide qu'une 6800Ultra (en terme de fréquence).

 
on sais pas y'a ptet un hack

NV laisse toujours certaines optimisations/circuits dédiés au T&L. C'était tout aussi visible dans les GeForce FX (en particulier dans le NV30).
C'est surtout bien pour les déclinaisons Quadro et ça ne fait pas de tords dans les vieux jeux/benchs en général

moi j'aime pas c'est du transistor pris sur autre chose

 
ca avait ete annonce que les circuits T&L etaient desormais integres dans les unites generiques de SM il me semble mais bon, y'a ptet des pitites magouilles

D'après ce que j'ai compris (mais c'est pas clair ) les ressources physiques utilisées dans les deux cas (T&L et Vertex Program) sont bel et bien les mêmes, La différence entre ATI et nVidia c'est qu'ATI crée un véritable vertex program pour reproduire le pipeline fixe, là où nVidia n'a pas besoin de ça (comment c'est géré exactement par contre   ). Du coup ça permet certaines optimisations et ça évite de tomber sur une émulation software comme ça peut être le cas sur ATI car certains cas pathologiques du pipeline fixe utilisent trop d'instructions.

Ouais enfin on a bien dévié de la question là
 
edit : Comment ça se passe la validation de mémoire
http://www.hardware.fr/news/7541/D [...] z-PQI.html
 
Y a un type qui test les barrettes sur une carte mère    
 
Je vois pas du tout comment ça peut-être fait de manière automatique à grande échelle.

 
Tu sais euh... les annonces ça n'a été que totalement vrai chez ATI.
Maintenant au final si ça ne prend à NV qu'une partie insignifiante du chip pour des résultats bien meilleurs en T&L, tant mieux  
 

 
Tu sais à combien ça leur revient le travailleur chinois qui prend 1 min pour insérer les barrettes/lancer le test/enlever les barrettes? (le test est plus long mais il peut travailler avec une série de couples mobo/barrettes)  
Je crois que le prix sur ce genre de barrettes couvre amplement les coûts de revient
Bien qu'on peut facilement programmer un robot pour faire ça mais ça leur reviendrait plus cher...

 
 
la grande question reste donc de savoir comment nv arrive a faire son truc alors

Ils ont dû intègrer des shadoks qui pompent

Ouais de toute façon ça restera tjrs obscur cette histoire, peut-être que dans 50 ans on saura la vérité  

en même temps, on s'en fout un peu, tant que leurs polys sont bien calculés
 
c'est tiut bénéf pour eux et ceux qui ont besoin de beaucoup en géométrie....
 
Remarquez.... c'est vrai, ça vient d'où ?

Que pensez  vous de cet article ?
http://www.matbe.com/articles/cg/gpu/page1.php

 
je ne sais pas si c'est bien destiné à la fréquentation de mat.be
ça semble plus orienté pour un site de prog ?
 

alors je commente au fur & à mesure que je lis:
 
1) le tramage entre le culling et le pixel pipeline ye vois pas ce que c'est. (j'ai la flemme d'aller voir si c'est juste une tentative de traduction du modèle de pipeline OpenGl ou du Dx). (edit: oki j'ai été voir plus loin, c'est la mise en quad etc, etc, tiens je sais même po comment ça se dit en english)
 
2) la normale: à éclaircir:
 
Dans la pratique elle est présente par vertex et non par triangle (point subtile).  
L'article présente bien la normale contenue dans le lot du "vertex", mais en parle ensuite au niveau triangle.
 
Donc plus précisément: bien évidement on la calcule d'abord par triangle (en hors ligne via le modeleur 3D ou autre, ou au chargement du modèle) MAIS la normale par triangle est perdue pour le rendu (mais pas pour le moteur physique/moteur de collision), elle sert à calculer la normale "moyenne" par vertex (=> moyenne des normales des triangles empruntant le vertex, avec gestion de cas particuliers comme les angles limites, etc, etc).  
 
Et le VS ne permets pas de calculer la normale par vertex, il se place au niveau vertex, et non au niveau triangle, quand un VS traite un vertex, il ignore les autres vertexs utilisé par la primitive.  
 
Mais par exemple pour le dot3 bump mapping (normal mapping) ,on peut par produit vectoriel obtenir la binormale ou la tangente à la volée, à condition d'avoir normale & tangente ou autre couple de vecteurs décrivant le repère texture..
 
3)  Pour le poids du vertex, j'aurai tourné la phrase autrement, c'est pas vraiement le poids du vertex, mais le poids d'un repère (matrice). pour le skinning les vertexs sont "lissés" entre plusieures repères, et ce poids permet de pondérer l'importance de ces repères.
 
4) triangle strip/fans
 
en fait dans le passé le strip était le plus interressant.
mais le problème c'est que l'on ne peut pas "stripper" tout un modèle, donc le strip peut générer beaucoup d'appels inutilement.
on peut pour réduire les appels API utiliser un strip dégénéré (où l'on fait des faux triangles qui seront rejettés par le culling) qui permettent de connecter plusieurs strips entre eux. mais ça génére des triangles en trop.
 
et finalement c'est les triangles indépendants qui gagnent, très peu d'appels de traçage, le cache post-T&L produisant le même effet qu'un strip, et pas de faux-triangles inutilement rajoutés.
 
5) Les tampons d'indexation:  
Oué point important toujours laissé pour compte dans 99% des articles, couplés aux triangles indépendants c'est ce qu'il y a de mieux, un indexbuffer permet de profiter du cache post-T&L (donc ne pas faire sans IB c'est le mal).
Le cache post-T&L étant un point interressant et critique: une carte 3D a "grosso modo" des perfs de traitement de  Vertex connues (prédictibles on va dire, donc on peut le communiquer en vertexs/secs), par contre les perfs en triangles/secs est plus variable vu qu'il dépends des vertexs/secs et du taux de réussite vis à vis du cache post-T&L.  
 
Il est donc de bon aloi pour avoir le max de perfs géométriques d'utiliser des Triangles Indépendants + IndexBuffer, et d'optimiser l'IndexBuffer pour avoir le maximum de réussite au niveau du cache Post-T&L, et finalement d'optimiser le VB par rapport au IB pour maximiser les perfs au niveau des fetchs de vertex.
 
voilà my 2 cents.

tant mieux si ils cherchent à relever le niveau.
ça donnera ptet envie à certains de se remettre à la prog en opengleu ou en direct3déé

tramage c'est la traduction quasi officielle de raster.

ha bon. boh je préfère parler de raster/rasteriser.

un tramage c'est le dithering pour moi. (spour ça qu'au début je voyais pas ce que ça foutait avant le pixel/fragment shader)

L'hyper threading permet-il vraiment de jouer avec des tâches en arrière plan (style msn, antivirus, firewall, etc...) sans aucune saccades ?
 
Le test sur le dual core semble dire que oui.

msn, firewall et antivirus (et speedfan aussi) ça bouffe dans les 0% de CPU, pas besoin de hyper threading pour ça !

bah les speedfans & co, si il attaquent le SMBus, ça peut imposer du polling violent au niveau driver kernel, et ça peut générer des micro-saccades.
mais bon ça l'HT n'y peut rien

oué enfin si il faut du dual core pour pas être emmerdés par msn... vires msn

Le_noob> Meme sans HT ça marche très bien. Tu peux ajouter FF et Winamp à la liste ça marche très bien aussi.
Par contre si tu lances un scan antivirus pendant que tu joues, ça va ramer
Et pas sur que ça reste bien fluide avec un dual-core vu la solicitation du DD.

ah merde, donc si j'avais un p4 ce serait pas mieux

+1000
 
l'
ht est bien que dans certain cas

Ce qui me saoule ce sont les micro saccades dans quake3 quand y à le moindre truc en arrière plan. Et même si je tu tous les porcessus le problème subsiste. En faite faut que je reboot chaque fois que je veux lancer Q3.
 
En même temps je m'en fou je ne joue plu. Mais je trouve qu'à l'heure actuelle c'est vraiment le truc le plus désagréable.

Le problème est donc ailleurs.

 
quoi comme truc qui te fait saccader ?

Emule  
Mais c'est génant que pour quake3, pourtant je pense pas que quake fasse des accès disque une fois une map lancée. Donc y a pas de conflit avec emule qui voudrait accéder tous les 2 aux disques.
Je pense que l'HT pourrait être bien.

ha oué Le_noob spa pour rien
et t'as des micro saccades quand tu joues sur un internet ou en local ?

Des commentaires sur les specs officielles de la XBox 360 ? on savait déjà à peu près tout mais ça confirme que ça semble être le monstre de puissance attendu. Le seul truc que je trouve un peu en retrait, c'est la RAM (comme d'hab). 512 Mo partagé ça me parait limite, ça équivaut à ce qu'on trouvait dans un PC haut de gamme il y a 2 ans (en comptant la mémoire centrale+mémoire video et la place occupée par le systeme) et ça limitera pas mal les jeux à venir . La bande passante me semble légère aussi, 700MHz (350MHz DDR j'imagine) partagé entre 3 core PowerPC à 3,2GHz et un R500 qui doit demander une BP monstrueuse pour pouvoir exprimer toute sa puissance c'est vraiment très léger, même si sur un bus 256bits
 
 
http://www.gamekult.com/tout/actus [...] 40875.html