Reprise du message précédent :
Fausse joie, le blem ati est encore là

courage ... la force est avec toi

 
Car perso, à part faire fumer les downloads ou le matos...

Ben faudrait qu'on m'explique pourquoi le même shader, compilé avec le même profil (et utilisé carrément en tant qu'assembleur) marche farpaitement sur Nvidia, et pas sur ATI.
 
Franchement, j'en perds mon latin. Ca m'éneeeeeeeeeerve.

question con .... les 2900 c'est pas celle qui ont un bug de shader justement ?? le meme qui est passé sur les 38xx et qui n'a ete corrigé que sur les 48xx ??
 

RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH

le crie d'agonie d'une ATI qui vient de passer par la fentre ????

Non, mais là non, c'est pas vrai, j'hallucine, j'hallucine.

Après avoir tout essayé, entre les uniform, les const, les shaders précompilés, les profils divers et variés, les variables globales, les lookup textures en dehors de la boucle, les pilotes et DirectX updatés, bref, 6 heures de taff, voilà la solution.

Attention, pour la compréhension, niveau de C disons... allez, 1 jour d'initiation requis.

Ca :

Ca marche sur Nvidia. Ca marche pas sur ATI (HD2600, Catalyst 8 ou 9, rien à foutre) quand on utilise 8 textures.

Ca :

Ca marche partout, no problemo.

MAIS C'EST QUOI CES COMPILOS DE MERDE

c'est tout ?????????    
 
si tu avais pas perdu tant de temps la dessus ca serai drole

Oui, c'est tout.
 
C'est triste.

Ça ne fait pas tout à fait la même chose là, puisque le premier, i part sur un indice de 0 et sur le second i termine sur un indice de 1 et non 0 (de même pour maxloop qui ne termine pas au même indice dans la première boucle que l'indice de départ de la seconde), non...?
(je ne suis pas trop codage, je suis à des A.L. de ton niveau, je dis ça juste au cas où... )

j'ai trouvé dès infos , apparement c'est les unité ROP ( pour l'AA) qui sont bggué sur le R600 et derivé ainsi que sur la generation suivante  
 
je sais pas comment tu utilise les unité mais surveille ca

 
ici, je m'en fiche, ca fait le même nombre de boucles (il ne me sert qu'à ça).

 
Tu peux me filer un lien ?

Oki doki.

 
qlq infos ici  
http://www.hardware.fr/articles/67 [...] 00-xt.html
 
je trouve plus la review d'archi complete que j'avais lu a l'epoque  
 
qlq autres infos ici  
http://www.matbe.com/articles/lire [...] /page5.php
 
ca donne pas mal d'info sur comment ca marche "sous le capot"  
par ex les 4 unité de texturique seulement qui sont peut etre en parti responsable de tes merdes

 
Est-ce que le reference renderer pose des problèmes ?
Est-ce que/comment le code réutilise i a certains endroits ?
 
Je sais que chez Ati il a fallut faire des compteurs de boucles avec des float a certains moments (hinhin)

 
Oulah ça c'est du compilateur en bois  

Reference renderer : je viens d'essayer, y a rien qui tourne si je balance un DXUTToggleREF Il aime pas les render to texture et co ?

Le code n'utilise pas i dans la boucle : c'est bien ça le pire dans l'affaire. Si tu veux ma boucle "dans l'esprit", pour mon fragment shader, c'est ça :

for (int i=0;i<maxLoop;i++)
 OUT.color += float4(0.01f,0.01f,0.01f,0.01f);

Evidemment, le float4 est un lookup de texture avec pas mal d'opérations matheuses dedans, mais ce qu'il faut retenir des opérations dedans :

• +, -, pow, cos, ce genre de fonctions matheuses "classiques"
• tex2d
• Aucune référence à i. Juste à la couleur de sortie (OUT.color), aux coordonnées de texture (texcoord) et rien d'autre.

Le shader en sortie fait dans les 150 instructions. Pas de quoi fusiller un dromadaire.

et 0 branching bien entendu, je vais pas m'amuser à faire du conditionel dans une boucle pour faire du burning GPU.

Le bug n'arrive que lorsque j'utilise 8 textures sur ma HD2600 mobile (évidemment, le caps me renvoie MaxSimultaneousTexture à 8, et MaxBlendStages à 8). Si je me limite à 4, no soucÿ.

Je vais mettre ca sur l'autel du voodooisme ATI je crois.

 
Merci pour les infos

 
Ca devrait être un bug ATI, mais tu est sur le runtime de debug ou le release ?
 
le debug peut te remonter moultes infos interressantes en temps réel. (avec debugview ou la fenêtre de sortie de visualstudio)
normalement, il faut que ton code fonctionne sur le reference renderer.
 
si tu toggle de renderer, j'imagine qu'il faut détruire et récréer les rendertargets que tu as peut-être crée à la mano.
 
tu utilise le framework de microsoft ? (je l'aime pas, alors je peux trop te dire )

runtime de release Je peux pas installer visual studio sur le PC du boulot, je me ferais tuer.

Mouais pour le software rendering, ca vient peut-être du fait que je fonctionne en RHW... il doit pas aimer.

Ouip, j'utilise DXUT

Normalement, le reference renderer doit marcher dans toutes les situations.
les vertexs prétransformés sont courants pour tout ce qui est HUD, post-processing du framebuffer, donc je vois pas pourquoi le ref déconnerait.
 
Le plus simple est démarrer sur le ref direct plustôt que de faire un switch une fois toutes les ressources crées. (rendertargets)
 
Bascule en runtime de debug, et ouvre un debugview (sysinternals), tu vas voir le D3D va te causer

Merci pour les conseils bjone Ca fait du bien de voir que je suis pas tout seul

Le bug ATI étant résolu, la béta devrait s'améliorer au fil du temps. Fin de cette semaine / début de semaine prochaine, la puissance de burn devrait atteindre son plein potentiel, maintenant

si tu est tout seul ..... a comprendre ce qu'il dit    
 
bon en attente de la nouvelle beta   ....

J'espère que la détection d'erreurs sera potable par contre
 
Là, c'est la loterie

oeil bionique demandé ???  
 
question con .. tu a moyen de faire une comparaison d'image entre elle ?? genre faire une soustaction de couleur entre le resultat du test et l'image de reference, comme ca tu obtient juste les pixels qui bug  
et la tu additionne ca a une image qui sert de buffer, la couleur du pixel incremente de 1 a chaque fois qu'un bug apparait dessus  
 
au final ca te donne une "carte" des bugs avec leur frequence ??  
 
 
enfin c'est une idée en l'air repompé d'une vieille methode alacon(TM] que j'utilisais sur des tableaux de variables, c'est pas forcement pertinent ou meme faisable  

Oh, je fais pire que ca.
 
Mon résultat final est une texture noire, quand y a une erreur, la couleur devient blanche... et le reste (ca disparait jamais).
 
A terme, le CPU les comptera, vous inquiétez pas
 
Je dois en fait jouer avec les textures d'entrée pour optimiser les calculs et obtenir un résultat avec détection d'erreur potable. Et évidemment, c'est quand on est au taff, avec pas forcément beaucoup de trucs à faire, qu'on se pose, qu'on pense au truc, que fusent les bonnes idées
 
Le problème : faut se remettre aux maths. Et là, on se dit qu'on était bien con, quand, au lycée, on disait "les maths, ca sert à rien". ben mon vieux, que j'étais con...

je sais pas si je suis clair .. j'explique  
 
image A : resultat du test  
image B: image fixe , resultat attendu
 
image C = image A - image B ( soustraction de couleur pixel a pixel )  
image C : defaut du test  
 
image D = image D + image C ( addition de couleur pixel a pixel )  
image : carte des bug a afficher une fois le test fini ( sauvegardable ?? )

C'est déjà ce que je fais (tu peux guère faire autrement de toute facon), à ceci près que tu peux te passer d'image C.
 
Dans mon vocabulaire à moi ( que je trouve plus compréhensible, va comprendre pourquoi... ptêt parce que c'est le mien) :
Tu as trois images : un résultat de référence, un résultat de travail, un résultat de "bugs".
 

• passe 1 : je déroule l'algo : j'obtiens le résultat de référence
• Passe 2 : même algo, j'obtiens le résultat de travail. Comparaison des deux résultats (travail et référence) : si il y a une différence, on marque l'endroit dans le résultat de bug en mettant le point à blanc.

Ce qu'il ne faut pas perdre de vue, c'est que transférer une texture par le port PCI-E est EXTREMEMENT couteux. Mais couteux de chez couteux de chez couteux. je veux l'éviter au maximum.
 
Si je dois afficher une texture, pas de problème. Si je dois compter, faut passer par le CPU. Donc transférer la texture pour que le CPU l'analyse. Donc ralentir tout le processus. Donc perte d'efficacité dramatique.
 
Ce que je veux éviter

a OK tu fait 2 passes seulement,mes images C et D servent a garder traces de N passes "sur place"  
 
a l'epoque j'affichais ca en 16 couleurs pour "voir" les evenement dans ma matrice après ~100 cycles de calcul
a la couleur je savais combien de fois le test etais sorti positif  
 
si tu fait comme ca c'est le GPU qui additionne donc pas de retour au CPU et tu n'as a raptrier la texture qu"une seul fois a la fin  
 
 
 

 
Ca dépend de ce que tu appelles "passes". Dans le vocabulaire classique 3d, actuellement, j'en fais 100. Chaque passe ayant une complexité variable (j'ai dit que c'était matheux). Mais ca va évoluer.
 
Oui, mais oublie pas que je suis en environnement hétérogène. Et que je suis pas à 1FPS. Disons que sur OCCT GPU "old school", le transfert de la texture du GPU vers le CPU te faisait perdre 10~15% d'efficacité, environ. Et encore, on était à 20FPS grand max.
 
Là, je vais limiter le test à 10FPS, j'ai remarquer que c'était là que ca chauffait le + sur ma GTX285.
 
Faut que je découvre l'équation matheuse qui détermine "complexité de la scène => FPS" maintenant. en mode grosso merdo. Ava pas être simple.

oki ...
en gros travailler sur le GPU c'est une usine a gaz infame quoi ....

Ca dépend comment tu vois ça, mais oui.
 
Ce que je peux te dire de mes conclusions personnelles (mais pas forcément toutes vraies):

• OpenGL passe mal sous vista (problèmes coté SLI, mode fenêtré, etc)
• Direct3d c'est bien mieux, mais bien bien plus complexe et bien moins documenté sur le web
• Les drivers Nvidia se démerdent pas trop mal, mais gèrent mal le WDDM coté mémoire (ils te disent "OK" quand tu alloues toute la mémoire, mais te font crasher vista si tu en alloues trop, les 128 derniers Mo de ma carte sont d'une lenteur à pleurer)
• Les drivers ATI ont des bugs pourris (specs mal respectées, bugs dans les shaders bizarres, comportements étranges, bref, franchement, je fais des trucs simples, et à chaque fois que ca marche, je pense à un miracle plus qu'autre chose...)
• Faut aimer les maths (bon, ca surprend personne)
• Faut aimer dénicher des infos dans des coins débiles
• Faut aimer les contournements débiles (t'as vu le coup de ma boucle à l'envers pour le bug ATI ?)
• Faut ne jamais perdre à l'esprit que tu travailles dans un environnement TRES restreint (pas de random ( ), pas d'entiers dans tes textures etc)

NVIDIA c'est aussi ceux qui réussissent a avoir leur carte pre-DX10 ~10x plus lente sous Vista que sous XP.

Franchement, d'après tout ce que j'ai vu, j'ai toujours eu un comportement bien plus sain avec mes Nvidia que toutes les ATI sur tous mes dev 3d.
 
Le coup de la boucle dynamique là le prouve par A+B, limite...

Salut

Salut

Salut