Y a pas de bonne sous cat pour ce genre de questions
 
je cherche la fonction Direct3d, n'ayant pas trouvé mon bonheur dans les caps Direct3d, me permettant de trouver le nombre d'unités de texture fixes d'une carte graphique, accessibles en une passe dans un pixel shader.
 
Je sais le faire en OpenGL via l'appel à la fonction suivante :

 
Sur ma 9800GTX, cela me renvoie 4, ce qui est la réponse correcte (dans un shader, il y a bien 4 unités de texture accessible, cf http://www.hardware.fr/medias/phot [...] 018449.gif ).
 
Dans les caps D3D, il y a les options MaxSimultaneousTextures et MaxTextureBlendStages, mais qui ne sont pas les bonnes valeurs (et pour cause, sur la même carte, ca me renvoie 8).
 
Bref, après un dump de toutes les caps D3D, je n'ai pas trouvé d'équivalent à cette info toute bête... qui m'est indispensable pour des raisons d'optimisation.
 
Quelqu'un aurait une idée ? Merci

Up ?

Je voudrais pas me retrouver à trimballer un .exe en OpenGL qui file l'info à mon .exe DirectX

Me dites pas que chai pô possib'

Je perds pas espoir J'ai toujours rien trouvé de concret.

pitié

C'est une très bonne question. Si dans les caps tu as pas trouvé ce qu'il te fallait, je t'avoue que.....
Pour le hardware moderne, je sais pas trop si ça aurait toujours un sens

Ben malheureusement pour moi ca en a un... Pour la série GeForce 9, dans le pipeline "fixe", tu as 8 unités de texture dispos pour ton multitexturing (de mémoire, c'est pitêt 16, mais je pense pas), mais 4 en une seule passe par shader core (évidemment, tu peux en adresser beaucoup plus en plusieurs passes). Sur la série GeForce 10, tu en as 8 en fixe, 8 par shader core.

Sur la série 10, je fais bien plus chauffer avec 8 textures qu'avec 4 évidemment. Sur la série 9, je fais plus chauffer avec 4 textures qu'avec 8.

De mon point de vue, sans cette info, le shader perd beaucoup d'efficacité. En gros, les unités me fournissent l'info, mais en deux passes (i.e. si j'ai 4 unités mémoires dispos par unité d'exécution shader et que je travaille avec 8 textures, elles vont le faire en deux fois, mon shader va se tourner les pouces, bref, y a du temps GPU gâché).

En OpenGL, c'est vite réglé. Alors oui, c'est vite réglé avec un petit .exe OpenGL que se trimballerait mon programme d3d, ce genre de trucs, mais je voudrais faire propre Ca m'étonne que ce soit pas dispo

J'allais dire:
 
----------------------------------------------------
 
Je pense que l'idée ce serait de rendre l'option visible à l'utilisateur (j'ai pas regardé si c'était déjà le cas), et d'avoir une passe de profilage de ton shader de chauffe en regardant le point crête de fillrate via la Query de bande-passante:
 
http://msdn.microsoft.com/en-us/li [...] S.85).aspx
 
En terme de recouvrement texture/math, c'est la variante qui a le plus de textures sans avoir le FillRateUtilizedPercent qui s'écroule, qui devrait chauffer le plus non en toute logique ?
 
----------------------------------------------------
 
Mais je sais pas si ce serait valable. (Et si les drivers reportent un truc exploitable au niveau de la Query)

T'as demandé à Tridam ce qu'il en pensait ?

 
Je vais essayer avec ca voir ce que ca rend... le blem, c'est que cela retarde d'autant l'exécution de l'appli, et dans un environnement overclocké, la détection d'erreur doit s'enclencher le plus rapidement possible... et justement, mettre en place ce genre de mesure interfère.
 
Tridam ?

Pour moi un tel profilling qui cherche le combo nombre de textures/FillRateUtilizedPercent maximum, ça peut prendre une centaines de frames.  
 
(genre 1 frame de precachage et une frame avec Query par cas)
 
Enfin à tester je me suis jamais servi des Query statistiques, donc je sais pas leur qualité d'implémentation.
 
Enfin je dis ça, si ça ce trouve c'est une mauvaise idée, mais avoir un shader de chauffe auto-adaptatif en se basant sur les stats de rendu ça peut être sympa.
 
Tridam, Damien Triolet qui fait les tests 2D-3D pour hfr.

Je suis bête:
 
http://msdn.microsoft.com/en-us/li [...] S.85).aspx
 
Donc y'a plus qu'à monter le nombre de texture jusqu'à avoir du 50:50. (J'aurai tendance a penser que le point de chauffe max doit être avec le temps math très légèrement supérieur au temps mémoire, histoire de pas avoir les unitées maths qui bullent)

Je pensais que l'info allait être rafraichie en termes de secondes... effectivement, en nombre de frames, c'est tout à fait acceptable. je vais y jeter un oeil J'espère que coté ATI ca a été correctement implémenté

Effectivement, ca peut être une bonne idée. Je vais creuser les résultats renvoyés par les querys en question.

Si les résultats renvoyés ne sont pas cohérents, je le contacterai Merci pour les infos, mister

Effectivement, le 2nd moyen est + efficace

J'ai jamais joué avec les Querys de stats, donc je peux pas te garantir que je t'envoie pas sur une voie de garage avec des orties, mais ça peut être pas mal

Je vais essayer, j'ai une ATI et une Nvidia sous la main, en croisant les doigts... Et comme j'ai déjà les shaders avec plusieurs textures que je peux modifier à volonté...

D3DQUERYTYPE_VERTEXTIMINGS => Not supported
D3DDEVINFO_D3D9BANDWIDTHTIMINGS => Not supported

le tout sur Nvidia GeForce 9 drivers à jour

Dommage, c'était une bonne idée

Rahhh
 
exact: http://developer.download.nvidia.c [...] rguide.pdf
 
Bon bah, faut revenir sur les caps, mais si y'a pas ce que tu veux
 

 
Ben dans les caps, j'ai :
 
MaxTextureBlendStages
    Maximum number of texture-blending stages supported in the fixed function pipeline. This value is the number of blenders available. In the programmable pixel pipeline, this corresponds to the number of unique texture registers used by pixel shader instructions.  
 
MaxSimultaneousTextures
    Maximum number of textures that can be simultaneously bound to the fixed-function pipeline sampler stages. If the same texture is bound to two sampler stages, it counts as two textures.  
    This value has no meaning in the programmable pipeline where the number of sampler stages is determined by each pixel shader version. Each pixel shader version also determines the number of texture declaration instructions. See Pixel Shaders.
 
L'un et l'autre ne correspondent pas (l'un est le nombre de registres, l'autre le nombre d'unités dispo dans le pipeline fixe, hors shader).
 
Il me manque la troisième info : le nombre d'unités dans le pipeline programmable.
 
Je vais finir par passer par l'OpenGL. C'est une info de base, certes, mais c'est moche quand même, faut l'avouer

Le prob c'est que les caps D3D exposent les limites d'utilisation, pas la topo physique du GPU. (Dont la description peut se retrouver obsolète dans le temps)